An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
- Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
- Manual testing
- Technical debt
By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”
Errors are going to happen. Trying to prevent them is helpful, but it is often more effective to minimize the impact they have by detecting them quickly.
In software development, waste can be thought of as “unplanned work caused by errors which are usually exacerbated by delays in feedback.” It can come from several sources. Continue reading “Don’t Worry About Process Waste; Worry About Delays & Output Waste”
The most important words of the Agile Manifesto are, “We are uncovering better ways …” This should continue to be true.
Agile is often thought of as a way of being. But getting people to “be” Agile is hard. And it’s not clear what “doing Agile” is. “Being” is good. But getting there is another issue. It requires us to continue to be “uncovering better ways.” Continue reading “Agile is Here to Stay (Or at Least the Being of It)”
I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.
However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.
Here is what I think has been happening. In all of the cases, I started out with:
- Depicting a value stream representing what they’d like to happen
- Adding their team names, relating this to what people were doing now (making it less theoretical)
- Identifying the client’s problems in this ideal flow
At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.
It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.
This is the first of a series on the implications of these insights.
The reason I am not a fan of frameworks is that they mostly have us focus on activities that are proxies to what we need to do to achieve what we really want to do – realize value quickly, predictably, sustainably and with high quality. Lean provides us insights on what to directly work on. Consider these 5 aspects of product development:
Focus on what’s of value to the company. Much of this will be providing better value to the customer some will be on how the organization builds them. This must be quantified for it to be relevant since everyone in the organization must see these driving factors. Use OKRs (objectives and key results) as a basis with strategies and initiatives being spawned by them.
Understand your value stream network details the steps and who does them that it takes to actually create the value.
Focus on lowering the cost of delay which is the time lost to delays in value realization. Organizational structure, development method, size of the work to be done and how people collaborate are significant factors.
Manage the flow of work and the ecosystem through which all of this flows. This includes when work is started and how decisions are made for how people work together.
Continuously improve the above.
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.
A key tenet of Lean-thinking is that we must adopt systems thinking and acknowledge that most of the errors we encounter are due to the system. For example, consider how the geographic arrangement of dev and testers affect their work. Continue reading “An ignored piece of the ecosystem”
After being at Agile 2018 I see more hope for people learning how to become more effective in a more effective manner. People were asking questions and fewer were looking for quick, rote, solutions. Of course, my sample was incredibly unscientific and is anecdotal. But I am an optimist.
I know I have a reputation for seeing the negative in things. But my path has always been: Continue reading “An open invitation for a discussion”
I was asked if Scrum per the Scrum Guide was an instance of Kanban. The answer is no because of the differences in the mindset. Scrum (per SG) has immutable roles, artifacts, events, and rules. These guide you to actions that fit within them. Kanban has principles you look at to see what to do. There are other differences in the mindsets of Scrum and Kanban. Continue reading “Frameworks are just tools. Good ones are instances of Lean”