NAYIMA
Jun
08

Université du SI 2010

I’ll co-present a session with Christophe Thibaut about the “A3 process” at the Université du SI conference on July 1-2 in Paris.

The “A3 report” is a standardized report format used within Toyota and other companies to make proposals and report. The standardized and constrained format helps the writer and readers to come to the point quickly, concentrate on the essentials and get the important information without wasting time.

However, when applying this technique we often only implement the superficial elements, the fact that the documents are limited in size and have a standardized format. Sometimes, the exact format of the Toyota reports is copied. And then we’re disappointed because this “cargo cult” application only delivers limited benefits.

In this session we’ll look at and let participants experiment with the social aspects of the A3 report:

  • How we define the standardized format to support our goals
  • How leaders and managers use A3 report writing by their team members are structured one-to-one coaching
  • How to build in iteration and feedback from peers to improve the proposals
  • How to use the review process as a consensus building tool
  • How to present reports in such a way that they’re heard, understood and accepted

Come and play with us if you want to learn more about this powerful continuous improvement and learning tool.

If you want to know more…

June 8th, 2010 | Category: agile, books, Events, lean, presentations, systems thinking, Uncategorized
Jan
29

Value in Lean

In search of Lean Business Value

I’m looking for useful and usable definitions of Business Value. Lean should have a lot to say about value (when they’re not talking about waste): Value Stream, (non-)value-adding work, Value Stream Manager.

And yet, a book like Creating a Lean Culture: Tools to Sustain Lean Conversions that describes Lean Management doesn’t define what Value is or how you define it. The Lean Manager’s job is to ensure that the right thing is done the right way. “The Right Thing” has been defined beforehand and the Lean Production Manager ensures that the value (as defined in the product to deliver) is delivered quickly and efficiently. In production, quality has been defined and is constant (except when the product changes). The emphasis of the production manager is on “the right way” and increasing flow by reducing waste because those are the only variables the production manager (and workers) can influence.

Implementing Lean Software Development: From Concept to Cash has a separate chapter on Value, which comes just before the chapter on Waste. The chapter doesn’t really define value. The closest to a definition of value comes from Lean Solutions: How Companies and Customers Can Create Value and Wealth Together. What do customers want?

  • Solve my problem completely
  • Don’t waste my time
  • Provide exactly what I want
  • Deliver value exactly where I want it
  • Supply value exactly when I want it
  • Reduce the number of decisions I must make to solve my problems

This gives us a good set of criteria to check, because each of these criteria reduces the customer’s value if done badly. How do we know what customers value? The advice is to understand the customer by:

  • Living in the circumstances of the customer, for example when the chief engineer of the Siena minivan cruises from Canada to Mexico to understand how to improve the car.
  • A similar technique is “apprenticing”, where we learn how to do the work from a user
  • Observe real users at work
  • Perform usability testing to ensure we haven’t reduced customer value

Toyota Way Value

If we look at the 14 Management Principles from the World’s Greatest Manufacturer from the Toyota Way (p. 37) we see that Customer and Value are only mentioned a few times:

  • Generate value for the customer, society and the economy – Principle 1: Long Term Philosophy
  • Quality for the customer drives your value proposition – Principle 5: Build a Culture of stopping to fix problems, to get quality right the first time

So, Value == Quality for the Customer.

Chapter 5 describes how Quality for the Customer was defined for the Lexus.

  • Look at who the competitors are
  • For each competitor, what do customers like and dislike about them?
  • Rank order the quality attributes
  • Select a small number of target qualities (in this case: top speed, fuel consumption, noise, aerodynamics and weight)
  • Define constraints and basic needs (reliability, safety, resale value, interior…)
  • Set targets for each of the quality attributes

Now, we know that if we ask potential customers and users what they like in existing products and want to see in the new product we’re not going to get a very exciting list. In “Kano model” terms, we’re going to get the “must have” basic needs and some performance needs (“It uses a bit less fuel than my current car? Nice.”). Where do we get the exciter features that make the difference?

In this case the exciter was the word AND. The new car had to beat its rivals in all of the target qualities: lighter AND faster AND more fuel-efficient AND quieter AND… than the leader in each quality.

Toyota Production System Value

The Toyota Production System (and all the material derived from it) doesn’t say much about value because value has already been defined and is a constant (or constraint) for production. The Toyota Product Development System has as its first principle “Establish Customer-Defined Value to Separate Value-Added from Waste“.

How is this done?

  • Appoint program leaders who have the background and experience to establish an emotional connection with the target customer
  • Perform Genchi Genbutsu (Go See the Actual Work) to see the customer in action in their environment
  • Create a vision for the product which includes quantitative and qualitative goals (using “Value Targeting Process”, as described above)
  • Create a concept paper based on thorough discussion, information gathering and consensus-building
  • The leader and the concept paper guide development throughout the project
  • The project is broken down into functional teams, each with their own leader who applies the same process recursively, so that each team has a customer perspective
  • Value targets are set
  • Cross-functional teams work together to find ways to achieve all the value targets

Business Value is a Model

At Agile 2008, Chris Matts and Andy Pols had a session about Business Analysis. They made one statement which clarified what I was looking for and what I was doing:

Business Value is not a value. Business Value is a model.

There’s not just one value or one quality: different stakeholders all value lots of (conflicting) things. Moreover, value is not static. For example: whether I deliver a car (or a software project) next week or in six months can have enormous effects on your valuation of that exact same product.

As with all models, much of the value comes from the thinking about value and the modeling, not the final model. When I come onto a project, I will always ask about the Business Value Model. If you have an explicit and agreed model, decision-making will be much more effective. If you don’t have an explicit model, that tells me a lot: we’re going to have constant discussion about goals and value. Even worse, some teams have an explicit model (“espoused theory“), but use another model (“theory in use“) which leads to no end of conflicts and dysfunctional behaviour. I can usually deduce very quickly what the real model is from the actions of those involved. That’s why I like to add a third part to the statement:

Business Value is not a value. Business Value is a model. Business Value models what you value.

So… How can build a Business Value Model in our work?

January 29th, 2010 | Category: agile analysis, books, lean
Oct
30

Resolve a Conflict in 6 easy and 1 difficult step

Tried Out

CRD # 1 at Scan Agile 2009When presenters propose sessions for XP Days Benelux, we always recommend they try out their session, as many times as possible. We should all know the power of iteration and feedback. You need some time to get it right. If you’re slow like me, you might need years to get it right.

The first tryout of the “Solve Conflicts without Compromise” session was run as a “Birds of a Feather” session several years ago at the SPA conference. The session (and the technique) worked, but only barely. Then, two breakthroughs happened at the same time:

Suddenly, the technique became a lot clearer. Bill Dettmer’s explanation is very clear and practical; the session at Agile 2008 showed that it worked and could be fun.

Solve Conflicts without Compromise

CRD # 2 at Scan Agile 2009So, after a few more iterations, an updated session was created. It’s now been run twice:

  • At  Agile Tour Besançon, in French. The participants gave a lot of useful feedback at the retrospective.
  • At the Scandinavian Agile open space, in English. The pictures show the three groups analysing a conflict for their “customers”. There was no time for a retrospective, because the conference was closing. I hope the three clients will blog or email me about their experience.

The next two runs will be at the Belgium Agile/XP User Group meeting on November 5th 2009 and at the XP Days Benelux conference on November 24th.

So, what are the 7 steps?

  1. Create a blank Conflict Resolution Diagram (CRD) like in the image below. 5 boxes connected with arrows. Easy.
  2. Articulate the conflict. State the problem in one of two forms, both impossible choices between conflicting prerequisites:
    • One chain of reasoning says “DO THIS”; another chain of reasoning says “DON’T DO THIS”. Now I have to choose: DO THIS OR DON’T DO THIS? I can’t have both.
    • I need two things, A and B, but they’re mutually exclusive. Now I have to choose: HAVE A OR HAVE B? I can’t have both.
  3. CRD # 3 at Scan Agile 2009Determine the goal and requirements on each side? Why do we need those two conflicting things? Because of two requirements. Why do we need those two requirements? Because we need them to reach a common goal.
  4. Evaluate the reasoning. Throughout the whole exercise we must ensure we maintain clarity: is each step in the reasoning crystal clear and well-understood by everyone? Is the reasoning clear?
  5. Develop underlying assumptions. If the CRD says “To achieve X we need Y”, ask “Why do we need Y to achieve X?”. All the answers are the underlying assumptions of the reasoning. Use “extreme wording” to make the assumptions stand out and almost beg to be invalidated. For example: “Why do we need to introduce Test Driven Development to achieve better quality?” Because…
    1. TDD is the only way to improve quality
    2. TDD is the most fun way to develop software
    3. TDD catches all errors
  6. Evaluate the assumptions. Which assumptions are valid? Which assumptions are invalid? Which assumptions could be challenged. If there are no valid assumptions behind a step in the reasoning, the reasoning is invalid. At this point, the whole conflict may have “evaporated”.
  7. Hard: Create injections. This is the creative bit where we find ideas to invalidate those assumptions that hold us back from creating a win-win situation, one where we achieve our goal in a way that satisfies everyone involved.

Solve conflicts-lWhy is this difficult?

When I see the participants in action, there are some difficulties that appear every time:

  • It’s hard to maintain the consultant’s stance and only ask questions. That’s why we have strict rules about what the consultants can do: they can only ask a limited set of questions.
  • We want to jump to the solution immediately without taking the time to understand the real problem. That’s why the session doesn’t allow talking about solutions, only about problems.
  • We censor our assumptions. Instead of brainstorming all our assumptions, we only talk about those that seem reasonable. That’s why there’s a lot of pressure in the session: you have to come up with at least 25 assumptions in 5 minutes. That’s just not possible if you think about the assumptions.
  • The most interesting assumptions are those that we no longer think about, the things that are “common sense”. That’s why we have people external to the problem questioning the client and why we bring in some “fresh blood” with a fresh perspective halfway through the session.
  • It hurts when we really think about a problem. It’s easier to just settle for a compromise. That’s why we can’t accept any solution where one of the involved parties is not completely satisfied with the outcome.

What’s in it for me?

  • The CRD provides a structured method to investigate a difficult conflict and channel our creativity.
  • You don’t have to settle for compromise and mediocrity. You can get what you really need.
  • It’s a lot easier to bring about changes if everyone affected benefits. As Machiavelli noted: “You will only get lukewarm support from those who will benefit from the change and strong resistance from those who stand to lose”. What if there were no losers?
  • Your projects can deliver more business value per cost if you can find the breakthrough ideas that make those painful tradeoffs (or more correctly: horse trading) between stakeholder goals unnecessary?
  • You can get more sales if your competitors offer “EITHER/OR” solutions and you can offer “AND” solutions. But first the customer has to regain hope that a solution is possible. Going through a CRD exercise with a customer and offering to invalidate all the assumptions that cause their conflict is an offer they can’t refuse.

The ChoiceWhat do I need?

  • A bit of time. Most participants got several ideas to resolve their conflict within the 90 minutes of the session.
  • Some simple materials: pen, paper and plenty of Post-Its
  • The willingness to think hard
  • The openness to share all assumptions
  • The courage to challenge every assumption, even those that are “holy” or common sense. Especially those.

It’s simple, but not easy. The question is: do you want an easy life or a meaningful life? That’s the choice you have to make.

Oh! “Easy OR meaningful”? That sounds like a conflict! Why can’t I have both?

How would you evaporate this conflict?

October 30th, 2009 | Category: agile, books, systems thinking, theory of constraints, XP Days Benelux, xpday
Aug
19

Agile Fixed Price revisited – part 2

Agile Fixed Price Projects

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

  • Qualifying: do I want to take this project on and if so, how?
  • Selling: how do I get the contract in such a way that we can succeed?
  • Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

In the previous blog entry I revisited “The Price is Right”. Today, we’ll have a look at “Do you want Agility with that?”

Qualifying Tip 1: Make sure you have a committed customer

Agile fixed price projects require greater effort and involvement from the customer. A hard release date is a good indicator of a motivated customer.

The customer will be more motivated, more willing to think about solutions if there’s the pressure of a hard  deadline.

In retrospect: this is clearly insufficient. A hard business deadline, not some invented meaningless deadline, is one positive factor in many successful projects. It’s also present in many tales of deathmarches. Necessary but not sufficient. A limited budget is always useful too; beware of customers who have too much money (they do exist). During the sales, we must test the customer to see if they’re really committed to this project. Ensure that you get to talk to everyone who will be involved in the project. If they don’t have time to see you during the sales process, they won’t have time to help you during implementation. Ensure that their goals are aligned with the project’s goals.

Qualifying Tip 2: Make sure you get timely feedback

We need timely and regular feedback from the customer. We put those customer commitments in the contract.

Customer collaboration AND contract negotiation. The customer has responsibilities too and those belong in the contract. If we don’t get the feedback in time, we can’t run the project. I’ve stopped several projects because the customer didn’t honor those agreements. We either resolve the problem (the customer ensures they make some people available) or we stop the project altogether. Maybe we’ll restart the project at a time that’s more convenient for the customer. See Selling Tip 2: It works both ways.

In retrospect: it’s about more than feedback. We need to agree on the way we’ll collaborate.

Sales Tip 1: Many small projects are better than one big project

Success rates are higher for small projects than for large projects. We reduce the size of the scope to only include a minimal feature set. As a result, the customer pays less, gets value sooner and can postpone decisions. I reduce my risk, get a chance to prove myself with the customer and can test our relationship with a small investment. But don’t do projects of a few days only.

Small projects bring lots of advantages to customer and provider IF we can keep the startup and transaction costs of each project small. As an example, at one time we had a rule that no project could take longer than three months and that we had to deliver at least each month for customer acceptance. The smallest project (an extra feature in a product) took one week from customer request to delivery of the product CD. Many projects had weekly delivery for acceptance.

In retrospect: the advice still stands, but we deal with scope differently. Instead of creating lots of User Stories and selecting those that have high value, we start with the Business Value drivers and then derive the minimal set of User Stories that will deliver the value. Therefore, our scope is minimal and sufficient by construction, not by elimination.

Implementation Tip 1: Let the customer sort the requirements

User Stories are ordered by the customer and implemented, as much as possible, in that order so that the customer gets the high value stories sooner, can test sooner and reduces the risk of dropping high value features.

Implementing this way is good for the team: we’re working with value- and business-driven priorities, we have to make sure that the user stories are independent to give the customer the liberty to sort.

In retrospect: the advice still stands. If the stories have been derived from the Business Value drivers, we will already have this ordering.

As an aside: many agile teams get off to a wrong start when they talk about this to their customer:

Team: we need you to order the stories by value and we’ll implement them in that order.
Customer: why is that important? As long as you deliver the scope, in any order, I’m happy.
Team: well, if we mis-estimate and run out of time we’ll drop some of the lower value stories.
Customer: what? You plan to run out of time? And you‘ll drop my stories? Do you guys know what you’re doing?

Mitigating schedule risk is one of the minor advantages of implementing by value. It’s more about delivering value sooner, getting information sooner, keeping the customer involved and mitigating the risk of building the wrong thing.

Implementation Tip 2: Requirements as stories. Don’t sweat the details

The requirements for the project should be expressed as high level stories. These stories’ contents have some margin for negotiation. The specification becomes shorter and easier to understand. We put less effort in creating the specification and we can delay decisions. This only works if I have a pretty good understanding of the domain and the customer. I need a good working relationship with the customer to be sure that the details will get filled in just in time.

We install a pull analysis system to create detailed specs just in time. We usually make this visible by having one or more columns on the kanban board that show this activity, so that we can quickly see if the customer is keeping up with the team.

In retrospect: the advice still stands, but how do you make it actionable? The best way is to start from Business Value Drivers and then to describe real Business Requirements. The specification and the contract shouldn’t fix implementation, they should specify the business goals to be achieved and the capabilities that must be delivered to achieve the goals.

Implementation Tip 3: Exchange Requests

If the customer wants to add a new User Story, they must first remove a number of User Stories for at least the cost of the new User Story. That’s the way we keep budget and timing constant. That’s the way we keep the price fixed.

Change Requests are evil. When we run a project (not only fixed price ones), we’re very strict on Change Control. Nothing gets changed in the scope unless we know there will be no negative effects. I don’t like change.

In retrospect: advice still stands. It’s simple, but very effective. A well-run project with Exchange Requests has a fixed price, fixed deadline and a minimum guaranteed value. The customer gets more value than expected, because they exchange high value new stories for lower value stories.

Implementation Tip 4: Put dropped requirements in a follow-up project

The User Stories that get dropped because of an Exchange Request are probably still useful (or they wouldn’t have been in scope in the first place). Never extend the current project, but define a follow-up project for these lower-value stories.

Fixed price, fixed deadline. The customer gets the system on the requested date. Qualifying Tip 1 means that the customer can’t afford to miss the deadline. If they want more, we’re more than happy to do another project.

In retrospect: the advice still stands. Moving deadlines reduce the value of the solution and demoralise the customer and the development team.

Implementation Tip 5: Let the customer use the software before the follow-up project

Let the customer use the delivered system for a while before starting the next project. The customer will learn a lot and come up with better ideas for the next project.

The best feedback comes from production use. Let the customer put the solution in production and start earning value. By the time we start the next project, the customer has more information and more money.

The problem is that we delay our income. I consider this a sound investment in a collaboration that’s valuable for both parties.

In retrospect: the advice still stands.

Implementation Tip 6: I’m the onsite customer

Not every customer can afford to have a full-time onsite customer in the team. In those cases, I as business analyst-project manager, can play the proxy customer role. This requires that the proxy customer knows a lot about the domain and that they know what they don’t know. Then we need to consult with the real customer.

Projects with a real onsite customer go measurably faster. Projects with a proxy customer are slower, but still faster than those with an off-site customer. We do need to be sure that we can get enough access to the real customers when we need it. That’s why we’ve agreed from the start how we’ll communicate and collaborate (see Qualifying Tip 2).

In retrospect: try to get a real onsite customer first. It may seem impossible, but if the project is value-driven you may be able to convince the customer. For example: “with an onsite customer avalailable N days, we can deliver the project one month earlier, which will bring an extra revenue of X“. If X is substantially more than the cost of N days, the customer would be stupid not to have an onsite customer.

Implementation Tip 7: Frequent releases, incremental delivery

Release frequenly for acceptance testing (for example once a week) and divide the project in one month increments that deliver a coherent set of functionality. The customer might discover that these increments are good enough to be used and will ask for incremental delivery.

The team and the customer need to learn to deal with regular releases. See how fast you can go today and decrease the “takt time” gradually.

In retrospect: the advice still stands. Unfortunately, I see more and more companies and team that go backwards, delivering fewer releases per year and increasing their cycle time. This leads to a vicious cycle, as releases get more complex and error-prone. Agile requires technical and operational excellence, otherwise frequent releases can’t be sustained.

Implementation Tip 8: Looking back to learn

Take time to look back and learn in a retrospective. Review actuals versus estimates to provide the basis for future estimates. Preserve new knowledge about risks and how to deal with them.

It may sound self-evident that you’d do this, but I’ve seen very few companies that learned from projects. In many cases there are retrospectives, but no actions or no time (or courage) to tackle root causes. Many projects feel like Groundhog Day: an endless rerun of the same mistakes with no hope of escaping. An ominous voice in my head keeps repeating “It is happening again. It is happening again.”

In retrospect: sound advice, but how do you make it actionable? Make sure that you find and tackle root causes using, for example, Systems Thinking techniques. Make sure that actions are defined and performed. Keep track of real project measurements, especially actual cost and time versus estimate.

And the score is…

Most of the advice still stands but the implementation should be described better to make it actionable.

We have changed the way we do analysis: instead of discovering the scope and estimating value, we define value and derive the scope from that. This value-driven approach brings several benefits:

  • The scope is minimal and sufficient by design, so we spend less time on it
  • The project is value-driven, which make prioritising and assigning an onsite customer easier
  • We negotiate about value first, cost second. Customers have no problem paying if they’re convinced of the value.

I’ve learned that the techniques from the two articles need to be taken together. It’s not “Do you want Agility with that?”,  but “You need Agility with that”.

There are some more tips I’ve collected over the years. We’ll look at them in the next entry.

August 19th, 2009 | Category: agile, agile analysis, books
Aug
17

Agile Fixed Price revisited – part 1

Agile Fixed Price Projects

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

  • Qualifying: do I want to take this project on and if so, how?
  • Selling: how do I get the contract in such a way that we can succeed?
  • Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

First, let’s re-read “The Price is Right“.

Qualifying Tip 1: Do I know what I’m doing?

I’ll only enter into a fixed-price contract if I can specify, estimate and plan the project as agreed, within a small tolerance.

I need to ask myself four questions:

  1. Am I familiar with the domain? If not, I’ll spend a lot of time learning and won’t be able to help the customer define what they really need.
  2. Am I familiar with the technology? If not, I’ll spend a lot of time dealing with stupid technology issues.
  3. Am I working with my usual team? If not, I’ll spend a lot of time building the team and I won’t be able to use velocity to estimate.
  4. Am I used to delivering projects of this size? I not, I’ll spend a lot of time scaling up my usual practices.

In retrospect: the advice still stands, not just for fixed-price projects.

Selling Tip 1: Don’t respond to RFPs, communicate

Don’t just respond to a written Request For Proposal but establish a real collaboration and communication with the customer.

We’re going to collaborate and communicate anyway, so let’s start now and see if it works before we’ve spend much time in this relationship.

In retrospect: the advice still stands. Some customers prefer not to communicate and keep providers at arm’s length. Do you really want to work with them? If so, plan on a large risk contingency.

Selling Tip 2: It works both ways

Ensure that the contract evenly distributes responsibilities and benefits between customer and provider. Make sure that the customer is committed to doing what you expect of them.

The most important goal of the sales process is to set up a working agreement between customer and provider than leads to success. Always “test” the customer: build in small commitments for the customer and see if they hold their part of the bargain.

In retrospect: the advice still stands. I won’t enter into an agreement that I think is unfair. I won’t start a project unless I have confidence that the customer will do what they’re responsible for. Too many projects go wrong because the customer agrees to do something and then doesn’t take up their responsibilities.

Selling Tip 3: Don’t underbid

Don’t quote a price below cost to win a contract with the intent of making it up later with extra costs.

No unfair contracts.

In retrospect: the advice still stands.

Selling Tip 4: Add enough slack to cover the risks

Do a risk assessment of the project. Add enough slack to the estimate to cover risk, estimation accuracy and (especially) the type of customer you’re working with.

How much slack needs to be added? That requires a lot of experience (see qualifying tip 1) and historical data. For example, what’s the fluctuation in velocity over the last few projects? How does this customer compare to previous customers?

In retrospect: the advice still stands, but I’d clarify that this is a “project buffer“, à la Critical Chain: the extra time does not get added to individual features, but is kept in a “global pot”. If things go better than expected, we add to the pot. If something goes less well than expected we take a bit from the pot. The state of the pot tells us if we’re on track.

Selling Tip 5: Real Business Requirements

Write the specification with the customer so that each feature is well-understood, adds business value and is testable.

We want to write a short, clear and actionable specification without technical detail and just enough functional detail to get started.

In retrospect: I didn’t emphasize this enough. We need to agree on Business Requirements, not System Requirements. What’s the difference? Business Requirements describe what the customer gets out of the project, the value that will be gained and the capabilities that are needed to achieve those goals. System Requirements describe how we will implement the capabilities. The customer doesn’t perform acceptance testing on implementations. The customer accepts when the capabilities deliver the expected value.

Implementation Tip 1: No Change Requests

Never allow Change Requests that increase the scope, cost or duration of a project.

Never. It’s a slippery slope: with each little change the project gets more out of control. I don’t like change.

In retrospect: the advice still stands, you should use “Exchange Requests” instead and only allow changes that are beneficial to the project.

Implementation Tip 2: Spend your slack wisely

Resist the temptation to “slack off” because there’s slack time left.

The project buffer should only be used when things go wrong. Avoid the temptation to “gold plate” features because there’s time left. The team should be energised and motivated to get their work done in time.

In retrospect: how do you implement this? Critical Chain recommends planning with “50% certainty” estimates, estimates that will be too short 50% of the time, to avoid Parkinsons Law. I recommend building a team that’s motivated to deliver quality and business value.

Implementation Tip 3: Simple, honest and correct tracking

Track progress using a simple burndown chart, but only count things that are DONE.

If you have a clear definition of done for every piece of work (and you can have definitions for each column on your kanban board), then you can simply record how much work is done versus how much work you expected to be done. For most projects, the expected amount of work done curve looks close enough to a zone around the diagonal from 100% to 0% done, so that a simple burndown chart, updated regularly, is enough to know where you are. Make sure that the information is visible and understandable to everyone involved.

In retrospect: the advice still stands. The important part is to be able to say that something is done. I’m very strict in this: I prefer seeing the burndown “flatline” because no story is done, than to see fake progress because something is “90% done”.

Implementation Tip 4: Manage your project

The job is not about specifying, estimating and planning perfectly. The job is about delivering what the customer needs.

Attack your risks or they will attack you.

Don’t shield the team. Help them to avoid and solve problems.

Good project managers don’t seem to do a lot and lead pretty uneventful lives.

Success comes from setting up the right project (qualifying) the right way (selling) and then doing all the daily work to keep it on track (implementing). It’s all about actively managing the project with a light touch.

In retrospect: the advice still stands, but to explain how you do this would require (at least) a whole book and lots of experience. Look for the project managers who have a reputation for “calm, quiet” projects that deliver and learn from them.

And the score is…

I still stand by what I wrote then, but I need to explain some of the tips in more detail.

I’ve learnt a lot more about writing contracts and discovering real business requirements.

I’ve also learnt that these tips aren’t enough to run a project, fixed-price or not. Agile (or professional) techniques aren’t an option, they’re necessary. Those are in the second part of the article.

August 17th, 2009 | Category: agile, books
« Newer Entries  
  Older Entries »