What's the point with Scaling Agile?

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.

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.

SAFe

• 20-50% increase in productivity
• 30-75% faster time to market
• 50%+ defect reduction
• Happier, more motivated employees

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.