Which has you feel more trusted and respected?
1) Consultant comes in and says “do this until you understand what I’m telling you. Only then can you modify it. Trust me.”
2) Consultant comes in and says “when looking to improve, look at this and these patterns. Imagine how they have affected you in the past. Take those experiences with these new insights and solve your problems. I’ll be here to guide you but won’t tell you what to do since you need to understand why what you’re doing is going to work or not. And I know you can. Trust yourself.”
Neither is inherently better. It depends upon you.
Frameworks provide us with:
- A list of roles, actions and artifacts which are useful
- A set starting point
However, frameworks don’t discuss:
- When they are most applicable
- How to transcend them after the adopting organization has successfully adopted them
Frameworks are also not meant to be modified. The reason for this is stated as self-evident & therefore rarely (ever?) discussed. However, there is much evidence that a framework being adapted to an organization while still providing a set starting point is a better way to go.
The net result of the above is that people tend to adopt a framework as is. And many tend to require adherence to it. All of the above strikes me as particularly non-Agile. We have put fences around what we can do. The justification for this has been twofold – people need to follow something until they can think on their own and it’s too difficult to come up with a tailorable model.
The first one strikes me as not having confidence in people’s ability to figure out what they need to do. The second one misses the point. I’m not suggesting that the people adopting a framework figure this out, I’m suggesting that consultants and trainers figure this out and be what they present to their clients.
Two common approaches for Agile adoption have been frameworks (eg Scrum, SAFe) or improvement via kaizen (eg Kanban Method). The advantage of the first is that it provides a solid starting point. But this works against us as well since the preset framework may not fit the team or organization attempting to use it. Also, frameworks tend to work on proxies of the work to be done. For example, having cross-functional team working in a time-boxed results in lowering delays and handoffs. Good things. But by focusing on the time-box instead of the delays time-boxing reduces, those using Scrum don’t learn as much about reducing delays as they might otherwise.
The Kanban Method has the advantage of focusing directly on the work. By not having an immutable aspects, however, it often does not provide enough structure.
What’s needed is an explicit approach which directly focuses on the work but is contextualized to the organization using it. I suggest laying out the ideal workflow (value stream network) for the organization as a start. This can be used to identify current impediments to that workflow as well as action items to remove them impediments. A customized roadmap can now be created by seeing the optimal sequence of implementing these improvements.
One of the major tenet’s of Lean is to not focus on individual activities but to look at the flow of value from concept to realization. Focusing on people, btw, is not Agile in my mind. We should be trusting and respecting them – not judging them. They are doing the best they can. management must provide them with a great eco-system in which to self-organize in order to achieve the business’ objectives.
The challenges around velocity illustrate this. If one understood the goal is to shorten cycle time (the time from concept to realization) it would be clear that managing (not measuring) velocity has no value. Many of the challenges we have in Scrum and SAFe is because these frameworks have us subtly look at the wrong thing.
But these things sure look important so someone sometimes has to shake us up to look at the right thing. The beauty is, once we look at our present in the right way, we can reflect on our past and instantly get a lot of experience. This is why newbies don’t have to be patronized and told to just use things as they are. They can think for themselves with years of experience once they know what to look at. This is the difference between giving advice and giving a new way to see a problem. I prefer the latter.
Scrum is based on empirical process control. If I understand this correctly, this means that we base our actions on what happens and inspect and adapt accordingly. Scrum is accordingly set up with a set of rules, roles, artifacts and events designed in such a way that if they are followed good results will happen.
Continue reading “The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)”
I have learned that developing good habits is key in improving my abilities. A series of good small decisions can often prove to be better than infrequent good ones. The most effective way to develop a habit is to have a trigger for it. That is, when an event occurs, do the thing you want to. Otherwise good habits just devolve to good ideas that don’t happen.
One good habit is to validate you understand something that someone has requested of you. In this case our trigger can be a request. The habit is to validate it by asking them what their acceptance criteria is. This doesn’t mean that they are right in their criteria – people often ask for the wrong thing. But a critical first step is to ensure you understand what they asked for.
Habit – validate understanding.
Trigger: When someone asks you to do something.
Action: Ask – “how will I know I’ve done that?”
Intention: Validate that what they say matches what you heard.
Habit – understand their why
Follow up Action: Ask – “and why do you want that?”
Intention: Validate you understand their objective as their might be a different way to achieve that.
Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”
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)
Continue reading “The Dark Cycle of Scrum and How To Avoid It”
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.
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.