Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

What's blocking your benefits realization?

Is your project information system of record the grapevine?

What's in YOUR sprint backlog?

Lessons in agility from wine tasting…

Control partners should have skin in the game!

Lessons in agility from wine tasting…

One of the benefits of living in the Greater Toronto Area is being less than an hour away from a large number of good wineries in the Niagara region. After visiting many wineries over 2018, I have come to the conclusion that wine tasting and agile have more in common than you might think.

It helps to have a guide

You could certainly partake in a flight of wine with friends without the benefit of a sommelier, but you won’t enjoy the experience as much and you might learn some bad habits such as not giving your wine a chance to breathe or drinking without sniffing the bouquet. Similarly a coach can help steer a team past anti-patterns so that they have a chance to appreciate what agility truly is.

Start small and grow from there

For novices, visiting more than one winery in a day could be a recipe for disaster. Without having developed the discipline to pace themselves they run the risk of getting tipsy too quickly and might get turned off by the experience. Starting with a large project is inadvisable for novice teams – they won’t possess the discipline to scale their behavior and practices and might blame agile rather than their immaturity.

There is no one right way

While there are good principles for enjoying wine, don’t let anyone try to convince you that you must follow pairing guidelines. While a robust red wine might be a good match for a meat dish, if you enjoy its flavour there is no reason you can’t have it with any other type of cuisine or even on its own. User stories are a good approach to starting a conversation about functional requirements, but don’t be bullied by agile wannabes who insist that all requirements must be captured as stories. Like with any practice, context and culture count.

Teams doing agile might make you want to drink but I prefer to have the perspective of the (wine) glass being half-full.

(Note: this article was originally decanted in June 2017 on kbondale.wordpress.com)

Posted on: January 09, 2019 08:21 AM | Permalink | Comments (15)

Is increasing agility a recurring New Year's resolution?

Categories: Agile, Change Management

As we kickoff the final week of 2018, many of us will be making New Year's resolutions. While some of these resolutions might relate to achieving a specific goal or objective (e.g. I resolve to run a marathon this year), most relate to changing our behavior (e.g. I resolve to eat healthier this year).

But for many of us it becomes a case of déjà vu as we end up making the same resolutions we had confidently made in previous years.

Increasing organizational agility is a journey and not a one time goal.

Similar to New Year's resolutions, some delivery teams initiate plans to become agile only to revert to long ingrained habits when things get tough. It might not be on an annual basis, but companies which have struggled with agile transformations once will often try again and many will experience more than one failed attempt.

When it comes to personal resolutions and being able to stick to them the American Psychological Association's website provides some good advice which could be applied to agile transformations.

Start small

It might be tempting to pick the very largest product or project when starting an agile transformation to surface many key organization blockers and to glean some valuable lessons. However, the very visible impacts of potential failure as well as the higher volume of stakeholders whose behavior will need to change makes this extremely risky. Just as a casual runner shouldn't try to run a marathon in their very first month, starting with too ambitious a set of pilot initiatives is usually a recipe for disaster.

Change one behavior at a time

There are multiple behaviors which leaders and team members might need to modify and trying to change all of those at one time is like a golfer who tries to keep multiple swing thoughts in their head when addressing the ball. Usually they will end up with a worse swing than if they had just cleared their mind of all thoughts! A transformation team should identify which behavior change might result in the biggest impact and that should become the focus of coaching and peer support.

Talk about it

To succeed with any significant organizational change we need to over-communicate. The more we can talk with stakeholders about our target operating model, the challenges we will face to get there, and the small wins we are achieving, the more we will remain committed to the journey.

Don't beat yourself up

No agile transformation is going to go smoothly. Some initiatives might turn out worse than if a traditional approach had been used. Some staff will leave the organization. As the APA website states "Perfection is unattainable". But as long as we have support mechanisms in place and a desire to get better, we can bounce back from such setbacks which are usually minor when viewed from the perspective of an end-to-end transformation timeline.

Ask for support

Every organization has a unique culture, but it can be easier to stick to an increased agility resolution when you have support from those who have been there and done that. The value of external support comes from the breadth and depth of experience to know which patterns of behavior or practice are likely to lead to success and which won't.

Adapting the quote from Dr. Lynn Bufka "Remember, it is not the extent of the change that matters, but rather the act of recognizing that lifestyle behavior change is important and working toward it, one step at a time."

Posted on: December 23, 2018 07:00 AM | Permalink | Comments (6)

Improving organizational culture through retrospective recognition

After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.

The Scrum Guide doesn't specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.

Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.

Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?

Just as with providing constructive feedback, we shouldn't wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.

A recent Washington Post article described how kindness can be contagious.

Anyone who has participated in or initiated a "pay it forward" chain would likely agree with the article's author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.

Posted on: November 25, 2018 07:00 AM | Permalink | Comments (9)

Change requests should be read like tea leaves to help future projects!

Change requests are similar to many project management artifacts in that significant effort is spent over the lifetime of a project in creating them and getting them approved, but they are rarely looked at once a project is over.

This is a shame, since while the primary purpose of a change request is to formalize changes to one or more of a project’s approved constraints or baselines,  they can also be a valuable source of knowledge beyond the lifetime of the project.

Some examples of these benefits include:

  • During the final harvest of lessons to be learned at project closeout, change requests could be reviewed to identify change triggers that could have been avoided due to better planning, requirements gathering or stakeholder participation.
  • They provide a source of knowledge for the impact analysis or effort estimation on risks, issues and changes for future projects.  While their usage cannot be a substitute for knowledgeable subject matter experts, they can act as a reasonable substitute if these SMEs are not available in a timely fashion.
  • When change requests are reviewed across a portfolio of projects at regular intervals, they can help to identify chronic or systemic issues.  For example, if the majority of change requests are not scope related, but are instead being used to formally approve delays to project end dates, analysis could be done to determine whether there is a common cause for these delays such as poor resource capacity planning, ineffective work intake or prioritization, or overly optimistic effort estimation.
  • They can be used by project managers who are new to the organization to understand how projects are “really” managed as well as to help gain insights into the attitudes or personalities of specific sponsors.

Change requests are the rats of the project management world – we usually go out of our way to avoid them, but just as rats are a critical input into development of future lifesaving drugs, change requests can be used to improve the delivery of future projects!

(Note: No change requests were harmed in the original publication of this article in January 2013 on kbondale.wordpress.com)

Posted on: November 21, 2018 06:59 AM | Permalink | Comments (16)

What are the tipping points for your agile transformation?

Categories: Agile, Change Management

I've frequently said that agile transformations are marathons and not sprints. But when someone runs a marathon there are mile markers to understand how far they've come and to help them get their second (or third or fourth) wind.

While there is no single model for how a company will progress through its agile transformation, it is a good idea for transformation teams to proactively identify tipping points where previously unique outcomes or behaviors have become commonplace. While such milestones won't help them forecast how much longer it might take to reach their ultimate goals, it can provide a leadership team with proof that things are continuing to move in the right direction. Such evidence is critical if there is to be sustained commitment and investment in the transformation.

This list is not exhaustive nor is it in chronological order. Depending on what the starting point is for the organization and where the transformation team chooses to focus their efforts, there may be additional milestones and the sequence of when those are accomplished will vary.

  • Team social pressure encourages appropriate agile behaviors without the need for sustained external coaching
  • Delivery frequency matches stakeholders' change appetite
  • Zero defects
  • Empowered Product Owners with sufficient capacity, capability, knowledge and influence
  • Team allocation shifts from maximizing utilization to maximizing value delivered
  • You don't hear team members say "the business" anymore (we are all "the business"!)
  • Pivots in product or solution direction are praised, not punished
  • Teams provide accurate and current updates to information radiators and stakeholders effectively pull information from those radiators
  • There is NO one size fits all for ceremonies, practices or tool
  • Overtime and weekend work is the exception not the rule
  • Hiring practices and performance measurement systems emphasize the "how" as much as the "what"

What would you add to this list?

Posted on: November 04, 2018 07:00 AM | Permalink | Comments (10)
ADVERTISEMENTS

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events