Mihai Iancu has a wonderful mindmap to show the patterns in a visual an approachable manner. Thanks to Mihai for allowing me to share this with you.

Here are some of my favourite patterns:

• Do food – Create a relaxed setting and leverage cultural bonding that happens when people eat together
• Tailor made – Find the right solution for the people you are working with; every situation is unique
• Step by step – Take things one step at a time and build on successes

Please comment on yours.

A typical (success) story

• Management – we need to hit the date.
• Developers – OK, we’ll cut quality but won’t tell you.
• Success! We made the date. We’re heroes!

BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.

Design-dead core

Do you have  a design-dead core?  Here’s a quick checklist (see mindmap below):

1. The code is fragile: difficult to work with and things break unpredictably
2. Little or no automated test harness.
3. Few experts who really understand the technology.

Innovator’s Dilemma

The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.

This is also called the inventor’s dilemma.

Agile to the Rescue

Teams that follow Agile practices avoid this peril in two ways.

By managing features and scope, teams can find the most valuable software to deliver by a certain date.

Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.

Release Burndown to illustrate the Innovator’s Dilemma

Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays.  After a few years, they build a design-dead core.

As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.

Help! I have a dead core!

OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.

Watch the video

The whole video is great, but for the part explaining the Innovator’s dilemma check out:

• Start: 35:38
• Stop: 45:07

One of my goals is to make a mindmap of every book that I read.  I figure if I can take the time to read it, I may as well take a little time to synthesize the content of the book into a mindmap so I can remember it later.  Seems like a good idea, and this is the first one in what I hope will be a long and informative series.

So, today’s review is on Why We Make Mistakes – a book that describes failure modes common to people. Many of my regular readers will be wondering what this has to do with Agile and Lean, but it turns out that there are several direct links to industry practices.

The most memorable phrase from the presentation is: All IT projects are a voyage of discovery. This seemed to be a very salient way to express learning and communication are key.  Check out my drawing of a boat

So the talk is all about governance - how do we ensure that our projects are succeeding? There really isn’t very much in there about the PMO’s role and for that matter about Agile.  Still some very interesting points…

One aspect of governance is making sure we have the right people in the right roles since IT is a people business. The reality is that most managers tend to stick with people even if they aren’t working out in that role. One idea is to use net promoter score: would you recommend a colleage for another project?

Another key idea is independent steering committees. In many cases the stakeholders (usually senior management) are on the steering committee for a project that they are sponsoring. Well, you know what happens when there is a conflict of interest. I’ve seen it happen first hand recently and it wasn’t pretty.

Finally, good steering committees have a breadth of talent that can function as a team to dig into the project data and ask tough questions. They need the right set of lenses to view the project from different perspectives – technical, financial, customer, etc.

Overall the talk was quite informative since I have seen lot’s of room for improving governance at most organizations I have worked at.

Scaling Factors are about the kinds of things that make software projects more difficult (whether using Agile or not). Each of these factors require additional considerations that are outside of basic Agile practice. I find this a nice way of thinking about project complexity since this directly maps to the challenge with adopting Agile.

There are no repeatable projects.

There are no repeatable projects. I thought that was worth repeating since a lot of organizations still don’t understand that each project has a distinct signature and may require a different approach: Standardization is a good recipe for failure. Reading between the lines this seems to be a shot at PMO’s that are mandated to standardize software delivery.

I have run up against this waterfallacy many times. Here are some of the things I have heard:

• “Agile is all about coding, not about documenting.”
• “The Agile manifesto says documentation is not important.”
• “How can you deliver software without a requirements document?”

The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.

How to overcome these statements?  I talk about 4 things:

1. Agile manifesto – what it actually says
2. Why Agile values face to face communication
3. How Agile documentation works and how Agile teams document a lot
4. If you are using Scrum, it’s up to the organization to define what is right.

Agile Values: Working software over comprehensive documentation

In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!

Agile Principle: Use face to face communication

One of the key Agile Principles is:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This signals that people should talk to each other rather than communicating through documents.  Does it say not to document?  No!

Agile Documentation – just the right amount

Agile teams tend to use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.

Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.

Scrum lets the organization decide how much to document

If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.

Usually people are convinced at this point and say – “Wow!  I didn’t know that.”

Strangely, I find myself in a situation where I need to place a very high value on process to provide shock therapy to a client that is in the whirlpool at the end of the waterfall.

It’s the usual software story of an over-full release with a fixed release date required by not one but two external customers. Add to this a chaotic process and broken telephone between functional groups. The interesting question posed by the client is this: “Is there anything you can do to help us?” (What would you say?)

Given the timelines and pressure, there is no way I know how to do Agile in a conventional way. So tomorrow, I am launching what Gerry Kirk and I called Guerrilla Agile – something light and tactical. To make this work, I will need to very directive in what needs to happen. The main goal of this phase is to get shippable software. A later phase is planned for a sustainable transition to Agile.

In terms of my training budget, I figure I have at most 3 hours. Here the emphasis will be on cross-functional teams and working together. So in this sense I am valuing people and interactions over process  - not the other way around. Perhaps the title of this post is backwards: maybe all the command and control around  process is just a smoke-screen so I can focus people on what’s important: teamwork.

P.S. Given all the passion and energy around Kanban and Scrum these days, I think it apropos to mention that we’ll get started with Kanban since even 1 week long sprints would be to big  a challenge in the current environment.

• Certified Scrum Master Training – Feb 16 & 17
• Agile Games Day – Feb 18

This is a great chance to learn from not one but two experienced Agile coaches.  If you know anyone who might be interested, please let them know.

The values and agile project life cycle slides were not show; instead, Gerry did a live diagram construction (see photo below). This approach worked well and we got lot’s of great questions.

One of the questions was about Agile contracting.  There is a good presentation I commented on in a recent post.