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)
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.
What would you add to this list?