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.

Agile Developer Habits 101 – How Will I Know I’ve Done That

I have learned that developing good habits is key in improving my abilities. A series of good small decisions can often prove to be better than infrequent good ones. The most effective way to develop a habit is to have a trigger for it. That is, when an event occurs, do the thing you want to. Otherwise good habits just devolve to good ideas that don’t happen.

One good habit is to validate you understand something that someone has requested of you. In this case our trigger can be a request. The habit is to validate it by asking them what their acceptance criteria is. This doesn’t mean that they are right in their criteria – people often ask for the wrong thing. But a critical first step is to ensure you understand what they asked for.

Habit – validate understanding.

Trigger: When someone asks you to do something.

Action: Ask – “how will I know I’ve done that?”

Intention: Validate that what they say matches what you heard.

Habit – understand their why

Follow up Action: Ask – “and why do you want that?”

Intention: Validate you understand their objective as their might be a different way to achieve that.

 

 

 

The Differences Between Scrum and Kanban

Looking at differences between Scrum and Kanban can help us see which will work better for us.

1) Scrum requires planning the sprint ahead. You can plan in Kanban but it’s not necessary and normally isn’t done.

2) Scrum requires cross-functional teams, a good thing to have. Kanban doesn’t but this often misses the opportunity for team structure improvement.

3) Scrum requires starting with its roles, practices, events & artifacts. Kanban allows you to start where you are & provides a transition model for improvement.

4) Scrum improves by removing impediments. Kanban improves by focusing on shortening cycle time.

Teams that don’t like to be told what to do may resist Scrum. Kanban requires more discipline from the team than Scrum.

Factors to consider when deciding which to use:

* culture – including resistance to being told what to do and attachment to roles

* nature of work being done (plannable?)

* ability to create cross-functional teams

Note that executives can better relate to Kanban’s focus on flow. Combined with its insistence on visibility, executives can better understand the importance of managing workload.

In few cases is one clearly superior to the other. Taking a blend of the two often makes sense. Doing this is not difficult. 

Why I Believe My Advanced SM/Kanban On-the-job Online workshop is my biggest contribution to Agile

Given I’ve written 5 books, delivered 100s of courses/talks/ webinars, influenced Scrum, Kanban & SAFe, that’s a big statement. I think it’s true because I hope its introduction of proven methods of training/coaching developed at Harvard will prompt the Agile industry to improve current methods which I believe are outdated and one of the biggest impediments to the widespread adoption of effective Agile.

Consider:
• Common training formats are ineffective and expensive. Intensive 2-4 day workshops have been shown to be the least effective method of conveying skills. These also incur the cost of lost days and possibly travel to take. Flipped classroom methods are both more effective and much less costly to deliver and incorporate follow up coaching
• Content. Being effective requires both Scrum and Kanban. Each are selective views of Lean, which is now recognized as a critical component of Agile beyond a team.
• Lack of a support system. There are patterns of challenge and solution which should be provided to students so they get assistance in solving problems on their own

Bottom line – this method can increase the effectiveness and content of a course while dramatically reducing real cost

You can learn more about this course here.  Take the overview box (mostly black) for a 28 minute overview of the class that explains both content and format.

An Open Letter to Participants When We Go In To Train

Among the things needed in the Agile space are better training methods and a better way to use frameworks. This pertains to all organizations coming to Agile:  They are rightfully concerned about what the kind of Agile training they’ll get. They want improvements, not frameworks. At best, frameworks are a means to an end.

Recently, I wrote to such an organization with these concerns. It had a proposal for a small-scale adoption of Lean-Agile involving 3-10 teams with associated Product Owners. Continue reading “An Open Letter to Participants When We Go In To Train”

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.

What The Software Industry Needs the Most

What The Software Industry Needs the Most

For almost 50 years I’ve seen the software industry continuously expand. This has had the demand for qualified people outstrip the supply. It greatly expanded with the PC in the early 80s. 15 yrs ago it was regarding Agile & now it’s regarding Agile@scale. This will continue.

How can we bring this under control? Throughout this time there has been one constant–attempting to solve it with in classroom training and coaching. This has never been cost-effective, being both expensive and ineffective (little is retained from training that doesn’t have people actually do real work). More recently the industry has gotten so enamored w/frameworks that most training is in frameworks & not in what to actually do.

The solution? Actually simple.

Provide training via scaled learning methods on what people actually do and in an on-the-job manner. A self-directed support system with remote support should also be provided, greatly reducing the need for expensive onsite coaching. The improvement in cost per learning can be dramatic:

  • 2x  material delivered via better training methods
  • 40% lower delivery cost with better training methods
  • 10x better retention

This literally improves ROI by up to 50x. I know this sounds dramatic–it is. It’s also possible.

Agile Can Be Simple But It Must Be The Right Simple

Simple is a big word in Agile.

But there are two cautions to being simple.

Einstein – “things should be made as simple as possible, but not simpler”

Mencken – “for every complex problem, there is a solution that is neat, simple and wrong.”

One way of going for simple is to focus our attention on selected things. This makes sense. Too broad a focus is difficult. But what should we focus on? That will determine our actions.

Every successful Agile improvement initiative I have seen has included a focus on product management, an effective intake process, building things in small batches, and proper coordination across teams when multiple teams were present.

The question isn’t do we need to do these things, the question is what’s the best way to learn to do them? Frameworks provide us with events & roles to encourage this. But learning them directly is more effective. Back in the day we weren’t as sure how to do this, but we do now.

The challenge with learning frameworks first is that it defers learning what’s truly important. Frameworks should support our learning, but not take our focus off of what we really need to know.

How Frameworks Are Being Used Now Is Impeding Agile and What We Can Do About It

Part 1: Frameworks are taking our eye off the ball

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

How Frameworks Are Now Impeding Agile: Part 1

We cannot solve our problems with the same thinking we used when we created them.

There is no question that Scrum & SAFe have transformed how we work. Both have created a new mindset around work- Scrum focusing on the importance of team & SAFe focusing on the necessity to coordinate teams.

And both have now created new challenges in somewhat the same manner. Each has taken our eye off the real task- working in an Agile manner. This is finding what’s of greatest value, allocating our capacity to work on it, properly decomposing it so it can be built in increments and being able to deploy frequently/continuously. Scrum’s focus on ceremonies has takes peoples’ eyes off of how they do their work – leaving it to the team with the unquestioned assumption that they’ll figure it out (& then blaming them for not doing Scrum if they can’t or change anything in their attempt).

SAFe has gotten management involved but mostly to demand that SAFe be done. SAFe is often led internally by agents who demand that SAFe be followed. Again, the focus is on the framework.

Frameworks were an excellent way to go when we didn’t understand the mechanics of Agile. We do now. We should attend to them or at least drive our frameworks with them.

How Frameworks Are Now Impeding Agile. Part 2 – Scrum

Take a look at the common challenges teams have when adopting Scrum:

  • not being able to write small stories
  • essentially doing waterfall in 2 week cycles-Scrumerfall
  • having many open stories at the end of the sprint
  • difficulties poised by being interrupted in a sprint
  • not being able to coordinate well with other teams

The similarities across widely variant dev groups is striking. Not a surprise since systems-thinking would predict this. While Scrum proponents claim “if you did Scrum these things wouldn’t happen” is likely true, what does that matter? People are doing their best.

We need to attend more to what insights & skills would help us avoid these challenges directly.

The above challenges are due to not attending to:

  • flow
  • managing work in process inside the sprint
  • the team’s part in the bigger picture

Yes, I know Scrum doesn’t say not to do these, but that’s not the same as saying to do them.

In the early days just getting teams co-located, cross-functional & working in small chunks was a major improvement. To go to the next level we need to shift our focus to the work & how to do it.

How Frameworks Are Now Impeding Agile. Part 3 – SAFe

Many people complain that SAFe is too complicated and doesn’t truly get management involvement. I would agree. But why is that?

Take a look at the common challenges organizations have with adopting SAFe:

  • little improvement beyond the program
  • little improvement in the area of portfolio management
  • difficulty resolving conflicting requirements given to platforms and shared services
  • a continuation of top-down management
  • too much work in play overall
  • not being able to get deliveries within a program increment

The similarities across widely variant organizations is striking. This validates systems-thinking’s assertion that the system people are in causes behavior. SAFe proponents claim it addresses the main issues & people just need to fill things in. I would suggest that the way SAFe addresses these issues prevents people from filling things in.

Pre-defining roles & artifacts takes our eyes off of the value stream and the work that is taking place in it. This is exacerbated by SAFe overloading and redefining terms.

In the early days getting a plan for a program & having teams work together towards that a major improvement. To go to the next level we need to shift our focus to the work itself.

How Frameworks Are Now Impeding Agile. Part 4 – The Solution

Actually, if you’ve been following my train of thought here, you’d know there is no solution. But there is an approach that will lead to a solution. It’s using Lean as an overall context for your work because Lean focuses directly on the work. Lean can help achieve business agility – the quick realization of value predictably, sustainably and with high quality.

Lean provides insights to shorten the time from beginning work until value is realized. It does this by starting with the question of what’s value to the customer? Then attending to the value stream so that we can improve it to eliminate delays in workflow and feedback. By attending to queues of work we can see where our bottlenecks are and improve them. Instead of overloading teams we have them manage their work by implementing pull systems. And, because we’re looking at improving our work directly we can continuously improve.

Fortunately, this doesn’t mean we have to re-invent the wheel. All we need to do is look at the outcomes we need at each step of the way and select the best method for us to get there. This is true agility – figuring out how to solve our problems instead of taking canned solutions.

A Simple Solution to Agile at Small-Scale

I keep running across organizations with 4-10 dev teams struggling with Agile. They look to the two most popular frameworks out there for a solution (Scrum & SAFe) to solve their problems. On one hand they see something that can work at the team but doesn’t help them with their product management. On the other they see something much bigger than they need. They’ve fallen into a trap–looking for a solution instead of solving their problem

What are their problems? Most have trouble Identifying what has the greatest value to deliver, breaking it down into the right size business increments to give to the teams, coordinating their teams’ work, teams not being able to decompose the business increments they’re given into small stories, and building, validating and releasing the code quickly. These abilities should be their focus

When Agile Product Management provides guidance in what’s important, coordinating teams is straightforward. It’s easier to pull a rope than it is to push it. 2-3 days working on prod management, ATDD, a little Scrum and a little Lean is all you need. Invest here, it returns more value. And it’s less expensive. Proper training &coaching methods can get your product folks, 6 teams & their coaches working with Agile methods for less than $40k