Two Common Misinterpretations in Agile
For the past six years I have asked interviewees on my podcast the question, “What are the two biggest issues in… ?” Recently, the table was turned on me, and I was asked, “What are the two most misinterpreted concepts in Agile?”
#1 – The Product Owner
First is the concept of the product owner. The product owner is the key stakeholder and the person that provides the vision for the project. They interact with the other team members daily (that means they are part of the team). I could continue to run down the list of responsibilities for the job, but those points generally aren’t the problem.
The problem is who should be the product owner. Simply put, the business should supply the product owner. They should have a vested interest in the success of the product and the project that is impacting the product. In a perfect world, they should have profit and loss responsibility. Proxies, whether from IT or the business, are bad ideas.
The product owner has to be a leader and decision maker who understands the business and the customers the product will serve. Confusing or conflating the role with an administrator or a go-between loses much of the benefit of value focus and rapid decision-making that Agile brings to the table.
#2 – The “Release”
The second is the use of the word release. The 12 Principles in the Agile Manifesto include the following principle:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (Source: http://agilemanifesto.org/principles.html)
In many cases, this has come to be read in an absolutist sense: That at the end of each sprint (or iteration) software must be put into production and released to the ultimate customer.
This misinterpretation leads to teams throwing up their hands and shouting that this Agile stuff just can’t work here. Or, just as bad, this misinterpretation can lead to long sprints (we used to call those phases or subprojects). Both of these outcomes strip away the value of agility.
Remember that most projects will need to create a release plan that provides a map showing the number of sprints and features that will be completed before delivering internally or to the ultimate customer. In many cases, multiple sprints are required to build to something the product owner wants or can deliver to her customer.
As an Agile team, your responsibility is to incorporate your sprint cadence into your planning for ultimate delivery. Using the concept of chunks provides the Agile team with an incredible level of flexibility. Each sprint needs to deliver functional software, but how it’s packaged for interim or final release into the wild is up to the product owner!
There you have it! In my opinion, the top 2 misinterpretations in Agile are the product owner and releases. I’m sure there are other opinions out there, so please share!
What do you believe are the top misinterpretations in Agile?
Tom Cagley (@TCagley)
Vice President of Consulting