2010 February » Agile Training Toronto – Kanban, Lean, Scrum Coach

Archive for February, 2010

Inventors Dilemma and the Dead Core

Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.

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):

The code is fragile: difficult to work with and things break unpredictably
Little or no automated test harness.
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

Why We Make Mistakes

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.

Please review the mindmap below. The left half relates to how Agile works to avoid making mistakes. The right half of the mindmap has to do with proving out NLP presuppositions such as “perceived reality depends on our model of the world” and “memory is a synthetic process”.

Multi-tasking = Forgetting

I love the term CFIT = Controlled Flight Into Terrain. They had to make up a name for when pilots aren’t paying attention and fly into the ground because it happens. The reason is the same as many car accidents – driver/pilot inattention. The main point is that our brains are designed to do one thing at a time. In Agile and Lean we see a clear focus on one task at a time. Kanban and Scrumboards enforce this.

Keep it simple and constrain choices

In Agile we use automated unit and acceptance testing as well as test-driven development and refactoring to keep things simple. In Lean we use poka-yoke to mistake-proof a production step. These are good things since people make mistakes. Even worse, if we routinely don’t see problem, we are unlikely to see them when they do happen (we look but we don’t see).

People are overconfident

I have seen this with a lot of technical teams – overpromising what can be delivered. Fortunately, there is an easy fix – feedback. Accurately measuring a team’s velocity (only counting fully completed stories) will provide very clear feedback on progress that is visible to all.

Attitude

A lot of Agile teams promote an open culture where people are encouraged to question and discuss things. This is critical for avoiding catastrophes.

Humour & Candy

A final point to consider is that happy people are more resourceful – so consider candy and a dose of humour for your Agile team.

Sleep

A key practice in Agile is sustainable pace or energized work. Lean equivalent is avoiding the wastes of muri (overburden) and mura (unevenness).

Comments (1)

February 8, 2010 · Filed under Communication

Agile PMO: Real Time Governance

Last fall, I had the opportunity to hear Ross Pettit and Jane Robart present at the ThoughtWork QTB in Toronto. You can see the full presentation and slides on InfoQ. (Hint: if you are in Toronto, there is a talk on Legacy Systems coming up on Friday, Feb 5th).

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.