Top 10 Reasons for Slow Velocity

The SVPG blog has a good post about the Top 10 Reasons for Slow Velocity.  It's interesting that their top two items have to do with the leadership and management of the team.  Both ideas come back to focus and motivation, which turn up again and again in conversations about productivity.

Code as an English Garden

I heard a quote recently I really like: "Computer code is more like an English garden than a stone sculpture. It must be tended to and pampered, or it will be overcome with weeds and die." This goes back to an earlier quote, "Creating an agile team begins with an agile codebase."  An agile codebase, by necessity, must be tended to.  Cruft must be re-factored, tight couplings must be loosened, and complexity must be encapsulated.  It's a constant, ongoing, and never-ending endeavor.

78 Things I Have Learned in 6 Years of Agile Coaching

This article, 78 Things I Have Learned in 6 Years of Agile Coaching, provoked some further thoughts regarding my earlier post, "Scrum: What We Were Missing."

A few things I'll add to that list:

• Releasing code at the end of each sprint.  We were following the spirit of "releasable" code, but that's too easy to wiggle out of -- lots of code is releasable, but that doesn't mean it won't take two weeks to deploy it.  We keep getting ourselves in a position where we're "done," and yet we still have to figure out how to get 140 files to production without affecting the customer experience.  That's hard.  So our new goal is to actually release code at the end of each sprint.  Even if the project isn't finished, we can deploy pieces of it to production sprint by sprint.  That way, we won't be overwhelmed by a massive code push once the time comes to get it live.
• Small, cross-functional teams.  We're trying to re-capture the spirit of a start-up, where everyone's in it together, a small group of energized people are working towards a common goal, and communication is as simple as yelling a question out to the room.  As we grow, our challenges to achieving this are figuring out how to arrange seating so that teams can sit next to each other and maintaining that feeling of a small group while the company inevitably becomes a bit more stodgy as it grows.
• Public burndown charts, updated daily.  We're still trying to reach this goal, but it's becoming clear to me that the visibility these provide to both the company and the group, and the group-wide responsibility these engender on the teams, are a key part of agile.

Cross-Functional Teams

We're trying out a new idea that I'm excited about: cross-functional teams.  Our group has expanded slowly and organically over the years.  As we've needed more programmers, we've hired them.  As we've needed more testers, we've hired them.  But now we're almost 20 people strong, and we're hitting the limits of a productive team size.

I'd been unconsciously steering us towards separation by task: the product managers pass their ideas to programmers, who write the code and pass it off to testers, who test it.  But that becomes harder and harder to coordinate as the number of projects and people grow -- without domain separation, everyone needs to know everything about every project.  And that's both unscalable and unproductive.

So we're trying out the idea of cross-functional teams: three groups comprised of a few coders, a tester, a product manager, "half" of a project manager, and one or two designers.  I see this as having a few benefits:

• It will reduce task switching.  People will be able to concentrate on one of a few different projects assigned to their group.
• It will let everyone more effectively embrace the business goals expressed by the product managers.  Instead of getting sent in a different direction with each new project, people will hopefully be able to internalize a larger set of goals and apply them automatically to each project.
• It will make communication easier by limiting the number of people involved and letting people develop deeper relationships than they could with a larger group.

I'm really looking forward to the benefits this change should bring, and will keep everyone posted on how it goes.

Lean Software

I recently finished a short, insightful book called The Art of Lean Software Development.  It connects the principles of lean manufacturing with those of agile software development.  It's a fascinating path: lean manufacturing started with Toyota decades ago, and focused on obsessively ridding systems of "seven deadly wastes:"

• Defects
• Overproduction
• Transportation
• Waiting
• Inventory
• Motion
• (Over)Processing

(These can be abbreviated to "DOTWIMP" if you're ever quizzed on them.)  Most of them are self-explanatory if you consider the additional costs they could bring to the car manufacturing process.  "Motion" refers to the idea of people or machines moving around -- if you can find a way to avoid it, you're better off.  "(Over)Processing" means doing anything that's not required by the customer.

It's interesting to apply these to software, as the book does, and find corollaries:

• Defects => Bugs
• Overproduction => Extra Features
• Transportation => Handoffs
• Waiting => Delays
• Inventory => Partially Completed Work
• Motion => Task Switching
• (Over)Processing => Unneeded Processes

As with a lot of discussions about process, it's easy to write all this off as common sense.  And yet we can all get mired in processes and miss the forest for the trees.  It's always insightful to step back and use a list like this to get a fresh perspective on what's working and what needs fixing.

I find a lot of people (including myself) trying to apply software development processes without always thinking about the overall idea: they have daily standups, planning meetings, workflow charts, etc.  It's easy to think that just going through the motions of these steps will help you.  And in some cases, it does.  But it's important to constantly challenge your assumptions.  Holding yourself accountable to eliminating these "deadly wastes" seems like a great way to do that.

Faster Codebases

Continuing with the idea of code design and productivity, a colleague recently shared some keen wisdom: "Creating an agile team begins with an agile codebase."  As the last post discussed, productivity and code design are clearly related.  What's interesting is to expand this idea to the entire spectrum of agile development.

Many of agile's mainstays -- quick iterations, releasable software, and continuous integration -- all require a codebase that makes these possible.  And that goes back to two main ideas: de-coupling and encapsulation.  Those principles, in turn, make the following goals a lot easier:

• Simple, effective unit tests (tight coupling leads to brittle, cumbersome tests that are really integration tests)
• Easily deployable software (tightly coupled code is hard to deploy without breaking other parts of the system)
• Team scalability (a team can't grow quickly if each member has to intimately understand the entire codebase)

I used to think re-factoring was a process that could happen slowly in parallel with business goals.  But now I realize it needs to be an end in itself, in order to support not only productivity, but a growing team and an agile environment.

Productivity and Code Design

One of our developers suggested an important relationship that I haven't discussed yet: that of productivity and code design.  Most of the productivity benefits of good code design come after the original code is written -- they affect the ability to improve and expand the code.

You can write code designed to increase productivity by focusing on a few simple ideas:

• It should be easy to understand, so that additions or changes can be made more quickly
• It should be easy to expand, so that future enhancements don't have to re-factor the core logic
• It should be easy to deploy, so that changes don't require a massive regression testing effort

In Rapid Development, Steve McConnell makes similar points in the chapter, "Designing for Change."  The chapter suggests identifying areas likely to change, using information hiding, and using object-oriented programming, among other ideas.

Fortunately, a lot of these ideas piggyback off of good coding practices.  But the emphasis on these practices is usually towards maintainability.  It's interesting to reflect on their strong relationship to productivity, too.

This is another good way to understand how older codebases tend to reduce productivity.  Inevitably, design boundaries will have gotten blurred, shortcuts will have been taken, and "just get it done" projects will have reduced readability.  This all affects future productivity, and is another argument for periodic refactoring.