Yes, I’m frustrated

A friend of mine said I sounded frustrated in my posts. My reaction to myself was, of course, that I’m not supposed to be frustrated. But the truth is, I am

The reason? After 20 yrs of working to help people see how to do their work better I find I’m fighting the same battles I was 20 yrs ago. Only the difference is now we know what to do & there are active forces working against it. Waterfall was just an ineffective belief system-but no one was behind it.

Back then no one understood Agile or Lean or test-first or the importance of flow. We didn’t have modern learning methods nor the technology we have now that enables remote, on the job training.

The choice no longer has to be Scrum or Kanban but rather an integration of the two in a manner that works. It has been demonstrated that learning ATDD/BDD up front is critical. Learning how to be an Agile coach should be multi-month program working with your team on how to help them be more effective. And improving organizations must be based on increasing the ability to take strategies through deployment & realization

Unfortunately, our focus is on frameworks & certification. While containing good ideas they distract us from the real work at hand. If you have this sense as well, as always, I’m happy to chat

A metaphor for team agility – GPS systems

Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.

Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.

Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.

A metaphor for team agility – GPS systems

Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.

Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.

Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.

Two approaches to training – you get to decide which you want

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.

How Frameworks Help Us and Hurt Us

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.

Using a Flow Model to Guide a Transformation

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.

Using Lean to Focus on Your Work

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.

Two Different Kinds of Training (admittedly a rant)

The prevalent kind of Agile team training is:

  • here’s what to do
  • follow it until you understand it
  • you can fill in the blanks, but don’t change the foundation
  • if you do, we can take no responsibility for results because then you’re not doing what we said

Continue reading “Two Different Kinds of Training (admittedly a rant)”

The Future of Agile

Here are some of the things Agile has demonstrated to be of value.

  • Having self-organizing small teams
  • Building incrementally
  • Taking an iterative approach

However, an organization is not merely a collection of small teams, it must also do the following:

  • Have a vision to guide what is built
  • Have collaboration across teams

All this means we need an ecosystem that illuminates the vision and allows teams to self-organize to achieve it. Continue reading “The Future of Agile”

The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)

In previous posts, I discussed that the first leg of emergent design is TDD, which provides code quality and sustainability. The second leg is design patterns, which provides insights into handling variation. The third leg is ATDD, which provides us a way of discovering and clarifying the value we will get. Continue reading “The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)”