BA's on Agile Projects?

Team EffectivenessThe role of the business Analyst (BA) on agile projects in some ways parallels the role of the project manager (PM). In that, some people believe these roles are not needed at all! The Scrum Guide, for instance, that outlines the Scrum approach describes only three roles: Scrum Master, Product Owner, and Development Team. Even when you look deeper into the Scrum Guide’s description for The Development Team role, it does not mention analysts or analysis work. However, most organizations agree, good BAs are great assets for any team, be it plan-driven, agile or hybrid.

This article examines what BAs really do, looking at what stays the same on an agile project and what changes. The quick version is that the What and the Why fundamentals stay the same, but all the How, When, Where and With Whom details change dramatically.

Let’s start with What business analysts are supposed to do. (I say supposed to do rather than actually do because yours might watch cat videos most of their time and that is not what they are supposed to do!) Anyway, Business Analysts elicit, analyze, communicate, manage and validate requirements. They also help understand the business and make sure the solutions fit the business. In addition, they help translate technical issues to the business and facilitate stakeholder communications.

Why they do these things should be fairly obvious. To help ensure the project builds the right product, and requirements are not missed or misunderstood. They are also valuable to help facilitate and bridge communications between client, customer and technical groups.

The good news is that all these functions, roles, needs or whatever you want to call them still exist on agile projects. Also, to some extent, because agile timelines are often compressed, these functions become more critical for teams to remain productive and so good BAs are extra valuable.

Now for what changes; let’s start with the How? Agile teams typically do not create large, detailed requirements documents that get reviewed and signed-off before development begins in earnest. Instead, requirements may be captured as user-stories, or on index cards that act as reminders to go and have a conversation with the relevant subject matter expert prior to development. They are typically smaller in terms of how much scope they cover and depth of description. More like micro-requirements for attention deficit readers who only want small, bite-sized components.

 

Continue reading "BA's on Agile Projects?" »


New Role with RMC Learning Solutions

RMCLS LogoI have taken on an exciting new part-time role with RMC Learning Solutions as their Agile Practice Lead. I worked with RMC to create my PMI-ACP Exam Prep book and their ACP training offerings. So, I am really looking forward to working with them further. Previously, as a one-person company with a full-time contract job, I had more ideas for books, web sites and articles than I ever had time to develop. Working with RMC who have dedicated production staff, web developers and editors, I hope to get a lot more content available for a larger audience.

For the last 16 years, I have been pursuing my agile writing in my “free” time. I moved to Canmore a few years ago, and love the location, but the commute to Calgary further ate into that time. Working 50% of the time for RMC from home will free up more time for writing and occasional training and consulting. My challenge will be to stay focused and not use all the extra time for biking, running and skiing.

For RMC, my year kicks off with an introduction to agile webinar called “Agile DNA”, sign-up here. Then an e-learning course and a new book I have been working on will be announced with more to follow. Stay tuned for updates and more articles; heck I might even upgrade my LeadingAnswers.com website to be responsive and searchable – or go fat biking.


Agile DNA Webinar

Agile_dna_webinarI am excited to announce a free webinar with RMC Learning Solutions entitled “Agile DNA: The People and Process Elements of Successful Agile Projects” that will be taking place on January 11th 2017 at 12:00pm Central Time.

This is an introductory level presentation about agile approaches that qualifies participants for 1 PDU. The “Agile DNA” title comes from the twin strands of People and Process that are woven into agile approaches and uniquely define what they are. Please join me for this review of agile through the twin lens of People and Process to get a deeper understanding of the building blocks of agile.

Register now for this event here.


The True Cost of Free Exam Prep. Questions

Free QuestionsMost people taking a project management certification exam use sample tests. Whether it is a PMP exam, ScrumMaster, CAPM, PMI-ACP, PgMP or many others, there are plenty of online options for getting familiar with the format and determining if you are ready to sit the exam proper.

Unfortunately, like all things found online, the quality and relevance varies considerably. If we are just looking for funny cat videos, the occasional shaky video filmed in portrait mode is annoying--but easily skipped and not the end of the world. However, bad exam simulators can give a false sense of security--or a false sense of insecurity--and generally do not prepare you at all for what the actual exam will really be like.

Before getting trained and involved in question writing for PMI and professional training companies, I had no idea about the science behind good multiple choice questions. Now, I cannot help but notice poorly written questions. Even if the test is free, if it tests material not in the exam, it can generate unnecessary anxiety for people studying--and so is bad value. More frequently, people get used to poorly written questions (because these exams are free, they consume a lot of them), and then find the real exam very different--and fail.

So how do you ensure you are taking good, quality sample exams? The simplest and most effective way is to only trust questions from a reputable training company. They have writers that have been trained in how to create questions that meet ISO/IEC 17204 requirements. This is the standard that PMI and many other reputable certification bodies use, such as doctors and teachers.

Ask yourself how much your study time is worth, what are you giving up to get this certification? Given the sacrifices made so far to study, investing in an exam simulation from a reputable source makes good economic sense. However, I understand not everyone can afford or justify paid content, so let’s at least understand how to assess questions to make a judgment call on if the exam simulation is useful or a dud.

Multiple Choice Questions: A Primer
First, a primer on exam question design. This is useful information for everyone taking a test. Understanding how questions are designed helps you answer them more successfully. We will also uncover why you might be good at acing free online tests, but then trip up on the real deal. It all comes down to your online question writers often not knowing this theory.

Multiple choice questions (MCQ) are deceptively simple, so people underestimate them. It seems pretty easy--there is one right answer and three wrong answers. As a test taker, you just pick the right one; as a test creator, you just write the questions and think up a few wrong answers to catch out the guessers.

Let’s start by examining the anatomy of a question and learn the lingo. First of all, questions--along with their correct answer and incorrect options--are called “items”:

 

Continue reading "The True Cost of Free Exam Prep. Questions" »


Agile Risk Management

Risk Action in BacklogThis article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches. 

Agile is Not a Risk Management Approach

Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process. It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are certainly present, but unfortunately just building something iteratively or incrementally does not ensure risks are managed. 

It is all too easy to develop iteratively missing opportunities to actively address threats or exploit opportunities. Many agile teams also fail to actively look for risks, discuss and decide on appropriate actions, undertake those actions and reassess the risks and evaluate if the risk management process is even working. 

It is a shame because in many ways agile methods provide an ideal framework for introducing effective risk management practices. They have short timeframes, active reprioritization of work, frequent review points, high team member and business engagement in planning, etc. However, similar to having a group of people to help you find something, a beach-party is not the same as a search-party. We need a conscious effort, coordination and cooperation to make it effective.

 

Consciously Adding Risk Management to Agile Approaches

The good news is, that when organizations and their participating teams decide to layer risk management onto agile approaches there are many self-reinforcing cycles and mechanisms to make use of. For instance, the frequent consideration of change requests and reprioritization of work in the backlog makes the insertion risk avoidance or risk mitigation tasks an easier process to handle. 

Likewise, the regular retrospectives that review progress and process are great points to examine the effectiveness of risk management strategies and take corrective actions. Daily standup meetings that surface issues and blockers can also act as early warnings for potential new risks, etc. 

For anyone interested in linking agile approaches to risk management steps, here’s a White Paper on Collaborative Games for Risk Management that was presented at the 2012 Agile conference and PMI Global Congress. These ideas and their development more into Opportunity Management were explored at this 2015 Agile Conference Session. However, the mechanics of doing the work and linking it into an agile lifecycle are the easy parts, getting people to take a risk-based view to project work is where the real work is needed.

 

Thinking about Risk Management

Education and acceptance are the keys to successfully adding risk management to agile practices. We need to get people engaged in the process and instill a common understanding of threats as the possibility of negative value. Once people understand this they can answer the question “Where is the next best dollar spent?” more effectively. It might not be on building the next feature from the backlog, but instead avoiding a risk or exploiting an opportunity. 

Continue reading "Agile Risk Management" »


When Outsourcing Makes Sense

When to Outsource GridDisclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.

To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?

Coding vs Collaboration Costs

The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.

Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?

Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve

So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.

Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?

The Compounding Costs of Delay

An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.

Continue reading "When Outsourcing Makes Sense" »


PMI-ACP Exam Prep with Mike Griffiths – Mind Map

Mind Map SmallFor anyone studying for their PMI-ACP exam, I have created a mind-map of the PMI’s Exam Content Outline and my book contents. So here it is, on a single (large) page all the topics within the exam and the second edition of my book.

Mind-maps show relationships between topics and provide hierarchy and structure. It could be used as a study check list – print a copy and cross off topics you are comfortable with leaving the topics to study. Or an everything-on-one-page view of the content in the exam – like a packing list for a trip, you can refer back to it and reassure yourself you “have” everything.

Anyway, if you find it useful you are free to use it for you own personal study. I hope it is helpful in an: “OK, I have got this” kind of way and not scary as in an: “Oh no, look at all the stuff in the exam!” kind of way.

I think it is interesting to understand why laying things out spatially helps with comprehension and recall from memory. It allows us to tap into our spatial awareness and engages the right hemisphere of the brain and that makes us less likely to forget them. (Assigning things we want to remember to a location is a memory aid that many memory-improvement techniques use. Probably using skills developed back in our hunter-gatherer days when our survival relied upon remembering where to find food and water, we have better recall of things assigned a physical location.) This is the reason today’s military still use visual tokens to represented enemy forces, despite having access to the world’s most sophisticated tools. The impacts of forgetting about them can be fatal; fortunately, exams are less critical, but we can still benefit from tapping into our spatial recall circuits.

Use the link below for the high resolution version.

Download PMI-ACP Book Mind Map


The Diagnosis and Treatment of Bimodal IT

Bimodal IT TreatmentIs it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution.

In my last post I reviewed some of the issues I see with Bimodal IT; these include promoting a segregation of techniques when companies really need integration and recommending sequential lifecycles for complex projects. While it is easy to poke holes in ideas, it is more useful and rewarding to fix and improve things. So, let’s help organizations using Bimodal IT improve.

First, we should acknowledge the elegance of its simple design and understand why organizations are drawn to it. The simplicity of an If-This-Then “A”, If-Not-Then “B” approach is appealing and it allows companies to try agile-like approaches without making a full commitment. There is a refreshing clarity and simplicity in a simple two-way model. However, true to its namesake personality disorder, organizations using Bimodal IT exhibit large swings in the execution approach that are not natural or optimal.

Diagnosis: Tyranny of the OR vs. the Genius of the AND

In the book “Good to Great” Jim Collins popularized the idea of the “Tyranny of the OR vs. the Genius of the AND” to explain the problems of being forced to choose from alternatives and the potential in choosing a better third alternative – even if it takes more effort.

The “Tyranny of the OR” part describes having to choose from two seemingly contradictory strategies – either Mode 1 which is traditional and sequential OR Mode 2 which is exploratory and nonlinear. The “Genius of the AND” part refers to instead embracing both ends of the continuum and simultaneously making the best decision for the unique circumstance at hand. Most organizations are ruled by the tyranny of the “OR”, whereas Great organizations find a third way to satisfy both and leverage the Genius of the “AND”.

Jim Collins linked the ability to leverage “AND” thinking to high performing companies, but this third alternative or “Middle Way” has been around for a long time. I wrote about it in 2008 here, and my favorite quote relating to it is: “The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” - F. Scott Fitzgerald.

Treatment: Mix Models, Engage the teams and Innovate

An example of applying the AND mentality to Bimodal IT would be to execute a couple of Mode 1 and Mode 2 projects and then get the teams together for an improvement workshop. We could ask them about their experiences and suggestions for cross-pollination of the best techniques. Maybe Mode 1 projects could benefit from a monthly Show-and-tell review of project outputs and planned work for the next period with the wider project community? Maybe Mode 2 projects would benefit from the development of RACI charts before distributing work between team members and part-time supporting roles?

I am not suggesting these are universal enhancements Mode 1 and Mode 2 projects, they are just examples of things that might be suggested. The real power of the process comes from getting people thinking about how to improve the process and caring about the outputs. Giving people input into how we undertake work and the ability to improve it moves them from un-invested-followers of a process to engaged-workers with some autonomy and say in how things get done. Guess which group enjoys their work more? Guess which group tries harder to overcome problems and deliver results?

I am in favor of using established and proven development approaches, they leverage good practice and help prevent common pitfalls. However, since organizations vary in function, organization and culture it is naïve to assume different companies should use the same one (or two) processes to execute their projects. The impacts of failure in air traffic control are quite different from pop-culture web sites and they should use different development approaches.

As Alistair Cockburn and Jim Highsmith have been saying for decades, we really need a methodology per project. Or as the Declaration Of Interdependance (DOI) say an approach that is "Situationally Specific". If this all sounds too hard or complicated it need not be. There are lots of free frameworks available to engage their team members in continuous improvement of their methodology. Doing so also increases ownership, support and engagement.

The continuous improvement model used could be one already in place at the organization or one that best fits with the mindset or culture. It could be PDCA, Six Sigma or Kaizen, they all share six common principles.

Summary

Gartner did a great job creating a framework that is appealing and accessible to organizations slow to adopt adaptive lifecycles. If they were to now follow it up with some guidelines for tailoring and evolution within organizations adopting it they would have a winning strategy for engaging participants and driving better results.


Agile Coach Camp

Agile Coach Camp CanadaI attended this event last year and enjoyed it...

We would like to invite Agile Practitioners to Agile Coach Camp Canada - West, an Open Space Conference to be held in Vancouver, BC on the weekend of June 17-19, 2016.

Agile Coach Camp – An Unconference

The annual gathering at Agile Coach Camp creates opportunities for our Agile community to share our successes, our learning, our questions and our unresolved dilemmas – all in an energizing and supportive environment.

The Open Space Technology, Unconference format, encourages participants to join the conversation.

Each of us can make a contribution to the art and science of helping people and teams be their best as they deliver valuable software. Share your stories, observations, and inquiries. Discuss challenges you have overcome or those you are still wrestling with today. Describe opportunities you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others.

The fee to attend this unconference includes all food & drink for Friday evening, Saturday (breakfast, lunch & snacks) and Sunday morning. Early bird pricing currently in effect $95 CAD until May 10th.  Thereafter the regular event ticket will be $125 CAD.

For more information, or to register, visit the Agile Coach Camp Canada West website.



PMBOK v6 Work

Agile LifecycleAs you probably know the Exposure Draft of the PMBOK v6 Guide is making its way through review at the moment. I have been working with the PMI on some iterative, adaptive and agile content and look forward to when the non-disclosure agreements are lifted and I can tell you all about it. I think I can state, without saying too much, that people can expect to see a natural evolution of mainstreaming techniques that are now considered common practice.

Looking through my web site visitor statistics it is clear that one of the popular resources is my PMBOK v4 Guide to Agile mappings. These were created many years ago to support a training course I used to run for project managers operating in environments governed by PMBOK v4 Guide processes.

A couple of years ago I updated the "Agile Guidance for the PMBOK V5 Guide" but did not share it publicly because it is just as easy to misuse it as use it. It is NOT a how-to-do-agile in a PMBOK based company, a project executed only through the steps discussed in the guide would be a nasty Franken-process that is neither agile or plan based. Instead, it is a thinking tool and discussion guide only for people operating in environments with both plan-driven and agile type. With that prefix and warning, my agile discussion of the PMBOK v5 guide can be viewed and downloaded here: Download Agile and PMI PMBOK v5 Guide Alignment.


DSDM Video

DSDMI get the feeling that DSDM is considered by many people outside of the UK as the uncool, out-of-touch great-uncle of agile. While somewhat related to modern agile, it is kind of forgotten about or dismissed as outdated or not applicable. While some Not Invented Here (NIH) prejudice is natural, there is a cruel irony in DSDM first being criticized for being too large and bureaucratic to be truly agile because it includes architectural elements and program management guidance, then 20 years later SAFe, LeSS and DAD adding these elements for large enterprise suitability.

Anyway, I was impressed by a short video produced by the DSDM Consortium. Despite helping create DSDM 22 years ago I still sometimes struggle explaining its origins and role in the Agile Manifesto to people who are not familiar with it. I think the video is a great introduction and applaud the Consortium for creating it.


In Two Minds About Bimodal IT

Bimodal IT MindsGartner’s Bimodal IT approach has been gaining momentum for the last 18 months. It promotes the adoption of a twin track approach to methodology selection. In Gartner’s words “Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.”

On the one hand I applaud any approach that helps bring the benefits of iterative methods and increased collaboration to organizations, especially those that have previously resisted them. On the other hand, I have some reservations with a model that polarizes guidance, categorizing projects into either traditional/sequential or exploratory/agility, when projects exist on a spectrum and the best approach is likely a smart mix of techniques.

It’s a Continuum Not an “A” or “B” Decision

Bimodal IT distribution

If your project is simple, visual and being undertaken by a small, co-located team then an agile approach is likely a good fit. However, big, complex, embedded systems undertaken by large and distributed teams also benefit from an iterative approach to the early identification of risks, confirming true requirements and surfacing gaps in understanding.

Also, given the complexity of large systems, the chance of getting something complicated done right through a sequential process is very small. Likewise, we cannot expect a project manager to understand all the technology portions, project dependencies and estimation outliers. Engaging the team more through collaborative practices to better estimate, plan and identify risks produces much more robust plans. Then through the iterative approach of developing real, executable slices of the application, the validity of these estimates can be checked and refinements made to model the likely outcomes.

These benefits coupled with others around an increased sense of ownership and accountability by the team for having been involved more in the planning and ongoing steering of the project, I believe large complex projects need agile techniques more than small simple projects.

I am not saying large projects should be run purely with agile methods, they need additional layers of rigor and communication, but there are some great scaling frameworks like Disciplined Agile Delivery (DAD) that do this without losing the benefits of iterations, adaptation and empowered teams. However, Bimodal IT steers companies away from many of the tools ideally suited for large projects.

“Bargaining” is the Next Step after “Denial” and “Anger”

Bimodal IT Progression Stall

Change acceptance, like grief, goes through stages. The first stage is Denial, we refuse to believe this is real, is happening to us, or applies to us. Traumatic loss or change is often accompanied by a surreal, outside-observer feeling as we struggle to accept what has happened or is happening. At a level of significance down from trauma, denial is expressed as rejection. “Agile does not apply to me!” Next comes Anger “You can’t make me use agile! I have been managing projects with a sequential process for 30 years, and I will not change now.

The next stage after Denial and Anger is Bargaining, where people try to avoid or minimize the impact of a change by making some highly visible or not really substantive bargains. For example, “OK, I will use an iterative approach, how about I make my iterations 6 months long?” Here, the resistor is negotiating or bargaining terminology “I will use an iterative approach when…” for an excuse to continue operating pretty much as they were before.

This is where I feel Bimodal IT resides and in part it explains its gain in popularity. It appeals to organizational leaders who do not really understand or believe in the benefits of an agile approach, but are under pressure to keep up with the times, offer agile projects to their teams, appear responsive to their business community. By publicly adopting Bimodal IT, they can push the small, trivial projects through an agile methodology - appeasing critics while clinging to their more comfortable traditional, sequential model. Since most organizations have significantly more small projects than large ones it may even appear that half or more of the projects being undertaken are Mode 2, agile projects when this represents only a small proportion of the project work being undertaken.

Simplicity Sells

People seem to like simple rules, even if they represent a suboptimal solution. The Atkins diet was very popular because a rule like “No Carbs” is simple and people liked that. Ask a nutritionist though and they will do two things, first they will explain that while it has some truth to it, the real makeup of good nutrition is more complex and varies depending on a large number of factors. The second thing they will do is to start explaining the large number of factors and either confuse you, send you to sleep, or make you wish you never asked them in the first place.

The same is kind of true for the best approach for developing software. Simple rules like Mode 1 traditional and Mode 2 agile-ish are appealing since they are easy to follow. However, like any restrictive diet, they are at best an over simplification and at worst are potentially harmful.

As an example Gartner states their Mode 1 approach that is traditional and sequential emphasizes safety and accuracy, but I would feel much safer and confident in a system where the highest priority features were developed first and have been reviewed and tested in every iteration since, than an approach that had lots of careful planning and then testing performed towards the end of the project. Iterations drive use and uncover missed requirements and defects. You can plan in detail and analyze requirements with reviews and tools – I spent 10 years of my software career working on very formal military projects – but, I believe the best way to discover if software works is by working the software.

Gateway Drugs

For me there is just too much wrong with Bimodal IT to recommend its use. It polarizes project selection when we should be looking more at hybrid models for large projects. It promotes more of a bargaining adoption of iterative methods and empowered teams than a serious acceptance of where these approaches can help all project types. Finally, it propagates dangerous sequential process models for large and complex projects that really need iterations more than small, simple projects.

If it has a redeeming feature it is that it could lead to the introduction of some iterative based projects, that then open the door to more agile projects, in organizations that had up until then resisted agile methods. I think Gartner should not end with the Bimodal framework, but use it as a foot-in-the-door primer for the Next Steps of continued evolution. So, while it currently has some use as a gateway or stepping stone to deeper thinking about project approaches, it should not be considered a destination for IS policy as it stands today.


20 PMI-ACP v2 Sample Questions

Pmi-acp_fastrack_2e_cdFollowing the update to the PMI-ACP Exam with the addition of the new “Agile Principles and Mindeset” domain I updated my PMI-ACP Exam Prep book and have now just finished the new questions for FASTrack Exam simulator. Feedback from people taking the exam indicated more difficult and more scenario based questions were wanted.

Well, you asked and we listened. The new FASTrack exam features over 500 PMI-ACP questions with answers and explanations to get you ready for passing your PMI-ACP exam as quickly as possible. The FASTrack exam simulator complements the book and provides references to which page in the book to read if you need more information about a topic.

As an early release bonus you can receive 30% discount off my book and the FASTrack exam simulator.

 

To give you a taste here are 20 sample questions:

 

Continue reading "20 PMI-ACP v2 Sample Questions" »


Back to the Future Slides

Back to the FutureHere are my slides from the recent PMI-SAC Professional Development Conference: Download Managing the Unknown with Marty McFly .The theme for the conference was Back to The Future and my presentation explained how projects throughout history have managed uncertainty and how we do it today. I also introduced a half-serious idea that the PMI accidently removed most of the theory on managing uncertainty in their attempt to simplify and serialize project management so they could document it in the PMBOK Guide and create multiple choice questions based on it.

It was great to catch up with old friends at the conference and receive such positive feedback about my presentation. It was a bit of a departure for me, delving into history, but an enjoyable one and I learned lots researching it.


Agile Benefits Management

Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the first place. Often the benefits of a project are not fully realized until after the project is finished. This is why benefits management is usually the domain of program management. Sitting a level higher than individual projects and operating over longer timelines, programs are better positioned to identify, track and transition benefits from individual projects or groups of related projects.

Agile approaches place strong emphasis on delivering business value. Work is prioritized with the highest business value items done early and definitions of “done” that focus on acceptance rather than completion of work help ensure benefits are truly delivered. This aligns them well for benefits tracking and management, but there is more to understand to truly integrate agile projects with effective benefits management.

First let’s take a peek at the established world of benefits management. The PMI’s Standard for Program Management has three program phases: 

 

  1.   . Program Definition
  2.     Program Benefits Delivery
  3.     Program Closure

 

 These are shown below along with a breakout of Benefits Delivery steps:

Agile Benefits Management

It is interesting to note that sub-steps 2 and 3, “Benefits Analysis and Planning” and “Benefits Delivery” are iterative. So we can see, program management is focused on the iterative delivery of benefits; which is what agile is all about so why do agile teams often face challenges from traditional project managers and PMOs? 

 

Thick Sandwiches

This is an aside, but a repeating pattern we often encounter is something I call the “Thick Sandwich”. It describes the situation where workers want to do the right thing and executives and senior managers want business benefits, but placed between them is a layer of middle management who, while well intentioned, tend to obstruct common sense and efficient delivery. So, engineers want to be useful, sponsors want products, but project management as a discipline aims to bring order, predictability, measurement and controls tend to gum up the whole process. 

Middle managers and their processes are created to optimize the process, add rigor and controls, but often just hinder the process. Lean processes (including agile) run up against this often. Agile is well aligned at CMMI levels 1 (Initial), 2 (Defined) and 3 (Managed), it also perfectly aligns with CMMI level 5 (Optimizing) that focuses on process improvement but runs afoul on the documentation and controls layer of CMMI level 4 (Quantitatively Managed). Here again the well-intentioned layer of rigor and control can act as a value delivery inhibitor if we are not careful.

 

Continue reading "Agile Benefits Management" »


PMI-ACP Training in Calgary

CalgaryI 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 9th 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.


Second Edition of My PMI-ACP Book is Now Available

2nd EditionEven though several people reported receiving their books last week, Canada Post takes a little longer, but today I got my first look at the second edition of my PMI-ACP Prep book. There is more coverage of Lean, Kanban and Scrum. It has been restructured to match the new PMI Exam Content Outline domains and has a new section on Agile Mindset. These changes along with more practice questions increases the page count by some 85+ pages.

It’s a hefty text book now, but the extra material is support, more explanation and feedback suggestions from hundreds of readers of the first edition. The exam content was restructured but did not change that much. So it is not that there is now more to learn rather more material to help you on your way to earning the PMI-ACP credential.

RMC has a 30% off early-release offer right now that can be found here.


Agile Talent Management

Talent ManagementTalent Management is the science of human resource planning to improve business value. It includes the activities of recruiting, retaining, developing and rewarding people along with workforce planning. From an agile perspective much of what we do on agile projects helps with talent management. We encourage empowered teams and give people autonomy over how they work which improves satisfaction and motivation. We also promote knowledge sharing through a variety of collaborative practices which reduce the impact to the team of people leaving. 

However, these measures only address some recommendations for talent management. This article examines the ideas and project implications of the other recommendations. First, let’s examine why talent management is important and understand the labor cost vs opportunity cost differential. 

Recruiting costs

If we lose a team member and need to replace them; a job posting needs to be created and sent out to agencies and online forums. We then need to sift through replies and come up with a short list of candidates to consider further. Next comes reviewing candidates with the project manager, arranging interviews, interviewing candidates (preferably with team involvement), following up on references, salary negotiations and hopefully finally hiring someone. I went through this recently for a developer on a software project and estimated the total time to the organization to be 64 hours. At an average labor rate of $80/hr that is $5,120. Had our first choice candidate not joined or failed reference checks the total time to hire would be much higher. 

Getting up to Speed Costs

A point often overlooked is not this initial hire effort, but the subsequent, much larger learning cycle before becoming a productive team member. A convenient Tayloristic view of management believes one developer can be swapped out for another. However, for a large, complex project it often takes smart, motivated individuals 3 months of learning to get up to speed with the business and technical domain and a further 6 months before they become truly productive. In these first 3 months not only are they not contributing to net new functionality but they are spending 50% of their time asking questions of other team members – slowing their output too. 

These costs are huge, assuming a fully loaded developer rate of $80 / hour (typical for North American software engineering) 3 months of not contributing and slowing other developers by 50% full time equivalent (FTE) costs: 3m X 4.2wks x 40hrs x $80/hr + 50%(3m X 4.2wks x 40hrs x $80/hr) = $60,480.

Follow this with 6 months of increasing capability going from 0% productive (no longer a net drain) to 100% productive (up to speed) we can use an average figure of 50% non-productive so 6m x 4.2wks x 40hrs x $80/hr x 50% = $40,320 

So, the cost of losing a team member and having to recruit and train another could easily be $5,120 + $60,480 + $40,320 = $105,920. However it gets worse, whenever a high performing team loses a team member they move from the Tuckman “Performing“ phase to the ‘Storming” phase again as the team dynamics change and have to get back through “Norming“ to “Performing”. 

Continue reading "Agile Talent Management" »


Agile Innovation

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.

Continue reading "Agile Innovation" »


Agile and Strategic Alignment

This month’s theme at ProjectManagement.com is “Strategy Alignment/IT Strategy.” This can seem at odds for agile teams who organically grow solutions towards evolving requirements. Where’s the strategy in that, and how do we promote empowered teams while preventing chaos? Most organizations spend considerable time and effort developing strategic roadmaps and they don’t want this work undermined by unordered development.

Fortunately, hope is at hand with some well proven models. While the common kernel of agile practices make little mention of strategy or architecture, many of the supporting guides and scaling approaches handle the topic well. So, when faced with a criticism of no place for IT strategy or struggling to link an existing strategy to an autonomous team we can turn to these agile “wrappers” for inspiration and guidance.

You do not have to be using these approaches as standards at your organization to make use of the integration points and approaches they recommend. Instead see how strategy and architecture are handled and then apply a similar approach in your project and organization.

DSDM

Dynamic Systems Development Method (DSDM) is an agile approach that started in Europe and covers a broader project lifecycle timeline than most agile methods. It starts early with Feasibility and Business Study phases goes beyond deployment to handle Post Project work. Unlike most agile methods that don’t mention architecture DSDM has an architectural deliverable called the System Architecture Definition (SAD) that is created early on in the Business Study phase.

Agile projects struggling to appease architecture groups and facing criticisms of lacking strategic alignment, could look to the DSDM System Architecture Definition as a template for an early project, light-weight solution. DSDM also fits well with The Open Group Architecture Framework (TOGAF) standard and there is a White Paper on DSDM and TOGAF Integration White Paper here.

SAFe

The Scaled Agile Framework (SAFe) is a knowledge base for implementing agile practices at enterprise scale. It presents this information through a Big Picture View that shows how the work of agile project teams can be rolled up into programs with their own program backlogs. Then explains how programs fit into larger portfolios that implement product investment and strategic themes.

Continue reading "Agile and Strategic Alignment" »


Agoraphobia: The Fear and Loathing of Open Space Offices

Agile methods like XP, Scrum and DSDM have been advocating co-located teams in open plan offices now for 20 years. The idea being that since face-to-face communications are the fastest and most efficient, teams should be established to work this way whenever possible. Also, software projects, where agile methods started from, build intangible, often new and novel solutions to problems; as such there are lots of opportunities for miscommunication about how these new systems should look and work. Having people working together makes it easier to surface these misunderstandings, collectively troubleshoot problems and collaborate on new solutions.

However co-location is not always possible and open plan offices can suffer from “noise pollution” and frequent interruptions. The following infographic was created by a Voice Over Internet Protocol (VOIP) provider so probably has some selection bias, but importantly draws its findings from over a dozen respectable sources including articles from Bloomberg, The Guardian, the Wall Street Journal and Fortune.

Continue reading "Agoraphobia: The Fear and Loathing of Open Space Offices" »


Agile Coach Camp

Agile Coach Camp CanadaLeading Answers is a proud sponsor of Agile Coach Camp - West 2015, an Open Space Conference to be held in Calgary, Alberta on the weekend of June 12-14, 2015. I would like to invite my fellow agile practitioners to attend!

 

Agile Coach Camp – An Unconference

Let’s have a conversation about what it means to be an agile coach, why it matters, and where we are headed. The annual gathering at Agile Coach Camp creates opportunities for our coaching community to share our successes, our learning, our questions and our unresolved dilemmas – all in an energizing and supportive environment.

 

The Open Space Technology, “Unconference” format, encourages participants to join the conversation.

 

Each of us can make a contribution to the art and science of helping people and teams be their best as they deliver valuable software. Share your stories, observations, and enquiries. Discuss coaching challenges you have overcome or those you are still wrestling with today. Describe opportunities you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others.

 

The fee to attend this unconference is $75 per person and includes all food & drink for Friday evening, Saturday (breakfast, lunch & snacks) and Sunday morning.

 

The Open Spaces Technology wikipedia page does an excellent job of explaining how this unconference works - we recommend taking a look.

 

For more information, or to register, visit the Agile Coach Camp Canada West website

 

Thank you

Mike Griffiths

Leading Answers

ACCC West Sponsor

 

 

Knowledge Sharing on Agile Projects: Absent or Abundant?

Absence or AbundanceKnowledge transfer and sharing on agile teams differs from traditional approaches in both form and the internal vs external focus. Agile teams produce few of the traditional knowledge transfer documents yet their daily practices focus on knowledge transfer. While agile teams spend much of their time transferring information internally they share little with external groups other than the evolving product or service they create. These differences lead to some polarizing views of knowledge sharing and transfer on agile projects.

Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer.  So why the disagreement, how can smart, experienced people have such different views about the same topic? It comes down to what we consider knowledge transfer and sharing to be.

A requirements specification document should be a great vehicle for sharing knowledge and transferring it from analysts to developers. It is a permanent record of requirements that can be read by many people and referred back to when needed. If questions or the need for clarifications arise – go look in the requirements specification. This works well for stable, unchanging requirements that can be gathered comprehensively up front.

Baselined plans are great knowledge sharing tools too. They lay out what should happen, when and by whom and paint a clear picture for all to see. Plans illuminate the path forward and communicate this to all involved stakeholders. Lessons Learned documents gathered at the end of a project are classic knowledge transfer and sharing tools also. Recording what went well, what did not go well and recommendations for similar projects to follow seems the epitome of knowledge transfer.

Agile projects down play the value of upfront plans, avoid detailed requirement specifications declaring them unreliable and wasteful. They often spurn Lessons Learned documents too, instead performing retrospectives amongst themselves. It is no wonder then, that to some people agile projects appear to lack the basics of knowledge sharing and transfer. However these people are measuring with the wrong yardstick, or fishing with the wrong size net and missing the knowledge rich plankton that feeds agile teams. When you “see the matrix” of agile projects you immediately realize the whole process is about knowledge transfer.

Continue reading "Knowledge Sharing on Agile Projects: Absent or Abundant?" »


PMI-ACP LinkedIn Group Growing

Last week we passed 500 members for the new “PMI-ACP Exam Prep with Mike Griffiths” LinkedIn Group.

That is a great start and plenty enough to begin discussing topics about the exam for people studying for the credential and those already with it. I have just posted a new discussion on the suitability of the PMI-ACP curriculum you can join the group and see it here

Text_illustration


Agile 2015 Conference Session

My presentation outline “Eat Risks for Breakfast, Poop Awesomeness All Day!” was accepted for the Agile 2015 Conference in Washington D.C., August 3-7. As much of the agile community seems engaged in scaling debates I am really happy to share some useful tools that can be used on any project, regardless of approach.

The learning objectives for the session are:

  • See why project managers are the least equipped to effectively identify and manage project risks.
  • Learn engaging ways to educate team members about risk management including identifying threats to avoid and opportunities to exploit
  • Preview 5 collaborative games for effective threat and opportunity management from planning and identification, through management, to reporting and closure
  • Understand the untapped potential of an increased emphasis on opportunity management
  • Review case studies of projects teams that have been using these practices for three years and are achieving measurably better results than teams that do not

Risks_monster_color


PMI Credentials – The Last Decade and the Next

PMI Certs Fig 3Today we take a look at how the number of PMI Credential holders has grown over the last 10 years and speculate where they might go in the future. While 10 years is a good period to look back over, the PMI’s PMP ®(Project Management Professional) credential dates back much further, to 1984, making it 31 years old this year.

Growth of the PMP was slow in the 1980’s partly due to the different communication methods being used then. The Internet did not start becoming popular until the 1990’s, so information about the PMP certification was shared mainly through periodic journals and newsletters. Another factor was the self reinforcing nature of credentials. When credentials are new few people outside of the originators have heard of them so there is little external incentive to get one. Slowly, people wanting to demonstrate their skills and/or distinguish themselves from their peers obtain the credential. Then, once it reaches a critical mass, hiring managers start asking for it so more people are motivated to obtain it and growth increases rapidly.

By the mid 1990’s the PMP credential was picking up steam and by 2004, our 10 year look back starting point, the PMP had over 100,000 holders. By the end of 2014 this has grown to nearly 640,000 certificants and is by far the most popular credential offered by the PMI. 

During the last 10 years a number of new credentials have been launched to provide opportunities for both specialization (like the scheduling and risk credentials) and diversification (such as agile and business analysis credentials). The first credential after the PMP was the CAPM (Certified Associate in Project Management) introduced in 2004 that serves as a potential stepping-stone to the PMP and is targeted for people who have worked on and around projects, but do not have experience leading and directing  projects.

Since then there have been several more credentials launched that we will discuss in more detail later, but for now we can see from the stacked areas graph below in Figure 1 that the PMP and CAPM make up the majority (98%) of all PMI Credential holders.

Continue reading "PMI Credentials – The Last Decade and the Next" »


PMI-ACP LinkedIn Study Group

PMI-ACP Study GroupI have created a LinkedIn group for readers of my PMI-ACP Exam Prep book. The group combines the features of a study group and Q&A forum along with exam taking tips. Once we have critical mass I will focus on a chapter for 2 weeks discussing topics and answering questions.

I would also like to hear from people after they take their exam to get feedback on how using the book worked for them and any suggestions for the second edition. If you are interested, please help me in spreading the word and join the group Here.


Quality Project Management

Unexpected SuccessHow do we define quality as a project manager? Is it managing a project really well, or managing a successful project? How about managing a successful project really well, that sounds pretty good. However it poses the next question: What is a successful project? Let’s look at some examples of project success, failure and ambiguity.

 

Apollo 13
Apollo 13, the third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from astronaut, James Lovell (that is widely misquoted as, "Houston, we have a problem".)

Apollo 13
The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing for future missions. Clearly, this was a remarkable achievement, but the original project goals were not met. Lovell now recounts this story at PMI conferences under the very apt title of “A Successful Failure”.

 

Continue reading "Quality Project Management" »


The Evolution of Teams

The Evolution of TeamsMy other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever.

Agile practices such as daily stand up meetings, sprint planning and retrospectives are great tools for encouraging team members to share information, collectively make decisions and improve. However, how do you maintain active participation for long periods without burn-out or boredom?

As companies recognize the productivity of high performing teams and bring new projects to established teams rather than disband and reform teams, how do we keep things fresh? My session is a case study of an award winning agile team that has been delivering projects for over 7 years. It examines how the original core practices that are familiar to any team starting agile have evolved into new practices while honouring the original values and goals.

A casual observer may be concerned: “What, no stand-up meetings, sprint planning meetings or retrospectives? You guys are not agile at all!” However teams can be agile without doing the traditional agile practices. Agility, after all, is a mindset not a To-Do list, and this session introduces the practices of “Show-and-tell”, “Tech-talk” and “Sense-Pull” amongst others.  They may not work for your team, but show the journey of one team’s progression through adaptation and refinement of process. (Along with all the bumps, set back and mistakes made along the way too.)

If the presentation gets accepted I will share the main topics of the session here for feedback before delivery.


Eat Risks for Breakfast, Poop Awesomeness All Day!

Risk Eating MonsterI have submitted a presentation for Agile 2015 Conference about team based risk and opportunity management that may well get rejected based on its title alone!

It has always been a good practice to engage team members in the estimation process; then agile methods taught us how teams should do the local planning and decision making too. So it should come as no surprise that the best people to undertake effective risk management are team members. They possess the best technical insight and are closer to any execution issues than team leads or project managers.                                               

However, risk management as tackled by many organizations, is academic, boring, seemingly removed from real-work and it often ignores the maximization of positive risks (opportunities). My proposed workshop demonstrates how to turn teams into risk-consuming, opportunity-chasing beasts that that leave a trail of business value and delighted stakeholders.

  Risk Eating Monster

At the Agile 2012 Conference I presented a session called “Collaborative Games for Agile Risk Management” that introduced fun, team based games to engage the team in risk and opportunity management. In the intervening years many teams have adopted these techniques and become much more effective at Risk Management. However it turns out I was focusing on the wrong end of the lever, the big news are the results teams are getting through Opportunity Management.

Teams using these approaches are not only driving out risks, but more surprisingly, building great inter-organization alliances, being given free passes on bureaucratic process and generally having an easier go of things. At first I was surprised at all the “good luck” these teams encountered but then I saw how small adjustments in team behaviour were being made towards freshly identified opportunities.

A little like the 18th Century discovery linking germs to infections that gave rise to the introduction of hand washing in hospitals increasing survival rate dramatically. Putting teams in charge of opportunity management leads to changes in day to day behaviour that dramatically increased the execution effectiveness and success rates of their projects. 

Good leaders know the value of a powerful vision; it “Reveals a beckoning summit for others to chart their own course”. In other words once we know what our true goal is we can make our own micro adjustments. Getting teams to own opportunity exploitation causes them to behave differently and benefits start occurring all over the project.

My session proposal outlines the practices and reviews case studies so you can equip your team to be risk-consuming, opportunity-chasing beasts that leave a trail of business value and delighted stakeholders. However if the mental image of eating risks for breakfast and pooping awesomeness all day is too graphic to share in your organization, maybe a machine that harvests risks and opportunities and outputs business value is an easier sell, but not as much fun.

Risk Eating Machine


“Solving Today’s Complex Projects with Agility” Presentation

Gran Canaria PosterNext week, on February 18th, 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. 


Big Agile, the Route Less Travelled

Scaling Collaboration not Process is the Key to Enterprise Agility.

CollaborationAgile methods have been found to be extremely effective when used correctly. A reasonable reaction to witnessing any great performance in an organization is to demand more of it. So a tremendous amount of time, effort and resources have been expended over the last few years on scaling agile for the enterprise with all the new processes and models that can go along with that. 

I admire a lot of the work done to scale agile methods in the attempt to replicate the success of the initial `golden-teams` to all groups in an organization. Unfortunately these roll out attempts largely result in disappointment or failure because the investment and effort has been applied in the wrong place. It is not process we need to scale and duplicate, it is the art of collaboration.

Agile methods are successful when they equip motivated subject matter experts to collaborate in an effective way with minimal process overhead. In attempting to make agile methods scalable, it is tempting to add more process to assist larger scale coordination. However that is the last thing we should do. Not that we don’t add more process, just that we add it last, not first, after you have replicated and established collaboration models. Adding process first kills collaboration and then even the best intentioned and resourced development environment is doomed.

This phenomenon of process stifling smart behaviour was identified by Dee Hock, former CEO of Visa who said: `Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behaviour.` The real path to scaling agile successfully is not choosing a scaled framework to implement, but focussing on replicating good teamwork and collaboration models and then adding minimal process.

The trouble is process and tools get all the press because they are more tangible and easier to describe. Plus vendors can promote and sell frameworks more easily than teamwork advice since they are proprietary and more marketable. So, a bit like diet pills and fitness gimmicks, we see more coverage of quick fixes that don’t really work than good (but less flashy) basic nutrition / teamwork advice that actually does work.

Continue reading "Big Agile, the Route Less Travelled" »


LeadingAnswers in 2015

PathwayI am well overdue for posting to this site, but it is not through lack of interest or ideas. There is an inverse relationship between postings and with how busy I have been. When I have time to post here it generally means I am getting some spare time. When you see nothing for weeks (or months) it means I have been busy doing “real-work” which I guess is a good thing. Since I last published some articles here I have been working with APMG on a PMBOK and DSDM Cross Reference and White Paper. This prompted me to update my “PMBOK Guide to Agile Mappings” and bring it up to the latest PMBOK V5 Guide version.

I have been doing some PMI-ACP Exam Prep training courses and taught a Collaborative Risk Management workshop. I gave a keynote presentation at an excellent PMI Conference in Poland and have been working with the PMI on the next version of the Exam Content Outline for the PMI-ACP exam refresh. I have also been teaching at the local university, writing for Gantthead (ProjectManagmeent.com), moved house and doing my regular day job.

These activities have provided me with lots of things to write about here and over the next few weeks I hope to post more regularly and share some cool new content. Thanks for your patience and stay tuned for some more articles soon.


9th International PMI Poland Chapter Congress

Poland-pmi-logo-2014I will be in Warsaw next week for the 9th International PMI Poland Chapter Congress – themed “Mission Impossible”. I am very much looking forward to it and sessions like the “Global Challenges of Mega Projects” by Virginia Greiman of Harvard University and “Agility in Business” by Arie van Bennekum, co-author of the Agile Manifesto.

I have a keynote on “Taming Today’s Complex Projects with Agility” and will be running a workshop after the conference on Agile Risk Management for Large Projects that features my Collaborative Games for Risk Management I have blogged about and documented. The conference will focus on Beyond Agile - taking agile beyond its original intent and also Mega Projects that challenge today’s project management practices.

Unfortunately this conference clashes with my local PMI-SAC Conference which also promises to be a great event, but hopefully I can catch up on some of the highlights of that from people who attended.

Mission-Impossible



The Economics of Compassion in the New Economy

Employee Perfect StormThis article is less about agile techniques and more about the people related challenges of today’s agile projects. As work switches from industrial work to knowledge work, companies face a perfect storm of employee engagement and retention issues. On the one hand the time taken to learn a job is increasing as domains become more complex and new tools add layers of abstraction and integration problems. On the other hand the average time spent in a job is decreasing. Frequent job changes are now the norm and long term workers are a rarity. Two years is the new five years average tenure and six months is the new two years of young worker average placement. It may seem just as people become productive they leave and the training process has to repeat.

An additional problem is that it is often the best people who move on, since they are sought after by more organizations and there is now less stigma with short work assignments. Companies not paying attention to their workforce or offering appealing work environments find themselves subject to an involuntary Sedimentation-Effect as the best float to the top and depart leaving less capable people behind. The process has been accelerated by social media and online job sites that make finding good places to work and connecting strong candidates to great companies easier than ever.

Things are not going to get better any time soon either, as Baby Boomers and Gen X workers leave the workforce Generation Y and Millennial workers are entering the market place in increasing numbers and with new expectations. Paul Harvey, a University of New Hampshire professor says that Gen Y and Millennial workers “…have unrealistic expectations and a strong resistance toward accepting negative feedback" and "an inflated view of oneself." 

Employee Perfect Storm

It is not all doom and gloom though; fortunately agile projects provide ample opportunities for tuning the workplace for better motivation and retention. Bill Pelster, principal of Deloitte Consulting, suggests that “Organizations need to understand that the world of work is changing. What millennials want — innovation, opportunities to grow and develop, mentors — aren’t overly demanding. They’re what every organization needs to succeed. All generations generally want what the millennials want, but what is different is the priority placed by millennials on development and core values versus, for example, a safe and secure job. Millennials are more inclined to take risks and change jobs much more quickly than other generations.”

In fact there are a number of things companies and managers can do to attract and retain the best talent.

Leaders, not managers - Forget trying to manage people, that’s too command-and-control and reactionary to cope with today’s speed of business changes, nor is it engaging. Today’s teams want leading. This involves communicating a vision of the desired end state, clearing the path of obstacles or bureaucracy, and providing mentorship with support.

There is a useful paradox that helps remind us of the leader role “We lead people by standing behind them” i.e. we back them up, provide support, encouragement, training and mentorship. Let them take any praise or glory and be a close, but in the background, supporting player.

Problems, not tasks – humans are hard wired to get a buzz from problem solving, that’s why many people play video games and do Sudoku puzzles in their spare time. Tap into this motivator and present the project’s goals as problems, don’t try to manage them away into tasks. Let the team see all the complexity then ask or challenge them to solve the project problems.

Engaged, self-organizing teams are incredibly resourceful and creative. The traditional model has solutions being designed by a small group of specialists and then selling the selected approach to the team for implementation. Agile leaders instead invert the model and engage the team in solutioning and have them “sell” their approach back to the project managers and business champions for approval.

This higher level of engagement builds a much stronger commitment to deliver and remove obstacles encountered along the way. It also taps into people’s reward mechanism of problem solving and helps build everyone’s sense of achievement rather than drudgery. Obviously some work will always be dull and we just have to grind it out, but that should be the exception not the norm.

Say “Yes” to time off requests – “kids school play”, “camping trip”, “whatever”,  if someone has enough of a reason to not want to be at work, especially contract staff who do not get paid when taking time off, why make them feel bad about asking or turn them down? The good-will and appreciation for having a flexible working environment ranks high among high achievers. Most people recognize when they have good working conditions and the small cost of reduced capacity is more than made up for by the benefits of retaining the best workers, reduced recruiting and training, etc.

Obviously if anyone abuses this goodwill guide and finds reasons not to work on a regular basis then there needs to be a separate discussion. Failing that I have only seen upsides from providing a very flexible work environment.

Leverage improv comedy’s “Yes, and…” – Responding to someone’s plan or suggestion with reasons why that won’t work here, or the famous “OK, but what about …” is demoralizing. “OK, but“ is often a thinly disguised “No” and after a series of these, people just stop suggesting ideas, shortly followed by stopping caring.  The first rule of improve comedy is build on ideas, not shut them down; it is the same with team work and co-creation in the work place.

So, if someone suggests an open house to demo the new system to customers, we can reply “Yes, and if we do a dry run with our business group first, we can iron out any kinks”. “Yes, and” promotes ideas and involvement rather than stifling them. We can always edit and improve plans later, but if the best suggestions never get made for fear of ridicule, no refinement can ever wish them into being.

Since collaboration and teamwork are so critical on knowledge worker projects, many forward thinking companies are looking to Improv training to help their employees. See these Forbes and FastCompany articles for more information.

Keep perspective and stay calm - remember our project issues are definitely first-world problems, a broken promise, buggy release, missed demo, or poor estimate are not worth getting truly upset about. Save the drama for where it is warranted, work compassionately and objectively.

Create projects, not roles – drawing from Deloitte’s Bill Pelster again: “It is important that organizations realize that millennials are looking to constantly gain new experiences and push their development. This means that organizations need to think through the velocity of developmental opportunities and the potential need to “re-recruit” millennials on a regular basis. Failure to do this will potentially lead to higher than expected turnover and more pressure on your recruiting organization to constantly source and on-board new talent.”

We can frequently re-recruit staff through exposing them to new projects with new problems to solve. Align people with key projects and mentors so that they are challenged and have an accelerated growth experience. This is good for the organization and their employees.

HippySh*t or Solid Sense?

To some people these recommendations may seem like indulgent panderings to a soppy workforce of over-entitled layabouts. They may seem to be overly generous, but the world is so connected now it is easier than ever for the best people to find good work. If your company undertakes industrial work involving the repetition of established process, you likely do not need the best and most talent workforce; instead reliable and cost effective staff are the way to go.

However if you are in the knowledge work space of solving novel problems then attracting and retaining the best staff you can is not a company differentiator, but the minimum required to stay in business. The suggestions outlined above, and others besides, do not replace standard work. Instead they get woven into our normal behaviour for leading teams, hopefully to effect subtle shifts towards a more desirable work place that retains the best talent and attracts more of the same.

The economics of compassion and empowerment might not sit easily with everyone from my generation. Like many people, I worked in junior, menial roles for decades before being given any opportunity to influence. But as the saying goes “If you don’t like change, you’re going to like irrelevance even less”. So, the question becomes what can we learn to stay up with the wave of change if we want to succeed?


The Dangers of Visual Project Management

(Or how a picture can divert 1,000 eyes)

Optical Illusion

This post was first written for ProjectManagement.com who were doing a series on Visual Project Management at the time. I was excited when I heard about the theme since I am a big fan of adding meaning through visual tools to all kinds of project elements, whether it is methodology scope, project progress, or risk lists.  As a visual thinker I like to make sense of a concept spatially before adding detail or explaining it to others. Yet I have found this to be a weakness as well as a strength, because what cannot easily be visualized can often get trivialized or forgotten.

Plans and prototypes are great because they easily bring people together to debate and collaborate on important project elements. Since we have something to point at and annotate; discussions and agreements progress quickly because consensus making is greatly facilitated. However what about conflict management, decision making across teams, or business engagement issues? These are more difficult to visualize but arguably more important than if a web site should have a blue or a green background.

The idiom of “Out of sight, out of mind” speaks to the dangers of an overreliance on visual management.  So how do we address this threat? I believe there are two main choices: first, find a way to somehow make it visible, or second, consciously bring extra attention to it.

Another project saying “What gets measured, gets managed” might hold a clue to helping find ways to make things more visible. I think there are some parallels between the visible / invisible issue to the measurable / immeasurable issue. Many of the things we can measure on a project are not helpful and many of things we would really like to measure are intangible and difficult to measure. Einstein summed it up nicely with the quote “Not everything that counts can be counted, and not everything that can be counted counts”.

Continue reading "The Dangers of Visual Project Management" »


Helping Your PMO Help You

PMO Agile CoordinationDo any of these traditional PMO scenarios match your agile team experiences? Your traditional PMO is so laughably outdated that most agile projects ignoring them; other projects produce token deliverables to appease them, but these bear little resemblance to anything actually happening on the agile projects.

The PMO looks for conformance to BDUF (big design up front) methodologies with signoffs to premature speculations about requirements and scope definitions. It reports progress on traditional projects such as being 75% through Requirements Gathering or 50% through Analysis and Design as if these non-value delivering activities are actual progress. Finally, when projects have issues the PMO responds by creating more review and approval groups to ensure competence and adds gates and sign-offs to try and improve quality.

If these scenarios sound familiar to you I would like to ask a follow-on question: How is your agile roll out going? Is the PMO the last bastion of opposition or are you fighting pockets of resistance and misunderstanding throughout you organization? Is the once “no-brainer” decision to switch to agile actually causing some headaches and frustration? If you answered yes to this too, you are not alone.

It turns out the PMO is not usually the problem, but they are a good litmus or canary-in-the-coal-mine for how an agile transformation is going. The PMO’s focus is project execution process, so if you cannot convince this group that agile is the way to go, then how do you plan to convince groups who don’t care about process at all? How about the BA Center of Excellence or the Architecture group, have they fully bought in to your agile approach or are they requesting more formal practices?

Getting the PMO onboard is helpful in convincing these other, more problematic groups that agile methods can be a better way of working. So how do we do that? Well making agile more accessible is a good start. PMO’s often shy away from agile methods since the short iterations and repeating cycles of work do not offer the familiar phases and gates they are used to. In fact interacting with agile team iterations seems as appealing as putting your arm in a spinning concrete mixer.

However we can make the process less daunting by showing how the user story and backlog process works. Take some required deliverable, like a handover document, and create a story for it. Give it to the team and along with a customer proxy (a Product Owner for instance) the story will get prioritized and placed in the backlog. Since it is required for Go Live the story will get selected and worked on by the team prior to the release date – all with PMO limbs intact.

PMO Agile Coordination
 

Another point of confusion around agile methods for some PMO groups is the lack of a visible end point or meaningful progress reporting. They may wonder if iterations just repeat until the customer is happy rather than the specification is complete? Gaining visibility into the process can help by providing retrospective data to the PMO along with story points and feature metrics. By explaining the cadence of reviews and tracking metrics PMOs are assured progress is measurable and all the old favorites like Budget At Completion (BAC) and Schedule Performance Indexes (SPI) can still be obtained.

Helping the PMO helps agile adoption by creating another advocate group. It may be a surprise to some PMs and teams but PMO’s are under a lot of pressure to justify their existence and demonstrate their value add. They are usually very receptive to ways to stay current and support emerging practices.

Investing some time to train them in Product Owner training or Retrospective Facilitation pays dividends since now they can offer these new project services. Project teams will benefit from a more educated and aligned business community and gain impartial facilitators making it easier for all to contribute ideas at retrospectives.

Rather than unaligned PMOs representing an obstacle to agile teams, they really represent missed opportunities for further agile adoption and an indicator that the agile message might be miscommunicated to other stakeholder groups. Spending some time to address their concerns, explain the risk reduction goals of early feedback, and equip them with useful services will pay dividends and ease the larger adoption of agile and lean principles.

(I first published this artice at ProjectManagement.com here)


It is not the Process, Stupid

ProcessEven though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the true focus.

Just as Disney is all about manufacturing a positive visitor experience through detailed buildings, social engineering and extensive staff “character” training; agile methods are really about creating a social framework where effective work can be accomplished. This social framework will vary from project to project and enterprise to enterprise. It is a problem solving exercise like building a custom galley kitchen inside a boat not a standardization exercise like force fitting IKEA kitchen cabinets.

I realize that by using analogies to Disneyland and IKEA so early in an article many readers may assume I have finally lost the plot but after 20 years of practicing agile I have had enough with rote methods implementation and attempts to scale through process training that fail. To me agile is about process as much as Disney theme parks are about Mickey Mouse. Yes, they are an easily identifiable symbol, a short cut to identification, but far removed from what the real focus is.

In fact Mickey Mouse cartoons kind of suck and most people would be hard pressed to think of a good one. However, luckily for Disney that is not the point, their real goal is to capture imagination and allow people to explore fantasy environments while spending lots of money, hopefully as part of a pleasurable experience so they will come back and also tell their friends.

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

Sense making – agree information gathering steps and prioritize exploratory work

Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting

Conesus gathering - collaboratively gain consensus on direction, approach and decisions

Prioritization – build mindful to risk reduction and business value

Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates

Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings. Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail and it is like assessing a Disney theme park by asking “Does everyone have their Mickey Mouse ears?”

I am lucky to work with an agile team that has been together for 7 years. Not that it has taken us that long to finish a project, but instead the business sees the benefits of a high performing team and keeps bringing us new projects to undertake.

[The whole idea of bringing projects to established high performing teams could be the subject of another post . Instead of creating new teams per project and going through the Tuckman stages of Forming, Storming, Norming then hoping to get to Performing, using existing high performing teams bring many benefits.]

The team is the best I have worked with and won a PMI Project of the Year award for the first project they completed. Yet I cannot remember the last time we had a stand up meeting or retrospective. We dropped two week iterations in favor of a continuous pull of features and use cycle time in lieu of velocity or detailed estimation based on points or days. So is the team still agile? An outside observer looking for process or ceremonies might say No; I would say You Betcha! The team embodies the sense making, iterative, consensus driven concepts implicitly. Techniques like prioritization, results oriented reporting and empowerment are baked into every conversation and action.

It would feel weird to wait until the end of a sprint to discuss adaptation of process. In fact the notion of a sprint seems an artificially restrictive and wasteful construct to manufacture. Inter team communications are too important to wait for a daily stand up meeting and team members get an equal say in decisions and spend lots of time in healthy debate, both face to face and with remote team members.

The set up is not perfect and still has room for growth. We could do better at interacting with other groups and our tendency to “fly-under-the-radar” to avoid delays for approvals from other groups also means we miss opportunities to share success stories and spread effective practices to other departments as well as we could. Yet on the whole the group is very effective.

Skills acquisition is often described using the “Shu”, “Ha”, “Ri” progression. In this model new practitioners start with obeying the rules (shu, which means to keep, protect, or maintain), then consciously moving away from the rules (ha, which means to detach or break free), and finally unconsciously finding an individual path (ri, which means to go beyond or transcend).

My point is that agile is not process following. Success is not methods replication, it is not really gaining an agile mindset either, that’s too insular and individual; instead it is creating a working ecosystem for your environment. The ecosystem may have activities that could be labeled as “processes”, but true processes are designed to resist change, they are like robust pipes that force compliance on items that vary. Activities and behaviors are more open to change and support it where it makes sense.

There are some popular tests to gauge if a team or project is truly agile. The Nokia Test and the Scrum Test are good starting points but they still ask if ceremonies like daily stand ups and constructs like iterations exist. These questions miss the true intent of these practices and bring focus to the process. Yet the process is not important and may/should change over time as a team develops, or be adapted to better suit a client. So it is better to separate the process from the behavior we are really trying to assess.

The following questions do not dictate what process to use but look for signs of a healthy, productive project environment.

  1. Does the business value what is being delivering and want to continue with the same group?
  2. Is the team still improving and learning as it works?
  3. Are the increments of delivered work frequent and of a high quality?
  4. Is the project ecosystem healthy?
  5. Is the system receptive to change?

Thinking of behavior and capability rather than process conformance will help organizations deploy and scale their agile adoptions. It might be easier to measure process adoption than underlying competency, but like associating Disney with Mickey Mouse it is not really about the process.

[I first published this article at ProjectManagement.com here]


Posting Update

Thank you for visiting my site or subscribing to this feed. Regardless of how you access this content thanks for your patience. I have not been writing recently, instead using my spare time to enjoy the great summer weather we have had here the Canadian Rockies. However that is about to change, I intend to post more frequently and am excited about the new content, training courses and opportunities I have planned for the fall.


Thinking Tools for Scaling Frameworks

Light bulbsScaling agile is a hot topic these days. Frameworks like LESS (LargE Scale Scrum), SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) are in the limelight as too are companies training up ‘’Agile Transformation Consultants’’ to transition entire organizations to agile. However, successful scaling is not easy, it is one thing to put a company through a week’s worth of training and mentoring, but another completely to make lasting changes to working practices and resolve all the issues that get surfaced along the way.

 The logic is simple, when executives see a successful agile project their initial thoughts are often: “Great, let’s do more of this!”, yet the solution is complex. Solving the simple question of “How do we reliably duplicate exemplary performance?” is anything but simple.  Moving from one or two successful agile projects to transitioning an entire organization to use agile methods is a challenging and daunting task.

Factors such as people who do not understand the problems with current practices and a lack of agile thinking are difficult issues to overcome. Strategies for transforming an organization to agile vary. Some favour a top-down education process, others a bottom-up, grass roots initiative.

Should the approach be Buddhist (teach the principles and allow local adaptations) or more like Catholicism (everyone must follow a strict standard protocol)? Insights into these concepts of scaling up agile can be found in the book “Scaling Up Excellence: Getting to More Without Settling for Less” by Robert Sutton and Huggy Rao. 

The authors describe this Catholic vs Buddhist split along with strategies for bridging the two. The In-N-Out Burger chain popular in California takes a very Catholic view to replication where common practices are replicated with very little deviation. This is akin to proclaiming all teams will follow Scrum by the book. The KFC food franchise on the other hand, allows lots of local customization and sells egg tarts and soy milk in its stores in China that are not offered in other countries. This is like explaining the agile manifesto values and principles and allowing variations in team implementation.

There are times when the need for local uniqueness is obvious. Stanford researches tracked a software company who opened offices in Silicon Valley and India. The Silicon Valley offices had bare concrete floors and rough unfinished surfaces to provide a funky, urban-contemporary look. Yet in India rough finishings send a different vibe and some locations have more dust and are impractical for women wearing long saris that quickly get dirty as they drag along the floor. So the company quickly dropped its Catholic approach and installed carpeting.

There are also times when people can suffer from “delusions of uniqueness” when they think they are “special” or more unique than they really are and miss out on some improvement. Brigham and Women’s Hospital had very high rates of doctor customization occurring in its selection of joint replacement products despite no evidence suggesting these new products were any better. It seems doctors just enjoyed trying out new technology - a problem common to many industries.

It is possible to bridge the two poles of Catholicism and Buddhism by using swappable sub-assemblies. Like reusable chunks of Lego, these proven successful components can be used to quickly get the benefits of some standard process while allowing for local customization.

In an agile setting this could be as simple as moving the 9:00am Stand-up meeting to 11:00 to ease co-ordination with a West Coast team, or more sophisticated such as swapping iterations for a continuous pull of features via kanban and DevOps in a high change environment.

When discussing the top-down education or bottom-up change, Sutton and Rao assert that success comes from a ground war not just an air war. During World War 2 commanders often called in bombing raids with the hope of devastating the enemy. Unfortunately only 20 percent of bombs dropped fell within 1,000 feet of their target. More recently with the advent of GPS and laser targeting it is easy to think air wars are now effective. However a review of NATO’s seventy eight day air war on Serbia to stop ethnic cleansing by Slobodan Milosevic concluded it was “a major blunder that the use of ground troops was ruled out from the beginning’’.

All the research and case studies in Scaling Up Excellence find that “Scaling requires grinding it out, pressing each person, team, group, division or organization to make one small change after another in what they believe, feel or do.”

Air assaults are often useful first steps, but are rarely long term solutions. More often, territory must be won inch-by-inch working through issues as they are encountered. This requires persistence, lots of work and slow progress to reliably instill a new way of thinking and working.

For these reasons we should be wary of “agile transformations” that claim to transition an entire organization over a 2 week or 2 month period. This is more akin to an air battle. Yes, maybe everyone in the organization was exposed to some agile training and this is a necessary step, but true understanding and adaption only come through use, failure, learning and growth which take much more time.

Before planning to scale agile (or any other approach) discuss the “Catholic vs Buddhist” and “Air-war vs Ground-war” concepts with those who will be engaged in the rollout. Learn to detect Delusions of Uniqueness and employ Lego Bridging Strategies. These techniques can avoid “Clusterfugs” - an enterprise friendly word used to describe a poorly received transformation and instead can pay huge dividends.

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


PMI-NAC Conference

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

  1. 21st 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: ”21st 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.


Are Virtual Teams the Next Revolution of Work?

Virtual Team T ShirtVirtual teams may well be the next step-change in the evolution of work. So it is interesting to ask if today’s management principles and processes are optimized to support them? To help answer this question let’s take an illustrated tour of work through the ages and also review how management has progressed along the way.

Work patterns have evolved through revolutionary and evolutionary waves. Some have brought major, irreversible shifts; others step-changes and refinements. Tens of thousands of years ago population densities were generally low as people worked at farming, fishing and still some hunting and gathering. You needed space to do this and too much local human competition was not helpful. Then, as crafts, trading and specializations emerged towns became useful hubs for exchanges and population patterns changed. Access to fresh food sources was still a major concern, but trading and money allowed for easier centralized living.

These were slow, likely imperceptible advances, quite unlike what happened next with the Industrial Revolution of the 1800’s. People were needed to work in factories and a major migration from rural to city living occurred within decades. Factory funded schools began focusing on time keeping, discipline and following instructions to better condition children as future workers. The Victorian work ethic promoted by many leading entrepreneurs was a useful conditioner for taking farmers, who were used to working following the daylight hours and seasons, and adapt them to a regular 7:00am to 7:00pm work days favored by factory owners.

How industry shaped cities is also an interesting topic. Steam engines where large machines that could only transmit power via shafts and belts over relatively short distances.  So early factories were tall, square buildings to maximize machine capacity within close reach of the steam engine. Electrification made power easy to transfer and factories became long, low structures that were cheaper to build and required less lifting of materials. As work patterns evolved so too did our industrial complexes from tall to sprawling.

Shown below is a picture of the moving production line at Henry Ford’s Piquette plant completed in December 1913.  This approach to manufacturing, generally known as progressive assembly, heralded a major increase in productivity that was adopted by most manufacturing industries. It was inspired by the time-in-motion studies done at the Bethlehem steel plant by Fredrick Taylor which showed increases in efficiency for specialized labor. Ford was the first to employ moving production lines and specialized labor on a large scale to increase productivity and drive down costs.

Model T Assembly

Photo Courtesy: Ford Motor Company

We still see examples of these decomposition principles today when software project work breakdown structures reduce complex systems into small components and assign “Developer 1” and “Developer 2” type resources.

The next photo shows the Tesla production facility at Freemont California.

Tesla Assembly

Photo Courtesy: Tesla Motors

The Tesla factory has a rich history of manufacturing and management evolution. Starting out as a General Motors Freemont Assembly plant in the 1960s it embodied the modern interpretation of production line thinking. A downside of working in a specialized labor role in a highly mechanized environment can be a feeling of being a machine yourself and the plant suffered many worker disputes and union clashes during the 1970’s and 80’s. There were reports of deliberate protests and cars being sent out with Coke bottles in the doors to rattle and annoy customers.

Relations broke down and the plant was closed in 1982 only to be reopened in 1984 as a joint Toyota / General Motors plant known as New United Motor Manufacturing Inc (NUMMI), rehiring many of the same disgruntled workers. Toyota introduced lean manufacturing processes including respect for staff and empowered workers to stop the line if problems were encountered. The Japanese / American relations during these transition years created many stories and was the motivation for the comedy movie “Gung Ho” that Toyota later used in training sessions of how not to motivate American workers.

The switch from traditional manufacturing using production lines and large inventories of materials and sub assemblies to lean, just in time (JIT) production systems was driven by new philosophies of management. Lean and JIT techniques follows the work of James Womack, Peter Senge and Eli Goldratt who reposition management from schedulers and task masters to identifiers and removers of impediments to workers. They encourage and reward team problem solving and promote continuous improvement.

As capitalism and the pursuit of labor cost reduction continued, many manufacturing plants moved to cheaper labor markets. North American and other previously industry focused countries saw a rapid drop in local production. In their place however we saw an increase in design, finance, research, health and education services. This was the birth of what Peter Drucker called the Knowledge Worker – professionals with subject matter expertise that work together to solve new or novel problems.

These three big shifts in work are shown below:

Evolution of Work

Picture Courtesy: www.LeadingAnswers.com

In 2009 the joint venture between GM and Toyota at the NUMMI plant ended and neither company could find a suitable use for it. In 2010 Tesla, then a startup Electric Vehicle research and development company struck a deal with Toyota and bought the 380 acre site previously valued at $1Billion for just $42M. Toyota also invested $20M in stock of Telsa and some of the Toyota staff were rehired as more traditional industrial work gave way to newer exploratory knowledge work.

Agile methods are very effective for knowledge worker projects. They provide Sense-Making activities for gaining consensus from diverse stakeholders during the early stages of projects where uncertainty is high. They also provide tools like short iterations of build / feedback cycles to help reduce risk, prove approaches, and surface deficiencies in designs when tackling novel problems or using new technologies. Finally, they have process adaptation and goal seeking reviews built into their operation that helps teams refine their approaches and work more effectively.

Yet the changes have not stopped. Now with the widespread adoption of email, video conferencing, real-time chat and an emerging workforce who “grew-up-digital” and fully embrace these technologies, virtual teams are poised to revolutionize work once again. We just discussed the car industry, but it is telling that for the first time ever fewer teenagers who are becoming eligible to drive are buying cars, the cost of ownership is perceived as too high, but don’t try and take away their smart phones! Maybe since communications are so easy and prevalent, texting your friend is easier than driving to see them?

One thing for sure is that talent is distributed and technologies for finding and linking teams is improving rapidly. If I want a logo designed or web site built I can log onto a freelance site like Guru.com or Elance.com and access a global marketplace of talent showing examples of their work and hourly rates. Escrow services exist to ensure work and payments occur fairly and help with arbitration if the need arises. Or, if I want a custom door handle or even a titanium bicycle I can download the design and print it in my home or at a local 3D Printing shop.

What these technologies mean to how we work and live in the future remains to be seen. Alvin Toffler wrote about the “Electronic Cottage” in his 1984 book The Third Wave that describes people living where they want in a future paperless society and communicating electronically. Many of the technologies we need for wide scale virtual teams working are in place but we need to overcome the C.U.T.E. problems:

  • Communications – how do we meaningfully communicate complex issues across geographically dispersed teams with different languages, time zones and cultures? How do we clearly articulate requirements, issues and feedback in universally understood ways?
  • Unity – How do we instill a sense of team in people who have never physically met? Why would people be motivated to go beyond their regular roles to help out people they have only seen on a computer screen? Remote working is easier with people we have previously worked with physically, but such relationships may be the exception in the future.
  • Trust – How do we build trust that people are working when remote? How do we strike the balance about remote work monitoring tools and trusted, empowered teams? How do we overcome differences in laws and ethics on a world scale?
  • Economics – How do we fairly compensate team members based on their skills and contributions? How do we effectively price, tax, invoice, collect payments and pay contributors on projects that may only take days or hours to perform?

The building blocks of each solution are already available. Video conferencing with real time translation, peer based endorsement networks, community voting, and bitcoins all might play a role. However what about our project management tools? Where do Microsoft Project plans, PMBOK Guides and Stage Gates fit travelling at the speed of trust?

In a poetic twist of fate, just as Victorian classrooms were engineered to condition children to the discipline of working in textile factories, maybe the Instagram, Facebook and text messages of today’s school children will shape the workforce and workplace of our future. Using these tools and their replacements, virtual teams will be the norm, today’s CUTE problems will be overcome and a new era of work practices introduced. If the past is anything to go by these changes can happen quickly so we should keep our eyes and options open!

[Note: This article was written by Mike Griffiths and first appeared on ProjectManagement.com here]


Agility as an Enabler for Local Intelligence

Team intelligenceMuch has been written about agile processes, how they can better respond to changing requirements and be used to tune approaches over time through retrospectives and adaptation. While this is true, it masks the importance of human involvement. It is people that respond to change and teams who update and tune their processes. Agile methods give more freedom and autonomy for teams to do the right thing, but it is the team members that act intelligently to improve things.

Understanding this distinction that agile methods don’t directly help much, instead it is the actions of agile team members, allows us to better explain why some agile projects go well and others do not. Agile processes are an enabler for intelligent action, but not a guarantee of it. Teams that are asked to follow agile methods, but not motivated or equipped to improve the project environment will likely fail.

This is why we often see some agile project teams do very well and others struggling to produce results within the same organization. If you look at the processes both teams are following they look the same. They might both be doing daily stand up meetings, iteration planning sessions, backlog prioritization, demos to the business and retrospectives. However, these processes don’t ensure success; it is the local decision making that comes from them (which we observe in different ways) that lead to successful projects.

The concept of “Local intelligence” is described nicely by Malcolm Gladwell in his book “David and Goliath: Underdogs, Misfits, and the Art of Battling Giants”. Gladwell tells the story of Lawrence of Arabia, an archaeologist conscripted into the British Army in World War 1 who led the Arab revolt against the Turkish army occupying Arabia.

Lawrence’s goal was to destroy the long railroad being built to set up operations deep in the Hejaz desert. The odds were against him, the Turks had a modern army and Lawrence commanded an unruly band of Bedouin nomads who were not trained in combat. However they were mobile and self sufficient they travelled extraordinary distances, attacked quickly and were gone before major battles ensued.

Lawrence is best known for leading a daring attack on the port town of Aqaba. The Turks expected an attack to come from British ships offshore, but Lawrence attacked from the unprotected East desert during summer, leading his men on a 600 mile loop no one thought possible and to anyone but the Bedouin nomads likely fatal.

His success was attributed to a number of factors. First, as a historian and archaeologist he had little regard to traditional military order or standards and that helped with unconventional thinking. Second he made great use of the local intelligence of his men who were very self-reliant and skilled in dessert survival and travel to mobilize and do the right things to be successful.

This enablement of local intelligence is the key to agile success too. The agile process is only a framework, the real work happens in the discussions and decisions made by the team. I used to be concerned by how much time some teams spend talking about work compared to actually doing work until I saw a correlation with project success. The teams that spend lots of time discussing options, priorities and business requests were actually thinking and refining strategies to be more effective. They were using local intelligence to be more successful and it showed in their results.

When my current team stopped holding daily stand-up meetings I was a little concerned. I wondered if we were getting lazy. If the process was devolving and should I intervene? However I trusted they must have had the same thoughts and the frequent discussions both face-to-face and online for remote members negated the benefit in these daily updates. To them these meetings felt unnecessary and low value. So, stand-ups became three times a week then twice a week then more sporadic. We have not had a daily standup meeting for three months now and things are going great.

One practice we are doing extra is a weekly technical show-and-tell meeting so developers and QA’s get to see what people have been working on and ask more technical questions ahead of, and separate from, the bi-weekly business demonstration. I am not suggesting that agile teams drop daily stand-ups and adopt weekly technical reviews. For most agile teams the daily stand-up is core and critical for effective communications between team members.

Instead, my point is that success is more closely aligned with the application of local intelligence from the team members than adherence to agile process. What works for one team may not work for another. As leaders of agile teams we should not be looking for conformance to process but signs of effectiveness and the application of local intelligence. High levels of “productive work related discussion” appear a good sign.

By “productive work related discussion” I mean new discussions that cover fresh ground and solve issues, not Bill and Ted having the same argument about architecture X or tool Y. Ask if the discussions result in solutions, are they business results focused, and inclusive to all team members that want to participate? These are indicators that they are productive.

In addition to productive discussion, team led modification of process is another sign of local intelligence applied. The fact the team diagnosed, discussed and agreed on an amendment to regular working process is a good indicator that they are applying local knowledge. Alistair Cockburn’s Shu, Ha, Rei model, describes a progression from obeying the rules (Shu, which means to obey, or follow), consciously moving away from the rules (Ha, which means to break or change), and finally unconsciously finding an individual path (Rei, which means to separate, or release).

Organization adopting agile and teams using agile methods are encouraged to first “use it out of the box” i.e. without modification. Then, only when everyone understands why things are as they are might we want to change process. Many of the agile processes balance each other. Rigorous testing allows for light documentation for instance. Dropping one without addressing the other and you could be headed for trouble.

However, in my view agile processes are a default starting point for teams. They work well and cover all the basics. Yet if the team sees a problem, or an opportunity for improvement then we should not stop them trying to become better. Iterations provide short test cycles to try new approaches and revert back if they are not working or build on success if they are.

When leading teams look for and encourage high levels of engaged debate and productive discussion. Support team based process adaptations and change. They are both signs of an engaged team applying local intelligence to improve their ability to deliver. Agile methods should be enablers of change not strict frameworks to work within. Our goal is performance not conformance so we should provide support and encouragement accordingly.

When asked if my team is agile I answer “kind-of, “mostly” or “predominantly” depending on the formality of the question. However I don’t really care about the label, they are kicking butt and delivering a ton of high quality software the business loves, which is my real focus and measure of success. Methodology labels help shorten conversations about process but are of a lower importance than results, we should act accordingly and spend more time encouraging local intelligence - a critical key to success for today’s knowledge worker projects. 

(Note: This post was first written for ProjectManagement.com here)


20 Years of DSDM

20This post is a personal reflection. 2014 marks the 20th anniversary of DSDM (Dynamic Systems Development Method). Ten years ago, back in 2004 I wrote the article “DSDM 10 Years on, RAD Relic or Agile Advocate?”, on re-reading it 10 years later I think it still holds true. It can be found on page 49 of this Agile Times newsletter.

Just looking at the names of contributors to that newsletter (Ken Schwaber, Martin Fowler, Mike Cohn, Lisa Crispin, Ester Derby, Brain Marick, Kent McDonald, Dianna Larsen, J.B. Rainsberger, Barbara Roberts, Linda Rising, Deb Hartmann, etc) reminds me of some of the great people I have been fortunate to work with over the years. Also how lucky we were to have such excellent collaboration from these thought leaders in a single publication. Good luck trying to get them all to contribute to a single conference today let alone an unpaid newsletter!

Realizing I have been doing pretty much the same thing for the last 20 years stirs up a few emotions. First of all there seems a worrying lack of career progression. Today I am managing agile projects along with training, consulting and writing. Back then I was also managing agile projects and consulting. However, just to prove my career councillor wrong - who said I would never go far, I did move from England to Canada which by anyone’s standard is pretty far!

I have tried other roles; I have had several stints as a program manager, development director and in various PMO roles. However I have always gone back to project management. It is what I love and what interests me. I read, on average, two project management books a month and am not getting tired of them. In fact the stack of new books to read on my desk is growing faster than ever.

I just don’t feel the same enthusiasm for program management or PMO work, for me, it is a little too far removed from actually executing projects. It is the problem solving, stakeholder coordination, execution and sense of achievement from delivery that gives me a buzz and keeps me excited about work.

Over the last 20 years the methods that we now call Agile have matured and morphed enormously. The whole Agile Manifesto popularity explosion of the early 2000’s opened up a tide of mostly good awareness and opportunities. Yes, a bunch of people jumped on the band wagon without really understanding things and caused some harm, but the vast majority of growth and adoption that I have seen has been extremely positive.

All in all I feel very lucky, I get to work in a field I find extremely interesting. While many of my colleagues have created large agile consulting and training companies, they now don’t get as much hands on project work. Maybe I lack their entrepreneurial spirit, business drive or sales skills, maybe my career councillor was right, but I can honestly say I’d be really happy to do what I am doing now for the next 20 years. I have no exit strategy planned or dreams of escaping it all.

I graduated in 1986 when the Timbuk3 song “The Future is so bright I gotta wear shades” was popular. From that song the line “Fifty thou a year -- buys a lot of beer” may no longer be true, but It feels to me that agile concepts are just getting started and the future is so bright. Hence, maybe like a family doctor who practices for many years, learning more but still in the same role, I will appease my uneasy guilt of treading water with a justification that is OK and hope I get to continue for the next 20.


Agile Horrors

ZombieI know it is Christmas time not Halloween, but think of it as holiday re-gifting. Here is an article on agile horrors I wrote for ProjectManagement.com Halloween Edition that we should be on the lookout for on our projects in 2014.

Frankenstein Process – This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment. Perhaps created in an attempt to satisfy the desires of competing groups, but this half goose, half salmon abomination neither flies nor swims.

Agile practices are in a balanced network. Ruthless testing balances the need for comprehensive documentation; colocation, demos and daily stand ups reduce the need for detailed status reporting. Changes made to this web of practices can easily create risks, gaps and duplications if they are not carefully considered.

Think candy apples not pumpkin pie; hybrid methods work best when there is a core of agile for the team to own and execute, surrounded by a wrapper of more traditional process to buffer and integrate into a less agile aware environment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

Zombie Projects – some projects should just die but won’t seem to. Doomed from the outset with unrealistic deadlines, overly ambitious scope, or ill equipped skills and support; everybody knows it will not end well, but nobody seems willing or able to kill it.

These death marches to eventual failure or cancelation are damaging to the people working on them who see the futility and mismatch of progress to targets. However, like the emperor’s new clothes there is a shared acceptance that this is unlikely to work, but nobody seems to speak out. Perhaps thinking that the “higher ups” must know what they are doing and would intervene if there are problems; they continue shuffling forward like an army of undead looking for brains.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solution. More often if it looks, smells, and behaves like an undead zombie, it is one. Just like in the movies, it is best not to start shouting and bring attention to yourself if you are surrounded by zombies. Instead try to find an opportunity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching about the issues, usually others have reached the same conclusion and are looking for support to fix things.    

Vampire Scrum Masters and Project Managers – These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Agile teams generally work very hard to deliver as many high quality features as they can. When they report problems or ask permission to undertake maintenance work it is so they can be better equipped to deliver high quality features long into the future. Like ignoring a Check-Engine light in your car or missing regular maintenance, you might save some money in the short term but it is a false economy longer term.

Scrum Masters and project managers need to learn enough about their teams and their technical domain to distinguish genuine reports of problems and requests for investment from everyday complaints and unnecessary requests for resume boosting technology upgrades.

Teams who routinely get their requests ignored by leads that just want results without investment will correctly draw the conclusion that they are not valued. When this occurs, the motivation to try hard, delight customers and go the extra mile to overcome an obstacle is removed. The delivery of results will decline and then the whole process sucks.

So, show some interest, ask people to explain why issues and requests are important. If all the solutions are not possible ask them to prioritize. Try as hard as you can to fulfill these requests and usually the teams will reciprocate with improved effort and results.

Product Owner Ghosts – these are business representatives that are kind of there, but not really, they tend to vanish or dissolve when pressed on anything. Whether it is a tough decision on a product feature, or their attendance at a demo; product owner ghosts are unreliable.

The product owner / business representative role is integral to agile processes. They are needed to ensure requirements are understood, refined and prioritized, along with providing prototype feedback and resolving design decisions. Like missing or getting a poor developer or QA person, a project with a “hardly there” product owner will suffer tremendously.

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business involvement include:

C - Contrary – decisions flip-flop with no clear explanation

A - Absent – you cannot find them or get their time when needed

S - Switching – the person changes, no dedicated product owner is assigned

P - Passive – without prompting we would not hear from them for long periods

E - Elusive – they will not provide clear feedback on the suitability of a prototype

R - Reclusive – they withdraw from priority discussions and decisions

Instead try to staff projects with product owners who exhibit more solid, proactive business representations.

C – Collaborative – willing to discuss and evaluate alternative solutions

O – Owners – owning the backlog of work, taking reasonability for its grooming

N – Nearby – available when required to ask questions and get clarifications

C – Committed – having the same person or people throughout the project

R – Representative – representing the group we are building for, not personal goals

E – Expert – knowledgeable about the domain at hand to answer team questions

T – Traceable – contactable when needed or with a proxy available if away

E – Experienced – experienced in the field to warn of outliers and exceptions

(I prefer these attributes over Barry Boehm's CRACK mnemonic that does not emphasize the Nearby, Experienced and Expert qualities that can really save teams time.)

Getting the best users is always difficult since the best people are busy doing real work. Try to explain the costs and risks of building the wrong or a sub-optimal solution. Offer to back fill admin work from the project for the best people even just to free up some of their time each week for input and feedback.

Summary

Hopefully this light hearted view of some agile anti-patterns in the guise of Halloween ghouls reminds us of things to be on the lookout for. Unlike Halloween these problems are year round threats. More than just something that goes bump in the night, these problems are ever present in our lights-on projects. Look out for them and use your garlic and silver bullet awareness to keep them from impacting your projects.

 


Agile Requirements Uncertainty

Requirements
<I wrote this article first for ProjectManagement.com here as part of their Requirements series>

Agile approaches are often used on projects where the end goals are not fully known or may change during the life of the project. This seems unusual to my engineering PM friends who manage the fabrication of facilities. To them, not knowing what it is you are supposed to be building or letting things change along the way is a sign of poor scope definition, requirements gathering, and change control. I hear quips from them along the lines of: “You guys need some rigor and decent specifications, maybe then you could build IT systems that work and don’t go over budget!”

They are right of course, for their domain of defined repeatable projects; first establishing a well formed scope definition and complete specification is the way to go. However, many IT projects are not defined, repeatable endeavors, but instead design explorations into unchartered territory for that organization. The mix of technology has not been used that way before. Sponsors have a vision of the end state, but not a lot of specific detail. No matter how much upfront work is done there seems a host of unknown issues that surface during the journey to the destination. Build/ feedback cycles with adaptive plans and progressive elaboration of requirements is the way to deal with these inevitable uncertainties.

These intangible, unprecedented, emergent, evolving characteristics of IT projects are difficult to explain, but need to be understood. They impact how we plan and execute today’s knowledge worker projects as well as how we should manage requirements. When the specifications are clear such as “A kitchen reno with new counter tops and appliances” then simple, signed off requirements can work well. Yet when things are more vague such as “A winter vacation to someplace warm” remaining flexible to changes and new ideas can be valuable.

Let’s look at some of the differences between plan driven, traditional practices for requirements management and those used in agile methods:

Requirements table

Learning and applying traditional methods of requirements management is easy, it is akin to a shopping list approach. We ask questions like “Did you get milk?”, “Did you get the bread?”, “What else do we need?” Changes may be declined or accommodated. “Billy wants some chocolate!” too bad, tell him he can’t have any, or “Oh, I remember we need light bulbs!” We can then ask do we have enough money for light bulbs, do we have time to go find them, etc. It is all pretty much second nature.

Agile requirements management on the other hand is less intuitive. The constant reprioritization, comparison of new ideas with remaining features, and focus on business value has more balls in the air. Like packing a backpack for a multi day camping trip we are always weighing up the benefit verses the size / weight penalty of bringing something along while keeping an eye on an ever changing weather forecast. There is more re-evaluation, more substitutions, more “Do you really need it?” type questions.

Traditional requirements management has a more satisfying progression of closure – Feature A is in the signed off spec, so we are doing it! This is like saying it was on the shopping list so we will buy it. The fact that it may then sit in a cupboard and never be used is a separate discussion. Agile requirements management lacks this reassuring closure since all remaining items are up for reprioritization or substitution until the completion of the project. Our shopping list is being changed as we walk around the store and that makes some people uncomfortable. However, fewer items should go unused.

In the end it comes down to trading off certainty against flexibility and value optimization within your purchasing decision. If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs.


Mike Griffiths Receives “PMI-SAC Fellow” Award

Fellowship AwardOn November 12, 2013 Mike was presented with a PMI-SAC Fellow award at the PMI-SAC Awards Gala. The Fellow Award recognizes and honours members who have made sustained and significant contributions to the project management profession and the Institute for more than a decade.

Mike was recognized for his work developing agile project management techniques and promoting agile project management including:

Mike is very grateful to receive this award and hopes to be active in the next 10 years of project management promotion and development.


Overdue Update and Designing the Pontiac Aztek

PDCI 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 “21st 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.


9 Ways PMOs Can Help Agile Projects

Agile PMOIt 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)

Next PMI-ACP Exam Prep Class with Mike Griffiths

PMI-ACP Prep BookMy 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 9th 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 Training@LeadingAnswers.com.