It’s been a fairly constant point of contention when adopting agile techniques that at some point, someone will say something to the effect of “…it’s not efficient”.
We can’t build the story like that, it’s not efficient…
In order to run an efficient stand-up…
Here’s how we can deploy efficiently…
Using the resources efficiently...
And, they are usually right. Sometimes it’s not “efficient” to do something in an agile way. It is usually, however, much more effective. The efficiency play is a very comfortable thing for most people to want to do. They are proud that they have a history and skill that they have used to optimize their time and abilities to do something in most streamlined way possible. The outcome? Well, we couldn’t really control for that so we did the best we could.
After hearing from someone about an efficiency play, my question is usually, is that going to be effective?
“We built the database story for the new site.”
Wonderful, can the client start to use it and give us feedback?
“Not yet, we have to build the other parts and then test it, it’ll be ready for them in 3 more sprints.
The teams may be building something “efficiently”, but their entire effort was wasteful because they haven’t produced anything of value yet, or worse, the wrong thing.
Being able to build something effectively is more critical than building that same thing efficiently. Once the team, customers, and leadership learn the value of doing things in an effective manner, then and only then, should they progress to doing that same thing efficiently.
“We had an efficient stand up.”
Great did everybody understand what they needed to do?
“I don’t know, but we got done in 8 minutes.”
I worked with a team that built the first version of a graph in an application in 6 weeks. The effort was all towards building that first version and get it to the customers. We came back to that product and built another similar graph in another release. We came back a third time to turn that widget into a component when the need was clear. Then we redid all the apps using that component so that it was consistent for maintenance, behavior, and look and feel. Was that efficient? Hardly. Was it wasteful? I don’t think so.
The teams touched and redid that component many times. If we waited and thought about all the times we might use that as a component, built it that way, and then deployed, we would not have released for months. We would have missed valuable feedback, not learned about what worked and what didn’t, and not improved the experience near as much. Which is more wasteful? Building something over and over, or building the wrong thing once?
From the 5th time on, when we needed to build that graph, we did it in a very efficient manner. The team took the time to understand the needs and I understood that this was something that we could now make efficiently.
The argument is very similar in nature to the Outcome or Output issue.
I know there are some people that would rather use the teams to 100% capacity and see a burndown track perfectly. So what? What did you finish? What value have you added? We’ve proven we can build the wrong thing in record time. Why are you happy about that?
“We finished the initial order process for the sprint, but they still can’t order all the products yet.”
Can they order the most important item from our feedback and tell us how it works for them?
“Yes but we might have to change it for the others.”
It’s a certainty that we will, lets celebrate what they can do now.