“When Will This Software Project Ever Be Done?”

NoProjects imageDoes this question sound familiar? If you get asked it regularly then you may be part of the mainstream transformation from software projects to products. It’s coming and it's going to turn many roles, certifications and in some cases entire companies on their heads.


The last couple of software projects I worked on were large, multi-year endeavors to build in-house systems that add competitive advantage for the sponsoring business group. It did not take multiple years to build the initial product, instead after delivery the business wanted more functionality, more integration, more automation.

The “When will you be done?” issue

The success and reliance on the new system bred further investment. The fact that business sponsors wanted to continue development was a good endorsement for the value being delivered. Yet there was a conflict at the steering committee level and PMO level. “When are you people going to be finished?” was the common question.

Answers like “never” or “when the business unit stops innovating and enters a decay phase” are generally not acceptable. Things are made worse by the teams being staffed, in large part, by expensive contractors. To the CFO or VP who does not use or see the benefits the system delivers these successful in-house products seem like make-work exercises or country-clubs for development teams that have become all too familiar with the business units they are embedded in.

This is not a problem, this is the future

However, we are not witnessing a problem, we are witnessing the future. Software is becoming more critical to business and projects are ending (or will never end) as we take more of a product vs project view of software.

Software More Critical

I recently attended a keynote from Sue Gardner, she was the executive director for WikiPedia as it rapidly grew from 8 to 200 engineers. She explained how Silicon Valley is a leading indicator or canary-in-the-coal-mine for the future of many businesses. It has been at the forefront of a shift that is transforming many companies. The shift is the significance of software as a market disrupter. As she recounted: “Software is eating the world” and examples include:

  • Amazon disrupting book sales and now other retail
  • WikiPedia disrupting reference books
  • Uber disrupting taxis
  • Airbnb disrupting hotels

The common factor with these disrupters is a reliance on software for competitive advantage and the change is only going to speed up, not slow down. Software is becoming more critical to an organization’s success and software developers who were once regarded as support staff are now critical and core staff.  So, company’s need to figure out how to engage, hire, retain and focus these suddenly more central roles.

No More Projects

The hashtag #NoProjects is a shorthand title for a movement that thinks the construct of a project with a defined beginning, middle and end is harmful to software product development. Instead, proponents like Allan Kelly see software development as a continuous commitment to growing the business, believing it should not end and working for it to end is destructive.

Kellys states: “Software that is useful grows and evolves. That fact that the business wants changes and new features is a sign they actually value it. Stop it’s evolution and it stops being relevant, valuable and a market differentiator. “

However, attempts to manage executive’s expectations about ongoing expenditure and to “finish” projects, create real problems for the ongoing development and health of the system. With the companies I was involved at, our attempts to “draw a line under this release” or “change the project name for next year” worked at best once or twice, but inevitably ended up in a formal project closure and loss of key people.

This is a big topic that has many impacts and I plan on writing a number of articles on the topic. I have added a new blog Category “NoProjects” on my www.LeadingAnswers.com web site so you can quickly filter articles and find them.

Upcoming articles include:

  • Realizing you are part of the problem and deciding to help fix it – Having pushed hard for project closures myself despite knowing the business need continues, how do we create a better system? The NoProjects movement have some good initial ideas about portfolio tools for managing ongoing teams but they seem to lack sophistication and scaling guidelines. Many of these challenges have been solved in the service industry and I think I can help.
  • Helping organizations transition to NoProjects – Often when organizations realize their software development need will not go away they react by outsourcing it. Not wanting to be in the software development business long term they see it as the responsible decision. However, you likely only ever built a successful software product because of the close collaboration between your business group and the software team. Breaking this up and losing the intellectual capital developed is not smart. In addition, inserting new obstacles to communication (remote teams, new roles, new contracts) only hinders the process.
  • The role of a Project Manager in a NoProjects Future – First the term “Manager” came under attack for denoting top-down, command-and-control style of task assignment instead of the servant leader, facilitator role really needed for knowledge worker projects. Now we are doing away with the “Project” part too. What does the future look like for product leaders and facilitators?

The Business Analyst and the Product Owner

BA and PO rolesIn my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of the BA varies and overlaps with the Product Owner (PO). We cover the similarities and differences including danger signs such as “BA as PO Go-Between” and positive patterns such as “BA as PO Supporter”.


The Product Owner (PO)

First, let’s make sure we understand the role of the Product Owner (PO). It originated in Scrum but is often also used beyond Scrum in other agile approaches and hybrid approaches. The Scrum definition of the role is the person responsible for maximizing the value of the product and the work of the development team. This includes being responsible for managing the Product Backlog. Extreme Programming (XP) has a similar “Customer” role, DSDM has one or more “Business Ambassadors” depending on the scale of the project. They all play a similar role in stewardship of the backlog, including:


  • Ensuring that the product backlog is visible, transparent, and clear to all, showing what the team will work on next
  • Ensuring the team understands items in the product backlog to the level needed
  • Clearly expressing the product backlog items
  • Ordering the items in the product backlog to best achieve goals and outcomes
  • Optimizing the value of the work the team performs


Benefits Beyond Backlog Management

In addition to this backlog focused work, the Product Owner is often the primary interface to other business stakeholders. They help teams gain access to business subject matter experts for insights on topics where the Product Owner may not have all the answers. They also often act as a gateway to funding, making the business case for additional funding requests, or as a powerful ally when asking for roadblocks to be removed. Playing the “Business is asking for X” card is typically stronger than the “Team is asking for X” card when asking for an exemption from process, or to expedite an issue.


Continue reading "The Business Analyst and the Product Owner" »

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 isa 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.


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" »