1) management tells teams to do Scrum
2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)
3) at some point they give up and do ScrumBut by not following sprints. They justify not doing Scrum by claiming that they are now doing Kanban (because they don’t have sprints). But they don’t do any of the things Kanban says to do. This is like saying “we do Agile because we don’t do documentation.”
4) their performance goes down
5) Scrum consultants are brought in and management is told the problem is “well, they’re not doing Scrum, can’t blame Scrum”
6) management tells the teams to do Scrum, because Kanban doesn’t work.
The solution is to teach Scrum, when it’s used for software development, with what is necessary to do software development.
The fact that Scrum can work anywhere works against you if you get generic Scrum training instead of Scrum training designed for you.
Proponents of Scrum often put the responsibility for failed adoptions of Scrum at the feet of management who don’t want to change. While I believe this is true some of the time, I believe the challenge is that Agile adoptions based on Scrum often don’t attend to management’s needs.
I believe management concerns regarding Agile adoptions are focused on reducing risk, making sure it fits their needs, and to be able to adapt when needed. It’s tempting to say “let’s just adopt Scrum.” But this ignores that we live in a complex world where you reduce uncertainty not by having a preset list of things you must do, but rather by learning to adjust to the situation at hand. These are things beyond our control.
What is in our control is our actions. 15 years ago we didn’t have a solid understanding of the “task work” so to speak of Agile. Why working on small batches were good, why visibility was essential, why managing queues is critical, … Now we do. This enables us to go beyond Scrum effectively.
Adopting Scrum is very often the best place to start. It provides structure & discipline. But get training from someone who knows how to go beyond it when that’s the right thing to do.
Addressing the issue of how to adjust Scrum while not worrying about if it is still Scrum is based on 20 years experience with Scrum and is described here: How to improve or change your Scrum practices. This is part of our larger Scrum Support system. I believe having a framework where being effective sometimes requires you to go beyond it is insidious. I contend there are place in any tech org of more than 50 people that no one set of practices work, particularly in shared services, DevOps, maintenance. We have put this together because we’re not limited to Scrum.
The Scrum Guide tells us “Scrum’s roles, events, artifacts, and rules are immutable”
This presumes people need this structure and can’t think on their own without it. Structure is good, but it can be achieved by specifying outcomes and principles while providing a starting point that can be changed as long as the outcomes are still achieved. Agile adopters should be focused on getting their work done, not on following a single set of rules that some people are advocating for everyone.
If you’re a new adopter of Agile don’t accept less than someone who respects your knowledge and experience. Get a coach, not a shepherd. Coaches provide clarity on the intentions and principles of Agile. Learn the how by doing your work. If that’s not in your vendor’s syllabus, get another vendor. If they say it can’t be done, find someone who does it.
You have more experience in your company than any outsider will ever have. Starting with immutability is the anti-thesis of Agile and it leaves an impression. Avoid the discussion of “Agile tells us we must do …”. It doesn’t. Scrum might but Scrum != Agile.
And it isn’t “Scrum And” over “ScrumBut.” Sometimes you don’t want to do something Scrum says.
This is an overview of a 5 part series starting tomorrow.
Agile adoption is often more difficult than it needs to be because most people settle for pre-packaged frameworks instead of what their particular org needs. This has people focus more on a framework than on the actual skills their ppl need to get the job done. Follow up training for these skills (eg ATDD) usually doesn’t happen. Resistance often sets in because people are put back in their jobs with higher expectations but no higher skills. This is made worse if the framework doesn’t match what’s needed close enough.
What keeps this in place is the focus on certification. While a good amount of what works in one place does work in another, the transition to these practices takes one of several paths. Many consultants offer only one type of framework, forcing them to push it only & blame their clients for not following it if it doesn’t work
What’s needed is to be guided to understand their problems, the root causes of these problems and a set of proven practices that can solve them. This is harder to manage, but the results are worth it & the cost is much less over the long term. It is also more likely to be sustainable as people actually learn the skills needed.
Scrum presumes it is effective to give all teams a simple preset, immutable framework that each team must follow until they figure out how to manifest it.
Scrum is designed for and requires cross-functional teams doing work that is plannable. If these conditions aren’t met it is presumed that manifesting Scrum’s rigid framework will achieve Agile in all situations if people are motivated.
An underlying believe is that teams can’t initially understand what they are supposed to do so must be given a predefined set of rules that must be implemented without change until the team understands what’s happening.
While this approach works when cross-functional teams can/should be created & work can be planned, it can causes resistance & abandonment of misunderstood practices when teams have challenges adopting the framework or attached to their roles.
Have expert have 2 hr discussion w/ team&their management to see what alternative or additional practices would be useful. Use these to provide a set starting point and provide teams a guide on how to improve/change practices when they encounter challenges. While coaching still advisable, significantly less will be needed.
I invite people to discuss these alternatives.
This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.
Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”
But ironically, Scrum limits the options of how to fix this dysfunction by requiring its immutable roles, rules, artifacts and events be followed. If one fixes the dysfunction by dropping a Scrum practice while adding a non-Scrum practices the team is still doing “Scrumbut” even though they’ve eliminated the dysfunction. But now, by not doing Scrum they are in unfamiliar territory since Scrum does not provide insights on the intention of each of its practices. This tends to have new teams in particular, that don’t understand the intentions of the Scrum practices, have to stick to Scrum or go outside of the range of Scrum.
If people just abandon practices without adopting a new one to fulfill its intent ScrumBut is likely a bad thing. Substituting practices requires understanding the intention of the practice being substituted &a set of alternatives to choose from.
This is an excerpt from Lean-Agile at the Team: A Lean Approach to Scrum &Kanban. See 1st comment for url
I’ve written recent posts about stoping the binary thinking & a Manifesto for Agile Learning. The key point of both is that breadth is more important than depth. If you’re an SM you may have the concepts of Scrum & Agile down, but may not have what you need regarding Kanban. If all you’ve done is Kanban, there are concepts in Scrum that are quite useful as well.
I co-founded Lean Kanban University w/David Anderson (I’m no longer affiliated). One reason I left the organization was what I perceived to be a tunnel-vision view. “Visualize, don’t reorganize” is limiting in my mind. Cross-functional teams have shown to increase innovation and reduce handoffs. I’ve always like Don Reinertsen’s statement “flow when you can pull when you must.” Flow is not just about using kanban &visibility.
This is why we’ve created Team Agility, a blend of the 2 and The Net Objectives Coaching Academy for Scrum Masters and Agile Team Coaches. It’s more about effectiveness using all of the methods available instead of mere certification.
Let me know if you’d like to learn more.
NOTE: i know many Scrum & Kanban trainers who teach both, I am referring to the orgs that promote only one.
At a conference years ago Don Reinertsen & I were watching from the back of the room together & sometimes making comments between us about the presentations. At one point it was clear that there was a pattern of “this or that.” Don made a funny observation “these folks have been around 1s & 0s too long.” I had had the same feeling so laughed at his eloquence.
We’re still doing that. We look at Scrum as a thing & Kanban as a thing. Scrum has the cross-functional team be sacrosanct & David Anderson says “visualization not reorganization.” There is power to both. Both are proxies to what we need to do.
Conway’s law tells us “”organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” My corollary is that “When development groups change how their development staff are organized, their current application architecture will work against them.”
We have to recognize we’re in a very complex situation. Ultimately we need to have some simple guidance to help with decisions. The root of these are:
- make sure what you’re building has value
- look at time it takes from start to end (cycle time)
- shorten the time any part takes from start to completion
- attend to quality at each step
btw, if this looks like Lean to you that’s because it is. Lean, boileld down to its essence is:
- systems thinking
- just in time
- build quality in
Scrum was inspired by the article “The New New Product Development Game” (’86). It introduced a new way to develop new products. The question essentially was “how do we get innovation from product development teams?” The emphasis was on speed & flexibility. Several characteristics of successful development included:
- Teams work best when they work autonomously
- Checkpoints are needed to prevent instability, ambiguity, & tension from turning into chaos.
- Continuous learning is essential
- Mistakes are both tolerated & anticipated
- Management must adopt a management style that can promote the new process
The bottom line is to have teams working autonomously but with a set direction / challenge and oversight (but not micro-management). Management has a significant role to coordinate all aspects of the organization that is required for the product. The team must coordinate with other parts of the organization to achieve value.
Scrum is essentially a framework for doing & learning. The approach requires more of a management shift to create such an environment than it is a how a team is to work. The implications of this when adopting Scrum in most organizations is significant.
I’ve been having a very interesting twittervation about how to start teams off with Scrum. I believe you best learn by doing. And that it’s more important to get teams actually starting Agile in the workshop than merely learning Scrum which will hopefully lead you to Agile.
So we “teach” Scrum with a 1-day emulation and discussion of it followed by 3 days of ATDD. This first day teaches the essence of Scrum but it illustrates how teams work – mostly their foibles. 🙂
The other three days are on ATDD. Each day isi split by 1/2 day discussing it & then an hour with each team doing it. What we’re really teaching is – collaboration, test-first, feature slicing, and how to use minimum business increments. These directly address the issues we’ve seen most teams have- unclear requirements, stories too large, POs not appreciating the impact of interruptions and a lack of focus on finishing.
The test-first is mostly about discovery & specification but it also informs design (the 1st mantra of design patterns is designing from behavior).
The result is that once a team gets moving they can keep moving. But a course that prepares you for movement may not ever get you started.