What’s the point with Scaling Agile?

If you are unfamiliar with Agile or still don’t see benefits of Scaling Agile, this is the blog to drop by. This blog is a hidden sub-section of the SAFe vs LeSS shootout.

Why Agile

Moving an enterprise (from waterfall) to agile is a huge task. The organization and culture must change. However, it is obvious that the waterfall-type process doesn’t work and therefore we must face the change. In agile way, we run fast delivery of the highest priority requirements, followed by fast feedback and learning. Some cynics ask why waterfall wouldn’t work. Well, here’s why:
  1. Don’t assume you can develop a new and innovative system based on fixed requirements and schedule. It is impossible to predict a schedule for large software system deliver. If you do waterfall development with tight schedule, the team haven’t started to code yet, when you hit the deadline. In agile development, the system is up and running from the start. You learn fast and fail fast. Reference: http://www.infoq.com/resource/articles/scaling-software-agility/en/resources/ch02.pdf
  2. Don’t assume you or your customer can understand requirements up front.You can’t define requirements before-hand. Intangible system like software will present its full existence only through functionality. And when you see and feel the functionality, it usually needs tuning. Light bulb of Edison, hoover of Dyson, iPhone of Jobs, Amazon book store, they all are results of endless rounds around Deming cycle. https://hbr.org/2008/05/innovation-and-iteration-frien
  3. Don’t assume you can manage the change. Business requirements change during defining the requirements. Throughout the requirement definition process one starts to understand better the system and its optimal functionality. Requirements do change during the system implementation. Change will be constant and can be managed only with small increments. https://hbr.org/2007/11/a-leaders-framework-for-decision-making
  4. Don’t assume the system integration is ever easy. Putting together independent code modules will bring the overall system architecture to alive. Only then can you validate the functional and non-functional features of the system. Software integration is harder and slower the more you postpone it. We have DevOps trending for a reason. All the non-integrated code is waste; we need to get rid of. It is inefficient, expensive and risky to store large amounts of non-integrated code. https://gofore.com/en/the-sweet-spot-of-devops/

According the 11th State of Agile report, companies benefit from agile by being able to manage changing requirements, achieving higher team productivity, gaining improved project visibility, better time-to-market and higher team morale.

Why Scaling (Agile)

Scaling answers on a question how to build large and complex software system faster, smarter and more transparent ways than waterfall could ever provide. In short scaling is iterative development in a large organization. Agile Scaling is about learning to use interative practices on Enterprise level.
  1. Don’t believe your need to do large projects or multisite and offshore development.
  2. Focus on creating great products with a small number people, team of extroardinary multi-skilled and co-located developers.
  3. Break the rules 1 and 2. Sometimes you need to create so big/complex/business critical deliverable that a single team cannot achieve the goal in the given time frame. Stuff that is listed for example in SAFe and LeSS case studies.

In Agile Scaling, the individual teams still work in Scrum, Kanban or whatever mode. The “scaling” part answers on the question how coordination between dozens of such teams is being handled. You need autonomy and alignment. Autonomy means that teams are Agile. Alignment means that all the teams work towards a common goal. Nobody suboptimises in the name of a team. Henrik Kniberg puts it beautifully “Like a Jazz band, each musician is autonomous and plays own instrument, but still listen to each other and focus on whole song together”.

Accoring the 11th State of Agile report the greatest challenges with Agile remain on old organizations adopting agile culture. According the report the most common (63%) challenge is “company philosophy or culture at odds with core agile values”.

Two very different approaches for scaling Agile: SAFe and LeSS

There exist numerous scaling frameworks like DAD, RAGE, Enterprise Scrum and more, which are being comprehensively compared in ASK Matrix. However, in Finland we have the most experience on SAFe and LesSS. They represent different ends of the Agile scaling. LeSS represents build-up and SAFe tune-down approach.

Tune down means that only parts of the framework are deployed, build up means that the framework is being created case by case

SAFe

Accoring the 11th State of Agile report the most common scaling framework is SAFe. SAFe provides power of agile while leveraging systems thinking and Lean product development. SAFe brings a new better program process, explained in familiar terms. SAFe is easily understood by the traditional management. SAFe works on the same domain as other project and program management systems, adding Lean/Agile methods. SAFe revolves heavily around program execution.
SAFe whitepaper states that benefits from documented case studies include:
  • 20-50% increase in productivity
  • 30-75% faster time to market
  • 50%+ defect reduction
  • Happier, more motivated employees
11th State of Agile Report shows where Agile Scaling is heading

LeSS

LeSS reinvents management by scaling Agile and Scrum. LeSS shows how to cope with complexity by creating simplicity. LeSS is deliberately incomplete and leaves rooms for situational learning. LeSS doesn’t offer apparently safe and disciplined approaches to offer a comforting illusion of predictable control. LeSS concentrates on the minimal essense required when scaling, like continuous attention to technical excellence and continuous experimentation. LeSS is scaling Scrum without adding layers or processes. On the contrary, it simplifies the organization radically – more with less. The teams take care of the technical coordination. The product owner works with the market and with the teams. The managers become coaches or product owners. LeSS is a framework that must be adapted to meet the particular needs. LeSS does not provide fixed answers, but provides a starting point for understanding the deeper principles.
LeSS case studies provide examples of LeSS adoption and list also some benefits like:
  • Nokia Networks: The previous product where we used a sequential life cycle model took twice as long to develop, and the sequential life cycle and single-function teams and component teams would not have allowed us to make the major change in direction that we did. LeSS gave us that organizational agility.
  • John Deere: Teams were able to give a useable realistic forecast. Within half a year, the teams were able to plan and forecast delivery dates reliably upfront. Massive quality problems were fixed and teams became focussed.

The Beginning

Now, when you’ve been converted into an Agile believer, you are ready to learn whether SAFe or LeSS is the best way for Scaling Agile. Please proceed to SAFe vs LeSS Shootout.

 

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *