Agile Success

I'm always interested in project success, so I was drawn to this article in CIO.com: "5 Principles for Reducing IT Project Failure"

Rather than being IT-specific I would say that these are simply 5 principles for reducing project failure:

1. Communicate: If everyone involved in your IT project doesn’t know what they’re working on, when it’s due, how to get it done and who the audience is, how can you possibly expect your project to succeed?

The aim is to ensure that everyone in the project knows what is going on, what is expected, when it's expected, for whom it's expected, etc. Nobody is then treated like a mushroom kept in the dark and fed fertiliser.

2. Consolidate: We’re talking about information and tasks here.

If you can't find the right information for what you're working on, or it takes you a long time to find it, you are wasting time and effort that can be better spent working constructively towards your project goals. Reduce bureaucracy, cut through the red tape and put information within easy reach so everyone can do the job that they are supposed to be doing.

3. Prioritize: Issues come in, bugs are discovered, and new application features are conceived of every day.

Dropping everything to work on a just-reported bug, or to do a "quick job" for someone is probably not the best use of someone's time. The bug may be of lower priority than what you are currently working on. The "quick job" is a distraction where your time can be better spent working on something delivering higher value.

4. Requirements: In ALM and your SDLC, before you can do anything else, you need to identify, prioritize and agree on application (and project) requirements.

It is fundamental that you need to know what the requirements are before you work on something. Once requirements are elicited, they can be analysed and prioritised. Misunderstandings can be removed to ensure that the project team and stakeholders are of one view as to what the requirements are. Understood requirements mean that something can be designed and built. Understood requirements mean that a plan can be made to test them.

5. Manage Time: As management, it’s up to you to take the first step in setting reasonable deadlines and milestones for your team throughout the project.

Knowing where you are in a project, where you should be and how fast you are delivering are vital pieces of information in determining what will be delivered by when.

Alternatively, these are just, 5 Agile/Scrum principles.


1. Communicate

Scrum revolves around a cross-functional, self-organising Scrum Team that has a daily stand-up meeting where every team member communicates what he did the previous day, what he is committing to do today and if he has any blockages or impediments.

Developers, testers, DBAs, designers, BAs are all kept informed of what all the other members of the Scrum Team are doing.

Scrum also involves the whole Scrum Team being involved in the Sprint Planning.

The Scrum Board and Burndown Chart should be visible to all, so everybody can see what the Scrum Team is working on, and what their progress is - instant reporting!

2. Consolidate

Agility is about individuals and interactions being valued more than processes and tools, and about working code being valued more than comprehensive documentation. "Muda", one of the Toyota Principles, is focused on removing waste, where waste means wasted materials but also means wasted time and effort.

Agile practices refer to doing "just enough" or doing what is "sufficient and necessary". Agile teams commonly use wikis to document information, they record requirements on cards or Post It notes which are kept on the Scrum Board (or Kanban Board).

3. Prioritise

Scrum requires the Product Owner to prioritise work. The Scrum Team only works on what is currently the highest priority collection of requirements. Requirements should be prioritised so that the ones delivering the highest business value are delivered first. Also, those requirements which eliminate the most risk should also be prioritised highest.

Considering simply high and low business value and risk, the best order in which to prioritise requirements according to their business value and risk is:

1. High risk, High business value
2. Low risk, High business value
3. Low risk, Low business value
4. High risk, Low business value

The aim is to eliminate as much risk and deliver as much business value as early as possible, overall delivering a high ROI. Risk can also be categorised as uncertainty - the uncertainty that something is feasible.

Bugs, new requirements, existing requirements all go on the backlog and are prioritised accordingly.


4. Requirements

Scrum can not proceed without requirements.

The list of requirements is maintained in a Product Backlog, in priority order (c.f. Prioritise)


5. Manage Time

Scrum sets regular deadlines for the Scrum Team to commit itself to delivering working software satisfying the requirements.

Progress is visible on the Scrum Board - which presents a snapshot of progress in terms of what's Done, what the team are Doing and what's still To Do. Progress is also visible in the Burndown Chart which shows the rate of progress.

Requirements and tasks are estimated by the people who will do the work - acknowledged to be more accurate than estimates by people who do not do the work - and that knowledge is used to set realistic expectations.

Daily reporting in the Daily Scrum means that people are held accountable to the whole Scrum Team for the commitments they make each day.


So, 5 principles for reducing IT project failure are satisfied by Agile practices. Though I often remark that what are often regarded as Agile practices (coding standards, continuous integration, etc.) are just good engineering practices. So, Alistair Cockburn is right that Agile is the norm - it's just good practice.

Peopleware: you must read this book!

Many people have heard the quote that the best software developers are 10 times more productive than the worst. Whilst I was reading the course material for my course in project management I came across the source for this statistic:

"Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister, 2nd edition, Dorset House, 1999

Reading this book you get to see the rest of the results:

• the best developers are 2.5 times more productive than the average - so there are a lot of very unproductive developers out there
• the best developers are in development teams that are 10 times more productive than the worst teams - it's not just about individuals, but who they work with, who they work for and in what kind of environment they work
• people are more productive when they have fewer distractions - obvious, but lost on many managers
• Parkinson's Law was a joke about a bureaucracy, not a general observation
• higher pressure does not improve productivity and/or quality

After just reading a couple of pages I came to the conclusion that this book should be made a mandatory read before anyone takes on a new position as a manager - including, or especially, several of my previous managers!

I've only read a few chapters, but my enthusiam shows no bounds.

Midget Project Failure

Some time ago I owned an MG Midget that I'd decided to restore.

I started with high hopes - expecting to complete the restoration project in a few months so that I'd be back on the road again by the following Summer. Events, as is often the case, took a somewhat different course.

Everything felt like it was starting off fine, though the breaking up of the old body shell would have benefitted from the use of better tools to speed things along, such as using a generator and power tools to cut up the pieces, rather than hand tools and brute force.

Fitting of the rear springs went well, but I'd not bought the right size of thread taps, so had to move a smaller-sized tap around inside the captive nuts to tap them, clearing away the paint. Using the right size of thread tap from the start would have made the task easier, and I would have been more confident that the threads were tapped cleanly and correctly.

Each of the parts to be refitted to the new body shell was cleaned down, de-rusted and re-painted. Unfortunately, not all of the de-rusting was 100% successful, and there were areas of rust that reappeared through the new paint. Also, the new paint was not always as tough a finish as I'd have liked. Meanwhile, these restored components were gradually refitted to the new body shell throughout the Winter and Spring.

So, I should really have improved on my de-rusting techniques, ensuring that they were completely successful in order to prevent me from having to do the same work to them again, but after having to remove them from the car. Similarly, I should really have improved on my re-painting techniques to ensure that the items were painted well, and that they had a tough, durable finish.

Also, did all refitted items have to be de-rusted at that point? Could they have been fitted in order to facilitate getting the car back onto the road and then restored later on?

Similarly, did all the items have to be fitted during the Winter and Spring? There was less natural light during those months, and the air was damp. If I'd prepared the parts to be fitted, and saved them up to fit them in late Spring and Summer the air would have been dry and the light better, giving me better visibility for the job, and less chance of trapping moisture that would cause rust later.

Whilst I was cleaning down and de-rusting the old parts, I saw how some components could be modified to improve the overall result - upgrading to newer parts, installing additional gauges, upgrading the suspension, modifying parts. Again, did these all have to be done at that time? Admittedly these were the exciting things, rather than the regular restoration, but they were a distraction from the goal.

Though, what was my goal? Was it to get the car running again by summer? Was it to perform a concourse-level restoration? Was it to perform an good restoration and to improve the car to my own specification? Admittedly, the goal was unclear, and the lack of clear objectives distracted me.

As the months went by, they turned into years. I changed jobs, and had less time to devote to the restoration project. Then the enthusiasm went - there was no real result for all those years of effort. The car may have been 90% complete, but the last 10% was feeling far from achievable. Doubts also began to creep in, with me worrying about whether I had done a good job on the car in the early stages, particularly on the vital structural pieces. These doubts were also fuelled by the fact that various adjustments had to be made to get pieces to (almost) fit into place.

Eventually I realised that I just did not have the time to complete the project, and I did not have the inclination either. So, away the car went, sold as an incomplete restoration project.

I learned a great deal from the experience, and not just about bolting parts together.

I learned that this project had failed because of a failure of project management.

• The goals were unclear - car on the road by the Summer, or car restored to concourse style?


• The un-clear goals meant that there was no clear plan. With no clear plan there was scope creep - in came all the little "nice to haves"; those shiny parts and new instruments. Without a clear plan there was no clear schedule for preparing parts in Winter and fitting them in the dry and light of the Summer.


• Quality control was not clear from the outset. There was no clearly defined quality standard for the use of the right tools, and the quality of the restored parts being refitted. If quality control is not established from the beginning, then it means that extra work is required to be undertaken later on to verify and/or correct earlier quality issues.


• The unclear goals meant that there were no clear deliverables. There were no iterations identified for getting the car on the road (almost as a working prototype) then building up from there with the additional features. An iterative approach would also have boosted my confidence with my project-sponsor's hat on and boosted my confidence with my project worker's hat on

So, there I left a failed project, but I came out of the experience wiser.