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)”

Shift Your View To What’s Important

One of the major tenet’s of Lean is to not focus on individual activities but to look at the flow of value from concept to realization. Focusing on people, btw, is not Agile in my mind. We should be trusting and respecting them – not judging them. They are doing the best they can. management must provide them with a great eco-system in which to self-organize in order to achieve the business’ objectives.

The challenges around velocity illustrate this. If one understood the goal is to shorten cycle time (the time from concept to realization) it would be clear that managing (not measuring) velocity has no value. Many of the challenges we have in Scrum and SAFe is because these frameworks have us subtly look at the wrong thing.

But these things sure look important so someone sometimes has to shake us up to look at the right thing. The beauty is, once we look at our present in the right way, we can reflect on our past and instantly get a lot of experience. This is why newbies don’t have to be patronized and told to just use things as they are. They can think for themselves with years of experience once they know what to look at. This is the difference between giving advice and giving a new way to see a problem. I prefer the latter.

The Insidious Side of Scrum and How I’d Fix It (and yes, I know it wouldn’t be Scrum anymore)

Scrum is based on empirical process control. If I understand this correctly, this means that we base our actions on what happens and inspect and adapt accordingly. Scrum is accordingly set up with a set of rules, roles, artifacts and events designed in such a way that if they are followed good results will happen.

I believe it to be true that if you in fact do what Scrum tells you to do you will get good results. But that’s not a huge endorsement. If you follow a financial advice system that says to buy stocks low and sell them high you’ll also make a lot of money. And if you don’t, it’s providers can always say you didn’t follow the method.  The question is not if Scrum’s practices will work if you follow them, it’s can you always follow them? And even when you can is it the best way to go? And, perhaps more importantly, does taking this attitude that you should learn how to be Agile by using Scrum defined exactly as it is the best way to go? Because we must remember, our goal is not to do Scrum. Our goal is to be effective.

Let’s look at the typical way teams are told to adopt Scrum. It is suggested that they follow Scrum’s rules, roles, artifacts and events. But what if the team has problems with doing this? They are told to keep at it until they can do this. Since many of the teams are new to Scrum and Agile they are told to trust their trainers and coaches (in other words, not trust their own thoughts about what might not be working but to do what they are told). Personally, I find this somewhat disrespectful. People know a lot about their jobs and as a coach I wouldn’t expect anyone to do something merely because I said it’s a good idea. If I can’t get them to see it’s a good idea then that’s a failing on me.

But there are two other problems here. One, it may not be possible to follow Scrum’s practices. And two, even if possible, it may not be desirable. I have seen many cases of this over the last 20 years of using Scrum. Yet, in 10 years of discussing this I have yet to have one CST (certified Scrum Trainer) admit to such a possibility even though I’ve given them dozens of cases. Instead they always claim if people were committed enough they could do it. In other words, they don’t acknowledge Scrum may be off, but rather people just are not committed enough to do Scrum (implying, of course, that Scrum is the right thing). But wait a moment, what if there is a better way? Why stick to Scrum? Is it really always the best way to become effective? Sounds like brand selling to me. And that’s not a bad thing – you wouldn’t expect a Chevy dealer to say a Ford is better.

Here’s the problem. When Scrum is taught, the training almost always focuses on the framework. This makes sense. If it focused on the actual laws of software development there’d be no Scrum brand involved. In any event, Scrum isn’t based on the actual laws of software development. It’s based on  empirical process control. But that doesn’t mean that’s what it should be based on – this is just an a priori assumption that is always accepted. But Scrum is what it is. So when there are problems, there is no basis for figuring out how to solve them other than following Scrum’s rules. People intuitively know this is not quite right. So resistance is not uncommon. When things don’t work well, people often don’t like to keep doing what’s not working. Even if they try, if they are in a situation where Scrum is not ideal, at some point people will give up. But since they don’t know what else to do they will likely just drop a Scrum practice and voila you have Scrumbut. From Scrum.org’s site – ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”

And now Scrum is off the hook because although the team is not getting effective, Scrum’s proponents can claim it’s not their fault because the team is not doing Scrum. Yes, the team is not doing Scrum. But Scrum’s definition is partly at cause. I believe what’s needed is to integrate how to remove dysfunctions into our Scrum training so that we have the opportunity to remove dysfunctions whether the solution strictly follows Scrum or not.

So what can we do instead? There’s a lot of evidence that taking an approach based on the Lean principles of systems thinking, just in time (reducing delays in workflow and feedback and in acting no new information) is more effective, Can we take the rules, artifacts, roles and events of Scrum and implement them within a Lean-thinking approach instead of an empirical approach? What would happen if we did this? Full-disclosure – doing this would result in something not Scrum. I’ll call it Lean-Scrum to differentiate. This is because The people who invented Scrum (Ken Schwaber and Jeff Sutherland) have the right to define what Scrum is.

So how would Lean-Scrum work and how would people trying to adopt it manage the situation where Scrum doesn’t work well?

Lean-Scrum would essentially say to start with Scrum but consider its roles, rules, artifacts and events to be examples of what could be done. That each of these have an object. If the practice of Scrum works then great – do it. But if not, teams should feel free to find another way to do things. This must be done in a disciplined way. This can be accomplished with this four-step process:

  1. Are you having challenges with the practice because it is being done poorly? If Yes, then inspect and adapt and see if you can do it better. If No, continue.
  2. Is there something else in the organization that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.
  3. Is the ecosystem that the team finds itself in causing the problem? That is, are people not collocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).
  4. What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

Step 4 begs the question of telling if you meet the objective of the practice in a different way. This can be determined by looking at the underlying principles in software development. This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We therefore must always be diligent and validate any change we make.

The measure to use is the value stream impedance scorecard. In a nutshell, the VSIS indicates how much resistance the system will impose on work being attempted. It is based on what improves total value manifested. Lowering this resistance usually results in more value manifested.

Psychologically this is a much better approach. Now people have a solid starting point. But if they have challenges with it, they can think for themselves and come up with what they think is a better way without just going off the deep end.  Hence, they don’t resist and can self-organize in more effective methods. Scrumbut can be avoided because people will understand what they need to do. It also avoids the stigma of being taught Scrum but then having to abandon it. Staring with Scrum and then going beyond it feels wrong – especially to management who said the team is going to do Scrum and just paid for Scrum training.

We call this approach Scrum as Example because it considers Scrum as an example of what we could do and that we can do other things while still being effective.

I’ll close this article by asing why is it that people do Scrumbut? If we trust and respect people the only conclusion we can come to is that they don’t realize it’s a bad thing. So why don’t we give them the understanding to realize that? When you believe software development needs to be controlled by an empirical process it’s because there is no understanding of it – one can only see it by doing it. There is no model that could explain it. When you believe that Lean-Agile principles can explain it, however, then we show people why Scrumbut is a bad thing and how to avoid it.

INVEST is a goal, not a guide

I–Independent
N–Negotiable
V–Valuable
E–Estimable
S–Small
T–Testable

This is almost universally used to teach how to write stories. But notice, it’s a goal, not a method. Goals are good, but in themselves, don’t provide much guidance to get to them (think “buy low sell high”).

A better way to learn to write stories is to take advantage of the discovery & specification phases of Acceptance Test-Driven Development (ATDD). While usually relegated to the 2nd or 3rd round of training we’ve seen light-weight ATDD integrated with initial Scrum training enables teams to write stories right out of the box and eliminates 3 of the major challenges most teams have adopting Scrum:
1) writing small stories
2) having clear requirements
3) understanding why testing cannot lag coding

This is the key to learning Agile- not just learning the end state desired, but using methods that actually help get you there. It is easier to act your way into a new way of thinking than think your way into a new way of acting.

ATDD has the dev team focus on identifying and validating (Testable) Small chunks of Value by “Negotiating” with the PO. Part of ATDD is to decouple (make Independent) the stories. Since these stories are now understood, they are also Estimable.

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.

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