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.
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)
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.
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
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.
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:
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)