Mark Levison recently wrote a blog on “Scrum Alone is Not Enough”, which is the first blog of a series to uncover various Agile patterns. Till now he has published blogs on Kanban Portfolio View and Portfolio Management in the series.
The blog series is very informative. It covers various Agile patterns with examples.
Mark says that scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns.
Scrum is a problem-finding tool, not a problem-solving tool
It doesn’t solve a single thing on its own. It requires that the people in your team and organization find the energy to follow through. Failure to solve the problems that scrum finds will demotivate people and leave a bad taste for scrum overall.
Mark also shares the difficulty with scrum while working on unplanned work and with unstable teams.
Scrum requires a stable planning horizon of at least two weeks. Scrum teams can handle unplanned work, but when it exceeds 50% of a team’s capacity on a regular basis, scrum is no longer applicable and Kanban makes a better choice. The obvious case is technical support - being on the phones/email support for a product means that new issues and problems arrive randomly, so a plan made by the support team on a Monday wouldn't survive to Tuesday lunch.
Scrum is a tool to help build High-Performance Teams, and so scrum needs stable teams. When a client hasn't formed those, we make that our highest priority, otherwise much of the effort will go to waste.
InfoQ interviewed Mark about his blog post series and discussed his viewpoints.
InfoQ: You recently wrote an article on “scrum alone is not enough”. What motivated you to work on this aspect?
Mark: In my work as a consultant and trainer, I see many different companies attempting to use scrum. They often have great success at the individual team level but then struggle as they try to move beyond.
Many teams do a good job of removing their own impediments but fail to remove the more systemic issues. Either they don't see the problems or, in many cases, they don't have the power/control to address the issue. This is demotivating because scrum has revealed the problem, but the problem doesn't get solved.
For example, a client’s product owners are struggling. They understand how to prioritize effectively, and they're trying to balance the short term needs of dealing with specific client problems vs. the long-term needs of the product because they know that, if they fail to address the long-term issues, their product will be irrelevant in the marketplace in less than two years. Yet almost all of their time is spent working on short-term items and they're frustrated that scrum doesn't solve this problem. Scrum has identified it, but they will need to use other patterns to address and resolve it.
Similarly, there is the problem of engineering practices - scrum doesn't prescribe any particular practice. Scrum is neutral. Scrum is designed to work for a variety of problems - from software development, to hardware development, to marketing, etc. As a result, it can't prescribe any particular practice to solve a problem. And since the practices have evolved and continued to evolve, by not specifying which practices to use, scrum remains open to their evolution. Jeff Sutherland, co- creator of scrum, has often said that in a software development environment, scrum will only work if you adopt modern/effective engineering practices, i.e. TDD/BDD, Refactoring, CI, Pair Programming and perhaps ATDD. Too many scrum teams - perhaps over half - struggle to get a truly shippable product by the end of every sprint. Of course in early days every team has this problem, but in the long run they should be truly shippable at the end of every sprint (even better, ship multiple times a day). Teams that don't take on effective engineering practices will not be able to get done every sprint, let alone multiple times a day. This is isn’t a scrum issue – this is an engineering issue and is outside the scope of what scrum can achieve by itself.
These are two of the most common issues I see organizations struggling with, that they think scrum will solve but of course it does not. Scrum is invaluable at indentifying the problems, but alone it’s not enough to solve them.
InfoQ: Do you see any challenges in the organizations which use only scrum?
Mark: It's not so much that organizations use only scrum, it’s that scrum is only designed to help teams become more productive. There are many aspects on which scrum is silent, which is a good thing since that allows you to find other tools that work well with scrum. When working with clients, I recommend a Portfolio Kanban board, however if they don't like that approach then scrum is fine with another approach. The illustration we chose for this series is a series of gears with scrum at the centre. To make the whole system work effectively you will need more parts than just scrum. Scrum is simply the starting point.
InfoQ: You suggested Kanban for the portfolio management? Why did you choose Kanban specifically and what are the benefits of using Kanban at portfolio level?
Mark: Kanban is a tool to understand the flow of work through a system. As such, it is an excellent tool to study the big picture and see systemic issues. Kanban has only a few simple rules: Visualize your work; limit your work in progress; Improve the flow. That makes it well suited to identifying clear problems that are true over multiple teams. For instance, at the company with the problems around short-term thinking, the portfolio kanban board revealed that most the teams' work was being discovered at the last minute and didn't come from the portfolio backlog. That gave us a chance to have a very challenging discussion around whether it’s better to save a few customers now or focus on replacing the out of date technology in the product. Of course, there isn't a right answer, but at least the portfolio kanban board made the problem clear.
InfoQ: From your experience what are the good combination of various agile methods, which you tried and resulted in a successful experiment.
Mark: I don't see agile methods as distinct entities anymore. I see it more like a series of Design Patterns - scrum is a series of patterns for teams; XP adds patterns around the engineering practices, Crystal added personal safety. When we see them as a series of patterns, there aren't specific combinations so much as there are sources for ideas and implementation. If I'm working with a client and I see there is fear and people are reluctant to share ideas, then I reflect on creating safety. To create great safety we might start a meeting with a safety check, use silent listing to gather ideas, and dot or multi voting. When the code base has become a big ball of mud, I point people to a variety of sources on dealing with legacy code. Once we view the world this way – by being open and responsive to whatever unique situation exists - our focus moves from specific methods to simply “how do I get better inside my current envelope?” Trying to prescribe a set combination of methods, whether it’s applicable or not, goes against the principles of scrum.
InfoQ: Most of the organizations start their Agile transformation journey by the implementation of Scrum. When do you think, organizations should consider implementation of other methods with Scrum?
Mark: There is no perfect place to start and there is no perfect time. Start where you can and expand from there. As you say, most organizations start with a couple of teams doing scrum. Depending on where their largest pain comes from, they will either want some way to visualize the portfolio (i.e. Portfolio Kanban), which quickly leads to Portfolio Management, or in other cases engineering issues at the team level are more important, in which case they should start to improve engineering practices. So the order really depends on the pain they're currently feeling and the energy of the people making the changes.
InfoQ: How do you see the combination of various methods and practices as per the size of the company?
Mark: Since we're using a patterns and principles based approach, very little changes as organizations get large. In a larger organization there will be more teams, so the importance of team organization is greater. In addition, larger organizations will have more dependency problems across teams and platforms. But even with the largest organizations, simplifying platforms and applications so that teams have a greater degree of independence is very important, and the Spotify model is one example of this trend.
The specific things that each organization needs (or doesn't need) vary more by the nature of a company’s culture than by its size. One of the challenges with the currently popular SAFe approach is the one-size-fits-many picture. The picture implies that you need an architectural group, yet many effective Agile organizations don't have one and would be harmed if one was created.
Each organization needs to discover its own path and not expect that it can just copy and paste from others.
InfoQ: Some people say that having engineering practices in place as the readiness criterion for the implementation of Scrum. What is your thought on this?
Mark: The only prerequisites to starting scrum is have a stable team and be able to plan for at least two weeks. That’s it. Otherwise, there is no perfect time to start, so just start and scrum will help you discover what you need to improve. The engineering practices are important, but if you don't have a good set in place to start, scrum will reveal that problem rapidly.
InfoQ: You are writing a series of articles on “scrum alone is not enough”. Please share with the readers about your next upcoming articles on the same series?
Mark: In the next few months I will be writing articles on:
Organizational Improvement - How do we resolve the big-picture systemic issues that are beyond the capacity of any one team to solve? This is the article that I'm currently working on between clients.
Team Organization - Feature teams? component Teams? others?
Intra-Team Coordination - How do you coordinate work between teams? scrum of scrums is the most well-known pattern but is rarely a good choice.
Engineering Practices - Without solid engineering practices, the health of your codebase deteriorates over time, yet in many organizations the focus is put on scaling up the number of teams before making the existing teams more effective.
InfoQ: Do you want to give any message to the Agile practitioners?
Mark: Don't stop searching for ways to improve. Always assume your current team can be better. If your team thinks it has nothing left to improve, then contact InfoQ to get a case study written about it. :-)
About the Interviewee
Mark Levison is a Certified Scrum Trainer® whose credentials span 20 years experience as a software developer and enterprise development manager. In 2001, having experienced what can go wrong when building software, he turned to Agile and Scrum for improved methods and tools. In 2009 he founded Agile Pain Relief Consulting to help individuals and companies build High Performance Teams and organizations with Agile training, coaching, and consulting services. In addition to Scrum, Mark also studies behavioural psychology and neuroscience for a deeper understanding of how teams work and improving team dynamics.
