A recent Magenic’s Forrester study (http://www.reuters.com/article/mn-magenic-agile-dev-idUSnPn3WkQCr+96+PRN20151021) 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 survey, 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 span of time and expect very high quality? It is the people who create products, not ‘methodology or process’. So the right question is “in order to get the high quality product did they invest and focus on creating agile mindset”? High quality, and faster delivery are the byproduct of super Agile mindset.
2. “Organizations are not adopting Agile all the way 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 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 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 become 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 valuable role in a self-organizing Scrum team. A Product Owner is a 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 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”.
Agile testing practices? The real tester of your product is the end user or real customer. There is nothing like ‘so called Agile testing skills’. The whole idea behind the agility is to become customer-centric and deliver product to the customer as early as possible to get their feedback. Automated test suite (for functional, performance, security testing) is the part of development effort and invariably included in the definition of done to add quality to your delivery. If they are not testing product every Sprint, it means they are doing a mega project (to be delivered several months later) with an Agile makeover. Again a classic case of wrong hypothesis with dubious conclusions.
Unfortunately, these studies woefully lack the substance and the right context to elicit the real problems organizations are facing in their journey to become Agile.