Many IT organizations, trying to emulate the pace and quality of software development by vendors, have tried to transition to Agile Development, typically going with Scrum, with varying degrees of success. In my experience when a traditional IT shop struggles with Scrum there are a few common factors that come into play:
- Dropping Scrum into an otherwise waterfall SDLC with extensive front end analysis and planning followed by a traditional build and release process (Fallacy of Water-Scrum-Fall).
- When testers and developers used to having all their work directed, now must own their work. This includes making planning poker story point assessments and choosing what stories to work on. Many struggle initially with these changed responsibilities, but a good scrum master with coaching skills and a few iterations under their belt usually serves to address the transition.
Biggest challenge? An Engaged Product Owner. It is hard to over emphasize how critical this role is and how challenging it is to find the right person to take this on. The traditional business subject matter expert (SME) even when enthusiastic about the software project is challenged to devote the time required to properly steer the team. In a traditional waterfall methodology the attitude is basically command and control, direct the work, have the team work on it and report back. This often means throwing it over the wall and see what the outcome is at the end. The SME typically continues to be swamped with their full time job responsibilities and can only devote an hour here and there to the software project. It is no wonder that so many software projects fail and so few meet the expectations of the business unit which pays for the work.
Scrum tackles this dynamic head on by elevating the product owner to a highly engaged person who has the responsibility to make sure the team is working on the right things. There is a lot of responsibility around both defining user stories and prioritizing the story backlog. When you have a good product owner Scrum can demonstrably deliver value faster to the customer. The challenge for most organizations however is that the Product Owner cannot maintain a pace required to ensure the SDLC is flowing smoothly.
The HiPPO Bias. Too frequently the business will push back devoting a key resource to an IT project. The IT organization might offer up a solid analyst with business acumen to act as a surrogate. The surrogate often becomes challenged as their ability to prioritize stories is based on secondary knowledge of what is critical to the business. They likely are highly influenced by the biases of the HiPPO (highest paid person’s opinion). They often second guess their judgement and abilities which brings a level of uncertainty to the team.
The importance of finding a good Product Owner becomes even more critical when software development is performed offshore and/or outsourced. Typically the Product Owner remains at the corporate office and the rest of the Scrum Team is in a different country many time zones away. The ability of such a scrum team rests on the level of interaction with the Product Owner and the communication that exists across the distance. It is even more important that the Product Owner be decisive, stay on top of the day to day activity and be able to respond quickly to provide any clarification the team requires to make good progress.( In a future post I will propose some Lean IT tools to address the challenge of Distributed Agile Development.)
Bottom Line. If your organization is willing to invest in a modern software development approach, then start with the investment with the biggest ROI, finding an engaged Product Owner.