Steering the ship: integrate risks (a sailing story)
Project management in agile is based on simplified indicators: in Scrum, a progress diagram compiling team speed and complexity remaining to be done. In Lean Software, a flow diagram integrating cycle time and work in progress. These indicators are decoys if you don't know how to manage risk.
Have you ever heard the nautical metaphors “the project is drifting”, “we're on course”? I'm going to take the metaphor at face value, and tell you an anecdote that once happened to me.
Hoist high!
During my student years, I went for a week of sailing with a professional skipper and 2 friends.
Very quickly, we saw that our team was functioning well. We got along without stepping on each other, a fundamental aspect in this closed box which is a 5.50m living area. Each one having his little experience of navigation, the coordination was prowling, we maneuvered faster and faster. One evening, while we were anchored in the harbor of Port-Blanc, the skipper offered us a challenge:
“Tomorrow, moderate wind forecast. Are you keen on the Channel Islands? Departure at night, long day of navigation, we have to plan everything, like real sailors. ”
We said yes.
Heading to Jersey
To navigate far from the coast, without visual reference and over such a distance, you only have the compass to orient yourself, so you have to set a course and follow it. This course requires certain calculations.
To begin with, we calculate the drift. We take the maps of the marine currents and add up all their vectors, hour by hour, throughout the journey, to arrive at the total drift. Let's say that according to this vector we would arrive 10 miles to the south of the theoretical destination.
So we take our default course, the straight line between us and Jersey, and we compensate for it, as if the island is actually 10 miles north. The heading (angle to north) is measured to follow this new line.
In our case, precision mattered because after 12 hours of navigation, we would definitely end up tired. Any delays would draw our strength. This would just be the beginning. Depending on the time of day and our position, we would easily suffer currents and winds that we would not have accounted for, making the journey a real pain. While GPS can eliminate the danger of getting lost, the sea is dangerous - especially for an exhausted crew who sleeps in a cramped living space smaller than most bathrooms. So everyone cross-checked the calculations to be certain of the drift vector and the resulting heading angle. With our freshly celebrated math baccalaureate, we were still confident.
The principle then is to pull anchor at the scheduled time, follow the course with a compass, and, deviated by the current, we arrive at the island. On the strength of our pilotage plan, we went to bed for a night departure.
4 am, they wake me up.
"In fact there is not a fart of wind, we let it go, we will follow the coast to Bréhat."
Goodbye Jersey.
After a lovely night sailing following the coast line, we docked on Bréhat in the morning under a bright sun. We rested and strolled there before heading out to sea, it was a magnificent day.
From “project that derives” to “damage to the project”
I come back to project management in agile.
Planning requires the assumption of a simplified, linear progression. The deviations tolerated by this hypothesis are simple excesses. But this plan has a pernicious effect: with the time that we invest in our prediction calculations, in summing elements, taking margins, 
we tend to take the hypothesis for a reality.
Excluding reality is not linear. An unforeseen event can explode your forecast.
This is what I reproach with velocity curves and progression diagrams: they suggest that the unforeseen will cause linear drifts, compensable heading deviations. I fell into this pitfall, and not just when I started out in agile.
I don't think I'm the only one.
I mentioned nautical metaphors, “drifting project”, “staying the course”, etc. But we never hear “the wind has fallen”, “damage to the project” or “lifeboat”. The unforeseen, the real ones, those which count, do not make the curve drift. They make it obsolete. Of course, you will realize it, but often it will take time, attached as you were to your Excel formulas, and it will be too late.
When the wind drops, we throw away our current calculations, and we forget about Jersey. It is a disruptive event.
How to integrate a progress indicator into project management that sets the course under normal conditions, while remaining attentive to these disruptive events, in order to let go of the plan and take the necessary decisions in time?
I believe in a schizophrenic piloting using at equal value:
- a progress chart, burnup chart or burn down chart, which predicts “what will we finish when”
- a risk sheet, recapitulating “what would make this diagram no longer make sense”
This risk sheet is a classic project management practice, I am not reinventing the wheel. However, I find it too little mentioned in the agile world, and often forgotten by new teams, so I insist: it must be included and up to date in your management documents. Go further :
it's not just a piece of information,
it's an antidote to the belief in linear progression.
Concretely, I draw a principle for roadmaps, progress diagrams, or any form of projection that you use to manage:
we never present a schedule without the risks on the side
On the wall, display the risk sheet next to the roadmap. In your excels, write the risks under the progress chart, not in a separate tab. With just one schizophrenic look, you will have one eye on the indicators, the other on the risks.
Coming soon: build a risk matrix (simplified)
Tags: Agile Management , Control , Drift , Risk matrix , Piloting , Project Management , Risks , Risks , Velocity
Rekindle the connection between the team and the sponsor
When I used the word “reporting” in a previous article about Agile iteration reviews, "Demonstration is not a stand up meeting", it triggered some interesting reactions on Twitter:
@avXXXX @duquesnay Seeing the iteration review as a moment of effective reporting is a bit itchy for me (a lot in fact).
@bmXXX @duquesnay Personally I would also prefer 'communication' or something like that of course, and efficient is surely too strong (cc @duquesnay )
@avXXX @duquesnay Me in a sprint review, I am not coming to report. What interests me is feedback. [@…]
There is an embarrassment of developers when we integrate the word "reporting" into agile practices. Here are my thoughts.
Project progress, anxiety-inducing notion
Progress measurement is not liked by developers, and that is understandable.
Firstly, development effort is relatively random. A development expected to take a day can turn to a week, and a week eventually become a month. Yet progress will be measured against the original estimate of these tasks.
On top of that, many team’s job depend on things outside of their control, other actors, external resources, or else.
Then, we get caught in a system that encourages commitment, sometimes forced. The pressure to promise optimistic results exists, and we often confuse the answer we believe in with the answer we like to give.
But if the estimates are wrong, it’s the team’s nightlife and weekends that will be sacrificed first.
Even if approaches exist to limit this problem (agile provides a number of them), the subject awakens painful experiences in many of us. I know my lot: our session short Agile projects, are you ready? (french language) with Jonathan Scher in 2012 was originally a case study on a project we failed. I understand that jaws are tightened when the question of work progress comes up.
“It is gonna be ready when it is gonna be ready” = tone deaf
What shocks me is to hear some within the Agile community refute the question itself, and the relevance of a project steering. Worst example heard among practitioners:
"It'll be over when it's over, it would be deceitful to give an estimate to our going client. If they don’t understand this, we shouldn't sign with them"
Riiiiight. I find this to be a very naive posture - blind to the context. The position of a development team stems from a relationship of interest with the organization that employs it.
Money matters
When on the first day of the project the developers, business experts, the graphic designer / UX and Product Owner all sit in comfortable chairs in front of modern desks supporting dual-screen computers in a clean, heated, and well-lit space, while the coffee machine purrs, someone has already put money on the table. They are the sponsor(s) of the project.
MasterCard ad version:
A team is gathered on a project because some sponsor are pursuing a goal. It's a financial risk, they could have tried nothing, or bet on another project. Their concern is legitimate. I think disconnecting from it leads to an unbalanced situation.
Let's imagine that they too propose to disconnect from the financial reality of the developers:
Ok to not do any estimation or reporting, but I'm not taking out a euro before it's done, no developer will be paid before delivery.
It itches on the current account side of the team members, right? Do you feel the relationship of mutual interest?
United by mutual interest
The exchange on twitter made me react to this feeling of disconnection. There was a lot of "I"s in there: “[…] in a sprint review, I don't come to do […]" ; "What interests me is […] ”. As if the end-of-iteration demonstration were designed solely for the developers' use. It is a meeting point with a collective goal.
A high-performance agile project is built around a balanced relationship of interest. The sponsor and the team are united. They talk together, chat about stakes and progression.
So why are we still there?
In my observations the disconnection of the team from the challenges of the project often goes hand in hand with a distance between the sponsor and the team. It's tempting to blame the sponsor but I think the blame is actually shared.
In any case, it's a shame, because the sponsor is the most powerful friend of the team. They have power, resources, bring a broader vision of the context and are often pragmatic… if they are sufficiently informed.
How to reduce the distance between sponsor and team?
As soon as I mention the presence of the sponsor during a coaching, the question comes up, so the problem is common. We have levers of resolution on both sides of the relationship. Here are some stinging questions to activate them:
Leverage on the sponsor side
- When was the last time you attended a demonstration?
- Have you tried the product before?
- What is your vision on the performance of the team?
➔ Tip: Reserve regular time to visit the team
Leverage on the team side
- Who has ever spoken to the sponsor?
- Do you know firsthand their first 3 stakes on this project?
- Who has ever seen the progress report shown at steering committee?
➔ Tip: Question the sponsor about the stakes, share the reporting task among the teammates
Note to management: get your feet wet
To titillate one or the other of the parties, any actor facilitating the project can intervene: direct managers, the scrum master, the coach if there is one. However, access to the sponsor is often more difficult. Rare availability, intimidating hierarchical level, barrier of assistants, we don't always have the access we would like.
In my humble opinion, do not hesitate to get management's feet wet on the problem. You can, for example, formally request the presence of the sponsor to a demo every 4 weeks. I write “management” in the broad sense: the network of managers of the organization, these people whose role is to grease the cogs of the machine. If several directors are involved in the project, one of them can pass the message around, for example.
The regular presence of the sponsor is a key to the success of the project. Raising this awareness deserves your efforts and your insistence.
Self note to the coach
The last lever is for myself, the coach. I've incorporated it into my practices for several years, but it doesn't hurt to rewrite it in black and white. I have to include the sponsor and his relationship with the team in the scope of my coaching. Complaining about their absence and only intervening with the team is nonsense.
Self-stinging questions:
-
- Did I bring up the coaching of the sponsor(s) during the setup of my intervention?
- Has an appointment with them been set before the start of the project?
- Did I offer them regular reporting on my intervention?
- When was the last time I asked them about the project?
(Note: this article is a rewrite of a first version in French from 2014: Retrouver la connexion entre l’équipe et le sponsor)
Tags: Agile Coaching , Agile Management , Communication , Control , Demonstration , Feedback loop , Agile management , Pilotage , Sponsor
Scrum Master: 5 keys to hit the ground running
As Agile methods spread within organisations, people from earlier agile teams are appointed Scrum Masters for new teams, often without much training. After practicing Scrum for a year or two with a team, it seems easy enough, right? Just replicate what you’ve seen, and voilà. Sadly, it’s never that simple.
The catch is, this role is usually very remote from one’s existing skill set. Plus, every team is different.
As soon as you start, you quickly realize that there are details, aspects, and mechanisms that you don’t yet understand fully. And of course, your boss and your teammates are counting on you. No pressure.
Can you do it?
The short answer? Yes.
Before we begin, I must reassure you that anybody can become a Scrum Master - no matter what your background or job may be. Although a bit confusing at first, anybody who likes to learn will get the hang of it in no time.
1) Prepare and debrief all the ritual meetings
The rituals are already set in the team's calendar: iteration planning; review + retrospective; stand-up meeting. But for the Scrum Master, a preparation time is necessary to deliver the best session:
- Mental Preparation: Approx 10 minutes:
Involves reviewing the flow of the meeting, recapping past workshops, and repeating the introductions you will make. Think about the delicate issues that could be tackled: you will need to keep energy up to stay on top of the fray during these times.
- Logistics: Approx 15 minutes:
Involves checking and adjusting technical points (room, projector, network, post-its, markers, etc.)
As the diagram shows, the best way to prepare for every appointment is to block it in your calendar rather than in your head: a 25-minute lead on the appointment you’re about to conduct, with an automatic repetition every consecutive meeting. This time is specifically useful for you to do everything before the meeting starts.
When the participants arrive at the meeting, they will find you already there,very confident and absolutely prepared. if you trust yourself, they will trust you.
Since we’re on the calendar topic ; some time after the meeting must always be blocked:
- Implementation of decisions: Approximately 1 hour during the half-day following the meeting.If decisions regarding the backlog or the team dashboard have been made, the easiest thing to do would be to implement them immediately. Same principle: Entry another entry in your calendar, 1 hour appointment, repetition at each iteration.
- Debriefing: 1 hour to 2 hours after the retrospective.
The role of facilitator is a tiresome one. You will tire out quickly at first - guaranteed. Staying above the fray & not getting caught up in the emotions of the group takes energy. A lot of it.. So avoid any complicated tasks in stride as you may not have the energy to do them. Save yourself for the heavy lifting. Your team needs you.
On average, the basic role of Scrum Master should take up around 30% of your time. During the remaining 70%, you will play the role of a teammate like any other. Remember,it's simply a role, not a full-time position.
2) Focus on the retrospective frame, not its process
The simple notion of frame in facilitation theory is the one that helped me the most as a Scrum Master, explaining how meetings can run smoothly no matter their process.
Most meetings end up in disarray because we’re, well, humans. We get passionate. We digress. We get stuck in confronting opinions, or reversely, we comply with the group’s direction. Your role as a scrum master is to help keep the ship pointed in the right direction. It is your role to steer the conversation, not participate in it.
In order to do so, it is essential to set a frame at the start of the meeting. Essentially, it’s an agreement between the participants to make the most of their time spent together.
Introduce the session by recalling this agreement:
- The purpose of the meeting (check if there are other expectations if you have any doubts)
- The time allotted (ask if any have time constraints)
- Each participant and their roles (if it is the first time or if new ones are participating)
- The progress steps and the division of the time that you propose (check that everyone nods)
- Any other rules to be observed
After everyone has agreed with the frame, they will understand your facilitating interventions, and you can always circle back to it. If you notice that the participants do not react well to your interventions, it is most often because they do not understand their justification ; go back to the frame.
Examples:
- "I have to ask you to conclude quickly, otherwise the round table will last too long and we will not have time to discuss the points afterwards”
- “I suggest we get into this later his is the demo, we agreed that we would just be checking the user stories and not dig into any exploration”
- “Are you still on the subject of the meeting?”
If the participants react negatively, turn this back on them: “Do you want to take more time?”, or “Do you want to update the meeting agenda?”, “Do you want to interrupt the round table to talk about XXX? ”. As a facilitator you help them respect the frame for their own good, but that does not prevent it from being changed if everyone agrees.
Tip: do not be afraid if your meetings seem formal the first few times: fun will come after you get comfortable.
3) Do not get involved in discussions during retrospectives
The secret to succeed during your first facilitations is to stay out of discussions and have only one goal: steer the flow of the meeting (not what transpires within it). This first exercise is a bit extreme for first timers, but I can assure you, not participating is effective.
Getting into debates is usually every facilitator’s mistake and what you should be cautious about. Discussions have a way to drag you further and exhaust you, and soon you forget about your facilitator duty, leaving the flow of the meeting unsupervised.
Yes, it will be very difficult at first. Yes, you will have answers to some problems that the group brings up. But I must insist: DO NOT ENTER THE DEBATE.
Being a facilitator is like hosting a party: you don't enjoy it much, but the guests do!
Instant advantage: by giving up participating, you hone your listening skills, develop your observation skills, and get a better understanding of the relationships and dynamics that shape your team.
4) Own your legitimacy
Often when starting out, we hesitate to adopt strict strategies from the getgo. How strict should we be? How direct are we expected to be?
The secret: this power, your teammates gave it to you. They agree that you must take action. They appointed you Scrum Master.
Once you understand this dynamic, you can ask them for help without putting your legitimacy into question
- ask what they want from you, in a meeting or over coffee with a colleague. Examples:
“I see that we have gone over 20 minutes; next time do you want me to be more strict on the watch?"
"When you slipped on the subject of the bug, you would have wanted me to cut you off?" - delegate certain tasks or responsibilities:
“Who wants to help me write down today’s decisions?”
“Mathieu, do you keep the time reminders?”, “Philippe, would you like to keep the dashboard up to date?”
Your teammates gave you a role and responsibilities, but they haven't left you alone: don't be afraid to ask for their help.
5) Exchange with peers
One last point too often forgotten: we often understand a situation better and what to do about it when we talk about it with someone. Talking with people outside your project (a Scrum Master, Agile coach, or a mentor) will make you step back and progress.
And of course, reach out and participate atto one of the many agile meetups. See you there?
Each Scrum Master brings a bit of their character to their team. Some bring a strong cohesion through their empathy, others bring a passion for metrics, some do document a lot, to each their own style.
Do you want to be a good Scrum Master? Be yourself. Do things your way, and develop your style.
TL;DR:
Encouraging team’s freedom : how much is enough ?
When talking with directors about how to enable collective intelligence and co-responsability in their teams, they usually find me too strict regarding their own behavior.
« Yes, last week I’ve been keeping someone’s action on hold -it was over a detail, but I didn’t understood her decision, you know. And the next day I stepped in and took direct control of à team’s action plan, telling people what to do.
But what’s the deal, that’s just two times, right ? On average, I let them go on their own if it’s good for the business. They know I expect them to decide and act without waiting for validation on details, right ? »
My point is : no, they probably don’t.
To explain why, I’ll use a reverse example.
Reverse proposition: dictatorship
Imagine a dictator of a 150 people village. How many people does he have to punish to remove any attempt of free-thinking and free initiative ?
My bet : 2 are enough.
It’s not about controlling all of the free-thinking leaders, it’s about making an example, telling a message. Once people got the message, they’ll stay away from displeasing you. The first punishment makes an example, the second one set a pattern. Then the word spread. Self-restraining behavior will soon appear.
Now let’s say the dictator changes his mind.
How many people does he need to reward to remove the former message, to say « good you take that initiative on your own. It helps ! » ? 10, 20 rewards at least, right ? While restraining from any censorship
Back in our management situation.
Control messages are far more powerful because they’re calling our inner surviving sense. « Don’t get into bad situation » comes before « Thrive in your life ». No balance is possible because these are not competing on the same level : safety wins.
You’re the boss, boss
As a CTO/CEO, you have a lot of power and influence on the people that works for you, probably more than you think.
So when you’re a manager, a CTO, a CEO, and you forget yourself 1 or 2 times per week by being over-controlling, censoring someone who takes an initiative you didn’t understood (in other words : you freaked out), you don’t get an « average » message at the end of the week. You drawn a powerful pattern that you’ll have a hard time to remove.
That’s why, even if I’m being tolerant as a coach, I stay relentless about the behavior required to set a proper messages.
Now, if you’re asking yourself « Am I doing enough to get my teams confident about their freedom to think and act by themselves ? », I would use two reverse questions instead :
1) how many censoring actions are needed to kill people’s investment in your project ?
2) how far are you from that number ?
[Video] Looking for remote Agile tools? Think remote supplies instead
It was a common rant already in the Agile community to talk about people thinking that going Agile was about rolling out some Agile management tools. How many times did I hear “We’re deploying Jira Agile and training everyone to it. Max budget, we’re on top of it”.
Then people start taking the tool as a method guideline, using everything just because it’s available: Kanban and Scrum Board at the same time ; Story points and Man.Hours. Wait, Man.Hours in a scrum team? Yeah, some Agile softwares provide very questionable options in regard of the Agile principles.
The frustrating part is that we know that some fellow Agile coach will some day be brought in to clean up the mess, and it’s much harder to undo some practices that have settled than to just set things right in the first place.
The most frustrating to me: seeing electronic canvas used to run rituals while missing out completely on the whole facilitation aspect, like a retrospective where one manager was just pulling answers from the team and filling the canvas on his own, without even setting the stage first.
Ok, that used to be an among-ourselves Agile practitioner rant, but the question of tools is very relevant now. Since the pandemic, our dependency to remote collaboration tools is real, and remote work is not going away.
If you’re wondering why and how to pick your tools, check out this video.
To improve people’s work, stay in the work context
Wellness activities at work, companies retreat, sponsored afterwork drinks, etc. A couple managements books I was reading lately helped me put this gut feelings into more intelligible words.
So what was my gut feeling about?
“Do we really have to do this?”
You’re in for a paintball with your colleagues. Are you willing to unleash your funny, super nasty self with them like you do with your friends? You went to a company ski “seminar”, actually that’s the first time you saw snow in your life. Wouldn’t you have shared this with a loved one instead? And did you really want to discover Mike-from-accounting when he’s drunk?
These management approach implies that in order to do a great job the employees have to open a part of their personal life, and even their privacy to their employer.
On the other side, are you going to miss out for your career if you don’t go paintball, don’t go for the drinks, don’t go skiing with them? So you went, with that lingering feeling: “do we really have to do this?”.
Here’s my first unease: aren’t we forcing one’s work & life balance for the sake of “happiness at work”?
“The truth is in the cheese”
they say. I would transpose this into “what is in the work is what makes the performance”. So why are we looking elsewhere to solve work problems? Isn’t a failure of work management if we have to go outside of work to get the job done?
Now I had these gut doubts, but several authors I digged into lately such as Yves Morieux, Daniel Pink or Isaac Getz went to my rescue to draw a more clear-cut principle
You only change the way people work by changing the work itself
corollary of
Introducing non-work related elements doesn’t really change the way people work
The authors hints:
A more pleasant job is motivating by itself
My friend works in a design agency. a year ago, the general manager realized that designers where unhappy so he created Friday afterwork drinks. I’ve been invited. Free flow, karaoke, good stuff.
As you guess, this didn’t change anything, because people were rational in disliking the work. Stress from last minute rush and unrealistic deadlines were the normal way of business. Too many jobs were half-assed and designers had to endure disgruntled clients. Exhausted, they made more mistakes and creativity was damped. Final note, their personal time was basically spent resting from work, so none of them had much of a life beside work.
The designers didn’t need to be pumped up for the company, they just wanted a job that doesn’t suck. My friend left.
Baseline: you don’t restore people lost motivation by bringing the like of free drinks, offsite weekends and in-house yoga session. You restore their motivation by changing something that makes the job less taxing.
Reference: The fallacies of hard+soft approach in “6 Simples Rules” by Yves Morieux
Improving your competence is its own reward
People feel good just by feeling more competent and capable at what they do. Think about the best waitress you know. Does it feel like they’re doing it for any other reason that getting the job done well.
Reference: Daniel Pink describes in his book Drive how evidence and experiments proves that increasing your autonomy and mastery is an effective incentive, while external incentives like financial rewards are actually counter-productive (good luck accepting this controversial belief).
We just like to do our job better.
Reference: “Drive” by Daniel Pink, “6 Simple rules” by Yves Morieux, “Freedom Inc.” by Isaac Getz
Trust at work is better built through work collaboration
When you played together with a colleague at a company fun activity, it doesn’t mean you find this person more competent at her job. I had a colleague, Djamel, who was an absolute trash talker at poker, very fun player to have at the table, fair looser or fair winner, and not a bad one. I trust his ability to make any game a good time. Do I want to see that at work? Nope. (thankfully Djamel at work is a very acute mind with a way more subtle side).
People build trust after they work together and found their cooperation mutually beneficial. We build trust through the work.
Reference: somewhere in rule 1 of “6 simples rules” from Yves Morieux
To help people, understand their work
If you ever seen “Undercover boss” reality show, here’s 80% of the baseline:
Boss experience field work and realize the policies from the organisation headquarters are bogus for what employees have to face in their stores. Also boss find absolute gems of employees who solve every day a tremendous amount of problems she had no clue about, then still manage to get the train on time and the clients delighted.
There’s no point implementing any organizational principle and theories on people before you understand what is their work, what is it that they do and what is their day to day goal in reality.
Reference: the Genba principle from Lean, 2nd rule of “6 Simple Rules” by Yves Morieux
Takeaway: stay lazy, no need to look elsewhere
This resonates a lot with my past experience as coach and consultant.
When approaching a situation to improve -usually I’m first told by my client before I get a sense of it myself- have a sense of the scope of the problem as described, and be wary of solutions that actually extends this scope. It is tempting to add that new happy disruptive practice, that new psychology angle you just red from the latest book that triggered you, but it’s just adding complexity to the problem. Changing something or removing something is usually way more influential than adding something.
Most times, a great solution is within the problem or in its direct vicinity.