A development team working in harmony is a beautiful thing. Every two weeks they get together to decide what they are going to do over the next sprint, and then they proceed to do it. Daily retros keep them on track. Guided by a product owner the team incrementally builds their product increment. A demonstration at the end of the sprint produces value and important feedback to make sure they are going in the right direction. They get better each week with retros. Magic.
Getting to this may be a challenge, however. Well formed teams may not exist and it may be unclear how to make them happen when some people are needed by many teams. Also, the culture of an organization may be such that reorganization is not an easy move.
Another type of magic is possible, however. That’s when people make agreements to get any started work completed as soon as possible and not to start work if it will slow down more important work. They make all of their work visible to each other so they can work as a team even if they aren’t dedicated to it. They continuously improve with small changes. Also magic.
Any company that has more than a few teams can find magic in both approaches, but often only approach is magic for a particular team
In the same way that looking at the value stream helps you observe how value moves, looking at the value stream helps you discover challenges you are facing. Here are some of the most common challenges.
- It takes too long to get anything done
- Work is not properly prioritized
- Chunks of work are too big
- Too many things are in work
- There are unclear requirements
- Teams don’t understand the needs of the business
- Some people have too much to do and are constraints on multiple teams
- There is high technical debt
- There are many integration errors
- There is insufficient collaboration
- Ops is blindsided and pulled in many directions
- There is a lack of visibility of what is taking place
Often, these challenges are apparent when work is stuck in large queues just before the step where the problem is. Lean suggests that instead of focusing on how people can work faster, you should take steps to keep queue size down. Usually, this involves working on small batches, how you do work, and how you organize talent.
The two major lessons of complex systems are:
1) small events can lead to big challenges
2) you can’t predict if attempts to improve things will work
But this doesn’t mean there aren’t best practices in complex systems. In fact, it means in complex systems you must look for the few best practices there are.
By a “practice” I mean something that:
1) takes little energy to do
2) simple enough that everyone can do them
3) provides value enough of the time to make them worthwhile
Here are some Agile Best Practices:
when given a requirement ask “how will I know I’ve done that?”
- before starting a new task see if there’s a task you can finish or help someone else finish
- have explicit work policies (i.e., have team members know what each other is doing)
While there are others, let’s consider the value of these. The first helps avoid misunderstandings. The second shortens development time. The third helps avoid misunderstandings.
All of these are clearly valuable. All too often we worry about managing big things, and overlook the little things that can make a big difference. While we can’t control complex systems, we should do what we can to avoid chaotic events.
Let’s face it. A 2 day class may be enough to get you understanding Scrum & another one might get you to understand it a bit better, but the only way you learn how to be a good Scrum Master / Kanban Team coach is by doing. This program, led by me, is designed to do just that.
In it, you’ll work through the issues that you are having with your own teams. Each week you will learn something and then apply that to your teams. Weekly Q&A sessions assist you with any challenges you have in doing this. While there is a designed curriculum, our integrated support system enables you to pick up topics in different orders while still get assistance from me as needed.
Based on Lean principles, this program will enable you to integrate the best of Scrum & Kanban. Learning takes time.
Ask yourself why take a 2-day class that covers half the material and costs twice as much and then leaves you on your own when you could be in a 3 month program working with your team and having a Scrum/Kanban thought leader helping you?
The class starts 1/18 and is only $595. Please message me for more information. See comments for more info.
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”
Live training always sounds great, and sometimes it is. But except when has your teams work together, or the materials requires a lot of interaction, it’s often not the best way to do things.
Consider the following: Continue reading “Why I’m So Into Scaled Learning”
I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.
The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.
Framework proponents suggest starting with framework training & later adding what else is needed (e.g., prod management, test-first). We believe this leads to a significantly higher cost of training
Companies with more than a few teams need a blend of Scrum & Kanban. Few companies need all of SAFe. The most important aspect of a workshop should be how to work together with your associates
Training should be oriented around
- the context of the people being trained
- increasing collaboration
- learning by doing actual work
- needed essential skills
Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.
Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. Less framework, more how to do is required. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need
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.