LeadingAnswers: Leadership and Agile Project Management Blog

Agile Project Leadership and More on Accreditation

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Agile Project Leadership Training Course

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

Agile Exception Processes – What to do when bad stuff happens to good projects

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

New Agile Project Leadership Training Course

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

Developments in Agile Project Management - Part 3

Here’s the last instalment from my Developments in Agile Project Management Paper. Last time I wrote about Accreditation and Generation Y. Today I cover Leadership, Lean and Six Sigma, and Tool support.

    

You can download the full paper with the additional intro to agile and post-agile sections at the end of this post.

Developments in Agile Project Management

Earlier this year I submitted a presentation proposal for the PMI Global Congress conference held in Atlanta this October. I called it "Developments in Agile Project Management" and wrote up a pretty seductive outline that got accepted. That is all well and good, but now the accompanying paper is due and I have to decide what to write about!

I felt a little guilty submitting a proposal when I did not know what I was going to talk about, but in the agile spirit of delaying decisions to the `last-responsible-moment` it gave me the flexibility of including some late-breaking new discovery or trend that may have been missed by locking-in early. Plus, it is not as though I have nothing to present, rather that my choice of topics had not been finalized.

So, in this and my next couple of posts I will outline some of my thoughts on "Developments in Agile Project Management" and offer an open invitation for readers to provide feedback and suggest alternative topics.

The Audience
The typical PMI conference attendee is not very familiar with agile methods. While the title will likely attract those who do know about agile, the majority will still only have a passing awareness of what it is all about. So I will have to keep the content fairly basic and prefix it with a quick tour of agile concepts to provide context. I`d love to present on something like `EVA to Andons: Mapping traditional metrics to agile-lean indicators`, but only a few people would understand it and many others may leave with the impression agile is just mumbo-jumbo and not for them. So, I think the topics should remain fairly basic to engage a large proportion of the audience.

Outline
My thoughts on the structure currently go like this:

Introduction

• Agile methods have been gaining in popularity for software development projects
• As they are becoming more popular, new people are expanding their boundaries and application areas

Why software development is hard to manage

• The intangible nature of software
• Difficulty articulating true requirements
• High rates of change
• High complexity, sometimes R&D based, unprecedented

How Agile methods help

• Incremental delivery provides frequent checkpoints
• Iterative development reduces technical risk
• Lifecycle supports late breaking changes

How Agile methods work

• Business Prioritization
• Timeboxed iterations
• Communications and constraint removal
• Reviews, Retrospectives, acknowledgements and adaptation

Then once this overview is out of the way, introduce the topics that can be thought of as "Developments in Agile Project Management":

Accreditation – Like when children grow up and progress from playgroup to school and start experiencing exams, accreditation and certification in agile methods are increasing as we leave the kindergarten.

Redesigning the workplace to attract and retain Gen Y`ers – how the new generation who “grew up digital” and are now entering the workforce demand: inclusion, collaboration and empowerment – handily the approach promoted by agile methods.

Recognizing the link to leadership – how agile project management is more closely aligned to leadership best practice than traditional project management.

Support by tools and processes – How a new segment of agile project management tools and processes have emerged to support agile projects.

Integration with adjoining fields such as Lean Six Sigma and the Theory of Constraints – How the boundaries between agile and these highly compatible fields are disappearing as a broader audience adopt agile and bring their own contributions and links.

This is probably more topics than I should attempt to cover in a paper or presentation but I wanted to get my ideas out there and ask for alternatives. If you where giving a presentation on "Developments in Agile Project Management" what would you include and why?

Lean Development 2

More from Mary Poppendieck's Lean presentation.
After the introduction to lean, Mary illustrated how lean can be applied to software development. The lean tenets are:

1. Eliminate waste
2. Build quality in
3. Create knowledge
4. Defer commitment
5. Deliver fast
6. Respect people
7. Optimize the whole

Many of these topics have already been covered in Mary’s first book better than I can describe them here, so I will focus on new ideas on the first (Eliminate Waste) and last (Optimize the whole) points listed.

Eliminate Waste
In software development, the first principle “Eliminate Waste” requires us to put on “customer glasses” and see the world as customers do. Anything that does not add customer value is waste; these include:

• Paper work and lists – these are just delaying tactics
• Red tape, like signing off on specs and documents
• Anything that confuses people
• Stuff that does not work
• Features that are not needed

In manufacturing there are 7 classic forms of waste and these have parallels in the software development world.

Mary made a nice analogy, likening extra features to “project cholesterol”, the silent killer of projects that drown projects in complexity.

Optimize the whole
Software on its own is rather useless, it becomes of value to an organization when it allows business benefits to be realized. In this regard if we can shift from thinking of software projects to thinking more of software products we will be better aligned with the business.

Projects characteristics include:
Upfront funding, which leads to
Scope fixed at outset, which leads to
Success = conformance to Cost, Schedule, and Scope
Documentation is often tossed to supporting groups

Product characteristics include:
Incremental funding, which leads to
Scope expected to evolve
Success = profit, market share
Documentation typically stays with team

The key point being made here is that many traditional projects are one large batch. They have one lump of funding, one set of requirements, one deliverable, and one set of documentation. From a lean perspective these large batch sizes are wasteful, and it would be preferable to model software development after a product lifecycle that gets smaller batches of funds and requirements and then assesses success by business value. Evolution is expected and the documentation stays with the team.

Finally, Mary wrapped up by talking about meaningful metrics, she confirmed that many traditional metrics such as lines of code are counter productive, and suggested 3 holistic measures to focus on:

1. Average Cycle Time – how long things take to go through the system. E.g. requirements from capture to acceptance and defects from detection to correction.
2. The Business Case – Is the project still viable? Without this, everything else is irrelevant.
3. Satisfied Customers – are your customers happy?

These are great measures to track and a nice introduction into discussing one of my favourite books “Managing the Design Factory” by Donald Reinertsen.

Lean Development

As I mentioned yesterday, Mary Poppendieck presented last night at the Calgary Agile Methods User Group (CAMUG). The title of her talk was “Beyond Agile Software Development: Becoming Lean” and she covered material from her new book “Implementing Lean Software Development: From Concept to Cash” which should be out next week.

Her talk started with an overview of lean and the Toyota Production System (TPS). This included key players such as Taiichi Ohno often called the father of the TPS and Shigeo Shingo a consultant to Toyota who’s book was translated into English, before Ohno’s. Mary explained that Toyota first started making cars in an environment of raw material short supply. Taiichi Ohno’s background was in the weaving loom industry and a key idea that he brought to auto manufacturing was the idea of stopping the line as soon as a problem occurred. Given this pre-occupation of defect avoidance, I always think his surname Ohno (as in “Oh-no, stop the line!”) is apt and amusing.

Mary talked about the lean concept of eliminating waste through just in time flow. Within software development that equates to looking for lists, such as lists of defects, lists of changes, etc and then finding ways to reduce or eliminate these lists. i.e. fix the underlying problem so the lists do not build up (as opposed to just throwing away your defect list).

During the introduction Mary also talked about two kinds of inspection that organizations typically undertake. The first, inspections to find defects, she described as waste. If we are attempting to test in quality at the end of the process then we are already too late. The second, and preferred type of inspections, are those aimed at preventing defects – i.e. inspections on the process not the parts, to ensure the process can not allow bad parts to get through. In the software world this would be getting people more engaged in automating the build and test process than performing manual unit tests.

The last part of her introduction to lean really struck a chord for me. It concerned the idea of Respecting People. The following quote was used: “Only after American carmakers had exhausted every other explanation for Toyota’s success, including better suppliers, cheaper labour, a heavier investment in robots, etc. Did they finally realize that the true differentiator lay in harnessing the intellect of ‘ordinary employees’”. So, the key feature is that management accepts that it is the workers on the shop floor that will have the best insights and best solutions for solving problems and creating innovations and efficiency savings. Workers can do this more successfully than managers because they possess the local domain knowledge and best insights into the key issues at play.

In the software world this parallels the idea of empowering the team to organize and design their own work packages to meet the high-level project objectives. As a project manager of a software development team, do not attempt to plan and specify the software creation steps in advance and hand them to developers in detailed Gantt charts, instead let the developers harness their own domain knowledge and serve the team by maintaining a clear project vision, removing obstacles, and shielding them from interruptions.

The Lean / Agile Connection Part 2

I have just come back from Mary Poppendieck’s presentation on “Beyond Agile Software Development: Becoming Lean”. It was a good talk that I will write up in more detail tomorrow, but for now here are a couple of points that I found interesting.

Queues, including backlogs of features to develop, are to be avoided. Ideally work should be limited to the capacity of the system. Mary was asked how this sits with agile methods such as Scrum that recommend backlogs and she acknowledged this key difference between lean and agile. She believes a backlog is a buffer that may cause disrespect towards those requesting the features and is really a mechanism to deal with dysfunctional organizations who can not organize their flow of work properly. This is an interesting insight and a motivator to try and keep backlogs as short as possible.

The three holistic metrics that software development project should be tracking above all others are:

1. Average Cycle Time – e.g. from feature description to production
2. The Business Case – is the project viable?
3. Customer Satisfaction – do the customers like and value what is being produced?

More on Mary’s talk and the differences between Lean and Agile tomorrow.

The Lean / Agile Connection Part 1

Baseline magazine recently published an interesting article entitled “Business Process Management: What's Driving Toyota?” that profiled Toyota’s lean projection system.

In the article they list six management tools for creating excellence in the workplace. Agile methods utilize many of the same lean principles from the Toyota Production System. In the following list I have augmented agile project management interpretations on the Baseline descriptions of their key practices.

1. Just-in-time: Toyota employs one of the most sophisticated supply chain systems in manufacturing, working closely with suppliers to ensure that parts arrive just when needed.

Agile Interpretation – in agile projects the elaboration of (non-architecturally significant) requirements is delayed until the last responsible moment. There is no point building up large inventories of detailed requirements and then handing them over, in large batches, to downstream activities. First of all, many of the requirements may change or go away completely before they are coded. This would be pure waste (muda), plus large batch transfers are inefficient and cause queues, and increased levels of scrap and rework.

2. Jidoka: At every stage of the assembly line, Toyota employs devices allowing workers to stop production to correct defects.

Agile Interpretation – Automated build and unit test systems that stop and alert the team if ever a code check-in breaks the build or unit test suite. Multi-disciplined developers pay closer attention to quality via techniques such as TDD. Team members can raise “blocking issues” at the daily standup.

3. Kaizen: This is a system for continuous improvement. Toyota constantly looks to improve its business processes by finding ways to take Muda (waste) out of the system

Agile Interpretation – At iteration retrospectives meetings the team is asked: What went well?, What did not go well? Recommendations for the next iteration? The intent is to improve the process within this project. Lessons Learned at the end of a project is frankly, too little, too late. Issues raised at the Daily Stand-up Meeting are often pointers to things that need improvement. Agile projects are always actively looking for how to improve the process during its execution.

4. Andons: Wherever possible, Toyota uses visual controls, or Andons, such as overhead displays, plasma screens and electronic dashboards to quickly convey the state of work.

Agile Interpretation – Agile metrics use clear visual controls over percent plan complete type measures. Information radiators, cumulative flow diagrams, burn down charts, To-Do / In progress / Done boards. These are all great examples of Andons in practice.

5. PokaYokes: Toyota uses a range of these low-cost, highly reliable devices throughout its operations to prevent defects.

Agile Interpretation - Build status traffic lights and lava lamps, anything simple yet hard to ignore, that helps alert the team to defects that need fixing.

6. Genchi Genbutsu: The literal translation of this term is, "Go and see for yourself." Rather than hear about a problem, Toyota requires its workers, team leaders and executives to go and see a problem directly and to work collectively on a solution.

Agile Interpretation – Again, Daily Stand-up Meetings are a great way to go and hear the issues from the horse's-mouth rather than interpret trends from tracking Gantt charts. Regular releases of working software are excellent ways of assessing progress and defects; go try it and see for yourself.

Mary Poppendieck writes extensively on the lean / agile connection. She is in town again tomorrow night, talking at the Calgary Agile Methods User Group (CAMUG) on “Beyond Agile Software Development: Becoming Lean”. I’ll add a post about her presentation after tomorrow’s event.