Lean Software Engineering

Change and risks of the unknown are the primary challenges of modern projects — changes in our team, our understanding of our problem, our market, etc. Experienced project members know that the “best process” for our project doesn’t fall neatly into formulas.  What was a successful strategy in one circumstance may fail completely in a seemingly similar circumstance. The relationship between our current situation and the best processes to deal with it are non-linear.

Lean thinking is one of the best starting points we have to systematically attack this problem with savvy about continuous improvement, shifting bottlenecks, systems thinking, statistical management, and respect for people on the front lines of the problem. And it’s been under-applied in getting us past the breakdown of traditional project management techniques in high-risk domains like software development.

But successful lean companies like Toyota have taken years or decades to build up institutional and cultural knowledge of where to start and how to evolve. Can we shorten this learning process for other companies or other domains?

Our unique circumstances and the changes around us require a kind of dance to make progress and stay balanced — sometimes steps forward, others to the side or back. This non-linear adaptation is very jarring for both our managers and our teams.

We need to find a way to empower people with the savvy to sense dissonance between the process we have vs. the process we need, give them the vocabulary to be able to discuss it, and the power to take action on that dissonance even if the solution is a step in a new direction or even a step back.

One of the best places to start is by attacking the belief that there is “one right process” for our teams.

Instead, we drive dialog around the spectrum of possibilities between any two poles or dualities: predictive vs. iterative management, larger vs. smaller batches, top-down vs. bottom up control, standardized vs. adaptative process, specialist vs. generalist teams, etc.

It’s not about choosing one or the other .. it’s about where you are on the spectrum.

As managers, we probe our teams, asking if they should be trying “more of this” or “less of that”. We can go forward or back on a spectrum, and we can step “to the side” by focusing our energies on a different duality.

What would help — in fact, what’s almost essential — is a pattern language to give names to abstractions and make dialog and discussion about where we are and where we’re going possible. Unfortunately, the PM pattern languages you’ll find today are based on absolutes (an assumption of one right process). We’re looking for one based on dualities — opposing forces or alternatives that we must balance to achieve the best-fit process for our circumstance, for this one point in time. We want terminology that ask us to think, adapt, and step in whatever direction our circumstance calls for.

Boehm (balance) and Cockburn (meta-methodologies) are wonderful starting points for this kind of thinking, at least in software developement. I’m sure there are others — please add a comment if you want to point out a resource.

Can we discover and build this pattern language of adaptive project management — and make it a an approachable, practical tool for today’s managers and project teams?

JD Meier has written a nice post on the value of capturing “lessons learned”. In the projects I’ve been on, having an open, honest, and well-run lessons learned session (aka retrospective or postmortem) at regular intervals during the project has been one of the most valuable uses of the team’s time, but also a big source of missed opportunities.

Four top barriers to successful lessons learned:

1. We don’t look back until the very end of the project.
2. We don’t set a tone of open and honest feedback.
3. We don’t look at the whole picture of product and process.
4. We don’t actually follow through on the feedback.

Nothing is more important than this kind of feedback from your team. So how can improve our approach?

• Don’t rush the project so that there’s no time for ongoing improvement or reflection. The projects that end most disastrously are those where everyone is sucking wind so much that there’s no air left in the room for calm and honest reflection and discussion of what’s going well, what’s going poorly, and how we can improve.
• Make reflection part of the cadence of your project. Whether it’s with a methodology like Scrum (which encourages daily small-scale reflection and monthly large-scale reflection), or scheduled feedback sessions called Kaizen Events which encourage analysis of the “big picture” of your processes, or systematic continuous feedback (a Kaizen culture — the Toyota way). Whatever cadence you choose, keep it up. When the project needs honest feedback the most, is when people will be most tempted to sacrifice the time spent on improvement or just keep their mouths shut to not put themselves at risk. I was on several projects where we went a year or more between opportunities for large-scale feedback (and these are projects that did not go as well as the could have). That timescale is simply far too long!
• Anticipate the barriers to honest feedback, and remove them. Structure the feedback so everyone has their turn. Sometimes intra-team conflict means it’s best to get a 3rd party facilitator for the retrospective. Sometimes a level-headed team member should start the feedback with a balanced analysis to start the discussion. Sometimes it’s essential to give an opportunity for anonymous feedback (a suggestion box) that will be read through at the meeting. With all these tips and others — keep in mind that if you fear the feedback process, it will become a self-fulfilling prophecy. Err on the side of being as relaxed about the process as the team will allow.
• Put the “lessons learned” front-and-center. Far too often great feedback is collected and good decisions are made to improve — but then the natural inertia of the team causes it all to be forgotten once the project gets busy again. Don’t let your “lessons learned” be forgotten. Capture your processes, and note lessons learned beside them. Email out your lessons learned. Put them on the team’s web page or wiki. Encourage management to refer back to them. Lessons learned do have a half-life — as the nature of your team and project change, older lessons learned may no longer be relevant. And they’re not always relevant across teams. But by encouraging focus on recent lessons and making available the older ones, you build a stronger corporate memory for reacting to the problems that may be common on your project — and what solutions worked well or didn’t.

What are your “lessons learned” about retrospection? What opportunities to do better were missed here?

Corey laid out an excellent introduction to the statistical magic of capture-recapture analysis to estimate the effectiveness of an inspection or review of code, documents, or other material.

But how can you practically get your teams to leverage these powerful feedback loops, leading them to conduct better and better reviews over time?

One thing that helps is a tool to get you started.

Here is a newly created, simple spreadsheet template that you can apply to any group document or code review.

Want to learn more? Get the template for this sheet and see how it works at http://leansoftwareengineering.com/capture-recapture-inspection/

In the previous post, we looked at 7 sources of technical debt. So how do we measure each of these to bring them to light?

1. Bugs. Measure and shrink your cycle time from when code is first written until it is tested (TDD is perfect for this, of course). Treat open bugs as work in progress (WIP) — and too much work in progress is evil. Constantly measure and manage WIP down with strategies like bug caps (no new features until existing bugs get below a defined bar).
2. Missing tests. Measure code coverage. Have a clear definition of “done” at each scale of your product: unit, feature, scenario, system. Treat units of code as incomplete until code, tests, and documentation are delivered as a set.
3. Missing automation. Make build and deployment first-class features of your project. Deliver them early, and assume (like other features) that they will constantly evolve with sub-features over the course of the project. Measure time-to-build, time-to-deploy, and time-to-test — including human time expended each cycle — and then drive those numbers down by adding automation work to your backlog.
4. Incomplete scenarios. Assign scenario ownership roles among the team. Have a clear definition of “done” for each scenario. Pre-release working scenarios to select customers as soon as possible, making special note of these bugs. And of course, minimize the number of scenarios each team focuses on at once (one at a time, if possible).
5. Not understandable. Like most open source projects, generate docs directly from the code (literate programming), including why the code does what it does. Systematically conduct code reviews. If the team can’t afford to review every line, always review a sample set of functions from each developer and component. Ask reviewers to rate code for understandability, track this data in code comments or a spreadsheet, and add workitems to the backlog to clean up those most needing improvement.
6. Not extensible. Encourage design pattern thinking. Buy your team a library of design patterns books and posters to help form that common vocabulary. Look at how open source projects tend to build big things out of many small, independent pieces — treat every component as a library with its own API and a clear (and minimized) set of dependencies.
7. Not integrated. Minimize the number of branched codelines, whether they’re formally in source code control, done on the side for customers, or sitting on developer’s disk drives. Unintegrated code is debt — it has work and surprises waiting to happen. Strive for continuous integration. This isn’t to say don’t use branching — even the smallest project should think about their mainline model — but always keep everything in source control, then track and minimize the number of active branches.

There is a rich set of metrics here — # of active branches, # of dependencies per component and globally, time-to-build, code coverage %, # of bugs, etc. Taken together (literally, from a spreadsheet as a multi-value line graph over time), they can provide a rough index of the health of your project.

Some are more expensive than others to collect and track, and some are more valuable — so not all projects will use all of them all of the time. Smaller projects might want to just focus on one area (e.g. getting all tasks in a database, and keeping that number down).

Of course, putting too much weight on any one metric or set of metrics in a larger organization will cause the numbers to get “managed down” — regardless of the underlying reality. And don’t get too distracted by the numbers. Use the numbers as feedback, as signals to take action, and as evidence to identify and attack the current bottleneck in your process — not as a way to reward or punish individuals.

So how much debt has your project accumulated? What are your next steps to systematically pay off and keep down that debt?

The true status and health of a large software project is surprisingly difficult to sense, and worse to measure. One of the best ways to understand this is to think about debt. Although not measured in dollars, software projects certainly accumulate debt over time. This is debt that you will have to pay someday — or continue paying interest to delay the day of reckoning — if the project is successful.

How many of these apply to your project?

7 sources of technical debt

1. Undiscovered bugs, failing tests, and open bugs in your database
2. Missing test automation (unit, feature, scenario, or system)
3. Missing build and deployment automation
4. Scenarios with incomplete user experiences
5. Code that’s too difficult to understand
6. Code that’s too difficult to extend
7. Code that’s isolated in branches

The insidious thing is your project can hit all its milestones and even make it the whole way to shipping — with any amount of these debts lurking in the code.

In a next post, we’ll look at 7 matching strategies for measuring and tackling technical debt, so you can empower your teams to systematically manage it in a lean fashion.