Monday, September 2, 2019

Q and A on Velocity, part X

In the last installment we talked about communication between managers and employees, efficiency notions, and other key continuous improvement ideas.

This installment let's pick up on the idea of doing great work quickly.

A: You have said several times that something has to change for work to be done faster. Skills and stuff to make the work easier. Is that the right way?
B: If and only if the bottleneck is actually in development, it will help.

There is some good material here from A. In fact, skills and tools and knowledge can make the work progress faster. A developer with deep knowledge of their tools and stack can get work done in a tiny fraction of the time it takes a less knowledgable developer to figure out how to get a result.

This is often misinterpreted as "a 10x developer" but really it's a 1x developer surrounded by other 1x people who just don't know the stack, the code base, or the tools as well. If you like a 10x devs, invest in helping them learn to go faster. This is expressed in Modern Agile as "Make People Awesome", and in the Agile Manifesto as "give them the environment and support they need."

But let's move on...

A: Okay, then. Let's assume the bottleneck is development. What do we change?
B: Whatever makes it difficult or risky to delivery working code now.
A: How do we know what that is, or what to do instead?
B: Experiment. Some changes help, some not.

Since I've started this blog series, I have had a series of workshops where I ask the team "what makes you go slow?" It really isn't a difficult question to ask. In the right (blameless) environment, teams are happy to tell you where the problems are.

Most of the time, teams don't know how to fix the problems, or they don't know how to acquire the time and support they need (see Agile Manifesto principles, again) to solve the problem so that they can go fast. Here a manager can make a real difference.

Supporting experiments and other efforts to relieve bottlenecks isn't just good agile practice, or good empiricism, or good Modern Agile ("experiment and learn rapidly"), it's good management and good business. Leaving people stuck with drag-inducing problems while exhorting them to move faster isn't good form. Better to be effective, right?

A: We can't afford to do that. I told you our schedule is tight. Can we only do things that work and not waste time?
B: If you can't afford to experiment & learn, you can't improve. Do the best you can with the velocity you have. Order work by value. Descope.

If we can't afford to learn and experiment, then we can't afford to go faster. Full stop.

Is it okay to be seen learning and trying things at work? What happens if you try something and it doesn't work? How does that line up on the annual review?

We hope an experimental and informative, mindful approach to software development is seen as a positive by the organization. It has happened, though, that speed is rewarded and knowledge is rewarded, but no concession is made to the acquisition of speed and knowledge. This makes retaining motivated people very difficult.

A: We can't descope. We can't miss the date. We can't experiment. What else do you have?
B: Fail as well as you can. Give the best result you possibly can, considering that you'll fail.

We have referred to "the best possible failure" as a goal for timeboxed work. We slice work into pieces and then slice the slices. We find that if we can put a bunch of little slices into the timebox, ordered by importance/priority, then when time runs out and we're not fully finished we will have the most important work finished and integrated.

The worst failure is to have 100% of the work 90% done. Nothing is deliverable or useful. It's a mess.

To have 90% of the work 100% done is a qualified success. It's not 100% successful, but that 90% functionality is usable, functional, demonstrable, sellable. It may not satisfy everyone, but it can help some people. It gives partial value, and that's a damned sight better than zero value.

If you can't go faster, then make the best of the speed you have. Fail as well as possible.

A: Is that all?
B: No. Remember development may not be the bottleneck.

Organizations are shocked and upset to find that their 45-days-to-market lead time can't be improved (much) by speeding up programming because programming isn't the primary consumer of time in their case. 

In some cases halving coding time, if even possible, would produce results in 44 days instead of 45.
Software work spends most of its time waiting in queues. 

  • Approval queues. 
  • Prioritization queues.
  • Review queues. 
  • Waiting for other work to finish first. 
  • Waiting for testing. 
  • Waiting to be repaired. 
  • Waiting until the current production crisis is over. 
  • Waiting for an expert to answer a question or become available to consult on it. 

And it's worse than it sounds because these queues are wrapped in loops. 

  1. Code waits for the programmer to be available, b/c they're busy on something else
  2. Programmers work on the code
  3. The code waits for a code review, b/c the reviewers are busy 
  4. If the code review sends the code back to the programmer for changes, goto 1
  5. The code waits for a testing build on an official testing server, b/c servers are busy.
  6. The code waits for a tester to be available, b/c testers are busy.
  7. The tester waits for the code to be built and installed on an official testing server because the server has just been made available to the freshly-available tester and has to be prepared.
  8. The testers test the code.
  9. If any anomalies or improvements are noted, goto 1
  10. Code waits in a batch with other code to be deployed.
  11. If there is a problem with deployment, goto 1 for troubleshooting and remediation.

What if a change cycles at 4, then 9, then 4 again, then 9 again, then 9 one more time?  How long are these waits? 

If, as is often the case, 95+% of the time is waiting then programming twice as fast may yield you a 2.5% improvement in time-to-market. Whee. Not very impressive is it?

But if this is your situation, then it is very good news

You don't have to be a technical genius to fix human waits and queues. It only takes someone with some managerial chops and some systems thinking. 

You can do it. You can make the BIG difference in time to market.

You can give your staff the environment and support they need. Is it training? Information? Thought leadership? Faster computers? Learning to prevent defects? Learning to use their programming stack more effectively? Eliminating silos (working together with people rather than queuing)? 

You can change the system. You're a manager. You have skills and latitude.

Isn't that good news?

Monday, August 26, 2019

No Common Sense in Agile

People say that agile is “just common sense.” 

I wish.

I mean, it’s well-precedented and everything makes sense. But there is nothing common about it. 

It’s still a counter-cultural and counter-intuitive movement, to such an extent that most companies can’t tolerate it and have to compromise and cripple it immediately, even during adoption. Often before adoption.

Two problems with the “common sense” label:
  • It’s not common at all. 
  • It’s unpalatably sensible.

Just the simple idea of forming teams with all the skills necessary to do the job — that’s so uncommon as to earn an “uncommonly sensible” label.  

The idea of management “providing the environment and support they need” seems so backward to many companies as to be unthinkable (literally — they can’t think this way). 

And let’s not even try to penetrate with the idea of producing code that works every week, instead of (traditionally) code that may work someday when all the (traditionally) not-cross-functional teams finish all the bits and pieces and we (traditionally) take time to integrate it all together and test it in the final days and hours before (traditional) release.

And stopping to reflect on how you can do a better job? Most companies lock into a pattern and continue without ever questioning the way they work. For people to not only inspect but reflect and adapt? People scream “too much change! Thrash! Inconsistency! Hard to predict!” ...and stop all forward progress.  

Every time someone says “it’s just common sense” I want to ask why people aren’t commonly doing it? Because even companies that identify themselves as “agile” aren’t doing these basic things.

And now the aggressively-sensible method is expanded out of software and into other industries where it is equally radical and hard to swallow, but still produces great results. 

If you’re interested, consider how common and palatable and easy ModernAgile is:
  • Make (other) People Awesome
  • Make Safety The Prerequisite 
  • Experiment and Learn Rapidly
  • Deliver Value Continuously
Sensible? Yes.
Principled? Yes.
Common? Not.

Friday, August 23, 2019

The relationship between Agile and Scrum

A lot of people's first brush with Agile is during Scrum training.  There is usually some mention of the Agile Manifesto and its 12 Principles, maybe even 10 or 20 minutes spent comparing these to the scrum principles and behaviors. 

For a lot of these people, it's the first time they have ever read, seen, or heard of the agile manifesto.

If we are really lucky, they might even have heard of the Modern Agile principles. That's pretty cool when it happens.  

But they heard them in the context of Scrum, so they assume that these are supporting documents and of course when they're told "Scrum is Agile" they misunderstand.

The instructor probably meant to say "Scrum done right is fully compliant with Agile Principles and is a fully agile framework" (which I'm not arguing here). 

Unfortunately, most people hear that as the identity function "Agile is another word meaning Scrum. Scrum IS Agile. Agile IS scrum. They mean exactly the same thing." 

They don't recognize that the relationship is between a set (Agile) and a member of that set (Scrum).

I've tried several times to help make this clear and with mixed results. Here is a Venn diagram I made a long time ago:

Sadly, the point was missed. It's easy for people in the scrum world to become defensive because Scrum spent a decade or two being the most maligned agile framework on the planet. Almost all of the "bad agile" in the world was a bad implementation of Scrum. It has been more compromised and twisted and turned against people than any other framework until SAFe emerged. 

The distraction for Scrum defenders here is that I let the Scrum bubble lap outside the agile bubble.
That was very upsetting for some of my friends in the community. I still feel that there are ways to do scrum without having a very agile mentality, but that was not the purpose of the diagram.

That little bit of a bubble was the flaw in the example that destroyed the primary lesson being taught. It's one of the problems with using an abstract model of a real-world ontology; you risk losing people in the example.

I'm a little wiser, though I just republished that one as a counterexample.

I later wrote in some forums that "Scrum != Agile" and that was even worse. It was universally read as "Scrum is anti agile" instead of being seen as intended, that the word "Scrum" is not equivalent to the word "Agile". 

I later had a bit more success by reversing the nouns. When I say "Agile != Scrum" it's easier to see that I mean that Agile has something more/different to it than Scrum.  But of course, Scrum is the most maligned framework currently so there were defensive reactions.

"You're saying that scrum is not an agile framework!!!"
"No, I'm saying that it is not the only agile framework. There is more to agile than Scrum."
"But you singled out Scrum! You are anti-Scrum!"
"I singled it out because it's the only framework that people confuse with being all of Agile."

On it goes.

I don't blame them. It sucks being everyone's whipping boy.

So here's my most recent attempt:

Agile isn't a word that means Scrum.  Scrum is a member of the set of Agile things, as are many others.

I listed XP and FDD just because I needed a couple to kick-start the list not because they're "special" though XP is very special to me.

We'll see if this helps.

My favorite Estimates and NoEstimates exchange so far.

From my point of view and involvement with #NoEstimates we consider the things where the price is unknowable and the desire to know the price interferes with our ability to make good decisions.
9:33 AM · Aug 23, 2019Twitter for iPhone

Likewise, how much will you pay for electricity in the house you live in, all totaled up? Or my earlier grocery example. You don't consider those "buying a lifetime's supply" purchases, because they're ongoing maintenance costs. Hmmmmm........

The benefits of the food or the electricity Is available in tiny chunks, so to speak. The perception of a software project is that it brings no value until it is done. This is of course the whole point. Let’s re-imagine how software development is done.

This is the first calm, rational metaphor I’ve heard that starts to make sense for me. Most #noestimate folks just get angry and insulting. Thank you for the clarity!