Now that my Beyond Agile book has been published, I would like to thank people who helped shape its content and ideas. David Anderson has done much to popularize and explain lean and the Theory of Constraints thinking.

The Kanban Method can teach agile practitioners many useful ideas about incremental improvement, successful organizational change, and improved team performance. So, rather than considering it an alternative to agile approaches, I like to think of it as a compliment, another source for ideas, tools, and solutions.

We have a tendency to get attached to our personal favorite agile approach, whether that is Scrum, XP, or something else, and regard alternative approaches as somehow inferior or derivative. However, the Kanban Method has some useful additions, so let us see what it has to offer.

First, many people are confused between kanban and the Kanban Method, so it is worth some clarification. The Japanese word kanban (usually with a lowercase k) means “signal,” “sign,” or “large visual board.” Agile teams often use kanban boards to visualize their work. These kanban boards typically show queues and work in progress (WIP). They may also show WIP limits for activities and expedite paths for urgent work.

The Kanban Method (usually capitalized) is a complete process for defining, managing, and improving the execution of knowledge work. David Anderson developed it in 2007 and, like agile, has its own set of values, principles, and practices. More than just using kanban boards to track and manage your work, it is a full lifecycle approach for running and improving knowledge-work projects.

David and I worked together in the early 2000s on the Agile Project Leadership Network (APLN) board. He appreciated the concepts of agile and combined them with concepts from Theory of Constraints and lean design to develop a method focused on the flow of work that could be applied to any knowledge-work scenario. Unlike agile approaches that suggest a complete switch to agile work execution, Kanban starts with the process you have right now and provides tools to improve its service.

This makes the Kanban Method much easier to adopt, as no big upheaval, retooling or enterprise-wide training is required. Instead, the Kanban Method principles are applied to the way things are currently done.

Kanban Principles

• Change management
• Start with what you do now.
• Agree to pursue improvement through evolutionary change.
• Encourage acts of leadership at every level.
• Service delivery
• Understand and focus on your customers’ needs and expectations.
• Manage the work; let people self-organize around it.
• Evolve policies to improve customer and business outcomes.

Based on these principles, three parallel and ongoing agendas (themes of work) are employed:

Kanban Agenda

• Service orientation: Look outward and focus on performance and customer satisfaction. Ask How can we meet and exceed customer goals?
• Sustainability: Look inward to find a sustainable pace and improve focus. Make intangible work visible and then balance demand with capability.
• Survivability: Look forward to remain competitive and adaptive to more change. Scan for the emergence of disruptors and value diversity to better handle change.

Throughout all the approaches, a core set of values based on respect and collaboration is embraced. These are:

Kanban Values

• Transparency: Sharing information through straightforward terms improves the flow of work.
• Balance: The understanding that competing elements must be balanced for effectiveness.
• Collaboration: People must work together to be effective.
• Customer focus. We must know the goal for the system.
• Flow: The realization that work is a flow of value.
• Leadership: The ability to inspire others through example, description, and reflection.
• Understanding: Kanban is an improvement model that starts with self-knowledge.
• Agreement: The dynamic co-commitment to move together toward goals, respecting, and where possible, accommodating differences of opinion.
• Respect: Valuing, understanding, and showing consideration for people. A foundational value underpinning everything else.

We can use the Kanban Method to help introduce positive change into a team or organization. The “start with what you do now” and “agree to pursue improvement through evolutionary change” concepts are nonthreatening and difficult to argue against. So, if faced with an organization or department that is reluctant to change its ways, the Kanban Method is an excellent approach.

It also brings some great insights often missed in agile approaches. For example, since knowledge work is invisible, managers may not know how much work someone has on their plate. Encouraging people to make their work visible helps them show and explain their workloads to others. It also enables coworkers to see what people are working on and then pitch in where they can…”

Thanks, David, for your popularization of and explanations of Theory of Constraints thinking. They are more relevant today than ever as people in organizations everywhere look to transform their work.

Last month I did a 20-minute overview of my new Beyond Agile book for the Washington D.C. Lean-Agile MeetUp group hosted by Sanjiv Augustine.

I outline how Beyond Agile grew from studying high-performing teams and trying to distill what they did differently than most other teams. In the video, I cover Agile Myopia, Buffet Syndrome and the need to drop agile processes when they no longer bring enough value to warrant their use.

I would like to thank Sanjiv and the entire team at LitheSpeed for hosting me and allowing me to share this video with you here.

Anyone interested in my Beyond Agile book can get a paperback or electronic version here.

I am excited to announce my new book “Beyond Agile: Achieving success with situational knowledge and skills“ is launching. It is available now from RMC in paperback or electronic form here. This post explains the name and motivation for the book. Future posts will profile the content.

 

Background

Since helping create DSDM in 1994, I have been working on agile projects for 27 years. In that time, I have personally been a member of around 30 teams, coached and consulted with about 400 organizations and taught agile to over 2,000 team leads and project managers worldwide. Statistically, most were around average, a few were really dysfunctional, and less than 10 were exceptionally productive.

 

Problems

Around 8 years ago, I noticed many capable teams were adopting agile but still not being very productive. They had embraced the mindset and were doing all the right things, but success still eluded them. As someone who had dedicated their career to spreading the word about agile and helping organizations adopt it, this was extremely concerning for me. What were they doing wrong? What was I doing wrong?

 

Researching Successful Teams

So I went back to study the small number of exceptionally productive teams to look at what they did differently. While they understood agile remarkably well, they did not emphasize its use. Instead, they used a clever mix of agile, leadership, emotional intelligence and industry-specific knowledge to get the work that needed doing today done.

 

Patterns and Results Emerge

Patterns emerged, and I explored further. Using these techniques, I was able to help organizations turn around struggling projects and programs. As a result, we outperformed expectations, delighted stakeholders and won a PMI Project of the Year award. One organization documented our approach and submitted it for tax credits in the Canadian research and development SR&D program. It was successful, and they received several millions of dollars in tax credits. The Beyond Agile Model was developed, and this book documents the components.

 

The Obvious, Non-Obvious Need to Remove Process

The Beyond Agile Model has agile at its core; it also layers in additional ideas while encouraging teams to discontinue practices that no longer add sufficient value. Since there are only so many hours in the day, focussing more effort on delivery requires dropping other activities - even if they are agile. It was obvious once I saw it. The most productive teams I studied spent more time delivering and less time on agile ceremonies and other tasks. The non-obvious part was learning what to drop since it varies from team to team, and the book explains the process.

 

In future posts, I will explain some of the core ideas. Until then, I just wanted to let you know the book is finally done and available here.

Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

Now that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

I am excited to be a keynote speaker at the Gatineau-Ottawa Agile Tour (GOAT) conference on November 30^th. Along with Mary Poppendieck, we will be leading a day dedicated to learning about agile culture and collaboration.

The Gatineau Ottawa Agile Tour is an annual conference in the heart of the nation’s capital, focused on sharing and learning. GOAT has run for 7 years and is part of the Agile Tour that takes place in 90 cities worldwide.

Click to see the Keynotes Overview and the Sessions Previews.

I hope to see you there.

I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. I have worked with several organizations this year that had issues with work dependencies between teams. My session called “Two-Pizza Team Heartburn Relief: Solutions to Team Dependencies” highlights the shift to global rather than local optimization.

We will investigate dependency problems through animations and simulations and then explore some candidate solutions. Each brings their own issues – if these problems were solvable they would have been already, but the suggestions do help considerably. Here is the description from the conference program:

Small teams are great - until they cause bigger problems than they solve. Small teams can communicate more effectively than large teams. They can leverage face-to-face communications more readily and share tacit knowledge without the need for so much written communication. However, for large endeavours, using many small teams present their own problems. Work dependencies between teams can cause major delays through costly hand-offs, mismatched priorities, and blocked tasks.

This workshop introduces strategies for structuring teams to reduce hand-offs and dependencies that create blocked work and delays. By investigating the (lack of) flow through multiple teams we can diagnose the cost of hand-offs and culprits of delays. We examine tools for making hand-offs and dependencies visible to highlight and bring collective attention to the problems. We then explore resolution patterns and work structures that maximize small team communications but limit negative aspects of managing multiple, inter-dependent project teams.

Learning Objectives

• Understand the time and cost penalties of team dependencies and hand-offs
• Gain tools for making dependencies, queues, and blocked work visible
• Learn how and when to balance small team benefits with more dependency issues
• Share implementation patterns and strategies to maximize team throughput
• Examine the pros and cons of larger teams, feature teams, and product vs. project development.

That probably sounds more technical than it really is. It is a workshop to show people how teams often get stuck with work items when they rely on work from other groups. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

Through case studies and exercises, we explore the hidden impacts of well-intentioned small teams. First, we’ll explore the “mostly harmless” two and three team dependencies, and then see the impacts when five or six dependant teams try to get work done. Please come along if you are attending the conference and have issues with dependencies between teams.

I am excited to be presenting at next week’s PMI-SAC Professional Development Conference on May 2 in Calgary. I am looking forward to seeing old friends and meeting new people at this new format conference.

My session “Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?” examines the hype, realities and use of agile approaches.  Here is the presentation summary from the conference site:

“The project world seems to have gone agile mad. The PMI has stuffed agile into everything in an attempt to stay current, but is it right or even helpful? Fear of missing out has vendors claiming to be agile and executives asking managers to be more agile. However, like InstantPots and cryptocurrencies, does the reality live up to the hype?  This session investigates the agile trend and looks at a new breed of agile suitability filters that help organizations apply agile approaches only when and where they make sense.

The presentation profiles organizations that effectively use agile approaches and how to build PMOs that support agile, hybrid, and traditional project teams. We look at the limitations and applicability concerns of using agile approaches. It would be naïve and arrogant to believe that agile (or any other approach) is universally the best way to execute projects. So, what types of projects do suit the approach (spoiler alert: novel, knowledge-worker projects) and what types of projects should best avoid it?

We will explore hybrid approaches where certain portions or periods of the project can exploit agile approaches. In these hybrid scenarios, we examine how to coordinate and integrate the agile work with the more traditional, plan-driven work. Also, we will examine the cultural fit of agile approaches and investigate how corporate mindsets and values effect structures and decision making. Trying to force fit a new mindset that is at odds with the corporate culture will inevitably be met with resistance. So, we need to be smart about what we try to introduce and how we plan to do it.

Our end goal should be successful projects and happy stakeholders. The approach we take should be appropriate for the tasks at hand, there are no points for style or conformance, since every project is different. So, learn how to analyze the project variables that include organizational, standards, technical and team components then act intelligently within that framework also guided by the inputs of the contributors.”

That description was for a 2-hour slot proposal and I was assigned a 1-hour slot so I will have to cut some material, but I will cover the highlights. The presentation title and outline are deliberately a little controversial to hopefully spur some reaction and interest in the session.

Having been involved in the development of the recent PMI standards, I personally do not believe “PMI has stuffed agile into everything in an attempt to stay current”, however, I can see how this may appear so to external parties.

As agile rides the hype cycle it is important to retain a grasp on where it can add value and where it’s use should be limited. This session aims to strip away some of the hyperbole and ground people with some practical application tools. Please come say hello if you see me at the conference!

“Software is eating the world” claimed venture capitalist, Marc Andreessen in his 2011, New York Times article. Seven years on, the trend continues, and project managers are also on the menu. The next generation of project managers face new challenges but also new opportunities as organizations undergo a major transformation.

Software is becoming omnipresent, it is embedded and integral to all industries. Not just technology companies (like Google, Apple) but every sector is being disrupted by software including retail (Amazon), banking (PayPal, cryptocurrencies), transportation (Tesla, Uber), and travel (Airbnb).

As a project manager you may say “Great, just think of all those IT projects that will need project managers!” Well, that’s where things get interesting. First, today’s software teams don’t respond well to being “managed”, that’s old-school command-and-control thinking along with Gantt charts and calling people “resources”. Instead, they are led, empowered and supported by servant leaders. Next, the idea of a “project” with a defined endpoint is dissolving too.

As organizations realize their software systems provide the competitive advantage then stopping development equates to an end to innovation or competing. When organizations become more software-driven their systems are never “done”. As a result, organizations are switching from projects (that have a fixed end) to products - that continue to evolve. This movement popularized by the #NoProjects and Continuous Digital titles is growing exponentially.

 

 The Project Manager in a No Projects, No Managers Future

This double whammy of no more projects and no more managers likely creates heartburn for people with the job title “Project Manager”.  While this trend is clearly the future of work, I believe there will always be a role for smart, cooperative people that can help with collaboration and development. 

 A quote that comes to mind is “The more things change, the more they stay the same.” by Jean-Baptiste Alphonse Karr. The next generation of project managers will have new titles like “Product Leads”, “Development Team Coordinators” and “Digital Transformation Leaders”. They will help organizations build development capabilities around long-term products.

 This new generation will still communicate with stakeholders about status and risks. They will still facilitate consensus gathering amongst experts. They will still try to diffuse conflict and find common ground during arguments. The goals (satisfied stakeholders and value delivery) will remain the same but the tools, titles and processes employed will be vastly different.

 

New Tools and Approaches

Heavy upfront planning efforts and the use of tools like critical path network diagrams and PERT charts are not so useful when the input data is very uncertain. Tools like work breakdown structures offer great insights into sub-system assemblies but they are slower and more difficult to reprioritize than modern backlogs and release roadmaps.

As rates of change increase so too does early lifecycle uncertainty and the competitive need to start work quickly. The days of carefully analyzing work products upfront are dwindling. Instead, organizations build prototypes based on what they know right now and then iterate towards the final product. In the intangible world of software, the cost of experimentation is less than that of detailed analysis.

Also, using a software product provides better feedback on its suitability and possible expansion than reviewing a document or diagram about it. IWKIWISI (I Will Know It When I See It) becomes the new mantra, replacing the “Plan the work, and work the plan” ideas of old.

As organizations adopt a continuous delivery model that is focussed on products not projects then funding models change also. Instead of yearly budget cycles to fund entire projects, smaller tranches of funds are released to create a Minimum Viable Product (MVP). Then, providing the product continues to return value, more funding is made available. A venture capital funding model lets product leaders focus on delivering a stream of high-value features that support continued investment.

Projects classically track metrics like on time/budget and Return On Investment (ROI). Products track customer satisfaction, market share, profit to funding ratios. They are similar concepts but a new vocabulary to learn.

 

Role Changes

Agile software development teams organize their own work, solve most of their own problems, and are empowered to experiment with new work strategies and approaches. They do not need (or want) to have work assigned to them, nor asked to report status. Instead, they make their work visible via kanban boards and new features.

They do however need people to remove impediments and chase up external dependencies. They also need investment in training, shielding from interruptions, plus regular encouragement and words of thanks to stay motivated. In short, all the servant leadership practices that good project managers did anyway still apply.

Project managers cannot be the center of work planning or task distribution. There is too much complexity to be anything but a bottleneck. Instead, we must trust development team members and product owners from the business as subject matter experts in their own domains.

Where these teams often need help is keeping the larger perspective on where it is we are trying to get to. When you are heads-down on solving a technical issue, it is easy to lose sight of the end goal. Having someone communicate the product vision reveals a beckoning summit towards which others can chart their own course.

In this way servant leadership and visionary leadership that predate modern project management are still valuable and needed. Yet the scientific project management that grew out of the industrialization of process is largely left behind.

 

The Future

In many industries, the classic role of projects and project managers will continue. I don’t see construction moving away from big upfront design and the reliance on project managers any time. In the software world though I think we are heading for substantial changes. Sure, some companies will continue as they always have with software project and project managers. However, most organizations will transition to long-term products with leaders and coordinators.

It is an exciting time for life-long learners willing to acquire new tools and approaches. There is no shortage of work for people who can collaborate with others and solve problems. The critical role of software will increase as organizations undertake digital transformation and adopt continuous digital strategies based on products vs projects. So, while the role “project manager” might be heading into the same category as “switchboard operators”, “human alarm clocks”, and “bowling alley pinsetters” the work and opportunities in this exciting field continue to grow.

[I first wrote this article for ProjectManagement.com here]

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.

 

 

Lean Thinking, described and popularized in the book “Lean Thinking” by James Womack and Daniel Jones, is summarized as: “focusing on delivering the most value from a customer perspective, while reducing waste and fully utilizing the skills and knowledge of those doing the work”. These are all relevant goals for today’s Project Management Office (PMO) and the reason that increasingly organizations are using Lean Thinking to boost value and reduce waste in the PMO. 

Lean Thinking embodies a wide range of principles and techniques. I like to think of it as a philosophy plus a toolbox of techniques. For this article, we will focus on applying some basic principles for delivering value and identifying wastes to avoid within the PMO.

It’s about people first.

Unlike some other project management approaches, lean is human-centered not process-centered. Two overarching themes prevail over all the practices: 

• Involve everyone – Always make sure everyone involved, impacted and perceived to be impacted is consulted and engaged in the process. This does not mean every font change of a Project Charter template needs CFO approval, but it does mean that all plans, initiatives and work are open and available for contribution or comment to anyone who is interested. Basically, be open and transparent, you never know who might have a great insight or spot a flaw before it impacts performance.

• The Customer Defines Value – Rather than automatically acting to minimize costs or reduce time to market, lean specifically adds the step of asking the customer to define what value means to them. Some groups may focus more on quality at the expense of time or costs, others may value time-to-market and happily sacrifice some scope or cost over runs to get there. It sounds like common-sense, but all too often people get disappointed with a group because of mismatched values. Adding the “customer defines value” step helps avoid those mismatches before the can occur. 

Lean Thinking Principles and the PMO

Lean Thinking suggests five principles as starting points for a continuous cycle of delivery and improvement. Let’s review them one-by-one and see how a PMO can embody the concepts they represent: 

• Specify what creates value from the customer – This principle takes the “Customer Defines Value” theme we just talked about and bakes it right into the first step of the process. PMO’s understand they serve multiple customers, typically including their sponsoring group who pays to put PMO’s in place. 

Value for the PMO sponsoring group likely includes helping projects be successful, ensuring good practices are followed, providing objective evaluation of performance and risk signs, providing help/training where required, etc. Another group of customers is the project teams and team leads / managers. These customers typically want low overheads for PMO compliance and timely responses to requests for support, training, etc. Both of these groups (and any others that apply) must be canvassed to determine what value means to them. 

• Identify all steps - value adding and non-value adding across the whole value stream that bring a product or service to the customer – This is the process of analyzing how things actually operate to get work done. Some activities are necessary value-adding tasks, such as performing a review, while others will be non-value adding activities, like waiting for feedback. 

Lean thinking provides tools such as Value-Stream-Mapping to analyze processes and categorize value-adding and non-value-adding tasks. It also allows us to calculate metrics like cycle time and process efficiency. Using these tools to look at the current-state and future-states of PMO processes, groups can analyze and optimize how to best deliver value. 

• Establish flow – The continuous movement of products, services and information from end to end through the process. Moving large batches of anything, whether its requirements in a specification document or artifact templates to a standards library creates consumption and improvement problems. 

It is better to move smaller batches more frequently. That way there is not a large delay while things are consumed and processed, also if defects or areas for improvement are found in an early batch the information can be sent back to the producing group and the issue addressed in later versions. Establishing flow improves efficiency, quality and the ability to manage changes. PMO’s can support this by encouraging the small batch flow of user stories and retrospectives vs specification documents and project lessons learned reports. 

• Implement Pull – The idea that nothing is done by the upstream process until the downstream, customer signals the need. Stock piling products or service offerings ready for consumption or in-hope that they are consumed is wasteful. It consumes time and energy with in-progress work that has not yet delivered value and often people will want something slightly different. 

A preferable approach is to spend this effort on getting good at rapidly delivering what is asked for. Then establishing signaling mechanisms so that the need (or imminent need) for a product or service triggers its creation. With a stock pile of zero the next item you get is perfectly made for you rather than the next available.  PMO’s can embrace this principle by providing just in time reviews rather than standard readiness assessments. They can also create, say, charter templates based on project characteristics not boilerplate, also Steering Committee updates based on current questions not standard templates. 

• Work to perfection – The goal is the complete elimination of waste so that all activities create value for the customer by continuous improvement. While perfection may be unreachable, the goal of this principle is to instill the idea that improvement is an ongoing process that does not stop. People should always be looking (and encouraged) to improve the delivery of value.

PMO’s can embrace and model this continuous improvement principle by highlighting their ongoing work in a “What’s New” section of their intranet site. They can help projects and teams by attending project reviews and retrospectives to endorse these activities, provide support and distribute the outcomes to a wider audience. Anything that promotes and encourages the continual pursuit of improvement. 

 

Eliminating DOWNTIME - The Common Forms of Waste

Lean thinking identifies 8 common sources of waste in an organization. Groups, including PMOs should be on the lookout for these forms of waste and avoid or reduce them wherever possible. This is not a one-off activity like a yearly Spring-clean of processes. Instead, it is an ongoing vigilance like work-site safety or maintaining a respectful workplace. People are encouraged to always be looking for forms of waste and then eliminating them if possible. 

Lean thinking has its roots in lean manufacturing and so several of the common forms of waste have titles that are associated with physical production, such as Over Production, Inventory and Transportation. However, versions of these wastes also occur in knowledge worker projects that are more commonly associated with manipulating ideas and information rather than physical goods. Listed below are the 8 common sources of waste and a description of how they apply to knowledge work projects along with advice on how PMOs can help reduce them. The forms of waste can be remembered by the relevant mnemonic DOWNTIME that stands for: 

1. Defects
2. Overproduction
3. Waiting
4. Non-Utilized Talent
5. Transportation
6. Inventory Excess
7. Motion waste
8. Extra processing  

Let’s look at each in a knowledge worker setting and see what PMO’s can do to help. 

1. Defects – Flaws in deliverables that create work to correct information. PMOs help project teams get things right the first time to avoid making defects. They can also help by providing extra tools and support when defects are found. Since Waste = Impact-of-defect X Time-defect-lies-undetected the timely resolution of defects is in everyone’s best interest. 

PMOs can also help address excessive defects by providing standards and quality control guidance and training.

 

2. Overproduction – Extra features or extra process that do not add sufficient value. We should always be asking “where is the next best dollar spent?” in other words, what should we do next to best add value.

PMO’s should reinforce this view by reminding people to ask: “Where is the next best dollar spent?” and avoid producing features or processes that are unlikely to be widely used or never completed. Likewise building things that are cool (resume architecture) or “might be needed” are forms of overproduction also.

 

3. Waiting – Delays for approvals, waiting for projects to start or resources to become available are all forms of waste. They cause people to task-switch which is inefficient and a contributor to defects. 

PMO’s should see if they can reduce waiting by scheduling a better alignment of project authorizations and start-up activities. Also, rather than waiting for team to form, consider bringing new projects to existing high-performing teams. Waiting delays strain learning loops as things get forgotten and it is better to seek out feedback early and apply it as soon as possible. 

4. Non-Utilized Talent – the waste caused by underutilizing people’s skills, talent and knowledge. Assigning staff to the wrong sort of tasks for their skills and experience results in a lack of engagement. PMOs should work closely with teams to determine not only what experience and skills people have, but also what they would like to try. Then working with projects leads to find a way to give people exposure to these new roles. 

Timeboxed iterations provide a great risk-limited approach for trying new roles and building new skills. If the new roles work out then great do some more, if it does not work out then we learned something and should now try something else. 

5. Transportation – In knowledge work projects unnecessary handoffs are like transportation waste. They create delays and slow down value delivery. Handoffs also always result in the loss of tacit knowledge. Like the Telephone game, when a message such as “Jon picked an apple from a tree” becomes “Joan licked Adam by the sea” after a few handoffs; details become lost in translation. 

PMOs can reduce transportation waste by eliminating unnecessary handoffs and ensuring information is gathered at source, not relayed through different groups. 

6. Inventory excess – This is partially done work that represents effort invested with no return yet. Generally, we should try to minimize work in progress (WIP) since managing that status of work and keeping it up to date gets in the way of doing other work. 

PMO’s can help by encouraging and supporting the transition from large batch flow (a single large specification document for a project) and a large analysis and design deliverables to small batch flow, for example just the requirements for the next two-week iteration. 

7. Motion waste – this unnecessary movement in the knowledge worker world often presents itself as task-switching. It occurs whenever we ask someone to stop what they are doing and work on something else. Team members working on multiple projects must task switch frequently. Each time they have to finish and mentally park what they are working on, move to the other project and reorient and then restart the activities they were doing there. Studies show a significant reduction in productivity and a dramatic increase in defect rates. 

PMO’s can eliminate task switching motion waste by first demonstrating the desired behavior within the PMO. Instead of having a dozen initiatives on the go at once with people splitting their time between them, prioritize and execute them sequentially. Having firsthand experience of increased productivity the group can more credibly help spread the word to project teams and into the portfolio and program planning activities that spawn so many simultaneous projects in the first place. 

8. Extra-Processing – This waste on knowledge work projects often takes the form of relearning. Poor knowledge capture leads to people having to go through the same pains and rediscovery rather than asking people who know. Other instances stem from poor instructions, and reassigning people too frequently. Finally, extra-processing can also take the form of overengineering a solution or demanding too high of a quality for the use of the product at hand. 

PMO’s can help by looking at the common questions they get asked or the common omissions they see on projects and then providing information and materials to address those shortcomings in future. Using the “Where is the next best dollar spent?” question can also help diagnose where overengineering and too high quality investments are being made. When you consider all the things we need to fix and where we are trying to get to, should we really be spending more time on X or working on some other initiative? These techniques and questions can help PMOs avoid Extra-processing wastes.

  

Take Aways

Lean thinking focusses on serving customers by adding value and eliminating waste, which is well aligned with PMO goals also. PMO’s can learn lots from applying lean thinking principles to not only increase the value of the projects they support, but also increase the value of the group itself.

 

I am testing demand for another Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in attending a 3-day Calgary based PMI-ACP Exam preparation course. 

 

Evolution of the PMI-ACP Credential

I ran a couple of Calgary based PMI-ACP courses three years ago when the exam first came out. Since then the certification has grown in popularity from niche to mainstream with over 10,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

In October 2015 the PMI rolled out the updated version of the PMI-ACP exam, based on feedback from hundreds of existing credential holders and agile practitioners. The new Exam Content Outline has been restructured with the addition of a new domain “Agile Principles and Mindset” to focus on thinking and acting in an agile way as opposed to simply implementing agile processes and hoping for improved results.

 

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile methods such as Scrum and XP. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to restructure it to the new Exam Content Outline. The book is currently available for 30% off from RMC here and is also included in the course.

 

Details about the Course

The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking. It includes the second edition of my book, colour printed workbook, sample exam questions, and USB stick of additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.

Psst, this is your conscious, I am here to remind you about something you have thought about, but then hid away in the back of your mind. Lots of this agile stuff is hypocritical, it preaches evolution and change, but then we ask the same old three questions at standup every day. Also, why must we have standup every day, isn’t that kind of prescriptive? Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. With a free rein to morph product and process there is a strong likelihood that by six months into a project the practices followed by the team would have deviated from the proven and tested methods of most successful teams. The risk of failure would increase and every project in a company would be using a radically different approach making integration, scaling and team member transfers a major problem.

The other reason is a little more sinister. Most of the creators, proponents and promotors of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over.

I am not suggesting we should be changing agile methods willy-nilly, I think a basic suggestion to try them out-of-the-box for a couple of years is sound advice. However, beyond that I believe there are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that and what other people can learn from it.

Next week, on February 18^th, I will be presenting on “Solving Today’s Complex Projects with Agility” at the Society for the Economic Promotion of Gran Canaria (SPEGC), co sponsored by ITProiectus. I have been working with ITProiectus for a while but this will be my first time to meet them and I am really looking forward to it.

The presentation will explain how today’s complex problems can be solved by collaborative teams that  better handle ambiguity than traditional plan-driven approaches. I will review some of today’s wicked project management challenges and show how agile methods, while they look deceptively simple, actually harness sophisticated approaches for generating consensus and driving towards high quality solutions. 

On May 5^th I will be presenting at the PMI-NAC Conference on the following topics:

1. 21^st Century Risk Management: Supporting mathematical analysis with social influence
2. PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches

I am looking forward to the event and will share thoughts and feedback on the sessions here afterwards. Until then here are the presentation outlines:

Presentation 1: ”21^st Century Risk Management: Supporting mathematical analysis with social influence”

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence.

While the project manager is key to project co-ordination and success, they are rarely the domain experts and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management and the importance of social influence on risk management. Using case studies, a team approach to risk management to collaborative workshops, new risk visualization techniques, and examples of team risk avoidance and risk mitigation actions are examined.

Presentation 2: ”PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches”

Agile, lean and kanban approaches are a part of the new project delivery toolkit, especially for projects with IT components. The PMBOK Guide v5 published in January 2013 now describes a lifecycle spectrum spanning “Predictive, Iterative & Incremental and Adaptive” approaches. The new “Software Extension to the PMBOK Guide” expands this model with further agile related guidance for project execution.  Gartner Research claims 80% of today’s software projects employ agile methods. So, is your PMO living in denial, or simply living in the past?

Fortunately, a new class of PMO has evolved to support a dynamic mix of traditional, agile and lean project approaches that we can learn from. Using case studies from award winning PMOs, this presentation examines how proactive organizations are tracking diverse project types with common metrics and enablers.

I have had a busy autumn and it has been too long since I posted here. I did some consulting in Europe and attended the PMI Global Congress in New Orleans to present on “21^st Century Risk Management” with Dennis Stevens.

More recently our local PMI Chapter won the “Chapter of the Year” award and held their excellent Professional Development Conference that I gave a couple of presentations at. The first on “PMO Evolution: Frameworks for Integrating Lean, Agile and Traditional Projects” and one on “Surviving Agile Projects” aimed at traditional project managers transitioning to manage their first agile project.

The consulting and conference interactions led to a number of ideas for application on agile projects that I will be sharing here in upcoming posts. At our local PMI conference in Calgary last week Bob Lutz, Retired Vice Chairman of General Motors Corporation gave a great talk on design and project management.

He was discussing the importance of defined, repeatable process for efficient, high quality production. Strict compliance and rigorous process controls certainly help improve the manufacturing process. What was interesting was his cautions about applying defined, repeatable processes to design work. He said it flat out does not work and can lead to terrible products.

Bob recounted how upon rejoining General Motors in 2001 he asked “Who the hell designed the Pontiac Aztek?” (which appears on many Top 10 worst car design lists and is generally slammed from a design perspective – although liked by some loyal owners.) The Pontiac engineers were very defensive claiming that in fact the design of the Aztek was one of the best executed vehicle design projects that had run, hitting each of its targets and assessment milestones during the process. Lutz went on to say while some processes need rigour, design processes need collaboration, feedback and frequent verification to ensure we are on the right track.

As we execute our projects I think there is great value in determining if we are designing something or manufacturing something. The creation of software solutions is like car design, we are trying to understand the problem space and create candidate prototypes for evaluation and evolution towards the best available solution. This requires collaboration, feedback and frequent verification.

Other projects like upgrading servers and training 500 people are more defined, repeatable activities that can benefit from well defined process and strict controls. Most projects I have worked on have elements of both work types mixed together. An important skill for project managers is to know when to employ strict process and when to encourage less structured collaboration where designs evolve based on build-feedback cycles.

I really enjoyed Bob’s talk; he is an engaging speaker who tells things as he sees them and I look forward to reading his latest book “Icons and Idiots”. Over the coming weeks and months I intend to post here more frequently and continue the dialog on the smart application of process and pragmatism.

It may not always be apparent but the goals of the Project Management Office (PMO) and agile teams are well aligned. Both groups want to get to the same destination: namely successful projects and happy stakeholders. However, things often come adrift as soon as the best direction to travel in to get there is discussed. The PMO might expect lots of planning and some documentation to confirm everyone understands the approach. An agile project team might want to build some proof-of-concept models to test feasibility and get confirmation of understanding. So, very quickly the two groups can disengage and have difficulty generating alignment again.

This is one reason agile teams don’t always see the Project Management Office (PMO) as a source of assistance. All too often a traditional PMO can Present Multiple Obstacles, but it does not have to be that way.

First let’s examine what PMO’s are supposed to do. The old roles of: “Rules”, “Tools” & “Schools” goes some way to describing their functions, but a more complete set of offerings was provided in the 2010 PMI Project Management Journal article “Identifying Forces Driving PMO Changes”. These are:

1. Monitor and control project performance
2. Develop and implement standard methodologies, processes, and tools
3. Develop the competency of project personnel, with training and mentoring
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5. Strategic management, including participation in strategic planning and benefits management
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7. Management of customer interfaces
8. Recruit, select, and evaluate project managers
9. Execute specialized tasks for project managers (e.g. preparation of schedulers)

  For organizations using agile methods, these services can be delivered as follows:

1. Monitor and control project performance – Help teams track their velocity. Assist with tracking team and sponsor satisfaction ratings. Look out for and alert teams of dangerous velocity trends, check backlog size, and offer reviews of iteration and release plans.

2. Develop and implement standards – Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.

3. Develop personnel with training and mentoring – Provide agile training courses, coaches, and mentors to help project mangers transition to agile projects and upgrade their skills. Send people to local agile events.

4. Multiproject management – Coordinate between agile teams, communicate between projects including items such as outlining progress, issues and retrospective findings. Help manage Release Trains at the program level and Investment Themes at the portfolio level using frameworks like the Scaled Agile Framework (SAFe).

5. Strategic management – Identify projects with opportunities for early ROI or competitive advantage.

6. Facilitate organizational learning – Gather project velocity profiles, capture, store and index retrospective findings. Include perceived PMO cost vs. value in project metrics.

7. Manage Stakeholders – Provide Product Owner training, guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of Subject Matter Experts (SMEs) to projects.

8. Recruit, select, and evaluate project managers – Develop guidelines for interviewing agile project managers.

9. Execute specialized tasks for project managers – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.

Understanding the role of a PMO and translating the goals into an agile setting helps create alignment rather than conflict between the groups. These items may sound a tall order for your average old-school PMO. However PMO’s are under pressure to remain current and demonstrate their value in a climate of fast moving projects, cost cutting and increased scrutiny.

In the September 2009 PMI Community Post magazine Jack Duggal published an article called “Teaching PMOs to DANCE” that dealt with the issue that many of today’s projects are moving quicker than PMO’s can respond. Many PMO’s struggle assisting projects that DANCE:

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

The agile community calls projects like these “a good fit for agile” and this is the synergy. When we can explain agile approaches are not just non-conformist, ill-planned projects, but instead a proven approach for these tricky new project types then a win-win is possible for both camps.

Jack Duggal also gave a presentation at the 2011 PMI Global Congress entitled “Reinventing the PMO” which was quite agile manifesto like. Jack outlined a need for PMO’s to shift:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough. PMOs need to cultivate a mindset to shift to a benefits and outcomes focus and establish measures to ensure benefits realization and achievement of business value.

2. From Delivery to Adoption and Usability
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted. With a shift to an adoption and usability mindset, PMOs can promote and plan for adoption throughout the project lifecycle to ensure intended realization of projects’ benefits and value.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Change management in the PMO realm has focused on configuration management and procedural changes. Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation. PMOs can play a key role in understanding, leveraging and leading change.

The “Next Generation PMO” as Duggal names it will have a mindset viewing the organization as a complex adaptive system. The PMO’s purpose becomes more focused on linking tactical & strategic help with business value. Success will be measured via benefits realization and business value rather than project delivery. All of which are very much aligned with agile concepts.

So, rather than PMO’s being unsupportive of agile, I have found most to be very co-operative when alignment with agile helps them address challenging projects, deliver value and stay current. Also as project managers experienced in agile take roles in the PMO I think this transition will accelerate. With some education and buy-in a good PMO can Provide Many Opportunities for agile teams.

(This article first appeared at projectManagement.com here)

My next PMI-ACP Exam Preparation course will be November 18, 19, 20 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book).

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To reserve your place or ask questions please contact [email protected].

Some rifts are occurring in AgileLand - a world supposedly driven by cooperation, trust and appreciative inquiry! Debate is arising about first generation agile methods (XP, Scrum) and newer upstarts like Kanban and the Scaled Agile Framework (SAFe). Perhaps because market shifts carry training and consulting revenue with them, but a few people don’t seem very happy, as evidenced by some recent blog posts.

Ken Schwaber’s UnSAFe at Any Speed article describe SAFe as a RUP based dinosaur focussing on processes and tools rather than individuals and Interactions. Ian Mitchel summarises the Scrum vs SAFe debate well in his piece Method Wars and speaks to his own SAFe experiences.

David Anderson wrote a post on how Kanban is Anti SAFe in the way the two methods approach adaptation for an organization. He describes SAFe as a collection of (somewhat outdated) software development best practices that you engage an expert or team of experts to tailor for your organization. Kanban on the other hand is based on the idea that knowledge workers know more about their domain than their supervisors or outside experts do and should therefore be the people selecting and tailoring the approach.  So, instead of using experts to select and tailor process, the team does this work as part of the innovation culture fostered by Kanban.

Alan Shalloway describes Why Net Objectives Supports SAFe; they are a SAFe Silver partner organization, and believe it offers a proven, documented approach to scaling agility that is underpinned by sound lean and agile principles.

When I read these different accounts I find myself agreeing up to a point with each perspective. I don’t go quite as far in my beliefs as each author, but if I was talking to the authors I’d probably just nod and bite my tongue for the small portion I feel they are pushing too far. So does that make me a hypocrite, or an easily persuaded novice?

Feeling a little uncomfortable, but not caring enough to worry about it too much since I’d rather be solving business problems rather than debating religious wars that rarely deliver much value, I found an explanation from an unlikely source. A friend had sent me a link to a DiSC Leadership profile tool, it asks a series of questions about your preferences in a leadership role and generates a nice report on your Leadership style.

My assessment indicated a “D” Dominance preference for Getting Results, Taking Action and Offering Challenge.

 The tool lists some good tendencies of having a strong drive to:

• Achieve results
• Overcome  obstacles
• Get things moving
• Work towards challenging goals
• Convincing others

The assessment also pointed out some potential negative traits including:

• Problems following strict rules and protocols
• Performing routine tasks
• Getting bogged down in inefficient procedure or meetings
• Things that slow down your pace
• Dealing with people who don’t meet your standards

Generally I am not a big fan of personality profiles, perhaps I hope to be not as stereotyped or easy to categorize as they suggest. I like to think people are unique and multifaceted, but this DiSC Leadership assessment summarized my tendencies very well and helped me understand why I feel the way I do about agile, Kanban, SAFe and even the PMBOK Guide.

Basically I am more results driven and will employ and adapt whatever tools and processes I think will help me achieve those results. As I have said before, if abandoning agile principles and instead wearing silly hats got my projects done better, I would be all for it. Instead however building motivated, empowered teams and championing smart behaviour from all stakeholders through servant leadership and savvy project management is the best I have so far.

So, when I look at the SAFe framework I don’t see too many problems, but instead tend to employ the elements I think suitable to solve my current project’s issues. Due to my “Problems following strict rules and protocols” I probably would not engage SAFe consultants to guide its implementation, but instead discuss the framework with the team and gain consensus for elements to incrementally trial. Being told “That’s not how we do it” or “The PMO has a different standard” tend to fall into my blind spot of “Getting bogged down in inefficient procedure or meetings”, “Things that slow down your pace”, and “Dealing with people who don’t meet your standards” etc.

I do see that these are weaknesses I should work on, but I am hired to get results and deliver value. When this occurs without breaking too many rules or upsetting too many people I call it a good day. I see bending rules and flexible interpretations of process as an enabler of value delivery. For example, in the recent upgrade from the PMBOK v4 Guide to the PMBOK v5 Guide some new “Subsidiary Management Plans” were introduced, but I see this as a boost for adaptability not more control or rigor to follow.

The new PMBOK v5 Guide processes:

• 5.1 Plan Scope Management
• 6.1 Plan Schedule Management
• 7.1 Plan Cost Management
• 13.2 Plan Stakeholder Management

These could be interpreted as more Draconian control of how we manage scope, schedule, etc. However I see them as my opportunity to tailor the process and define a more lightweight, adaptive approach.

Since the goal of “5.1 Plan Scope Management” is to “… describe how the project scope will be defined, developed, monitored, controlled, and verified” here is my opportunity to explain that we will be using  a vision statement and prioritized feature list instead of a WBS to better support reprioritization and accommodate changes.

Likewise, the new process “6.1 Plan Schedule Management” is a great place to explain the use of release plans, iteration plans and story maps. In my half-full world, these new processes are there to help us be more agile or whatever we need to be (perhaps more structured for your project) in order to be successful - they support tailoring and specialization.

So, where does this all leave us? Well, I found a way to justify my methodology indifference and explain my disregard for rules or process. Maybe your DiSC profile can help explain your feelings towards these recent methodology debates. Likely if you are more of a DiSC "CS" style you would have a different view and very strong opinions about their importance.  Please let me know what you think.

I have a client who uses lean and agile-like processes outside of IT on research and development projects. They have been doing this for a number of years to help optimize constrained tools (drilling platforms) and resources (specialist inspectors). They like the agile concepts of prioritizing based on business value, working in short cycles, expediting rush jobs and frequently validating results and adaptation.

Recently they asked for help with some improvement initiatives that use multi-disciplinary teams to investigate and improve cross-department processes. These groups are staffed by senior engineers who volunteer to help make improvements, but the work is low priority and their time extremely limited. They are also geographically dispersed. Obviously that creates problems for agile practices like daily standups if team members get on average of two to four hours per week to contribute on an initiative.

At first I saw lots of challenges--agile promotes dedicated teams (co-location where possible), daily conversations with business stakeholders, etc. These groups had none of those things, yet three months later they were pleased with the successes they had. It seems when you are trying to coordinate the work effort of distributed, low-availability resources, the structure and visibility of tasks that agile brings is a great strength.

This somewhat counter-intuitive application makes more sense when you consider how such improvement committees traditionally function. Historically, similar work groups had faltered and failed to deliver benefits. The company was mature enough to look for inter-departmental improvement opportunities, but because it was no one’s full-time job (and they spanned departmental jurisdictions), work started but then failed.

My PMI-ACP Exam Preparation course will be April 15, 16, 17 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book). To reserve your place or questions please contact [email protected].

Continue reading to see further details from the Course Outline

The Project Zone Congress will be taking place in Frankfurt, March 18-19. I attended the Project Zone Congress last year and was impressed by the quality of sessions and access to speakers for Q & A. This year’s conference is set to repeat the format and has some great speakers including Jurgen Appelo author of “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. I love this title and wish I’d come up with it myself!

Readers of LeadingAnswers can receive a 10% discount from the conference by using the code “PZ2012_MEDIA03B869C8” when they register. It promises to be a high caliber conference with sessions on practical agile, the PMO and agile, strategy and leadership, see the schedule for full details.

I picked up a copy of my PMI-ACP^SM Exam Prep book on a visit to RMC Project Management over the weekend. It was good to see it printed up for the first time, and with all the exercises and 120 sample exam questions, it was thicker than I expected at over 350 full-size pages.

The extra weight also comes from the case studies of agile projects I have worked on over the years and the additional materials I included to link the exam topics together. These items that are not in the exam are clearly marked so you can skip over them if you want. However, I am sure some people will find they add value by making the ideas more real. These additional materials also supply useful information to allow readers to fully understand the topics, rather than just memorize the information for the exam.

I am very grateful to the staff at RMC for pulling together my thoughts and ideas into this book, and for the people who reviewed it. Alistair Cockburn and Dennis Stevens were particularly helpful, and after reviewing it, they wrote the following quotes for the cover:

“As one of the authors of the Agile Manifesto, I am delighted to see this book by Mike Griffiths. It is great that such an exam guide was prepared by someone with a deep understanding of both project management and Agile development. Personally, I hope that everyone reads this book, not just to pass the PMI-ACP exam, but to learn Agile development safely and effectively!”

– Dr. Alistair Cockburn, Manifesto for Agile Software Development Co-Author, International Consortium for Agile Co-Founder, and Current Member of the PMI-ACP Steering Committee.

“This is a VERY enjoyable book to read, due to Mike's firm grasp of the underlying concepts of Agile, and his articulate and entertaining writing style. My favorite part is the fact that it is organized into a framework that helps all of the Agile concepts hang together, so they will be easier to recall when taking the PMI-ACP exam.

But Mike's book is more than just the best PMI-ACP prep book out there. It is also the best consolidated source of Agile knowledge, tools, and techniques available today. Even if you are not planning on sitting for the PMI-ACP exam in the near future you need to buy this book, read it, and keep it as a reference for how to responsibly be Agile!”

– Dennis Stevens, PMI-ACP Steering Committee Member, PMI Agile Community of Practice Council Leader, and Partner at Leading Agile.

Thanks to you both, working with you over the years has been a blast. I would also like to thank the visitors of my blog here, too, for reading my posts and submitting insightful comments that kept me motivated to write. RMC has provided me a limited time promotion code that gives readers a further $10 off their currently discounted price for the book. If you follow this link and enter promo code “XTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.

Forbes ran a nice article a couple of weeks ago on how agile is the next big thing for management, but its unlikely origin in the software industry may hamper its adoption. The article provided some nice analogies:

1)    When the British government, in 1714, offered a prize for determining longitude at sea, of £20,000 (£3M in today’s money), a Yorkshire carpenter called John Harrison eventually solved it, but the scientific community refused to believe that a carpenter could have solved the problem that had thwarted the best scientific minds. In 1773, when John was 80 years old, he received an award of £8,750 but not the actual prize. A Yorkshire carpenter was the wrong person to have solved the problem.

2)    In 1865, Gregor Mendel, an unknown professor created a theory about gene inheritance after studying pea plants. It answered inheritance issues that had stumped the finest scientific minds. The paper was ignored by the scientific community for the next 35 years until people eventually realized that Mendel had indeed come up with the solution. His theory later became known as Mendel’s Laws of Inheritance. His work had been ignored; a researcher on peas was the wrong person to have created the theory.

3)    In 1981, Barry Marshall, a pathologist in Perth, Australia, came up with a bizarre new theory that ulcers were caused by spiral bacteria. No one believed him so in 1984 he drank a batch of spiral bacteria and sure enough developed ulcers. Eventually in 2005 he received a Nobel prize for medicine for his work, but it took that long to be accepted. An unknown pathologist from Perth was the wrong person to have made the discovery.

So then we come to agile; for decades management had struggled to balance execution with innovation. How do we simultaneously get work done yet still drive improvements without one factor stifling the other? Now we know agile methods do a great job of balancing delivery with improvement.

Agile methods also provide a framework for sense-making and managing ambiguity when there are significant gaps in our understanding of requirements, approach, or technology. These uncertainties have a habit of stalling plan-driven approaches that struggle to reach escape velocity from the process of gathering requirements and planning. Agile methods instead choose to build what we know, evaluate, gain consensus on where to go next and iterate to a final solution.

The credibility problem we have is that software people, those weird IT geeks with poor communication skills are the wrong people to have proceduralized a complex communication and collaboration process. It should have been some management professors at the Harvard Business Review or Sloan School of Management at MIT. How can that IT crowd, who some believe have trouble making eye contact and describing an issue without resorting to techy speak, have figured out a way to collaborate and communicate on unique problems with unprecedented solutions?

I have been away attending the excellent “Agile on The Beach” conference recently, but when I returned I had an email waiting requesting some PMI-ACP study help on Value Stream Mapping. So here is quick outline of the topic.

Value Stream Mapping – is a lean manufacturing technique that has been adopted by agile methods. It is used to analyze the flow of information (or materials) required to complete a process and to determine elements of waste that may be removed to improve the efficiency of the process. Value stream mapping usually involves creating visual maps of the process (value stream maps) and progresses through these stages:
1)    Identify the product or service that you are analyzing
2)    Create a value stream map of the currant process identifying steps, queues, delays and information flows
3)    Review the map to find delays, waste and constraints
4)    Create a new value stream map of the future state optimized to remove/reduce delays, waste and constraints
5)    Develop a roadmap to create the future state
6)    Plan to revisit the process in the future to continually tune and optimize

To illustrate lets optimize the value stream for buying a cake to celebrate passing your PMI-ACP exam with a friend. Let’s say this involves choosing a cake, waiting at the bakery counter to get the cake, paying for the cake at the checkout, then unpacking and slicing before enjoying the benefit of the process (the cake).

I created the following fun periodic table of agile adoption to explain some of the ranges of adoption, adaptation and blending that we see in the workplace.

 

The Model
On the left to right (X axis) we see varying ranges of agile purity to pragmatism. On the left we have the agile zealots and fundamentalists for whom everything must be done exactly by the book or it is just not agile and therefore wrong. On the right hand side we have the pragmatists who are happy to take what works for them and forget the rest.

On the vertical (Y axis) we have the degree to which people blend other techniques and practices into their work. Low on the scale people use a simple implementation of the theory they have adopted. High on the scale we see a complex blend of multiple practices; perhaps agile, with the Theory of Constraints (ToC), Complex Adaptive Systems (CAS), or their own in-house standards.

The next occurrence of my Agile Project Management class will be in New Orleans on February 28 and March 1st (Feb 18 Update: and is now full ). After that there is:

Savannah, GA - April 11, 12
Dallas, TX  - October 26, 27
Anaheim, CA - November 7,8

I enjoy delivering these courses and people enjoy attending them too, here are some feedback comments:

"Mike delivers an exceptionally well reasoned and effective presentation of agile. Thoroughly appreciated" - Bill Palace, El Sugund, CA
“The best PMI class I have ever taken.” - Scott Hall, Marriot International
"This was a very well executed course. Instructor (Mike Griffiths) was very engaging!" – Ameila White, Boeing
"The instructor was very knowledgeable, class well organized, content at the right level of detail and very comprehensive. One of the best classes I have taken regarding PM topics" – James Bernard, Scottsdale
"Excellent course with great information" – Tom Gehret, JNJ Vision Care
"Excellent facilitator. Mike is respectful and knowledgeable" - Nghiem Pauline, San Diego, CA
"The course was fantastic " - Kimberly Kehoe, San Diego, CA
"Mike is an excellent instructor and I really appreciated his organized and clear, well researched presentation. His domain and project management experience is evident from his talk. Also I appreciate his exposure/experience to multiple approaches like PRINCE2, PMBOK, Scrum, DSDM etc." - Sarah Harris, OpenText
"Great content and delivery" – Andrea Williams, Fed Ex
"Great Stuff!, Really enjoyed instructor and real-world examples" - Don Brusasco, Northridge, CA
"The instructor did an excellent job of keeping the pace, - clearly explaining topics and providing practical applications" - Cathy MacKinnon, Schering Plough Corp
"Excellent!" – Peter Colquohoun, Australian Defence

All of these classes sold out last year so if you want to attend I suggest you book early; I hope to see you in New Orleans!

Decision making is both analytical and emotional. We need to make decisions to move forward beyond the forks in the road, but when exactly is the best time to make them? Agilists have the automatic response of “At the last responsible moment” drummed into their heads so often that you may think they are drones rather than free thinking individuals.

Delayed
Agile and Lean gurus have explained the benefits of delaying decisions until the last responsible moment for many years. It prevents us from committing to potentially harmful decisions too soon and instead enables us to gather more information and then make a better decision when we actually need to. It keeps design options open, enhances agility, and allows agile teams to be more responsive to change than teams who have locked into a defined approach early.

Dated
Real Options adds some math to the picture. It supports the same general idea of decision delaying and providing some dates and values for our decision making calendar. This could be reassuring for people left feeling a little uneasy by all the “up in the air” decisions. Now, it is not that we are just putting them off, but instead have agreed that there is an optimal time to make each decision and when that arrives we will make them.

Done
I recently read the excellent “Rework” book by Jason Fried and David Heinemeier Hansson of 37 Signals and it was refreshing to read about their thoughts on Decision Making. They say: “Decisions are progress. Don’t wait for the perfect solution. Decide and move forward. You want to get into the rhythm of making choices. When you get in that flow of making decision after decision, you build momentum and boost morale. You can’t build on top of “We’ll decide later”, but you can build on top of “Done”.

Plus, you don’t have to live with a decision forever. If you make a mistake, you can correct it later. It doesn’t matter how much you plan, you will still get some stuff wrong anyway. Don’t make things worse by overanalyzing and delaying before you even get going. Long projects zap morale. Make the call, make progress, and get something out now – while you’ve got the motivation and momentum to do so.”

I like this a lot. We can often get caught up in the analysis of the perfect moment to make a decision and forget the very real motivational impact of not deciding. Decisions are emotional and our emotions impact our productivity. Yes it might be marginally better to decide on that reporting tool at the end of the month, but if everyone is non-committal until then or only 90% focussed, perhaps not sure on what will happen, then what is the real cost of this Real Option?

People’s ability to deal with ambiguity varies from person to person. However many people find it disconcerting to work with little bits of their commitment parked at each of these delayed decisions. It is foolish to try and schedule being happy on Thursday at 2pm, likewise it is foolish to assume delaying decisions comes without motivational penalties.

Like most things, we can’t live by a single mantra such a “Delay decisions to the last responsible moment”, instead we need to balance the analytical benefits of delaying decisions against the emotional costs and remember that, as Rework goes on to say: “Momentum fuels motivation. The way you build momentum is by getting something done then moving on to the next thing.” Rework keeps it real, and for that is a great read.

“…we need to balance the analytical benefits of delaying decisions against the emotional costs …”

This article summarizes my “Lessons Learned in Project Metrics: Are your Metrics Dumb or Smart?” presentation. It covers the following six topics

 

2010 is shaping up to be a good year for training courses and events. I have the following public enrolment courses available through the PMI.


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

 
My private courses are available year round, see here for a list and course outlines, and I am also hoping to head back to Alaska this summer to teach a class for the PMI Alaska Chapter there again.

As normal I’m keeping the bulk of the summer free to take full advantage of the short, but fantastic hiking and mountain biking season we get here around Calgary. I was hoping to attend the Agile 2010 Conference in Nashville, but the dates August 9-13 clash with the TransRockies Mountain Bike Race August 8-14 that comes right through my backyard of Kananaskis and is too good to pass up.

Instead of the Nashville agile conference, I hope to attend another agile conference in the fall, perhaps the Agile Business Conference in England again, or a Scrum Gathering event. Then of course there is the PMI Global Congress conference in Washington, DC in October. With the PMI Agile Community of Practice now the largest PMI community with >1700 members there will be a large Agile contingent attending and many great agile sessions to go to. Once again so many events and so little time!

My last post was on modifying Parking Lot Diagrams to use the area of boxes to show the relative effort of differing parts of the system. The idea was that while traditional Parking Lot diagrams are a great way of summarizing progress at a project level, the customary approach of giving all the feature groups the same size box may lead people to believe these chunks of functionality are of equivalent size or complexity.

In the boxes below, the number in brackets describes the feature count, but this requires people to read the numbers and then consider the relative sizes. My goal was to create a new graphical summary that depicts the relative sizes via box area to make the summaries easier to understand.

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

In the second example we can quickly see the relative estimated sizes of the areas of work, with for example, “Enter Order Details” being three times the size (in area) of “Create New Order”. In this example to keep things simple, I am using feature count (15 vs 5) to depict effort and area. Most projects will use development effort in points or person days as the scaling factor.

Anyway, I have been using these scaled Parking Lot diagrams on my projects for a while, created quite laboriously in Excel and PowerPoint, and I was hoping that someone with better skills than I have could help me streamline the process. Well, in typical fashion, soon after posting I learned that:

A)    I may be asking the wrong question
B)    My invented solution has already been done before and far more elegantly
C)    It has been done on the Simpsons

Oh, the joy of the internet! Actually this is of course a great thing and now I can progress from a much firmer foundation, and far quicker than my slow evolution was taking me...

This past week I have had an opportunity to experience some hospital process control and contrast it with traditional project process controls. In doing so, I saw many instances of where today’s projects that exhibit uncertainty could be better managed via prioritization and collaborative decision making than preset plans.

How did we get to Traditional Project Management?
Project management is a fairly young discipline, yet because its repeatable process scales so well, and is easy to duplicate and automate; it rapidly became the dominant process for running projects. Frederick Taylor published his studies on “Scientific Management” in 1911 outlining the process of decomposing complex work into simpler and simpler steps until localized labour could be employed to perform each simple task. Embraced by Henry Ford and others, Scientific Management became the prevailing way of problem solving for entire industries.

It was not until the 1950’s when Peter Drucker and then later Michael Porter convinced the world that centralization and command-and-control structures were flawed. Respect for workers and a holistic value based view of systems can produce better results and more sustainable organizations. Yet traditional project management persisted.

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.

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.

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.

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

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.

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?

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.