When introducing agile methods we need to consider factors such as lifecycle coverage, roles, and activities. Methodology Scope Diagrams provide a way of illustrate these characteristics and quickly highlight gaps in coverage for further consideration.

For example, many agile methods don’t really start until a candidate list of features has been identified. So while they may offer great ways to develop software, they may not provide much in the way of project feasibility guidance. Before discarding existing practices, we need to determine if they are really required and if so, if they need to be replaced or retained. 

When leading teams, credibility is a prerequisite for support from the group. This does not mean that you have to be an expert in the project domain, or have a stellar record of leading teams on complex projects (although these help). Instead in means that people trust you as a person, they believe that you are looking towards the right end goal, have a fair idea of how to get there, and can generate enthusiasm for the work.

James Kouzes and Barry Posner, authors of the best selling book “The Leadership Challenge” have undertaken extensive studies that ask company employees “What values do you look for in a leader?” Over a 10 year period they have amassed answers from over 75,000 people and the same qualities recur across industries and cultures.

On November 7-9 the Agile Business Conference and Leadership Summit will be taking place in London featuring agile and leadership presentations and workshops. I will be presenting on “Utilising Agile Methods alongside the PMBOK Guide”.

This is the same title as a presentation I gave at the PMI Global Congress conference in Anaheim in 2004. I will of course be updating the material and tailoring it for the audience, but how the title came about is an interesting story. For a number of years I had been submitting outlines for the PMI’s annual Global Congress conference and despite, what I considered, good content they were all rejected. The titles were a bit controversial, like “Agile Methods as a Replacement to the PMBOK for Software Projects”, “Agile Methods as the Next Evolution in PM Theory”, etc. It should really have been no surprise that my applications were turned down. So I smartened up, and submitted the non-confrontational “Utilizing Agile Methods Alongside the PMBOK Guide” and all of a sudden it was accepted. Now, with the door open to present at the PMI, I could suggest all the Agile focused material I wanted.

The next Calgary Agile Project Leadership Network (APLN) meeting on Thursday October 12th is full. However we are currently putting names on a wait list in case of cancellations, so if you would still like to attend this event send an email with your contact details to [email protected] and we will see if we can get you in.

For those of you already signed up, I’m sure the presentation will be very interesting. Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects” and I had a chance to review Rob’s material earlier this week. It looks really good and draws from Rob’s deep experience along with materials from Mike Cohn and Steve McConnell.

Event:                         Calgary APLN: “Agile Estimation and Planning”
Presenter:                  Rob Morris, Principle Software Engineer, CDL Systems
Date:                          Thursday October 12, 2006
Time:                          12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
                                   Light beverages to be provided
Location:                   5th Avenue Place – Conference Room
                                   Suite 202, 420 – 2nd Street SW

Topic: “Agile Estimation and Planning”

Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.

About the Speaker:

Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.

I listened to the Tenrox “Managing People in a Flat World” webinar earlier this week, the title of which inspired my first “Leading Teams in a Flat World” post a week ago. The webinar did not elaborate on Flat World needs much, but launched very quickly into the sales pitch for their project management tool. This was OK and really all I expected from a vendor company, kudos to them for at least tying the webinar into a timely, relevant best-seller. However, it did get me thinking into how companies should be preparing to harness Flat World forces.

When new tools became available during previous work revolutions, organizations were slow and clumsy to adopt them. When electricity replaced steam-power, companies attempted to replace their single, large steam engine that drove the factory machines via large belts, with a single large electric motor that drive machines via the same dangerous and unreliable belts. It took many years for companies to change from tall compact factories that facilitated centralized power distribution, to long, low buildings that more efficiently embedded smaller electric motors in machinery. I think there is a parallel here with our attempts to harness Flat World powers to-date.

Risk management is an important activity on both traditional and agile projects. This article will introduce a method for quickly visualizing the risk status of a project and identifying risk trends.

A widely accepted definition of a risk is:

“A discreet occurrence that may affect the project for good or bad”

However, I prefer the less comprehensive, but higher impact statement:

“Today’s risks could be tomorrow’s problems”

We need to actively attack risks before they become problems on the project. Unfortunately, all too often risk analysis and risk management steps are conducted alongside the regular project tasks rather than being drivers for work scheduling. Risk management plans and risk lists are created, but their findings do not influence task selection and scheduling, then risks occur and people identify the issue “Oh look, risk #4 occurred”, but the risk mitigation steps had never made it into the project plan.

Agile projects have many opportunities to actively attack the risks on a project before they can become tomorrow’s problems. Iterative development allows high risk work to be tackled early in the lifecycle. Features (or stories) that carry high risk can be undertaken in early iterations to prove technology and remove doubts. Carefully balancing the delivery of business value and risk reduction is a wise strategy for feature selection that I will write more on shortly. Until then how do we illustrate the risks on our projects to all stakeholders?

“In no other area of management education is the concept of myth as prevailing as in leadership.” – Jeffery Pinto, Project Leadership: from Theory to Practice.

Agile project management is more closely aligned to leadership best practice than traditional project management best practice. However, the domain of leadership is rife with myths and misconceptions. It also has an “elitist” reputation which puts most people off wanting to learn more about it since our sense of humility guides us away from pursuing such egotistical goals. This produces a vicious circle, we have these misconceptions about leadership, but because it seems egocentric we leave it alone and do not overcome them.

This is a shame because when you strip away the myths; leadership is really about team work, empowering others, and putting the goals of an endeavour above personal goals – quite the opposite of elitist, egocentric behaviour.

Let’s explore and slay the five myths of leadership…

Cumulative Flow Diagrams (CFDs) are valuable tools for tracking and forecasting agile projects. Today we will look at creating CFDs and using them to gain insights into project issues, cycle times, and likely completion dates.

In Microsoft Excel a CFD can be created using the “Area Graph” option. The attached file “Example CFD.XLS” contains the data used to create the CFDs in this article, including the one shown below.


Figure 1 – Sample Cumulative Flow Diagram
Download cfd_example.xls

I recently received an invite for a webinar entitled “Managing People and Projects in a Flat World” that occurs next week. I’m not keen on the term “managing people” as I believe “We manage property and lead people. If you try to manage people they feel like property.” However the general topic is interesting and so I thought a more appropriate theme for a post might be “Leading Teams in a Flat World”

First, we should define what a “Flat World” is. The term comes from the best selling book “The World Is Flat: A Brief History of the Twenty-First Century” by Thomas L. Friedman. In the book Friedman builds a compelling argument for an impending globalization we are just beginning to witness. Many factors are acting as “flatteners” to bring about competition and collaboration from around the world in traditional and emerging markets. These factors include widespread broadband access, open source software, outsourcing, and a proliferation of highly educated engineers in India, China, and Eastern Europe. Friedman asserts that in the future organizations who can embrace these changes will prosper while those who ignore them do so at their peril.

So, abilities to lead teams in a flat world will likely become vital skills. Given the challenges and opportunities for effective teamwork and collaboration what recommendations can we offer for geographically dispersed, multi-cultural teams?

The next Calgary Agile Project Leadership Network (APLN) meeting will be on Thursday October 12th when Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects”. Here are the details:

Event: Calgary APLN: “Agile Estimation and Planning”
Presenter: Rob Morris, Principle Software Engineer, CDL Software
Date: Thursday October 12, 2006
Time: 12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
Light beverages to be provided
Location: 5th Avenue Place – Conference Room
Suite 202, 420 – 2nd Street SW

Topic: “Agile Estimation and Planning”
Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.

About the Speaker:
Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.

To register for this event and for more information about the Calgary APLN group visit www.calgaryapln.org

The software development industry has a poor track record for developing and employing effective software metrics. This is because most of the metrics selected are tangential to the true goal of software development - delivering business value, and instead focus on software attributes and accounting measures.

Metrics such as lines-of-code per developer week, function points created, hours worked, or budget consumed appear important measures, but they have dangerous and counterproductive implications. The use of these metrics reward the wrong behaviour, the phrase “you get what you measure”, highlights the problem. By tracking lines of code written, visible and unconscious incentives to generate lots of code are established. On the surface this may seem attractive, as a manger of a project it is gratifying to see lots of code being written, but what is really required is functionality completed, business value generated, and customers satisfied.

The more code generated the harder a system is to maintain and extend. With incentives like lines-of-code written, how do value-adding activities like refactoring simplifications appear? Reducing 20,000 lines of code to 15,000 is a good thing, but from the lines-of-code perspective it looks like the project is going backwards.

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.

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.

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.

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.

Planning in projects, agile or traditional, is a critical activity, but it is only as good as the information it is based on. The bulk of planning effort should not be reserved for when we know least about a project - at the beginning. Instead planning needs to occur throughout the project and plans need to evolve to reflect the changing realities of projects.

All too often projects begin to diverge from plans and the assumption is that the project needs bringing back on track. Well, perhaps the plan was lousy? The quote “The map is not the territory” from Alfred Korzybski, nicely summarizes the position. When reality diverges from the plan, it is reality we have to rely on. Now, I am not suggesting that we do not track to plans and just let things take as long as they like. Rather, we insert the step of analyzing why the plan and the project have diverged; in software projects the reason is often we had a poor initial plan.

I was recently interviewed by Dina Scott from the Controlling Chaos podcast show. It was a good  discussion that contrasts agile and traditional project management, iterative development, adaptation, and the agile emphasis on empowered teams.

It was produced in two parts, part one can be found here (it really starts 8:45 in) and part two is here. As always, I would be interested in hearing your comments.

Download googledfe4023865a7f9ea.html

Technorati Profile

Given the close correlation between leadership best practice and agile project management, it is useful to search leadership techniques for additional approaches that could also assist on agile projects. (Un)fortunately there is no standard Leadership Body of Knowledge, instead there is a plethora of overlapping, but thankfully aligned practices.

James Kouzes describes Five Practices and Ten Commitments of Leadership –

  1. Model the Way
     a. Find your voice by clarifying your personal values
     b. Set an example by aligning actions with shared values
  2. Inspire a Shared Vision
     a. Envision the future by imagining exciting and ennobling possibilities
     b. Enlist others in a common vision by appealing to shared aspirations
  3. Challenge the Process
     a. Search for opportunities by seeking innovative ways to change, grow and improve
     b. Experiment and take risks by constantly generating small wins and learning from mistakes
  4. Enable Others to Act
     a. Foster collaboration by promoting cooperative goals and building trust
     b. Strengthen others by sharing power and discretion
  5. Encourage the Heart
     a. Recognize contributions by showing appreciation for excellence
     b. Celebrate the values and victories by creating a spirit of community

This list is very similar to Pinto’s effective Leadership Behaviours, but adds some useful “how to” guidance.

The importance of Modelling the Way
From Posner’s “Model the Way” practice and Pinto’s “Modeling the desired behaviour” recommendation it is clear that this is an important role. As leaders of agile teams it is natural to try and exhibit the behaviours that we wish team members to emulate. However, agile methods tend to underplay this critical role.

“Emotion precedes thought and action” which means that we will not effectively follow people that we do not trust. So if a team member sees evidence of duplicity, perhaps a project manager padding estimates for the business to create a refactoring buffer, then this mistrust will be transferred to other communications from the project manager. Trust, integrity, humility, and a desire for the true picture, even if grim, are attributes that must be instilled in leaders to build effective teams.

The need to re-communicate the vision
While it is important to create a common vision, the need to constantly re-communicate this vision and check for comprehension throughout the project is paramount. People get caught up in details, tangents and changes can disturb the project's “compass”. Stakeholders and team members may change and people just sometimes forget the true goals of an endeavour.

Vision should be reiterated frequently, preferably using new analogies and metaphors. Sports analogies are often over used and poorly understood and therefore should be used with caution. Having created a compelling vision during a kick-off meeting, work with the team to generate Elevator Pitches, Overviews for the Steering Committee, and Quick Starts for new stakeholders. By engaging the team this way, leaders can get a true measure of team understanding and generate a variety of valuable new ways of describing the project.

Recently a development team at a product development company generated the following elevator pitch to describe their view of the project. “To create a flexible reporting engine that links both Sales and Production data, the “AceReports Project” is replacing the existing static reports with a new user defined report system, that allows custom reports to pull data from across the company.” While not the snappiest of pitches, it is reassuring as a leader to confirm the team has a similar view of the goals as the project manager.

Celebrating Success
Morale and enthusiasm fuel team commitment and work rates and need to be renewed by recognition, thanks and understanding. Teams that are continually pushed for results without recognition will burn-out, lose members and drop in productivity.

Before looking at new processes or tools to improve productivity, we should not forget people. People are the most influential factor in the people/process/tools triad of productivity factors. As Posner suggests, by the regular celebration of values and victories we can renew the commitment and enthusiasm of the team. Agile project managers should schedule and budget for celebrations at regular intervals throughout the project. An afternoon out, or $100 gift certificate is cost effective preventative medicine, compared to the possible costs of overtime and recruiting expenses associated with a tired, sick team. So in a moment when you have finished reading this post, go and say “Thank You” to the team member who deserves it, but you have not had the opportunity to thank yet. It could be the most effective use of your time today!

Conclusion
Agile project management diverges from the task scheduling focussed guidelines of traditional project management. However, it is closely aligned with Leadership best practice that already has a people focus. So, when looking for a common thread to promote agile methods, or a source of guidance for agile project management, move past the traditional project management books onto the Leadership guides where there is a fertile source of complementary information.