PrintAccording to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity:

“Consistent with last year, most respondents adopted agile practices to accelerate product delivery (59%) or enhance their ability to manage changing priorities (56%). However, in 2014, productivity (53%) has moved into the top 3, outranking last year’s #3 response – improved IT and business alignment.”

This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I put my waterfall hat on and read the twelve principles that support the Agile Manifesto from a traditional stance. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

For example, a project that is managed with a traditional waterfall process has big upfront design and is transitioned over to a team that knows they have six to nine months to produce the software. At the beginning of project, the teams are more relaxed and moving slower. The intensity level and sense of urgency is a lot lower. Then as time goes on – three months, six months – the teams and management start to miscommunicate and stop being as diligent about status meetings. Near the end of the project suddenly the pressure and a bit of panic set in. Teams and management are panicking because now they have to scramble to get the software finished. Maybe this is what creates the perception with waterfall that your teams are not constantly producing software; there’s an ebb and flow.

Waterfall projects start out with very low intensity. By the end of the project the intensity is extremely high and teams are burned out because they’re working crazy hours. The teams are producing low-quality code because they have to rush and the code isn’t being tested. The low quality work damages the team’s pride, which decreases morale and can lead to turnover.

The benefit of going to agile is that the team maintains a constant level of intensity and consistent working hours, which in turn empowers the team to produce beautifully working software at a constant pace.

So when people are saying “productivity,” what I think they really mean is “intensity.” If we’re maintaining a constant level of working hours, a constant level of quality and a constant level of delivery, teams are happier, they’re proud of their work and they enjoy going to work. This is super important because keeping good developers is really difficult. If good developers aren’t happy they can easily leave and go somewhere else. That’s why 26% of respondents to the 9th annual State of Agile survey said improving team morale was the reason they adopted agile.

That’s my take on why there is a perception that agile is more productive than waterfall. When I saw the 9th annual State of Agile survey, I was curious about why people felt that if they moved to agile their teams were going to be more productive.

Why do you think there’s a perception that if companies go agile, teams will be more productive?

State of Agile is a trademark of VersionOne Inc.

728x90-red-demo

Join the Discussion

    • bhupinder

      Based on what I have observed so far, productivity measured in function points per person month in agile projects is at least half compared to a waterfall project. The key reasons, I think, are:
      (1) in agile, the full team is ramped up upfront while in waterfall the team ramp up is slower (so the covered area, assuming the same duration, is higher for agile)
      (2) any delays in schedule result in a higher burn rate.

      This is not to deny other advantages, but cost/productivity does not seem to be agile’s selling point. I wonder if anyone has empirical observations to the contrary.

    • Paul Arrowood

      You raise a good point, and thank you for sharing!

      I coach my clients, and tell all my teams, never underestimate the value and effect provided through having focus. Many (most?) matrixed organizations present this grand illusion that they are delivering so much work to the business. Look at all of these wonderful projects we have in flight. As any ‘lean’ practitioner will tell you, true value exists when a product is delivered to the end customer. So work-in-progress holds little relevance when deriving value. It does, however, suggest whether you’re a great ball juggler–and most of us are not. Matrixing may work; I’m not the expert. But I know managing that many people and teams and differing (competing?) subgoals and personalities is difficult and generally not the best job for some technologist promoted into management.

      Agile cuts through all of that. Smaller teams with a shared sense of purpose, visible goals, access to decision-makers, and frequent feedback loops allow those teams to deliver what matters most, first. When you’re not spending time on the inefficiencies of the matrix, the juggling of resources, the multiple masters one must serve, and I could go on–you spend precious time on delivering value vs. waste, gold plating and features the customer doesn’t even want.

      I would think that contributes to this feeling of increased productivity.

      Curious what you and others think?

    • murugan

      Yes. Productivity rests in the mind set of the development team/vendor/management and not in the methods adopted (whether waterfall or agile). In order to avoid the ill effects of students syndrome (in waterfall method) consistent/regular delivery (in Agile) was suggested. At the same time over production is also not encouraged as the same may lead to team members paid holiday time during the working hours. So Waterfall or Agile method won’t make you more productive.

    • Mark Manta

      As its name states “Agile”, when there are changes in the stages of a project the team is able to adapt more quickly to them and incorporate them sooner into the develpment. Hence, eliminating some re-work later. Because there is better communication in Agile i.e. daily stand ups. Impediments are able to be addressed sooner and removed earlier. Thereby, increasing workflow and productivity.

    • Collin Carbno

      There are many reasons agile is more productive that waterfall. (1) Less work in progress , (2) less stuff done that is not needed ( typically something like 40% of requirements developed are never used in traditional project), (3) lower error rate with pair work (4) emphasis on excellence of design (4) emphasis on quality code and test driven development – lowering rework (5) sooner feedback from clients, discover design and oversight errors sooner, (6) constant integration (so teams don’t build stuff that turns out to be incompatible). (7) more excited team with higher cross training levels — thus more depth to handle sickness, illness, loss of team members, etc. and so on…..

    68 + = 72