Information radiators are a great idea.
After all, who wouldn't want to reduce the effort involved in keeping stakeholders up-to-date about a product or project or increase the consistency in messaging to all stakeholders?
But convincing executives to use information radiators as a primary means of staying current is not an easy task. Yes, there might be a few early adopters who are open to trying a different way but most are likely to prefer to receive these updates the way they've always got them through one-on-one or steering committee meetings using status reports. So project managers or Product Owners spend time harvesting and curating information from the radiators into traditional status reports or presentation decks.
This introduces a few challenges:
So how can we help executives through the transition to using information radiators?
Start with why - if they don't understand how traditional reporting approaches hurt them, they are unlikely to have any sense of urgency about adopting a different approach. Whether it is reducing delivery costs or improving the quality of information presented, find out what concerns them and use that as a lever for change.
Second, you will want to ensure that the information radiators being published are relevant to senior stakeholders. Taking the time to understand what they need to support their decision making should help in creating dashboards which they will actually want to use.
Finally, rather than asking them to make the significant leap from a meeting-based approach to a self-service model, consider continuing the meetings, but use information radiators as the supporting materials for the discussions in place of traditional presentation decks. This should spark your stakeholders' curiosity as they are likely to ask questions based on their interpretation of the information published which will provide you with an opportunity to provide live "color commentary" about the project or product's status.
If you want management to change, you need to apply effective change management.
While teaching a class earlier this week, a learner asked how will team members start to feel psychologically safe, especially if they are working in a company whose culture isn't fully supportive of this critical ingredient to a high performing team.
Updating existing corporate values, and senior and middle management leaders holding themselves and each other accountable to modeling behaviors consistent with these refreshed values helps as does coaching at all levels of the organization. For individual team members, the Scrum values can provide good reminders of our own responsibilities for creating a psychologically safe working environment regardless of which delivery framework or method we are using.
Commitment: While we normally think of this value in terms of committing to achieving team goals, this value can also be considered as a shared commitment to creating a safe environment.
Courage: The Scrum Guide encourages team members to show the courage to do the right thing and work on tough problems. This is equally applicable to interpersonal relations. It takes significant courage to speak up when you witness behavior which is corrosive to psychological safety especially when the person misbehaving is more senior than you are.
Focus: While team members should be focused on completing work, living this value also means that we are focused and actively listening when we are part of a discussion or ceremony. By doing that, we are better able to pick up on the tone and body language of others to understand if they are feeling uncomfortable about what has just been said or look like they want to say something but just need that little bit of encouragement to speak up.
Openness: Just as we expect our teams to be transparent about the blockers they are facing, the same level of openness should be exhibited during retrospectives or other opportunities for inspection and adaptation with regards to how we interacted with one another.
Respect: Demonstrating this value towards our team members means not only treating them with respect but challenging others who would show them disrespect.
Edmund Burke - "The only thing necessary for the triumph of evil is for good men to do nothing.”
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