|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When we take on a project, we like to hit the ground running. We seed the project with an experienced team, ready to begin executing immediately on your product vision. As the vision grows and changes, our team adapts. As you hire your own development team, we’ll weave them into our team, teaching them the code base, and all our techniques as well. We want to make sure that when you’re done working with us, your team can move into the next phase of development with confidence, and keep things running smoothly. Once your team is self-sufficient, we can weave our developers back out, and move on to the next engagement. You’re always welcome back, for that next new feature initiative, to add a little extra horsepower, or to help out with some thorny issue down the line.
One thing that’s special about us is that we can vary the team size on demand. During the early stages of development, startups will often have big fluctuations in workload. We can ramp the team size up or down, depending on development objectives and financing constraints. We can develop at full speed for a week, a month, or a year, then stop on a dime—and stop burning capital—and stop for as long as it takes for the client to close a funding round, or get some traction in the marketplace, or decide on the next round of features. Our clients are done with us when they decide they’re done. Their business goals and product needs are always in the driver’s seat.
We strive to be a strategic partner for our clients. We are not an outsourcing firm but instead work to get our clients self-sufficient. We believe our approach offers a unique balance between the short term need for execution and the long term need of sustainability.
Pivotal has been using and improving agile development methodologies since the very beginning. The particular flavor of agile process Pivotal favors is called Extreme Programming, or XP. It combines Test-Driven Development, Pair Programming, short iterations, and Continuous Integration, to radically improve software quality and flexibility while reducing time to market and cost.
When we build applications, we start by writing tests for every feature we implement. Only after the tests are in place do we write the code that implements those requirements. The rhythm of writing a failing test, and then making it pass by implementing the feature, ensures complete test coverage, and a more reliable product.
When we check in our code, a Continuous Integration server checks the code out again, and runs all the tests, to make sure that the code will work correctly in production. When the build breaks (i.e. when tests fail in the Continuous Integration environment) the focus of the team shifts to fixing the build, ensuring that defects don’t creep into the codebase. We continually deploy new features to our demo environment, so that the customer can see the new features in a realistic setting, and immediately begin play-testing them to make sure they’re what was intended, and that the actual behavior is desirable.
We keep our development cycle to one week iterations. This keeps features from drifting out of control, and gives quick feedback on each new feature being developed.
One of the first things you’ll notice about us is that we pair program. This means that two developers sit down together at one computer, and write code together. Perhaps surprisingly, two developers can produce more and better code more quickly by working together this way. Why is that? There are a number of reasons. For one, pair programmers spend more time doing productive work. They are constantly engaged, refining ideas, and they discard bad ideas quickly, saving projects from poor choices that can cost weeks of work down the road. Beyond that, with enough eyes, all problems are shallow. If we look at what a typical developer spends time on, much of the time spent is spent stuck on relatively trivial problems, often ones that same developer would breeze through on a different day. When two developers collaborate, one can press on when the other gets stuck, and the flow is never broken. Progress is made consistently and rapidly. We’ve found it the best way to work, and use it on all of our projects, particularly the ones we pay for ourselves. The quality of the code produced is superior, and the time spent to produce it is shorter.
Developers are most effective when they collaborate full-time, to bring more perspectives to bear on the problem at hand. To this end, we always deploy programmers in pairs. How many pairs to choose is up to you, the customer, but we wanted to provide you some guidance as to how to look at the decision.
One pair is the smallest team you can choose. Typically this is the right team size at the beginning of a project, when the team is just getting up to speed on the particulars of the application being developed. One pair is enough to do solid work, but as the project moves forward, it is useful to change up who pairs with whom. With one pair, there is only one pairing. With two pairs, there are 6 possible pairings, and the team typically produces about twice as much work. Three pairs offers more pairings, and typically produces just under 3 times as much work as a single pair, but can start to suffer from the inability to parallelize tasks. This often depends on the scope of the particular project, and how well the work can be segmented. With more than 3 pairs, communication overhead starts to become a cost, but when time to market is the key consideration, larger teams, as large as 5 pairs, can make sense, particularly for short stretches when the needs of the project are sufficiently segmented. At 5 pairs, you should expect to add one additional full-time person in a leadership role to coordinate the efforts of the team.
It’s the development team’s job to work with the customer to break down the features into small, user visible units of work, called Stories. These stories are the key to keeping development focused on visible, tangible, customer value. Once the feature breakdown is complete for the next set of features, the development team can estimate the effort involved in completing each story.
Our main planning tool is Pivotal Tracker, a web application we developed in-house that embodies many of the principals above. We use it to keep track of stories and estimate them, and to track releases and deadlines. It is used by both developers and the customer to keep track of where things are in development, and to keep development focused on the highest priority features at all times.
We use a simple, point-based system for story estimation, where the points are measures of relative complexity. Developers are much better at estimating the complexity of a problem than they are at estimating the duration of work to solve that problem.
Velocity is a measure of how many points a given team completes in a given week. Experience has shown that a given development team will work through a fairly consistent number of points on a weekly basis, and this strong central tendency means that velocity for a team becomes very predictable after the first two to three weeks of development. This will give you a very early indication of how long a given set of features will take, and give you the visibility to make informed choices about what features you choose to implement.
As the customer, you play the key role in the development process. Your involvement with the team shapes what gets done, when. You determine the backlog of features to be developed, and you determine their relative priority. You make those decisions informed by the relative cost of the features in your backlog, since you can see at any moment what the relative cost of those features is, in terms of points. Pivotal Tracker lets you rearrange stories to your heart’s content, and always keeps you informed of the impact your choices make on the schedule, and by extension, on cost. One thing you may be surprised by is how our development teams respond to changes in priorities. They respond by doing whatever it is you asked them to do, in whatever order you choose. They are confident that they’ve exposed the cost to you, and they trust you to make informed choices about what the highest priority is. For many of our customers, this is a revelatory experience. For us, it’s just the sign of a healthy relationship between the development and product teams.
As developers work on stories, their current state is logged in Pivotal Tracker. When work on a story is completed, and all tests are green, the story is checked into source control, and marked finished. Several times a week, the current code is pushed to a demo server for story acceptance, and it at this stage that credit for completion of the story is granted (or withheld.) When a story is pushed to demo, it is ready for the product manager to accept or reject. A story isn’t done until you have seen it working in a live application. That application is deployable at any time.