Software development started with a small-team focus, yet now large enterprises are trying to implement Agile methodologies such as Scrum. Getting twenty people to move in the same direction can be pretty easy -- you have a single product manager who speaks with one voice -- yet those ideas often fail to scale to product suites and teams of teams.
Tailoring the process in such an environment takes a good bit of finesse; something Alan Shalloway will be speaking about in his talk at the Agile 2011 conference, titled "Handling Product Management across the Enterprise."
SSQ: It's clear that some large organizations have struggled to adopt Agile. Can you tell us a little bit about why?
Alan Shalloway: Well, I think the problem is two-fold. One is that Scrum is so popular,
SSQ: What do you think are the critical success factors for large-scale Agile adoption?
Shalloway: The overriding concern is that business value be produced. Agile is really about incremental business delivery. Team iterations are merely a way to achieve that. An approach of driving from business must be undertaken. Agile teams are like the engine in a car, but if you don't drive it in the right direction, a powerful engine only does you so much good.
SSQ: Speaking of which -- how do these ideas tie into your talk at Agile 2011? Can you tell us more about what you will be speaking about?
Shalloway: I'll be talking about how one must manage product development from the context of the value being produced. In large organizations, the product owner role is insufficient. When you have multiple business stakeholders and multiple teams, the product owner role is essentially untenable due to the fact that the value required by business stakeholders require multiple teams to build it. I'll talk about a method of using product managers and product owners to coordinate this many-to-many relationship between business stakeholders and teams. This requires a business perspective and a top-down context within which the teams work.
SSQ: Let's say someone is working in a large organization, with teams of teams and directorates of directorates, trying to "do Agile." Perhaps they have previously had a PMI-type of worldview, and had some success with a PMO and portfolio management approach. What should they be thinking about when they transition to Agile -- what are things to do first, second, etc.?
Shalloway: The first thing I'd do is map your value stream. We've found a good way to do this is actually to create a Kanban board of it. While this may seem odd, Kanban boards are very concrete in nature and people readily relate to them. It is critical that these maps/boards be of what is actually happening. One can then talk about the challenges that become visible through doing this mapping. The intent is to discuss what one's real problem is. It often isn't at the team level. It is very important to make sure you start your Agile transition in the right manner. First determine if you should start with a pilot, and if you should, you must pay attention to selecting the right project to use as a pilot. Otherwise you invite initial success, but will fail to sustain it. I've written about this in a blog called How Successful Pilots Often Actually Hurt an Organization. It is also critical to understand why Agile works. Scrum's view of "just do it" just doesn't do it for many organizations. I like people to understand the principles of Lean on which Scrum has been constructed - albeit not always recognized.
SSQ: Could you describe a Kanban board for us in your words? How do teams transition to a Kanban board from other methods?
Shalloway: Basically, a Kanban board is a reflection of what work you are doing now. People don't actually transition to a Kanban board. This is a huge difference in Kanban and other Agile methods, most notably Scrum. Kanban says you can't manage things for improvement unless you make them visible. A Kanban board creates visibility on what the team is doing now. It does not require them to change what they are doing -- it merely creates visibility into what they are doing. After seeing what's happening, it usually becomes clear how to make small changes that improve the methods used. By doing this on a long-term basis and building on the prior improvements, teams tend to progress, improve and sustain these improvements. Scrum requires a change in methods and, ironically, doesn't help so much on creating visibility into the teams practices (only the team's results - which is big, but is not often sufficient for sustainable improvement).
SSQ: I've seen Kanban boards, and used them, but it's always at the team level. Are you suggesting teams do an organization level Kanban board, or something else?
Shalloway: We used to do value stream maps to show the organization workflow. Then we discovered that one could create Kanban boards from start to finish -- and that they were easier for many people to understand -- because they showed stickies moving across the boards and were therefore very tangible. Scrum boards are geared to the team and are difficult to extend beyond the team. The reason for this is Scrum is based on iterations and letting the team formed operate in an uninterrupted manner. The team's process is typically not defined even to the team, let alone made visible to outsiders. If you've got people who can map and understand value stream maps, then those will work well. But we've seen Kanban boards be an easier description of what people are doing now for many people.
SSQ: Thank you for you time today Alan -- where can we go to learn more?
Shalloway: We have a huge amount of information on Lean, Kanban, Scrum and more on our website. You'll have to register to get most of it - but it is worth doing so. There are literally days of information in the form of recorded webinars and seminars out there. This will also get you our announcements of upcoming events - which we have many. Thank you for the opportunity to share.