A common question amongst many large enterprise clients is how do we "Scale Agile". And most often than not these enterprises don't have the time and patience to work through the values of using agile methods and inculcating that within their organisation.
What they are really asking for is a shortcut way of spreading some agile practices within an average talent pool in the company with the hope that they might learn to deliver software better. And this is the very reason process frameworks like SAFe and others seem more attractive to senior execs.
Ironically though what might seem as a shortcut of adopting a framework in first place ends up burning more of the IT budget with minimal results within 3-5 years.
With an average talent pool, the problem of scaling agility soon becomes a problem of enforcing agility (pardon the oxymoron). Being prescriptive at a large scale requires a ton of micro processes and standards to be setup to manage the average worker.
SAFe talks about normalizing estimates across all teams at the very beginning by forcing teams to adopt 1 point as 1 day. This defeats a lot of benefits of point based estimation and relative sizing. Again in SAFe, teams are forced to sign up for objectives at the end of every increment planning of 2 months or so. This obviously does not take into account the nature of the work the team is doing. A team that cannot release something in 3 months ends up with weird looking objectives just to satisfy the organization standards.
Such standards are created to put some checks around the average talent pool who might be prone to wrong doings. A company even went to the length of running reports on story checkin commits to ensure that stories do not span multiple iterations. And then when there were hangover stories, people were asked to split stories accounting for partial, untestable work in the previous iterations.
Another company I worked with, was trying SAFe, and was forcing product owners to come up with a quantification of business value and time criticality so that cost of delay could be calculated. While core to product development, the essence of this whole calculation was diluted by the middle management of product owners who ended up making up numbers as a shortcut. Justification of the business value numbers ended up becoming more subjective and usually the loudest product owner in the room won.
These experiences clearly show that there is really no alternative to investing in hiring and nurturing good talent. While for execs at the very top, a scaleable framework with checks and balances might look very attractive, the middle management along with folks on the ground will find ways and means to work around these checks and never end up learning the real values.
While hiring talent is hard, it is equally important to nurture good talent, especially in IT where the market is highly competitive.
Design your enterprise towards continuous delivery of value. A lean enterprise should be able to build, measure and learn from the software they delivered and iterate rapidly towards maximizing business value. This is not easy, especially if you are a large enterprise. Reaching this goal will require hard work and changes within the organization that are beyond IT such as financial budgeting, performance reviews etc... Invest in hiring smart talent and then invest in your people to coach them on fundamental principles such as early feedback and failing fast and how core XP engineering practices and CD help achieve that.
Just scaling agile with a prescriptive process framework will be attractive in the short term but will not live the test of time for your enterprise. Don't give in to the temptation. Do the hard work.
What they are really asking for is a shortcut way of spreading some agile practices within an average talent pool in the company with the hope that they might learn to deliver software better. And this is the very reason process frameworks like SAFe and others seem more attractive to senior execs.
Ironically though what might seem as a shortcut of adopting a framework in first place ends up burning more of the IT budget with minimal results within 3-5 years.
With an average talent pool, the problem of scaling agility soon becomes a problem of enforcing agility (pardon the oxymoron). Being prescriptive at a large scale requires a ton of micro processes and standards to be setup to manage the average worker.
SAFe talks about normalizing estimates across all teams at the very beginning by forcing teams to adopt 1 point as 1 day. This defeats a lot of benefits of point based estimation and relative sizing. Again in SAFe, teams are forced to sign up for objectives at the end of every increment planning of 2 months or so. This obviously does not take into account the nature of the work the team is doing. A team that cannot release something in 3 months ends up with weird looking objectives just to satisfy the organization standards.
Such standards are created to put some checks around the average talent pool who might be prone to wrong doings. A company even went to the length of running reports on story checkin commits to ensure that stories do not span multiple iterations. And then when there were hangover stories, people were asked to split stories accounting for partial, untestable work in the previous iterations.
Another company I worked with, was trying SAFe, and was forcing product owners to come up with a quantification of business value and time criticality so that cost of delay could be calculated. While core to product development, the essence of this whole calculation was diluted by the middle management of product owners who ended up making up numbers as a shortcut. Justification of the business value numbers ended up becoming more subjective and usually the loudest product owner in the room won.
These experiences clearly show that there is really no alternative to investing in hiring and nurturing good talent. While for execs at the very top, a scaleable framework with checks and balances might look very attractive, the middle management along with folks on the ground will find ways and means to work around these checks and never end up learning the real values.
While hiring talent is hard, it is equally important to nurture good talent, especially in IT where the market is highly competitive.
Design your enterprise towards continuous delivery of value. A lean enterprise should be able to build, measure and learn from the software they delivered and iterate rapidly towards maximizing business value. This is not easy, especially if you are a large enterprise. Reaching this goal will require hard work and changes within the organization that are beyond IT such as financial budgeting, performance reviews etc... Invest in hiring smart talent and then invest in your people to coach them on fundamental principles such as early feedback and failing fast and how core XP engineering practices and CD help achieve that.
Just scaling agile with a prescriptive process framework will be attractive in the short term but will not live the test of time for your enterprise. Don't give in to the temptation. Do the hard work.