Lean Software Engineering

Have you …

• Had an important decision for which you’ve waffled between several viable choices?
• Had a decision that split your team into camps with no consensus and poor buy-in?
• Had a design decision or policy that kept being attacked or reconsidered, months or years down the road?
• Been using Set Based Development — exploring several design alternatives, looking to pick the final choice for this version of the product at the “last responsible moment”?

A great decision making tool for this kind of situation is a Pugh Decision Matrix, with the technique often called Pugh Concept Selection. “Pugh” comes from its originator, Stuart Pugh.

Here’s an example of a spreadsheet, applying our variant of the technique. I was looking at alternatives for buying a cellphone here in the US. Based on what I’ve filled in so far, the Nokia 6682 with T-Mobile is the best choice.

So how does this work? The basic steps of the Pugh Concept Selection Process are

1. Brainstorm alternatives, list them across columns of sheet. Make one alternative the “default” — often it’s the “do-nothing” or status quo choice. This choice is rated zero for all criteria.
2. Brainstorm criteria and characteristics important to the customer. List them down rows of sheet.
3. Begin filling in 1, 0, or -1 ratings in the main area of sheet, based on whether that alternative is better, equivalent, or worse than the status quo for that criteria.
4. If some criteria are more important than others, adjust the weights. If some products are much better than others, adjust the rating weights in the main area of the sheet. Don’t go overboard with this.
5. Look at what the spreadsheet tells you is the best choice. Do you and the group feel good about that decision? If so, you’re done.
6. If not, look again at steps 1-5 — do you have a complete set of criteria, or was something important to the decision missed? Are the weights you’ve assigned close enough?

I’ve found this technique personally useful whenever a simple pro/con sheet didn’t cut it — and taught the technique to a few hundred people at a little company here in Redmond, WA. The response was often positive — “this is a great way to more methodically make a tough decision as a group, and leave behind a record of why we made it.”

Sound interesting? Jump to our Pugh Decision Matrix page to download templatized versions of this spreadsheet to try yourself. Thanks for any feedback you have!

Is a culture of giving staff more control over their project priorities a simple way to statistically leverage the hive-mind of the organization? A natural form of prediction market?

Prediction markets are a powerful tool to harness the wisdom of crowds to peer into the future. In a bottom-up fashion, the individual instincts of people who are closer to the customer and/or technology are given a voice — which can provide a healthy balancing force to temper the otherwise top-down vision, plans, and predictive beliefs of the company. And from a lean perspective, these are sister concepts to Kaizen continuous improvement and many other techniques to close your feedback loops.

All businesses would love better insight into the fuzzy future. Here are 10 ways to harness the wisdom of crowds in your organization.

1. Launch an internal idea market
2. Give your engineers something equivalent to 20% time
3. Give your staff more discretion to choose their next project / group
4. Systematically analyze and prioritize feature requests from your sales pipeline
5. Use group quality techniques like Capture-Recapture analysis in reviews (look for a posting from us on this soon)
6. Use group prioritization techniques like Multi-Voting
7. Use group estimation techniques like Wideband Delphi
8. Use group decision making techniques like Pugh Concept Selection
9. Provide frequent, regular pre-releases of your product during development
10. Systematically collect and analyze customer feedback from all releases

The particular techniques used are important — the good ones systematically reconcile core personal instincts and discourage committee-style groupthink.

We’ll look at many of these in more detail in future posts.  But feel free to beat us to it in the comments if you like, ye crowd of wisdom.

Cockburn got it right that when it comes to creative teams, people are primary. And the jokes you hear about “herding cats” are funny because they’re painfully close to the truth — it’s an insight to embrace.

When it comes to large-scale, creative engineering, the right processes for all the various teams in an organization depends on both people and situation — both of which are constantly changing. You can’t just adopt a particular process and be done with it.

So really the only “bad process” is one that doesn’t provide framework to reflect and permission to adapt. Nothing else is sacrosanct. XP and TSP take some heat, because they’re both strong in “framework to reflect” but weaker in “permission to adapt”.

But it’s also a mistake to dismiss XP, TSP, or any other system that’s clearly working for huge numbers of people. Every methodology can be the right one for certain teams for certain parts of their existence.

And XP or TSP can sometimes be a better starting point for teams than something like Scrum, because they’ve chosen “default” tools out of the toolbox for you and Scrum hasn’t. I’ve seen teams at big companies like Microsoft adopt Scrum and suffer for months for lack of a strong definition of “done”. For some, TDD or pair programming might have been a great gateway to a healthy state. Why suffer, when XP or TSP has done a great job of defining a working, holistic system?

But the danger — the one Scrum avoids with its simplicity and intentional focus on just the reflective core of the engineering system — is that the default tools in a methodology like XP or TSP are unlikely to be 100% right for your team. And adopting them all with a single big-bang process change is fraught with risk. Yet the methodology may create a mindset on the team where that’s the only way — not encouraging the team to improve and adapt slowly and continuously. So the team breaks down, and they fall back on the obvious practices (waterfall thinking) that are ill-matched to creative engineering.

So that’s why XP and TSP are great, but starting with something simple like Scrum can be great advice. That, and avoid dogma when helping your cats to herd themselves.

Hi. My name is Bernie Thompson. I’m one of your occasional tour guides here at our library of the latest lean thinking.

I’ve managed teams and done development on some pretty huge projects (OS/2 and Windows OS development teams), been on the periphery of large-scale open source development, and played the jack of all trades in startups. It’s a good sampling of the spectrum of environments for writing software. Today, you can find me at leancode.

In every project, people come to the table with many different conceptions and expectations — sometimes wise but often naive. We always seem to be re-learning how challenging large-scale creative engineering projects are. I certainly have.

A few years ago, I had the chance work with a great group of people in Microsoft’s internal process improvement group, including working with a guy named Corey Ladas, our co-conspirator for this blog.

Microsoft is an amazing, massive petri dish of development practices. We had the wonderful opportunity to teach and consult with many of these teams. Microsoft has whole orgs doing TSP, even more orgs doing variations on Scrum. But most orgs — especially the large ones — are doing their own thing, often reminiscent of what you’ll read in Microsoft Secrets or the recommended practices of Rapid Development. I had the chance to take all that experimentation, tie it back to theory, and test it in class each day.

So here are 6 things I’ve learned about large-scale creative engineering (of which software development is a type):

1. Creative engineering is a knowledge creation process. It’s mostly a research activity, sometimes a design activity, never a production activity. The cone of uncertainty is an essential concept. Risk is everywhere.
2. Lean thinking, applied to software development, can do amazing things to attack risk — in doing so, increase your output and decrease stress on your people
3. People are primary. Processes and tools are important, but they must “first, do no harm”.
4. Every person, team, and project is different. Teams and individuals at every level must be empowered and self-directed to be their best. We must resist the instinct to command and control.
5. To be effectively self-directed, teams need regular feedback, time for reflection, and permission to adapt to their unique circumstances.
6. To facilitate adaptation, yet avoid miscommunication — it helps for teams to leverage a common toolbox of practices and techniques.

I hope you find our toolbox interesting and useful. We stand on the shoulders of giants.