I’ve written a number of posts of late (1, 2, 3, 3a) on the topic of Agile/Scrum and Product Management. My goal was to discuss some of the issues I saw with Scrum in relation to software product management.
Given our blog stats, this is one of the hottest, if not THE hottest topic for software product managers today. Within the PM and (I’m assuming) development communities, there are a lot of questions and there is a lot of confusion on this topic. I’ll take a break from my multi-part series on Agile/Scrum and Product Management to bring a little clarity to this topic. If you don’t agree with me or have some comments, please post a comment or question below. It is only with discussion that clarity will be gained.
Agile is a software development philosophy
I made this point in my original article on this topic and it is a very important one to remember. There is so much hype around being “agile” these days: agile development, agile product management, agile companies etc. Who wouldn’t want to be “agile”? But, the second line of the Agile Manifesto clearly states:
Working software over comprehensive documentation
Emphasis on the word software is mine. So don’t get lost or caught up in the rest of it, at least in this discussion. There is nothing wrong with being “agile”, but don’t confuse the specific meaning of the word for the purposes of developing software, and the general meaning of the term “agile” that seems to get applied to everything from people, to departments and companies.
Scrum is a software development methodology
Based on the philosophy defined in the Agile Manifesto, and the Principles behind the Manifesto, Scrum is one of several, and arguably one of the most commonly used, “agile” software development methodologies. It defines specific roles, such as Scrum Master and Product Owner, and a set of best practices for creating high-performance development teams. By decomposing large development efforts into smaller user stories, implementing them via sprints or iterations, and daily progress tracking and reporting (via burndown charts) it is possible to detect potential project delays earlier than other non-Agile development methods.
Scrum is not a panacea for organizational issues
As a development methodology, Scrum can provide more visibility into potential problems in the development cycle earlier than other methodologies such as a traditional waterfall approach. But, Scrum will not solve any organizational problems you may have. It won’t make bad developers better. It won’t make bad product managers better. It won’t fix dysfunctional relationships between Product Management and Engineering. As a general rule, organizational problems cannot be addressed by process changes, and bad relationship between those two groups may actually get worse with Scrum because of the expectation of Engineering of that daily interaction with “the customer” or “the voice of the customer”.
As I’ve written previously, this principle of Agile — that business people and developers must work together daily throughout the project — is a cause for concern. I’ve seen development teams within the same company not talk to each other daily, let alone business people and developers. Personally, I find this requirement of daily interaction an over adjustment to the large lack of business/technical engagement that has generally plagued many software development projects. Regular, clear and meaningful communication across teams is needed, but daily communication isn’t always needed nor possible.
Scrum can increase developer productivity, but at a price
Every system requires tradeoffs. A lot of Scrum teams focus on velocity which is a Scrum term for the amount of product backlog functionality that a Scrum team can take on in a single sprint or iteration. But, given that analysis of the work needed takes place at the beginning of each sprint (in a sprint planning meeting), it can be difficult to plan out well in advance how how much progress on the backlog of features can be made in a fixed period of time.
Now why is that important? For a Product Manager in an ISV, sprints and iterations are simply a means to an end. The end being a release with a pre-defined and agreed upon set of functionality that will need to be marketed and sold, and much of which is likely tied to customer commitments related to opportunities or sales commitments. In short, the price for speed and agility via Scrum is a loss of certainty about the state of the software at a given time in the future.
This can lead to frustrating discussions between Product Management and some Scrum teams who adhere rigidly to the Scrum development model, and don’t understand the need of the business to be able to confidently communicate a planned future state of the product to customers, partners or other internal or external parties. Those parties need this information well in advance of the release, so they can make decisions related to their own objectives and goals.
Agile/Scrum should be viewed as an Ethos
Tom Grant at Forrester Research asked if people viewed Agile as a Creed or an Ethos. He defined the two as follows:
- Agile as a creed. One type of Agile enthusiast treats the methodology of choice as a set of firm guidelines, to be followed or ignored (at your peril). The closer you get to orthodoxy, as the Pharisees communicate by voice or in print, the better the results.
- Agile as an ethos. The other species of Agile enthusiast sees the methodology as a guide to action. Perfect adherence to its principles are impossible in an imperfect world, so the goal is to add a healthy dose of Agile to the blend of different techniques and imperatives.
First, let me make a point of clarification. I’m not sure if Tom meant it this way, but the way I interpret this, is that when he says “Agile”, it’s really referring to Scrum or any other specific Agile methodology. i.e. Agile is a software development philosophy, whereas the methodologies, like Scrum are defined based on the Agile philosophy.
So, for me, Scrum has to be ethos. And here’s why? No single development methodology can be applicable to every situation or every team. Scrum defines a number of best practices, but is not in itself dogmatic about exactly how everything must be done. This is a good thing. It provides people (IMHO) flexibility to implement what works best for them given time, people, needs and constraints.
If it were rigid, it could hardly be called “agile” could it? 🙂
Hopefully this helps provide some clarity into my views on this topic and a little more fodder for discussion. So comments please.
Saeed