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
These challenges are represented in Figure 1.
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.
This is Al Shalloway. Visit us at www.netobjectives.com.
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”
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
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.
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.