Software Development: Agile, Team Size and Dynamics
I’ve long ranted about Amazon’s 2-Pizza Team, which is defined as the following: a team where the team size is no larger than 2 pizzas can feed. Amazon realized early on that in order to cut software development time, the solution was *NOT* to put more people on the project. What is required is a team, where the roles are defined and each member has the right skill for that role, and following a lean, agile, method — all focused on the customer.
Agile Methodology
Agile is a response to the well known issues in software development: rigid planning and nazi-like fidelity to original software requirements leads to customer needs not being met. Bottom line — software development is hard and things change. No prior methodologies focused on adaptation and customer needs, so Agile was created by several notable software gurus.
Alistair Cockburn, one of the Agile Authors explains Agile this way:
* individuals and interactions over processes and tools,
* working software over comprehensive documentation,
* customer collaboration over contract negotiation, and
* responding to change over following a plan.
While we value the items on the right in this list, we value the items on the left more. Processes, tools, documentation, contracts, and plans are useful. But when push comes to shove—and it usually does—something must give, and we need to be clear about what stays and what gives.
Relying on interactions between individuals facilitates sharing information and changing the process quickly when it needs changing. Using working software allows us to measure how fast we actually produce results and provides quick feedback. Frequent interaction between individuals compensates for minimizing documentation.
Customer collaboration means that all players—the sponsor, customer, user, and developer—are on the same team. Merging their different experiences and expertise with goodwill allows the combined group to change directions quickly so they can produce more appropriate results and less expensive designs. Contracts or project charters with the customers are necessary, but without collaboration, they are insufficient.
Working through producing a plan drives the team members to think through their project and its contingencies. The plan itself usually goes out of date within just a few days. Afterward, rather than focusing on the outdated plan, it is important to deal with the changing realities.
Some of Agile Methodology comes from the manufacturing world, specifically the Toyota Production System, but better known as Lean Manufacturing. The language of Agile has a Lean flavor, but with a software twist. I think it works well.
For me, it is equally fascinating to apply the principles of Lean to software. I’ve applied Lean in a manufacturing and operations setting at Amazon; Lean in a service or health care environment at Kaiser Permanente, in medical devices, and at other consulting projects. I’ve also developed software at Amazon and at other contractual gigs (I was on the project that was internally called “Fastrack”, which is essentially a customer receiving an order within 24 hours of ordering — have you ever thought how an order gets assigned to a fulfillment center, picked, packed, shipped and arrive at your door the next day? This order, of course, is mingled among 300,000 orders that are made daily at Amazon). I’m excited to see other innovative ways in which Lean is applied to software development and program management.
Team Size and Dynamics
At Amazon, there were six roles. If the project involved the fulfillment centers, then industrial or mechanical engineering would be part of the team; sometimes the Operations folks would be part of the team. It just depends, but there were six basic roles: Technical Program Manager, Software Development Engineer, Tester, Release Manager, Product Manager, and more Software Development Engineers.
This team model — the 2-Pizza Team — is incredibly effective at getting things done. The team size is small, interactions are often, and there was frequent circling-back to the customer’s needs and requirements.
As projects became bigger, then several 2-Pizza Teams were placed on it, but each team owning a certain portion. Interactions was also frequent between each team, though this wasn’t formalized — it just happened that way, based on my limited experience.
Software dynamics are often politically-charged, and full of waste. Have you ever experienced this scenario?
Boss: “Tell me, shmula, when do you think our project, the one with
the October deadline, will be done?”shmula: “Honestly boss, I think it won’t be ready until November.”
Boss: “Hmmm. That’s a bad estimate, a really bad estimate. I’m
afraid that won’t do. Try again.”shmula: “Uh, well let me see. October?”
Boss: “shmula, that’s a GOOD estimate!”
Often the problem stems from the wrong people estimating how long a software project will take. Sometimes, the experienced developers make the estimation but, more often than not, when the engineer gets under the hood, it usually takes longer than was estimated. When an engineer makes this estimation mistake, it’s expected. But non-engineers ought not be making these kinds of estimations.
Agile also responds to the above dynamic by the following:
* produce the first delivery in weeks, to achieve an early win and rapid feedback;
* invent simple solutions, so there is less to change and making those changes is easier;
* improve design quality continually, making the next story less costly to implement; and
* test constantly, for earlier, less expensive, defect detection.
Agile software development stresses quality in design. These methods are sometimes confused with ad hoc or cowboy coding because the design is done on an ongoing basis, in smaller chunks, as opposed to all at once and up front. Each agile method addresses quality in certain ways. For example, dynamic systems development methodology calls for a series of prototypes to attack unstable or unknown areas: new technology, new business rules, and user interface design. Scrum uses intense 15-minute daily meetings and comprehensive iteration reviews at the end of each 30-day iteration.
For anyone who has ever developed software or managed a software project, you know that software development is hard. Making reliable commitments and setting reasonable expectations is critical, but it must be balanced by an eye and focus on the customer’s needs. Small, quick, iterations follows the single-piece flow of lean and gets away from the batch-thinking that many American companies follow. Focusing on value (80/20 in feature set), managing the bottlenecks, and the value-stream and reducing waste at each step is critical to building quality software that meets the customer’s needs and in a timely way.
Blogged with Flock
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
[...] This is a testament to the Agile Method for developing software. At Amazon, we used a cowboy-scrum version which worked fine. But, I think doing things “by the book” often yields better results, provided that the method is tweaked to fit the company culture etc. [...]
[...] I was going through the Joel Reddit and after reading a very good article in the NY Times comparing development practices between Google and Yahoo, I came to another article talking about lean software development. As one that makes software and one that actually read (half) a book on the Toyota Production Method, the word “lean” triggers my interest when in the context of making products. [...]
[...] does this mean from an SDP delivery team perspective? For anyone who has worked on a front-office project, the concept of moving forwards will not be [...]
Leave a comment
Additional comments powered by BackType
Helpful post. How does the dynamic change (or is influenced) by working within a budget? Software development and deadlines are difficult, but they still need to fit into a budget. I know you could “drop” the low priority features to stay in the budget if development hiccups occur, but…we still wanted those features!