Software Development: Agile, Team Size and Dynamics

Interested in a free 25+ eBook on the 7 Wastes? Please DOWNLOAD HERE.

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

search terms for this article:

agile team size, agile development team size, software development team size, development team size, software team size, ideal development team size, skyrim dev team size, amazon development agile, team size pizza, amazon agile development, agile development and team size, agile team dynamics, size of software development teams, perfect team size for app development, team size agile, software development team dynamics, pizza team developer, pizza team size, product management team size, software development defintion of a large team size, size of 2 pizza team, size of an Agile development team, sizing agile team, size of developer teams, size of project in agile methodology, size validation development team, sp development team size, WHAT SIZE TEAM IS NEEDED FOR DATABASE DEVELOPMENT, what size team is appropriate for database development, what size is dev team, windows development team size `, What is the appropriate size team database development, typical team size for agile, typical software team sizes, two-pizza team amazon mean, transition team size for it development, software development team sizing, team size for agile sw teams, team size best practices for software development, team dynamics agile, team and size agile, suggestable agile developement team size, space planning for agile development teams, What software development process does amazon use?, Optimal sw team size, amazon software developer hours, amazon developers agile, agile variable team size, agile teams size, agile team szie, agile team size minimum, agile team grootte, agile optimum team size pizza, agile methology and team dynamics, Agile manifesto, agile dynamic team size, agile development size of team, agile development amazon, agile dev team size, agile best practices team size, A3 report Agile software development, amazon software development process, average size of a software development team, optimal size of agile team, managing software development non-engineers, limiting the size of the software project team, it application development how is team size determined, ideal team size in software industry, ideal size for software teams in india, how to size the initial team in agile, how decide the team size of software team, how big are software teams, growing software development team size, flipkart and agile software development, firefox development team size, define software team dynamics, capacity for software team, average team size in agile, average size of software development team, 2 pizza plate amazon

Related Articles: