Agile Developer Habits 101 – Focus on Finishing to Manage Work in Process

Kanban suggests we manage work in process (WIP). Many people interpret this to mean add WIP limits on queues. But that’s not the only way to do it. And it often takes a very disciplined team to do that.

An easy way to start managing WIP is to simply build a habit of looking to finish something before starting something new.

Habit – manage Work in Process

Trigger: When you complete a task.

Action: Look to see if there’s another task that’s already been started that you can finish. If it’s yours, just finish it. If it’s someone else’s see how you can help them.

Intention: Avoid increasing WIP above capacity without having to put a lot of effort on it while also creating opportunities for cross-learning and collaboration.

Announcing On the Job, Online Training for Scrum & Kanban Coaches

The best way for people to learn is on the job over time. The worst is in a 2-4 day course with where you learn information about something but don’t get a chance to try it. Studies have shown that 90% of what was learned in a classroom is forgotten in less than a week.

5 years ago I asked myself – “what would I do if a company asked me to train their thousands of Agile coaches who needed to become more proficient?”

We think we’ve come up with the best way to deliver on this. It also turns out to also be the most economical. The format we use is called “flipped classroom”, a method developed at Harvard. Essentially each lesson starts with a reading and video. An assignment is then given that participants work on with their team. Two live sessions are also provided so participants can ask questions before and after their assignment. Participants learn by doing while having the support they need. In addition, participants are provided access to an online support system that covers virtually all of the common challenges faced by teams. In this way participants can learn both the curriculum they need and get help on their own specific problems. The next program starts 1/28. Contact me if interested.

Elephants in the Room and No Clothes on the Emperor

There are many things I, and many other consultants believe, that are not politically correct to talk about. I am going to talk about them now. The reason is if you are a practitioner and these resonate with you, then you might want to consider working with people like me to help you get better. If you don’t want to work with me, then use this as a checklist to vet your potential providers.

Both coaching & training is more expensive than they need to be. Much of this happens because the certifying bodies control the number of trainers by quantity. Many of the top trainers in the industry have no certification by choice.

The biggest problem with the Scrum-Kanban confrontation is that neither are the right thing to do all of the time. Usually some combination of the two is best.

Intense training, except where people do hands on work is effective. True learning takes place over time in the learner’s workplace.

People need a support system that can be used to provide them insights into their own problems. Reinventing the wheel should not be required.

AFAIK our Advanced Scrum Master / Kanban Online Workshop is the only workshop that fits the above. It’s worth checking out.

How I define Lean-Scrum (how Net Objectives does Scrum)

I mostly love Scrum, but I am concerned with that it:
1) doesn’t work everywhere but is promoted as if it does
2) sets up a sub-conscious resistance to go beyond it as because the case where “We do Scrum, but we do X instead of Y” is virtually always considered negative whether it is or isn’t. Also, when you are certified in Scrum and go beyond it the value of your certification is lessened

Lean-Scrum differs from Scrum in the following ways:
1) Scrum practices & roles are considered to be ways of achieving particular intentions
2) The team needs to fit into the context of the organization
3) Any part of Scrum can be modified as long its intention is still retained. This may have you no longer be doing Scrum but you should still be doing some form of team-agility
4) It considers Scrum as a tool in a toolbox with other tools being needed (e.g., Kanban)
5) Scrum mostly works iterations & cross-functional teams are advisable
6) We don’t really care if we’re doing Scrum or not as long as we’re consistent with Lean principles
Lean-Scrum is an approach where use take what’s useful and leave what isn’t.

Be clear, Lean-Scrum is not Scrum. But my 19 years of doing & helping others do Scrum has demonstrated it is more effective

Making Frameworks Elegant: Avoiding the Simplistic or Complicated Trap

I define elegance as enhancing while simplifying.

These two have to go together. The result of enhancement without simplification is complicated. The result of simplification without enhancement is simplistic. In tour complex world both of these extremes are high risk approaches.

In the “enhance alone” approach we have people trying to follow something that tends to grow over time. But this inherently creates confusion. People also don’t usually have the time to learn all of the necessary intricacies. What happens is they proceed with a limited understanding and make up things as they go forward. This causes confusion and going back to old habits.

In the “let’s keep it simple” approach, people are forced to figure things out to fill in the gaps. This may work for early adopters, but is not so good for others. The result is again going back to old habits.

We often hear proponents of frameworks following one of these approaches exclaim that things would work if people would only use the framework. But that ignores the reality of how people adopt new ideas. Without clarity, old habits return.

While it is difficult to create an elegant approach, it can be done, and you should not accept less.

The Next Chasm To Cross

There is no question that Agile at scale has crossed the chasm. I would say that even the late majority is now involved. But where are the innovators and early adopters now? I would say they are:

  • Using operating models instead of frameworks
  • Focusing on business agility
  • Driving from Lean principles
  • The use of scaled leraning

However, as I go to conferences & write posts on social media I see that these endeavors are not limited to innovators anymore but are being pursued by many early adopters – the so-called “pragmatists.” The “chasm” between early adopters and the early majority is already being crossed.

I am seeing more and more companies who are looking for what works, even if they have to fill in the blanks a little themselves. While frameworks provide set solutions with some leeway for filling in the blanks, they rarely fit organizations perfectly. Also, current frameworks are based more on Agile than on Lean (even SAFe which incorporates many Lean principles supports a bottom up implementation approach). I think (and hope) that 2019 will see a crossing the chasm of the above topics. To facilitate this is the purpose of my new book and some new social media collaborations. Let me know if you’re interested.

FLEX is not another framework

FLEX is based on a different mindset than current frameworks. Most frameworks have a set structure within which you can add practices. People want to know what to do and frameworks provide this. But the pervading idea is that at the beginning people must just adopt the framework. This has two bad side-effects which I believe are the causes of much of the bad Agile we see out there. The first is that the framework rarely fits the organization perfectly. A slight variance is not bad, but the disparity between the framework’s starting point and what would fit them better creates a dissonance. This not only hurts effectiveness but often creates resistance because the dissonance will create extra work for people who are already overloaded. The second side effect is that you are subtly teaching people to follow.

The way to solve these two challenges is not difficult but takes experience. The first is that some method of tailoring the framework or starting point must be used. The second is that you always emphasize the why of any practice and provide a method for improving or substituting it when challenges occur. Both of these can draw from the deep experience 20 years of Agile now provides – giving us patterns of challenge and success.

It’s important to understand what really needs to be worked on

Experience has shown that virtually all workflow problems can be distilled down to delays in:

  • workflow
  • feedback after a decision or activity
  • value realization
  • knowledge transfer

These all not only delay value delivered but they literally increase the amount of work to be done. Lowering them is critical and can be done by:

  • Managing queues
  • Having small batches
  • Creating visibility
  • Automating testing
  • Having a test-first attitude at acceptance and unit level

It is important to note that most frameworks’ practices work on these items indirectly. Consider the impact of time-boxing & retrospectives.

There is no reason not to work on these directly. One, of course, can add this to most any frameworks, but be forewarned, doing so will likely lead to activities inconsistent with the framework.

My belief is that frameworks should be designed by working on these issues directly & giving practices that support them as a starting point. Then as people learn more they can refine their practices. That way we can use the framework but not be limited to its practices while still being clear whether what we’re doing is good or not.

20 Years In a Week

I try to take a scientific approach to things. I view frameworks & methods as hypotheses for how to best be effective. If I disagree with the hypothesis, I’ll speak about it. Some ppl don’t like that. But in the information age, methods are public knowledge & we should learn from them, not make them dogma. Learning from them also means improving them

When I started Net Objectives (20 yrs ago 1/1) I did it on the basis of adding value to the industry. I’ve always liked Earl Nightingale’s perspective that money received is a measure of value delivered. That’s served me well.

My drive has always been how do I help others learn and become effective. Over the last 20 years I have learned a lot by being a consultant, including:
1) people know a lot more than they give themselves credit for
2) people will listen to a consultant’s dogma as if it were ok that they have dogma
3) people won’t figure out things on their own if they haven’t already, but they are smart & can learn quickly if you give them a little guidance (not tell them what to do)
4) there’s no one-size fits all but there are many best practices that work almost everywhere, yet aren’t popular

If you have a sense that Agile can be better than it is, please drop me a line. I think I can show you why you’re right.

Let’s not put limits on our methods. And let’s not accept methods with limits.

Here are two serious questions:

1) As a provider of a framework whose intent to increase the ability of an organization to deliver value more quickly, why would you put limits on what could be in your framework? This means limits on both what could be added to the framework or what could be substituted for any of the frameworks rules, roles, practices and events? If you do, you are limiting the effectiveness of the framework.
2) As an adopter of a framework with the intent to increase your organization’s ability to deliver value more quickly, why would you accept limits by the framework you wanted to use? In other words, if something was more effective than what was in the framework, you’d have to stop using the framework to adopt the practice, … Why wouldn’t you find a framework that didn’t require this?

As far as I can tell, the only real acceptable answers are:
1) I don’t know how to do otherwise
2) I don’t know of a framework that doesn’t do that

Let me know if you have other answers.