Jari is a dynamic and enthusiastic project management professional. He has spent the last decade on project management using numerous different frameworks; onsite, nearshore and offshore project management using waterfall, agile, hybrid, as well as agile scaling models. Jari has also been designing support models, building quality processes, and doing wide variety of consulting and training on both technical and management domains. He is interested on management theories, evolution of strategy processes along the agile transformation and coaching people on various domains and subjects.
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.
- 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
- 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
- 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
- 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)
- Don’t believe your need to do large projects or multisite and offshore development.
- Focus on creating great products with a small number people, team of extroardinary multi-skilled and co-located developers.
- 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”.
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.
- 20-50% increase in productivity
- 30-75% faster time to market
- 50%+ defect reduction
- Happier, more motivated employees
- 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.
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.