Forrester study on agility - A fashionable trend of dubious conclusions
A recent Magenic's Forrester study included online surveys with 100 cross-vertical IT and business decision-makers in the U.S. The responses to those questions ‘revealed’ four key reasons Agile isn't succeeding. But far more intriguing is the way the survey was designed, and the context was set. This is a classic case of iniquitous surveys, erroneous results, and wicked conclusions.
Let’s take a look at the key findings…
1. “Development teams are not achieving high quality with Agile. According to a previous Forrester study, organizations can deliver new software features in production every 11.6 seconds. But that speed is not accompanied by quality. In Magenic's Forrester study, 74% of respondents stated they expected improved technical quality with Agile, but only 30% were experiencing it”.
A classic mistake: Agility is not about speed. Speed may be achieved in the long run but you may lose speed by switching over to agility in the beginning. It is the art of maximizing work not done so why would they need a lot of software in a short period and expect very high quality? It is the people who create products, not the ‘methodology or process’. So the right question is “To get the high-quality product did they invest and focus on creating an agile mindset”? High quality and faster delivery are the byproducts of a super Agile mindset.
2. “Organizations are not adopting Agile through the application development delivery cycle. Ninety percent of respondents in Magenic's Forrester study stated that they recognize Agile requires an investment in the skills, processes, and technology to build a modern application delivery organization, but 37% indicated they lack the automated infrastructure needed to make this a reality, and 30% indicated company culture is a barrier to full adoption”.
领英推荐
Agile adoption vs Agile adaptation: Many organizations think Agile is another ‘process’ that requires investment and needs to be ‘adopted’ all the way or should be scaled all across the organization. In the good old days, we used to adopt robust processes all across the organization to become ‘efficient’. We have moved on from becoming efficient (Taylorism) to becoming more effective in the new Agile world. So we need to scale agile values, not retrofit the ‘Agile process’ to the old bureaucratic processes. Interestingly culture is considered a barrier in full adoption but the whole agility is all about evolving a vibrant organizational culture to adapt to the changing marketplace.
3. “Organizations lack skilled Agile product owners.?Thirty-seven percent of respondents in Magenic's Forrester study noted that the lack of skilled product owners was creating a barrier to Agile implementation and success. Fifty-two percent of respondents said product owners are hard to find, and 38% said that when there is a product owner, that product owner lacks the necessary skills”.
Product Owner or Superman: Product Owner is a new and valuable role in a self-organizing Scrum team. A Product Owner is as good as the team is. A common fallacy of thinking is we should have superhuman Product Owners who could deliver amazing products and great values. In my experience organizations that promote a collaborative culture get awesome Product Owners who combine the ordinary powers of the team members to create a superpower effect. That requires investment in humans, not processes. Another argument against a powerful Product Owner is he/she tends to become an anchor in the team which kills collaboration.
4. “Organizations are not incorporating new Agile testing practices.?In Magenic's Forrester study, more than 40% of respondents indicated that they only test the product once the application has been completed; only 12% state that they perform application testing early on and within each sprint. In addition, 34% of respondents noted that those conducting the testing lacked Agile testing skills”.
Writer on software science and information metaphysics.
8 年Oh dear, another one of those "Agile doesn't work if you aren't" articles. I guess you can't expect the consultancies to be very keen. It's all very well expecting quality to be higher but did they tell the development team? If the quality wasn't in the definition of done then why did they expect it? If it was then why did they accept the release? My experience of agility was that customers wanted lower quality than we would have traditionally have given them, in order to get value quicker.
Too many organizations treat Agile as an IT initiative. True Agile adoption is an organizational initiative, not just IT