Easy in theory, difficult in practice

I was asked to facilitate a lessons learned session for a program team using a retrospective format. After the team had brainstormed, prioritized and discussed most of the challenges they had faced, it became clear to them that there were only a couple of root causes for most of the main pain points they had identified. Neither of those root causes was a true learning but rather they were just simple reminders of good practices to follow for large, complex programs. I then asked them the somewhat rhetorical question: "Remembering now what should have been done then, how will you ensure that this doesn't happen on a future program?"

A project team I've been working with has struggled with judging how many work items they can successfully complete within a sprint. In the retrospective for their last sprint, they identified a number of simple, effective ideas for resolving this chronic concern. Again, I challenged them with the same question: "You've come up with a great list of ideas, but how will you ensure that you actually act on those the next time you are sprint planning?"

Both of these experiences reminded me of how difficult it is to break habits.

In his book The Power of Habit, Charles Duhigg has written about the three part neurological loop governing habits which was discovered by MIT researchers: a cue, a routine and a reward.

In the project team's case, the routine has been to accept more work items than they can complete in a sprint even when historical evidence shows this tactic hasn't worked out well. The cue is that moment in the sprint planning ceremony when the team makes their sprint forecast. It's hard to say what the reward has been but perhaps it's the temporary high which comes when we take on a significant challenge as a team.

To break habits, we need to find a way to substitute a different routine for the old one and soliciting the help of a close, trusted colleague might be one way to do this.

The team could designate a single individual to come to the sprint planning ceremony with a stuffed pig or some other visual gag which represents gluttony. Then, when the team is about to forecast how much they will accept in the sprint, that team member could hold up the pig and say "Oink! Oink!" to remind all of them to be a little more conservative. While the team might not bask in the short term glow of having accepted a bloated sprint forecast, they will enjoy the much more rewarding experience during their sprint review when the product owner and other stakeholders congratulate them for improving their predictability.

Breaking habits is hard to do but by identifying cues and implementing good routines to swap in for the old ones, we can prevail.

Most organizations regardless of their size or project management maturity will initiate a proverbial “800-pound gorilla” project at least once.  Mega-projects can torpedo a company, but they are often critical to their long term sustainability or strategy.  For the “lucky” program or project manager that is asked to manage one of these, it can either be a career-limiting death spiral or a priceless differentiator for their portfolios.

Failing to plan is planning to fail – this is the mantra of mega-projects.  Organizations that were historically able to successfully complete small to mid-sized projects in spite of themselves will discover that heroics that worked in the past will not work on a mega-project.

To plagiarize Jeff Foxworthy, here are some ways of identifying mega-projects:

• If the project schedule is longer than 100 tasks at outline level 2, it may be a mega-project.
• If the project budget exceeds the GDP of most small nations, it may be a mega-project.
• If you are thinking of submitting your project profile to the committee that administers the Seven Wonders of the Modern World list, it may be a mega-project.
• If your project is mentioned in the annual reports or quarterly results calls of your primary vendors, it may be a mega-project.
• If your will lists your project control book as the main part of your estate, it may be a mega-project.

What are a few ways of coping once you’ve identified the fact that you are the proud owner of an 800-pound gorilla?

1. Tackle it one piece at a time – a phased or iterative approach to mega-projects is one way to avoid “big bang” change nightmares.
2. Address big risks early – a disciplined, consistent approach to risk management is crucial, and once key risks have been identified try to address them as early as possible to help increase the predictability of future deliverables.  Use a pilot or prototyping approach to validate approaches – fail small but fail fast.
3. Use (multiple) independent estimates – it’s doubtful that anyone on the project team will be able to provide accurate estimates for the full scope of work.  There are simply too many variables to deal with, so you’ll probably have better odds of winning a lottery than of coming up with a good estimate.  Given this, derive  independent estimates – commercial estimation tools might be an option.
4. The journey is the reward – slogging through a mega-project with no end in sight, and few wins along the journey impacts team morale and productivity as well as  increasing the likelihood of failure.  Use agile techniques to structure the project to deliver “wins” throughout the lifecycle, and celebrate these wins as they occur.
5. Find mentors – Whether it is helping you assess options for a decision or validating your perception of a situation, a mentor can help you or other key project participants avoid tunnel vision.

Tackling a mega-project can sometimes feel overwhelming, but remember that even King Kong was laid low by a combination of fighter planes and gravity!

(Note: Neither King Kong nor Donkey Kong was involved in the publishing of this article back in November 2010 on kbondale.wordpress.com)

In last week's article, I wrote about the benefits of having a Definition of Ready for agile ceremonies as one method of ensuring that they are adding value and not being perceived as just more wasteful meetings.

But how do we know that we achieved what we were hoping to from the ceremonies? A Product Owner might walk out of a sprint planning session feeling happy that the team will be delivering a major feature but some team members might feel that they have accepted more product backlog items than can be completed in a quality manner while working reasonable hours.

The Scrum Guide encourages Scrum Teams to create a definition for what "Done" means for product backlog items and for product increments. This ensures consistency in understanding across all stakeholders and ensures that expectations have been met. The same approach could be utilized to ensure that teams aren't just going through agile ceremony motions.

Here are a few examples of "Doneness" questions for the same ceremonies I had written about in last week's article.

Sprint Planning

• Have one or a few key goals for the sprint been articulated by the Product Owner?
• Does the entire team understand why the goals are important and how they connect back to the product vision or roadmap?
• Has the Product Owner collaborated with key solution ("How") stakeholders such that product quality and technical debt were considered when populating the sprint backlog?
• Has each team member assessed their available capacity and used that knowledge when contributing to the team's sprint commitment?
• Does each team member have a "sufficient" understanding of the sprint backlog items to feel confident in the team's sizing of those items?
• Has the team reviewed the top ideas from the previous retrospective, shared them with the Product Owner and agreed to act on those in the current sprint?

Scrum/Daily Standup

• Does each team member feel the team is aligned to doing the highest priority work in support of the sprint and product release goals?
• Does each team member have a general understanding of what everyone else is working on and the dependencies between each other's work?
• Have all potential and realized impediments for the day's work been surfaced and either addressed or have an owner identified to address them after the standup?

Sprint Review

• Do the invited stakeholders understand what was completed in the previous sprint?
• Has feedback been received on all completed product backlog items?
• Have any new requirements or ideas raised during the ceremony been added to the product backlog or at least captured by the Product Owner?
• Has the team been given a chance to share their thoughts on the previous sprint?

Sprint Retrospective

• Did every team member get a chance to contribute to the discussion and did they?
• Have some improvement ideas been identified and is there a plan in place to act on those, ideally in the upcoming sprint?
• Did the team assess not just "what" they did, but "how" they did it?
• Did every team member feel it was a safe environment to share their thoughts?

Similar to a normal Definition of Done, there is no single set of guidelines which should be adopted by all teams and these guidelines may evolve over time as the team inspects and adapts their ways of working. But, as usual, caveat agilist: Focus on the outcomes, not the processes.

"If you spend too much time thinking about a thing, you'll never get it done." - Bruce Lee

When I first started to manage projects, I had envisioned the role as being similar to that of an orchestra conductor – while not being directly responsible for playing specific instruments, possessing familiarity with the strengths and weaknesses of each, and being instrumental (pun intended) in creating harmonious melodies instead of raucous cacophonies.

This illusion rapidly dissipated after a few days on the job.  I came to realize that project managers need to be like Lon Chaney – the man of a thousand faces.  Here are a few of the roles that a PM might be called on to play in a typical project.

1. Salesperson – Successful PMs need to be able to create a need for and “sell” their customers, stakeholders and team members on decisions or recommendations that may not be popular.

2. Football lineman – A PM must often be the offensive lineman preventing their “quarterbacks” (a.k.a. team members)  from getting tackled by distractions.

3. Coach – Vince Lombardi nailed the essence of effective project management with his quote “Coaches who can outline plays on a black board are a dime a dozen. The ones who win get inside their player and motivate.”

4. Diplomat – PMs are often called upon to help resolve conflicts, negotiate for win-win outcomes and to deliver bad news in a constructive fashion.

5. Historian – PMs should be able to review the past life of their projects, analyze events and derive lessons that can be applicable to future projects.

6. Diagnostician – PMs require the analytical ability and perspective to look beyond symptoms to help identify the root issues that are plaguing their projects.

My guess is that there are probably a hundred other roles that could be part of this list – how many can you add?

(Note: I was wearing my blogger hat in November 2010 when this article was originally published on kbondale.wordpress.com)

A Definition of Ready (DoR) is an agreement established by some agile teams to help them assess if a given product backlog item can safely be accepted by the team to be worked on. It is not expected to be used as a gate but rather as guidance.

I frequently hear from teams who are frustrated with one or more of their ceremonies. There can be many reasons for such perceptions but some times the root cause relates more to what wasn't completed in advance rather than what actually transpired during the ceremony. This made me realize that there could be some benefit in inviting such teams to come up with a DoR for their agile ceremonies.

Depending on the method or framework you follow there are likely to be different events, so I will focus on the standard ceremonies as defined within the Scrum Guide.

Sprint Planning

• Has the product backlog been refined recently?
• Is there shared understanding between the product owner and team as to what the items at the top of the product backlog mean and why those are important?
• If the team has established a backlog work item DoR, do the items near the top of the backlog satisfy the essence of that DoR?
• Has the product owner determined what they would like to achieve within the next sprint?
• If the team came up with some improvement ideas in the previous sprint retrospective which they would like to implement right away, have they sized the level of effort needed?
• Has each team member assessed whether there are any activities outside of product delivery work which will consume their capacity over the upcoming sprint?
• Is the product owner and whole team present, in body AND in mind?

Scrum/Daily Standup

• Are information radiators (e.g. work boards, burn down charts) up to date?
• Has each team member spent some time thinking about the upcoming day to identify potential and realized impediments?
• Is the whole team present, in body AND in mind?

Sprint Review

• Does each work item which the team intends to review satisfy the essence of their DoD?
• Has a dry run been done before the review to ensure that what was working before is still working now?
• Have the "right" stakeholders been invited and confirmed that they can attend the review?
• Has the product owner defined the order in which the completed work items will be reviewed?
• Has the team decided how the work item reviews will be done (e.g. one team member demonstrates everything)?

Sprint Retrospective

• Has the team had sufficient time after the sprint review to gather their thoughts?
• Is the whole team present, in body AND in mind?
• Are information radiators (e.g. burn down charts) up to date?
• Has the Scrum Master or whoever will be facilitating the retrospective identified a theme or recipe for the retrospective?

Like all DoR's or Definitions of Done (DoD), the list above is only intended to generate ideas for your team and not to be adopted "as is" as context counts.

"The beginning is the most important part of the work." - Plato