Resist the urge to monitor status in meetings too frequently

It was another ‘high stakes’ project. Those types of projects where it felt like, talking to the stakeholders, that the entire future of the company rested on the success of this one project. The work was anything but simple, involving multiple teams and a complex system. Everytime the team meet, more requirements were identified. Leadership became increasingly concerned with status. They joined the team’s daily standups, but a morning update was not enough for leadership, who introduced a second standup at the end of the day to gather additional status updates and remove impediments.

Unfortunately, I see patterns emerge like this all too often. A project is not progressing according to some plan or arbitrary expectations, so leadership increases the frequency of check- ins. This brings to my mind a quote from the Sci-Fi Cartoon Futurama:

“No fair! You changed the outcome by measuring it.” - Futurama

I term this the ‘Quantum Meeting’. In Quantum Mechanics, the state of a quantum system can be changed just by measuring it. The Observer Effect is an interesting challenge in Quantum Mechanics. “The Observer Effect implies the very act of measuring a quantum system by observation can alter its behavior.”

This sounds a lot like what occurs in our own quantum meetings with a team and leadership ‘observing’. A team under observation by leadership in a meeting will inherently alter their behavior. The extent of the alteration will depend on a number of factors, such as the psychological safety of the team, their relationship with leadership, the leaders themselves, and the personalities of the team members.

At times, additional meetings are needed as the team rapidly learns, encounters impediments, and needs to stay aligned as a team. Leadership may be able to assist in removing impediments, but remember, leadership’s mere presence in observing the team alters its behavior. Be careful to apply the quantum meeting and carefully consider if the negative consequences of altering the behavior are outweighed by the benefits.

A roadmap provides a visual statement of where we are taking a product and a backlog gets us there

Agile development spends a considerable effort on defining a backlog, but spends little time on roadmaps. This can give the impression that a roadmap is outside of the agile software development lifecycle. But that’s far from reality. A good roadmap sets the vision of a product and a backlog is the actionable expression of work for a team to undertake to achieve the vision.

In the ideal flow, a roadmap is created, the backlog is populated, development starts, and features are delivered. The each step builds upon the previous step. In the flow of work, we rely on work to be broken down, taking the roadmap and building out a backlog.

Building a roadmap and building a backlog require two different sets of skills and more importantly, different decisions to be made. A roadmap is typically crafted in conjunction with stakeholders and product/engineering leadership. It requires an understanding of the market the product and business operates within and deciding what opportunities to pursue. Most roadmaps also include a sense or indication of time, and thus require an estimate on effort, either well informed by consulting the engineering teams by analyzing the ask and crafting an estimate based on the understanding. Or, lacking the time or effort, a random guess is applied and the roadmap is adjusted later.

Building a backlog, by contrast, requires understanding the problem to be solved and enough details of the solution to sequence work and identify dependencies. It’s a collaboration between product and engineering, requiring both parties to contribute, on one side the problem and the constraints around the potential solution, and on the other side a solution that is actionable and solves the given problem.

Product team members are more heavily involved in upfront activities and transition the knowledge and activities to the engineering team members. Roadmapping is largely a product activity with some engineering consultation. Crafting the backlog is a joint exercise between product and engineering. Development then is a largely engineering effort with some product consultation. Release and support is largely an engineering function with some product consultation as needed.

Delivery can happen without a roadmap, but it cannot happen without a backlog. Without the collaboration between product and engineering to explore problems and craft solutions, the development team cannot plan yet alone build a solution for the business or customer.

That’s not to say that a roadmap is completely useless. A roadmap sets the vision for where we are taking a product. This gives the development teams a sense of purpose and direction. It also aids in the solutioning of current work, giving an indication of how the teams may have to evolve the system in the future.

The key audience for a Roadmap however is the stakeholders. Stakeholders responsible for budgeting decisions. Stakeholders who set organicational direction. Stakeholders who must make marketing plans, training documents, and staffing decisions. A roadmap is a sales pitch and a communication device, meant largely for the broader organization to consume. In many cases, its necessary to receive funding or justify continued investment in a product.

Roadmaps and backlogs are intricately linked. A roadmap sets the visuion while a backlog organizes the desired roadmap into an executable plan. While it’s rare that a backlog could exist without a roadmap, a roadmap cannot be realised without a backlog. Both are necessary for a well-functioning and evolving product.

Striking the right balance takes skill and patience

Conventional Leadership wisdom states that one shouldn’t care what people think of them. “You can’t please all people”, nor should you try. When leading, one must focus on providing a direction, lead the way there, and manage the team on the journey.

This doesn’t mean a leader should be reckless in how they treat their people. If you treat your team poorly, they will leave, stop following you, or become demotivated and accomplish less. A better way to state the conventional wisdom is that you should care about your team’s general sentiment, but you shouldn’t care how individuals feel about you.

As a leader, your job isn’t to make people like you. Together, we have to get a mission to accomplish. In software development, that’s the delivery of software updates to provide value to the business and the customer.

Agile leaders find themselves in a predicament. Agile leaders, especially one asked to work permanently with a team in a specific capacity, such as a Scrum Master or Release Train Engineer, lead largely with influence. In order to influence others, one must have a relationship in which one has earned a certain level of trust with the other person. Trust is earned slowly and can disappear in an instant.

Agile Coaches, brought in for an engagement, are a bit different. While they tend to lead largely with influence, they are “gifted” authority by the leader who brings him or her in for the engagement. The more authority the leader has, the more authority the coach will have. Though, this will deteriorate if the leader disengages or distances themselves from the coach.

So how can an agile leader build trust without focussing solely on getting everyone to like them? First, it’s important to remember that an agile leader is a Servant Leader, which means they have a vision and they serve to that vision. Agile leaders cannot just become servants to the team. Going down that path blindly is like trying to please everyone and ultimately, you may please no one.

Second, high Emotional Intelligence (EQ), is critical for an Agile Leader. One needs to not only be aware of their own emotions, but also be aware and adept of observing and navigating the emotions of others. As an agile leader, you may have to give bad news or critical feedback. Having high EQ will help in navigating challenging situations like this where people may not like you or like what you have to say, but will respect and trust you for delivering it.

Finally, I’ve found consistency to be key in building trust. Do what you say you will do. Develop strong routines and be a person that people can rely on. If you are a person who gets things done, people will notice and begin to trust with with larger and larger items.

When I started my agile leadership journey, I devoted a lot of my time in trying to get everyone on my team to like me. When I sensed someone didn’t like me, I would go out of my way to try to get them to like me, which ultimately made me less effective in influencing and leading the rest of the team. As an agile leader, your job is not to be liked, but to help the team become the best version of itself it can be. The team may not like you for it, but in the end, they will respect you for it.

Life-long learners meet an industry flooded with certifications

A collegue once bemoaned that so many agilists collect certifications like baseball cards. With such a proliferation of Agile certifications from Scrum Alliance, Scrum.org, ICAgile, Scaled Agile, and PMI to name a few, it’s easy to see how the agile community garners this impression. And when you encounter a few people who’s email signuature contains more letters after their name than in it, you come face-to-face with the explosion of certifications exists in our industry.

On one hand, the proliferations of all of these agile certifications is simple economics. Businesses demand agile and Scrum experts and certifications are an easy way to demonstrate knowledge of agile. And if employers are demanding these certifications, then employees (and employers) will pay for them. And if enough demand exists, organizations will rise up to supply.

The very nature of agile development instills a culture of experimentation and learning. In my experience, most agilists are life long learners and always seek new sources of information and opportunties to learn. Some, like myself, seek that learning from books and first hand experience. Others flourish on conferences and meetup groups. Yet others seek certifications as way to build their resume and brand to the world, seeking outside validation that they possess a specific aspect of knowledge and skills that are useful to an organization.

For those already with agile certifications, additional certifications provide one more benefit - reminding attendees of the agile basics. We all get caught up in our day-to-day operations and get bogged down in office politics. We become blind to the sacrifices we have made in order to get work done. Sometimes we take shortcuts. Sometimes, we become the evil that we sought to vanguish. At times, it takes returning to the source material on order for us to notice or recognize what we are doing wrong. At other times, we need the energizing interaction that comes from agile certifications, training, or conferences.

Certifications play a unique role in our industry. They serve a dual purpose in providing training and recognition for the mastery of a topic. They also serve as a marketing tool to help spread a particular framework, mindset, process, or tool. This can be seen most clearly if we go back to the early days of agile, when XP and Scrum were the main frameworks. Scrum embraced certifications as a way to rapidly train new experts in the framework. XP choose to forego certifications, taking a more skeptical view of their usefulness, likely born out of the general negative opinion developers had of certifications in the late 90s and early 2000s. If we look at the landscape now, Scrum is widely embraced and XP exists only in pockets and in specific practices like pair programming.

Certifications in the agile community is the prevailing standard. Applying for a new Scrum Master or Release Train Engineer position will require a certification. Even XP has made the pivot, with XP certifications now available from the Extreme Programming Alliance. While others may bemoan the state of our industry, it’s up to each of us to decide how we’ll shape our career, embracing the certifications or finding another way to showcase our expertise and our commitment to life-long learning.

Given the meeting has acceptance criteria, when the last acceptance criteria is meet, then the meeting ends

In my last post, I talked about the utility of defining a meeting as a user story, using the classic ‘As a {who}, I want to {outcome} so that {purpose}’ to convey the meeting’s purpose for existing, what it should achieve, and who benefits. Leveraging this format clearly informs the audience of the important details and also
sets a clear vision for you as the meeting organizer.

We can take the analogy a step further and add an additional tool common to user stories - acceptance criteria. Just like in a user story, a meeting acceptance criteria defines the conditions for when the meeting is over. When all of the conditions have been met, the meeting is over. Too often, meetings run to fill the time allotted. Having clearly defined acceptance criteria for their ending gives a framework for the meeting leader or team to call the meeting early.

The format in which you write the acceptance criteria can vary. You can try the ‘Gerkin’ format like that I used above that follows the ‘Given - When - Then’ syntax. While this format works well for development user stories, I find it challenging to adapt for a meeting. Instead, I prefer to think of the acceptance criteria for a meeting like a checklist. Once each bullet in the checklist has been completed, the meeting can be considered done and the attendees can move on with their day.

Examples

Here are a few examples for a few common meetings:

Daily Standup

• Everyone has discussed their plan for the day
• All impediments that have been identified have a plan to discuss or resolve
• The sprint board has been updated to match the current state

Sprint Review

• Team shares the outcome of the sprint
• Any functional demos are shared
• Any feedback is captured or a plan for discussion has been agreed upon

One on One

• All current prerformance and improvement goals have been discussed
• Any feedback for maanger or team member has been shared

Final thoughts

Just as there are many ways to craft a user story, there are many ways to craft a meeting invite. Don’t get caught up in the nuances of the format, nor with following the analogy of a user story meeting to the full extent. The analogy itself should provide value, and so long as the acceptance criteria is clear and helps us determine if the meeting is over and if it completed its outcome, then the analogy has served its purpose.

If you haven’t tried this technique, test it out with your next meeting and see if it helps you convey the purpose and outcome to the meeting attendees, keeps the meeting on track, and provide a clear signal that it is over.

As a meeting organizer, I want to provide meeting attendees with a clear, concise statement of our purpose and outcome, so that they understand the purpose and importance of the meeting

If you were to perform an audit of the meetings on your calendar, how many of them would have an agenda and a description? Of those that did have a description and agenda, how many of them provide a clear indication of the outcome of the meeting, who benefits from the meeting, and the clear steps we’ll follow along the way?

If you’re like me, most of the meetings on your calendar fail to meet these criteria. Sometimes, that’s because we’re busy and juggling multiple priorities. Other times, it’s because we didn’t put the preparation in for the meeting.

Meetings are painful, but they don’t have to be. Better meetings starts with preparation. And you can showcase your preparation to the attendees with the first thing they will see about the meeting: the meeting invite.

The best way I’ve found to capture the outcome and other important details of a meeting is to frame it like a user story, as suggested by Matt Philip and others over a decade ago. The user story format is one that most teams are familiar with and if it captures enough background and context for development of complex software, can we make it work for complex, collaborative meetings?

The basic user story format is:

As a {Who}, I want to {Outcome}, so that {Purpose}

Who

In our meeting as a user story, who could refer to 2 different groups; the group of attendees or the group that ultimately benefits from the meeting in the first place.

The simplest approach is to find a name to call the group of attendees. This is simple when we’re working with a development team. The next level approach, and a powerful technique, is to consider and name who benefits from the meeting. The audience benefits in some fashion, but who else beyond the audience? Leadership and stakeholders can benefit, but where possible, I like to consider the meeting from the customer’s perspective and frame the meeting in terms of how it benefits them.

Outcome

When we’re done with this meeting, what will we have achieved together? Sometimes, this is framed more of an output, such as a list of activites This approach has its place, but where possible I try to capture how we’re impacting the ‘who’ with the work that we are doing. Try to consider beyond the superficial surface activities if you can - those can always be captured further down in the description of the meeting.

Purpose

Purpose is the ‘so what’ portion of the user story. Why does this meeting matter? As an attendee, why do I care about the outcome and the person who benefits from it? This isn’t the same as ‘what’s in it for me’, but really more what’s in it for the borader organization. How does what we do in this meeting and achieving the outcome help us collectively achieve a broader goal?

Examples

Here’s a couple examples for a few common meetings:

Daily Standup

• As a team, we want to review what we accomplished yesterda, what we plan to accomplish today, and what blockers we have so that we can stay aligned on the goal for the team’s sprint.

This format lists outputs instead of outcomes. A next level user story for a daily standup would be

• As a team, we want to ensure we are aligned on our plan for the day so that we can monitor our progress on our sprint goal and pivot if necessary.

Sprint Review

• As a stakeholder, I want to review the Team’s progress, provide feedback, and adjust the backlog so that we ensure we’re developing the most valuable solution for our customers.

One on One

• As a team member, I want to meet with my manager to discuss current challenges, understand priorities, and talk about career advancement, so that I can grow and better serve the organization and customer.

Closing thoughts

Writing meeting descriptions in the user story is just the first step. A user story ussually contains acceptance criteria which further defines what is in scope for the user story. We can apply this to our meetings too, giving ourselves and the attendees a clear defintion of when the meeting is over. Approaching a meeting like a user story can help keep a meeting on point while giving us a clear purpose and outcome to work towards.

POWER through meeting preparation

Museum curators are responsible for collecting artifacts and the information behind them, caring for the artifacts and the stories behind them. Museum curtors then find a creative way to share the story.

As a meeting facilitator, we too are responsible for collecting and caring for information while finding a way for our meeting attendees to interact with the information, all in service to a purpose and outcome. Key to caring for this information is preparing for the meeting. In doing so there are 5 key items to preparation, captured in the acronym POWER

• Purpose - Why does this meeting exist?
• Outcome - What outcome are we working towards?
• who -who benefits from this meeting and who is necessary
• Execute -How to execute the meeting to accomplish the outcome?
• Role -what role do I play in this meeting?

This is a start to coneting a better meeting. To learn more, check out my deck on Curating Better Meetings, which I presented at Cincy Deliver on July 26th, or stay tuned her for more on how to prepare and execute great meetings.

Effective meetings require preparation and forethought from the organizer

Ask any Software Engineer what they’re least favorite part of their job is, and on that list will be meetings. Meetings are crucial to bring people together to collaborate, share information, or make decisions, but are universally loathed.

How can we make meetings better? The key is proper preparation. For novel, important meetings, I will devote anywhere from 1 to 3 times the length of the meeting to prepare for it. So, for a 1 hour meeting, I’ll prepare anywhere from 1 to 3 hours. I don’t follow this rule for recurring meetings, but I do spend some time preparing for each meeting. When establishing a recurring meeting or a novel meeting, I’ll pause to consider 5 important elements: the meeting’s purpose, the outcome, who needs to be involved and who benefits from the meeting, how I will execute the meeting, and the role I will play in the meeting.

Purpose

First I consider why the meeting exists in the first place. What larger purpose does the meeting play? What would happen if the meeting didn’t occur at all? When we rush through scheduling meetings, clarifying the purpose the meeting serves is often the first thing we neglect. But if you want the meeting to be valuable, you need to clarify the value it provides both for your attendees and for your self.

Outcome

Second I consider what outcome does this meeting need to achieve? Is this an informational sharing meeting? Are we introducing a new change? Are we collaborating on a solution? Or are we making a decision? These are a few of the common outcomes I encounter, but there are many more. Be concrete in what outcome the meeting should achieve, that way you and the attendees know when the meeting is over. Otherwise, with an unclear outcome, the meeting risks filling all of the space we allot for it.

Who

Next I consider who benefits from this meeting. Who is the chief benefactor for this meeting? If the purpose and outcome are clear, who benefits from the meeting should be obvious. As a facilitator, it is helpful for me to keep the benefactor in mind as I hold the meeting to center myself and consider how they would think of the progress we are making.

Also part of ‘who’, I consider who needs to attend this meeting. Who has the information we need in this meeting? Who needs to be present to hear the information? Who must make the decision? Understanding the purpose and outcome first helps us consider who is necessary for the meeting so we can limit the attendee list to the smallest group possible while still achieving the outcome.

Execute

With the outcome and the attendee list formulated, I then consider how I will execute the meeting. If collaboration is necessary, how will we engage all of the attendees? What is the journey that I and the attendees must take together in this meeting to ensure we reach the end of the meeting and achieve our objective? What conversations, questions, or decisions need to be made along the way, and how do I best support the group for those discussions?

Role

Finally, I consider what my role is in the meeting. As the organizer of the meeting, am I in a pure ‘facilitator’ role, or is there some secondary role that I may play, such as coach? What else must I do to prepare for the role(s) that I will be playing? What dangers may I encounter with the role(s) I am playing and if I am playing multiple roles, what confusion or problems may that cause?

Conclusion

Meeting preparation is crucial in setting the ground work for a successful meeting. Preparation will give you, as the meeting organizer, increased confidence stepping into the room that you’re meeting for the right reasons and working towards the proper outcome. For the next meeting you organize, consider POWERing through the preparation to make it a better meeting.

A Metric without context is just a number

In the 21st century, metrics are king. What organization isn’t informed or focused on metrics, relying on them to keep score, identify problems, and implement solutions? Metrics allow you to ask better questions, but they require interpretation. A metric without any context is just a number. One cannot make a decision knowing only a metric and without any other information.

For instance, if you were car shopping and all you knew was Car A had a highway fuel mileage of 32 while Car B had a highway fuel mileage of only 25? With just that information, would you be willing to buy Car A? Hopefully not, especially when I tell you Car A is a 1978 Ford Pinto.

If I said a particular scrum team had a velocity of 9, what use is the number alone? What’s the first thing that comes to mind when we consider that team? Do you, (like me) immediately jump to a conclusion? A better approach is to consider what questions to ask, questions that put the number into context such as

• How many people are on the team?
• How long has the team existed in it’s current form
• What’s the seniority of the team?
• How does the team point stories?

The answers to these questions may spawn other questions. For instance, if I respond to the last question that each story is pointed as a 1 and the team follows a “No Estimates” approach, you’ll want to know more and consider asking for additional metrics, such as cycle time and cummulative flow to further dig into how the team is perforiming.

Intuition and context play a huge role with metrics. Metrics should not replace smart people with their intuition nor should we rely solely on our intuition and observations alone. For those on-the-ground working the code, their intuition will point out where the problems lie. Sometimes these problems are obvious in the metrics. For many of the teams I work with, there is a bottleneck in delivery right after development completes. I see it each day looking at our Kanben board and from our conversations. The metrics also back up my observations, though it doesn’t come across as a large of a problem in the metrics as my intuition says it is.

Metrics also help us see patterns we have not seen before. Paired with our observations, metrics may help us articulate a challenge in ways to influence leadership action. Metrics, paired with intuition and context, can help spur leadership into action. Metrics help us see the consequences of a problem and consequentially, the benefit of fixing the issue.

Whether you rely on intuition first or metrics first, remember that they are stronger together. While some leaders may be influenced by observations and gut-drawn conclusions on their own, most will want to understand the numbers, not just for themselves but also for their leaders.

Prioritize your wildfires or your entire organization will burn

In spring 2023, thousands of wild fires raged in Canada. Across much of North America, skies were covered in a haze and the smell of burnt wood lingered in the air. With so many fires and so few firefighters, tough decisions had to be made to determine which fires would be controlled and which would be allowed to progress unchecked.

Not all fires are the same. Some occur in remote regions, making fighting them difficult. Also, due to their remote nature, their impact to human life is minimal. Still other fires occur near population centers and risk lives and property damage.

Wildfires are a naturally occurring phenomnon. Many are caused by lightning strikes. Still others are caused by careless
activity of humans. Environmental conditions and climatic trends play a huge role, as well as land management practices.

Organizations encounter their own types of wildfires. When was the last time you had a panicked email from a colleague, a last minute project request from your boss, or a meeting appear on your calendar with short notice? All of these are organizational wildfires, requiring you and your colleagues to respond quickly or face consequences. Just like a real wildfire, the consequences will vary. If you don’t respond to that panicked email, nothing may happen. Or a deal could be lost. Reputations impacted. Or not responding quickly may mean your team has to work a long evening or weekend.

Organizations will have problems and the organization’s culture comes out in how it responds to them. Do you respond quickly and with overwhelming force to each one? Or, are you more selective, choosing which ones to let smoulder while you forcus your efforts on the more critcal and impactful issues? Be careful the precedence you set with your leadership, as your people will look to you on how to respond to these problems. If you respond to every single problem with the same intensity, you risk burning yourself out as well as your team.

Just like wildfires have both natural and human based sources, organizational wildfires have different sources. There will always be problems that occur. Some problems are unavoidable. Yet others are completely avoidable. Next time you resolve a wildfire, consider if the problem could have been avoided, either through improved risk management, improved training, better expectation setting, or some other means.

Remember, only you can prevent organizational wildfires.