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

Why TDD is more about design, emergence & sustainability than testing

With a name like TEST-driven development you’d expect TDD is mostly about testing. Especially when the end result is tests. In our book Design Patterns Explained we discussed how testability (how easily code can be tested) is an intrinsic property of software and is highly correlated with good design. This is why the 1st mantra of design patterns is to design to the behavior of the objects being written. These behaviors being described as tests.

One of the characteristics of good design is that it is modifiable with less effort than poor design. So testing first give us both better design of the code & increase its sustainability-enabling emergence. This is the big difference between test-FIRST and unit testing.

But we now have the added burden of the tests which often add to maintenance costs. The cause of this is insufficient focus on the quality of the tests. An ideal test will validate only one behavior. The intent is to decouple the tests so that when one behavior changes only one test needs to change. This requires attending to the coupling of tests as future enhancements are made. Coupling of tests inform coupling in design.

This is why TDD is a cornerstone of our technical offerings. Just added Javascript to C#, Java, and C++ of languages supported.

The Magic of Scrum, The Magic of Kanban – Why You Need Both

A development team working in harmony is a beautiful thing. Every two weeks they get together to decide what they are going to do over the next sprint, and then they proceed to do it. Daily retros keep them on track. Guided by a product owner the team incrementally builds their product increment. A demonstration at the end of the sprint produces value and important feedback to make sure they are going in the right direction. They get better each week with retros. Magic.

Getting to this may be a challenge, however. Well formed teams may not exist and it may be unclear how to make them happen when some people are needed by many teams. Also, the culture of an organization may be such that reorganization is not an easy move.

Another type of magic is possible, however. That’s when people make agreements to get any started work completed as soon as possible and not to start work if it will slow down more important work. They make all of their work visible to each other so they can work as a team even if they aren’t dedicated to it. They continuously improve with small changes. Also magic.

Any company that has more than a few teams can find magic in both approaches, but often only approach is magic for a particular team

Seeing Challenges in the Value Stream

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

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.