Richard Lawrence

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs. For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.

As agile approaches the mainstream, it’s easy to lose sight of some of the core principles, especially this one:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

If agile is to apply broadly, we can’t reserve it just for those projects that start with motivated individuals. We need to learn how to cultivate them.

What makes for motivated individuals on a software team?

1. The belief that the product is worth building. (I consider really interesting technology a special case of this.)
2. The belief that the expectations placed on the team are achievable.

(The book Influencer divides these into Motivation and Ability, but I find that ability so often drives motivation that the two can’t easily be separated. Nonetheless, the book and the authors’ blog are well worth reading.)

Scrum’s sharp distinction between “what to build,” which belongs to the Product Owner, and “how to build it,” which belongs to the team, can create a situation where the team passively builds whatever the Product Owner asks for whether they believe in the value or not. If better software is built by motivated individuals, this is not the way to get it.

This week, I facilitated a project retrospective for a team that struggled with the value of the product they’ve been working on since May. On several occasions, the team was visibly demotivated by the low value they saw in the product. They worked hard and did a good job, but I could tell that they weren’t motivated by the product itself. In the retrospective, one of the answers that emerged to “What should we do differently next time?” was, “Engage the Product Owner in conversations about the value of the product.” Had they done this, the team might have been able to help the Product Owner identify more valuable stories. Or the Product Owner might have been forced to articulate the value of the current stories more compellingly. Either way, the team would have been more motivated to deliver.

The principle I quoted above can be read as, “Find individuals who are already (or inherently) motivated and use them on your projects. Avoid the unmotivated individuals.” That’s fine as far as it goes, but I don’t think it usually works that way. It’s better interpreted something like this: “Find individuals who are open to caring about their work (i.e. potentially motivated). Engage them to become motivated about building something valuable. Let them make delivery commitments they believe they can achieve. Support them and get out of their way.” That’s how you build projects around motivated individuals.

Please don’t do this:

It will hurt. Not right away, but around sprint 4 when the bugs found in sprint 3 for the stories built in sprint 2 need to be mixed in with the stories planned in sprint 3 for sprint 4. And then it’ll hurt more in sprint 5 and later when you have to start regression testing more and more code each sprint.

Instead, just do as much work as you can get really DONE in each sprint. Plan it, build it, test it, and deliver it. It’ll be hard to ensure that testing doesn’t get squeezed out the back of the sprint. It will. When that happens, try moving testing to the front of each story. Create your test cases as specifications and then do just enough development to make them pass. (Consider a tool like Cucumber for this, using it to drive Watir if you’re building a web app. Or look at Fit/Fitnesse if that’s more your style.)

If you’re an IT executive, which is less risky? Investing a little bit in an effective agile adoption, something that’s been proven at other companies to improve cash flow, increase productivity, and grow revenues…or…hunkering down and cutting costs, knowing that at this time when your business needs you the most you’ll be less productive than you were last year?

I’m often asked how architecture works on agile software projects. It’s a big question, but the core answer, I think, is this: Neither a big, detailed architecture up front nor no architecture at all is a good approach. The former leads to waste. The up-front architecture tends to support features that turn out never to be necessary and that unnecessary complexity tends to make the features that are implemented more expensive than they need to be. I worked in one organization where the requirement to fully implement the company-standard architecture added several hundred thousand dollars to the initial release of any new product with questionable business value in return. The latter approach, no architecture at all, is prone to produce a system that is unmaintainable, leading to waste later as features cost increasingly more to implement and maintain as the system grows.

Here’s my two rule heuristic for agile architecture:

1. Have a minimally sufficient technical vision. Know where you’d like to go architecturally at a high level. What technologies do you expect to use? What architectural patterns are appropriate (e.g. SOA)? You may not implement most of the target architecture until features require it, but it will keep the team working in the same direction. Revisit this target architecture regularly as the backlog changes to ensure that it stays relevant.
2. Make decisions that keep your options open. Always try to build just enough to support the current features, while keeping it easy to move towards the target architecture (or any other architecture that future features may require). Avoid making commitments to a particular architecture before you have to.

For example, suppose your target architecture includes SOA. Until your features require your business layer to be consumed as a service by more than one client, you might defer actually building the service interface. Instead, build a good OO interface and use it directly from your client, designing it such that a service facade will be easy to add when needed. Your current features will be usable faster, allowing for early ROI and for learning that might change the requirements around the service interface. Fortunately, since you haven’t built a service interface yet, you won’t have to throw anything away to incorporate that learning into the product.

You can employ a similar approach around persistence, caching, reporting, configuration, and security, among others.

Where have you struggled with agile architecture? What creative architectural solutions have you come up with that allowed you to implement just enough architecture while leaving your options open?

I’m hosting a free seminar on Tuesday, November 11 from 1:00-2:30 PM in the Denver Tech Center area. Please join me there and spread the word to others who might be interested.

Here’s a brief description:

Too many teams adopt agile processes like Scrum and XP, become effective at iterative and incremental delivery, get their software quality higher than it has ever been before, and finally achieve a sustainable pace…yet fail to harness that new productivity to deliver anything of real business value.

As an agile coach, I see Product Owners who don’t understand the features on their Product Backlogs well enough to explain them to the team in a planning session. I see Product Owners who can’t explain the larger context of a user story. I hear teams and Product Owners tell me that it’s not possible to come up with a valuable release that will take less than 6 months to build. I see teams demotivated because they don’t see the value in what they’re building.

In this free seminar, I’ll show how effective agile product management can accelerate and increase ROI, I’ll introduce an approach to identify high value feature sets, and I’ll share some tips on how to avoid getting bogged down in the details and losing the big picture.

You can find more info and register here: http://agileproductmanagement1108-rl.eventbrite.com.

As the saying goes, “Cash is king.” It doesn’t matter how good your P&L or balance sheet looks or how good the business case for your project is, if you don’t have enough cash every month to pay the bills, you won’t stay in business.

With the economy tightening, then, companies are desperately trying to cut costs in order to stay cash flow positive. In IT the major cost is salary, so cutting costs means cutting people. Nobody likes that.

Fortunately, there’s a simple way to reduce expenses and increase returns on a software project: incremental releases.

A Typical Big Bang Release

Let’s look at a example. Our project will spend $1m (mostly salaries) for a year of development starting in January 2009, release at the end of that year, and is projected to make $2m over its first year in production. We’ll simplify this model and assume that expenses and returns will be distributed evenly over their respective years. We’ll ignore ramp up time and we won’t discount future cash.

The result is a cumulative cash flow chart that looks like this:

We spend money linearly until we’ve spent our whole million. Then, we release the software and start making money linearly until we make the projected two million. We break even in June of 2010, 18 months in, and we see a 100% ROI.

Variation 1: Incremental Releases

Now, let’s keep all those same assumptions and make one small change. Instead of building the software and releasing it all at once, let’s break it into four equal size feature sets. Every three months we’ll build and release one until the whole product is released. To simplify things again, we’ll assume that each feature set is equally valuable and will account for a quarter of the expected return. Since we can start seeing returns as soon as we release a feature set, our cumulative cash flow now looks like this:

With this arrangement, we only need to invest $375k in the project rather than $1m. We break even in February 2010, 14 months in. With an investment of $375k for $1.75m in returns ($2.75m in revenue less the same $1m in expenses as the previous example) we see a 467% ROI over two years.

Variation 2: Prioritizing Releases by Value

For most projects, however, value isn’t distributed evenly across the features. Usually an 80/20 rule applies and some features are much more valuable than others. For our hypothetical project, let’s assume that we can divide up our features to get a pretty typical distribution where Feature Set A accounts for 50% of the value, Feature Set B for 30%, Feature Set C for 12%, and Feature Set D for 8%. Now, our cumulative cash flow looks like this:

When we deliver feature increments by value, we have to invest only $250k for a $2.1m return, or 844% ROI. We break even in November 2009, before the original project was even going to release!

Variation 3: Cutting Out Low-Value Releases

Once we’ve prioritized our features by value, we can go one step further. We can decide that some features aren’t worth the investment. With their long 15 and 19 month waits to break even, feature sets C and D may not be worth it. Over the two years we’re considering, those features have a negative ROI. Let’s cut them out of the project and have the team do something else more valuable. Here’s our cumulative cash flow now:

This variation generates less revenue, but only spends half as much. The return is $2.15m on a $250k investment, or 860% ROI. It breaks even in August 2009, tying up the cash for less time and freeing the team to do something else more valuable. In fact, if we can assign the team to two feature sets on another project as valuable as A and B were on this project, our two year cumulative cash flow looks like this:

Now we see $3.5m returned on our $250k investment, an ROI of 1400%. We break even in October 2009, still three months before the original plan would have had us starting to see a return at all. Simply by rearranging our work by value and releasing incrementally, we’ve dramatically improved our cash flow situation while increasing our revenue. And we didn’t have to lay anyone off to do it. Going into a tight economy, odds are that this is exactly what your business needs.

(In case you’re interested, here are the details behind the charts: big-bang-vs-incremental-releases-cash-flow.xls.)

I often advise teams against using a release burn-up (or burn-down) chart because I’ve seen too many managers try to use them as a stick to beat the team with their original pre-project release estimate. Since velocity changes from iteration to iteration, the size of the release needs to change, as well. Jim Shore has a great post describing how to do a release burn-up that takes into account changing velocity and the cone of uncertainty, giving a more and more specific estimated release size to burn up to after each iteration. Check it out.

Esther Derby has a good post this morning about how trust is embedded in a context. She writes, “The sort of trust that you need for a productive working relationship is different from the trust you need for a healthy marriage.” She gives some good examples of what trust means on a work team.

I believe trust always comes down to this: I believe that you’re not going to do me harm. What kind of harm depends on the context in which we have a relationship. On a work team with me, you can harm me by not doing your work or by complaining about me behind my back, as Esther describes.

My belief that you’re not going to do me harm comes from the accumulation of everything I know and have experienced of you. Everything that happens in our relationship either builds or undermines trust. Nothing is neutral.

Because of that, one of the best ways to build trust in a relationship is to simply be aware of it. A good tool I’ve found for that is cultural anthropologist Marvin Mayers’s prior question of trust (or PQT for short): “Is what I’m doing, thinking, or saying building trust or undermining trust?” Of course, you can never be sure what effect a given action will have on trust—people aren’t that predictable. But asking the PQT in your head before acting can point you in the right direction.

A recent essay in Wired says, “The traditional office, meanwhile, remains a black hole of interruptions, procrastination, and soul-crushing politics. According to Gloria Mark, an informatics professor at UC Irvine, the typical office worker is interrupted or switches tasks every three minutes—hardly enough time to accomplish anything of substance.” (via Kathy Sierra) The alternative, according to the article, is telecommuting. For everyone.

I love working from home. Given a choice, I’d rather not commute, and I’d rather have meals and breaks with my family. And when I’m doing solo projects, I’m definitely more productive there than in an office. For team projects, especially software development, however, I’ve never seen a dispersed team become anywhere near as productive as a high-performing collocated team.

The solution to the problems of the traditional office may, for some workers, be to do away with the office entirely, as Wired suggests. But that may be throwing the baby out with the bath water for the large number of workers who do team work. Telecommuting solves some problems and introduces others (e.g. isolation, communication overhead, potential for task orientation over results orientation). A better solution: fix the office environment instead of abandoning it.

A few modest proposals…

1. Eliminate multitasking. Assign workers to a single project and allow them to see it through to completion. Within a project, allow them to complete one task at a time. For interrupt-driven roles like technical support and maintenance, allow workers to do just that role and to see individual cases through to completion. (Kanban systems are perfect for managing work this way.)
2. Collocate teams. Once teams are working on a single project, put them together in the same room. Conversations will be more focused on the project goal and will be less distracting. Increased collaboration and face-to-face communication will lead to more productivity and improved morale. People enjoy accomplishing things with other people; make it easy and natural to do just that.
3. Measure up. Too often, metrics reward the wrong things and lead to unintended consequences because they measure details of the work rather than results. For software development, find ways to measure the delivery of business value by the team. Leave the implementation details for the team to manage on their own. For other disciplines, the Results Only Work Environment started at Best Buy looks like a good framework for finding the right results-level metrics and letting go of details like hours in the office.
4. Allow telecommuting. Once you start using the right metrics, workers may find that they can be more productive out of the office. Not all work is well suited to the office environment. Let them go.