To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns.
Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems.
Beyond Scrum you should consider:
– Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time.
– Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole. (Part 1: Visualize Your Work | Part 2: Limit WIP, Measure and Improve)
– Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order. (Part 1: Portfolio Management | Part 2: Idle Teams)
– Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems. (Part 1: Taking Organizational Improvement Seriously | Part 2: Case Study)
– Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice.
– Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds?
There are no best practices.
Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours. This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context.
Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement.
Scrum is just the starting point.
In the next few months, I will explore patterns that can be effective when attempting Scrum at a larger scale (more than three teams). What topics would you like me to explore?
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Great points on what else an org should look at. I have been focussed recently on the technical practices and portfolio. Many companies either don’t give these any time, or assume what they set up years ago works just fine.
Great article, i agree with the author that focusing on one specific tool or methodology is not a good idea because like he mentioned what works in a specific context may not work in an other. After reading this article, i realized another important benefit of incorporating a project management office (PMO) in any organization. The PMO may be composed of few people that will have the responsibility of determining what tools and methodologies work the best in each specific context.
Roni – yes its important to check more than just expert opinion. When you study cognitive biases you realize expert opinion alone leads to more mistakes. In Estimation the Planning Poker approach is an attempt to make sure all opinions are sampled.
For more depth consider: https://en.wikipedia.org/wiki/The_Wisdom_of_Crowds
The author of the book has shown in many cases a crowd will make better decisions than the experts.
That is one of many reasons in the Agile world we try to place most (if not all) decisions in the hands of the team.
A PMO would better off understanding the results of team level experiments and sharing them with the rest of the organization than controlling the teams ability to experiment.
I am surprised that Intra Team Coordination and Team Organization are not referred to as project management especially now that organizations are beginning to consider Large Scale Scrum and Enterprise Scrum. It seems to me that it is time for scrum to finally accept project management as one of its essential element to be successful at the large scale/enterprise scrum.
Samad – thanks for taking the time to comment. Your approach has been tried. Most famously at Nokia – a presentation from Ran Nyman and Ari Tikka: https://agileprague.com/slides/ap2016/RanNyman-Taylorism-Agile.pdf documents alot of what went wrong. From my own conversations with them it was the overhead of the coordination eventually became to large a burden.
If you really want an approach that creates a coordination layer – consider SAFe which is designed to ensure the best alignment between doers and executives. I generally don’t recommend SAFe to my clients.
You mention Large Scale Scrum (LeSS), which I know well and Enterprise Scrum (which I have less familiarity). At their heart both start with Scrum, Scrum requires self organization and expects teams to eliminate dependancies.
LeSS requires self organization between teams, it teaches systems thinking, lean and some behavioural psychology in an attempt to help teams understand their dependancies. LeSS challenges organizations to re-shape themselves to eliminate most dependencies think Feature Teams over Component Teams as the simplest example. So instead of Intra-Team coordination becoming the domain of specialists it in fact becomes the domain of all team members so that they can be more effective (not more efficient).
I’m not picky about the titles people hold, I do need all people in a organization to help improvement otherwise we bottleneck on the capacity and skills of those people.
Thanks Mark.
Thank you for commenting on my remarks.
Thank you also for the link to the presentation about Nokia. It is interesting that the researchers from Insead found that the core driver of the failure of Nokia had everything to do with a prevailing “culture of temperamental leaders and frightened middle managers, scared of telling the truth”.
You can probably say the same thing about the demise of Blockbuster in the U.S and Blackberry/Research In Motion in Canada.
You are right, we should not be too picky about titles.
Unfortunately, I often see project management and scrum being discussed as mutually exclusive domains with project management or any project coordination role often vilified in the process.
I just don’t see project management or roles responsible for coordination as the real problem for projects. Failure of these roles is more often that not due to the prevailing culture in an organization and the type of behaviors it tends to reward and people it promotes to these roles.
I often say organizations get the managers they deserve.
As for self-organizing teams capable of cross-coordination, perhaps my 20+ years of project experience, primarily in typical (traditional) IT shops in non-technology organizations, made me a lot more pessimistic about organizations being able to foster truly self-organizing teams. I know it is dangerous to generalize but perhaps self-organization is the norm in some technology companies but I just don’t see it happening elsewhere, especially when we are talking about large project, regardless of the type of industry.
I just don’t see it happening in the near future either.
Thank you again.
Samad – rather than take my word for it head over to Less.works and checkout the case studies. Even better find a LeSS Trainer and get them to invite you to a client that does something like this.
From personal knowledge I know that parts of Microsoft have moved this way, Google and Facebook have never had special people to coordinate.
So it does happen, its easier if you build it from the ground up, it is possible to evolve an organization although hard. Read the rest of my series its basically the toolset I and others use to achieve this.
Cheers
Mark