I’d just finished presenting at my first Project Manager Anonymous meeting, where I talked to them about the First Step towards Agile Operations, and to be completely honest the results weren’t what I was hoping for. The other people in the room were looking at me like I was some sort of crazy person.
“You want to put risks and issues up in public where senior management can see them?”, questioned one rather flustered looking PM named Jim, “You’ve clearly never worked in projects before”. Another questioned the value of demonstrating progress using a Kanban board: “My stakeholders get far more value out of Gantt Charts. How are they going to know when things are going to be finished?”. A third, a woman named Judy, scoffed at the idea of visualising happiness.I walked home from my first PMA meeting feeling a little demoralised, but soon overcame that negativity and developed a greater resolve to convince my peers that in the majority of scenarios, transparency trumps secrecy. I concluded that perhaps this group of people PMBOK disciples, who had spent years trying to manipulate outcomes to meet aging and inaccurate plans, would need more convincing than most.
I was sure that my colleagues at the PMA would appreciate this concept so I walked into the next meeting full of confidence…The next step in my eight-step program is all about helping people to work together:
#1 – Visualise everything
#2 – Collaborate to win
#3 – Reduce WIP & batch sizes to improve predictability and flow
#4 – Make sure we are doing the right thing and just the right thing
#5 – Collect tangible results and celebrate quick wins
#6 – Have in place different feedback loops to improve continuously
#7 – Grow a great Team
#8 – Share experiences, successful or not, to enable others to learn
“Why should I care about collaboration?”, “Just let me code!”, “Just let me do [whatever one’s silo does]”. “Shh! Don’t interrupt him! He’s producing!”.
I’ve heard these phrases many times on agile transformation journeys as people are often caught up in the illusion that productivity is measured in individual output rather than collective learning. I see two main reasons why we should care about collaboration: Firstly, it helps to create a shared vision; and, secondly, it helps to grow a great team.
Create a shared vision
In a complex problem domain, no one person has a complete picture of the whole context. Some people will have high-level visibility; some will have a very specific view and some may have no view at all. In any IT Project, since each person has only an incomplete set of information, it is fundamental to have everyone collaborating as much as possible. Collaboration ensures that information flows and that everyone learns from the emerging information which comes from those interactions.
Grow a great team
A team that has empathy with each other works better together. You may be surprised at just how much of an impact a good team culture can have. While empathy is certainly about one’s nature, it is also about one’s nurture, and leaders should care just as much about encouraging the growth and development of their team’s culture as they do about its productivity.In this blog, I want to share some things I’ve been doing in the Ops Team as well as some company practices of caring about their people, promoting an inclusive, family-like, collaborative and fun workplace.
The following practices include well established ceremonies such as daily meetings, lean coffees and retrospectives, and also some more unusual ones like the happiness radiator and outdoor activities. I tried to make it as DIY (do it yourself) as possible, because I am not spending all this time collecting evidence and writing for people to think I am awesome. What I want is to help to create better work environments with happy and performing people. I want you to finish reading and rush back to adopt the practices that have resonated with you.
So let’s go!
Agile Ceremonies: Daily Meeting, Planning Meeting and Retrospectives
You don’t run those ceremonies to be compliant with the Scrum Guide, right? You run them to promote a sense of emergence from people’s interaction, to create opportunities for information flow, to help improve the collective knowledge of the team, to allow people to commit to each other, and to establish a culture of continuous improvement. I won’t tell you how to run these ceremonies because there is heaps of content available on the subject. I just want to highlight two things that are imperative to promote a healthy and collaborative environment / atmosphere: Timeboxing; and, Icebreakers.
Agile Technique: Timeboxing
Temporal motivation theory (TMT) says that time is a critical motivational factor. The TMT formula can be applied to human behaviour, procrastination, and to goal setting. The theory models the motivating power of approaching deadlines, arguing that the perceived utility of a given activity increases exponentially as the deadline nears.
Motivation = the desire for a particular outcome
Expectancy = the probability of success
Value = the reward associated with the outcome
Impulsiveness = the individual’s sensitivity to delay
Two things are necessary for great achievement: a plan and not quite enough time. It can be argued that humanity made it to the Moon for one simple reason: John Kennedy committed the United States to a timebox. In the absence of that deadline, we would probably still be wondering whether it is made out of cheese.
Working in timeboxes increases the team’s motivation to get the most out of it. Timebox everything! Get people comfortable and familiar with the idea of deadlines. Consciousness reduces complexity.
Agile Culture: Icebreakers / De-Stress Activities
Whenever you are starting a new ceremony, try to invest some time creating the right atmosphere, helping people to de-stress, and get into the right state of mind for that moment. This makes a significant difference and you’ll find that the level of energy and the quality of your meetings will improve dramatically.
You can go from very elaborate exercises (just google to find a good one) to very simple ones, like asking them to breathe. Yes, just take a couple of deep breaths.
An alternative is doing “Power Posing” for just 2 minutes. Social psychologist Amy Cuddy shows that “power posing” — standing in a posture of confidence — can decrease the cortisol (the “stress” hormone) by about 25 percent and increase testosterone (the hormone linked to power and dominance) by about 19 percent for both men and women. In addition to causing the desired hormonal shift, the power poses lead to increased feelings of power and a greater tolerance for risk. Just 2 minutes! 🙂People do have a tendency to avoid the unconventional: “No Marcio, this would never work on my Team”, “My team would never do that”, “Sorry Marcio, we are a Bank, our culture doesn’t allow that”.
Unfortunately that is, as we say in Portuguese, rubbish.
The reality is that your team is thirsty for the unconventional, even if they don’t know it yet. They may play hard to get, pretending they are not interested, so use all the charm that your mothers gave you to make it happen. In time they will come to love the collaboration involved in the activities and start to proactively request it.
The Happiness Index – Fast and cheap feedback loop
The Happiness Index is a tool that helps you to understand the health of a team. It should work as a safe space where people can share how they are feeling with their teammates and whomever else cares about it. It is also a great way to grow a steady team; by getting to know each other better every day you can create a family-like environment.
The success of the happiness index is that it helps people to learn how the environment affects other people’s happiness, e.g. when someone puts a sad face in the happiness radiator, the team asks, and “What made you sad yesterday?”. When someone puts a golden smile in the happiness radiator, the team asks “What made you feel ‘freakin awesome’ yesterday?”. The happiness indicator is a shortcut to empathy and a great way for a team to learn from each other.
The way that the facilitator poses the questions should demonstrate an interest in one’s feelings rather than making someone feel bad about putting in a sad face (for example). When something is making team members feel bad, it becomes an excellent candidate for a retrospective. The team reflects on how to avoid behaviour that makes their teammates sad and reinforce those which makes them happier.
Managers should pay attention to the Happiness Radiator as some patterns may clearly represent a call for help. It might be that some small things in the environment are creating unnecessary friction which could be easily modified with significant impact on people’s happiness. Quick wins.
The Happiness Index can show you the overall healthiness of your environment in an easy and cheap way in pretty much the same way that Flow Efficiency can show you the overall efficiency of your System. These two simple metrics, together with courage and a lot of energy, can transform any organisation.
How to create yours
The mechanics of the happiness index is very simple:
- Take a picture of each team member, print it in 12X12cm and put it on the wall. This creates the Happiness Radiator.
- Print a bunch of mood faces like the set below.
- Every day during the daily meeting, get each team member to choose which face best represents their mood for the day before. We have five slots on the Happiness Radiator for each team member, so they can have one smile face per day.
- When the week finishes, track the results in a spreadsheet (0 to 4) and clean the board for the next week.
We used the following faces:
Golden Smile – means you were feeling freakin awesome! In theory, something very nice happened and elevated your level of energy.
Happy Face – means that yeah you were happy, everything is fine; life is good!
Neutral Face – means that you were… Nah… you know… wasn’t one of the best days of your life. Your energy was lower than the average. Maybe something happened, maybe you couldn’t accomplish something you were keen to, I don’t know.
Sad Face – means that yeah, you had a bad day yesterday. Something may have frustrated you, or went against your personal values, or maybe the activity you did was just boring; who knows.
Butt Face – that’s a funny one. Well, not that much. One day someone in the team asked me if there was something worse than sad that could represent his day. It was the kind of day where Murphy’s Law takes hold. Obviously, if your environment is more formal, or if it’s not politically correct to have a butt face, just change it to something else.
X Face – means that the person was not present in the daily meeting to share their mood or didn’t feel comfortable to share.
Of course, there is always some resistance when implementing new practices and even more with tools that are addressing people’s moods. Sadly, for some people, work life and happiness are two entirely different matters. After running it for a while, I started seeing some patterns on how people use this tool.
You have common behaviours:
- People who explicitly refuse to play
- I don’t share my mood. My mood is my business.
- People who basically don’t care
- Most of the time my slot is empty. I just share it when people insists, or the boss is looking.
- I just put a random face.
- I am an extremist. Always things are too bad or too good.
- I would prefer not to be doing it. But since I am doing it, I will put my real mood.
- People who think this is a great initiative
- I share my mood every day because I believe I am helping to grow a better team
How to fail
- Don’t use it as a team tool
- Let people just put their mood in the Happiness Radiator, without any collaboration
- Don’t ask questions when you see changes in your teammate’s moods
- Don’t do retrospectives about things that are preventing people’s happiness
- Don’t use the happiness data in 1:1 conversations
- Don’t capture data without also committing to making changes to improve people’s happiness
Agile Risk Management
Risks are the known-Unknowns of the project or product. They are the undesired events that may occur, so we do whatever is possible to reduce the likelihood of the event and/or minimise the magnitude of the impact.
If you’re running Projects, the risk may represent things that could prevent your team to deliver on the target time/budget. If you’re running an iterative process, incrementally evolving your product, the risk list could be things that would affect your Release. If you’re delivering in a release train approach, the risks can represent things that may prevent a feature to take the expected train.But wait Marcio. Why are you talking about risk management in a blog about collaboration?
I see everyday the Team discussing the risks and from my point of view, the only way of properly managing risks in a project is through collaboration.
Each one has just a portion of the context. One says, I think we should decrease the likelihood of this risk because of that. The other comes and says, but we can’t because of that other thing. And the third person comes and says, actually, because of this and that, I reckon we actually should increase both magnitude of the impact and the likelihood. Then the whole team agrees. But if the first person hadn’t started talking, the third would never have said they needed to increase the risk. This has all to do with collaboration, doesn’t it?
How to create yours
Create a risk list. Remember, risks are known-unknowns the team is trying to avoid. Each risk has an agreed likelihood to happen, and in case it materialises, an impact measured in how many days it would take to resolve it. The product of the likelihood and size of loss (in days) of each risk, gives us a crude but useful measure of risk exposure.
We review the risk list every single day before the daily meeting. It takes less than five minutes. Observing the transparency of the discussions around the risks, how they prioritise and discuss mitigation and resolution strategies, I can ensure you that it would be impossible to do without having the whole team collaborating.
For example, consider the scenario in which a team is migrating an application to run on Amazon Web Services. The team agrees to raise a risk (imagine it is the first item on the list above), called “Redesign the application to work with AWS”, because they are not sure at that point in time if that will be necessary or not. The team had spoken with the appropriate people and conducted some experiments, which made them feel that the likelihood for it to happen is low (30%), but the magnitude of its impact is significant; in case they need to redesign the application, it may take 90 days. Thus, we consider that our exposure to this particular risk is 27 days (30% of 90 days).
Review the risk list is an ongoing activity of the Team. We run the first Risk Discovery to gather everything that could slow us down and create our Risk List. Now, every day, we review it adding new risks that have emerged as well as closing some that have been completely mitigated.
There are good ways of visualising the risks. Visualisation is a fundamental component of collaboration. After all, nobody will open your spreadsheet every day and start talking about it. So make it ridiculously visible!
For that we use the Risk Radiator, spotting the main open risks.We also use the Risk Burndown to visualise our exposure over time, reviewing the list daily and adding new risks as they emerge, updating impact and likelihood of risks as they are treated, and constantly focussing on experiments or mitigating elements to reduce the project/product exposure.
How to fail
- Keep the data just on the spreadsheet.
- Don’t share the information outside the Team. Don’t make it companywide available.
- Don’t review it frequently.
- Don’t use the team’s gut feel to estimate the likelihood and impact. Prefer isolated opinions. The boss’ opinion is the best one in this case.
- Don’t associate the risks with some feature or epic that will completely mitigate it.
- Don’t have a probable date for each risk where it should be completely mitigated.
The digest email is a summary of the progress of the Sprint towards the committed goals. It helps keep everybody on the same page, not only the Team but also stakeholders interested in the progress of that project or product.
Ideally, that information is visible in the Team work environment. Sometimes printed from an electronic tool otherwise manually drawn every day in the daily meeting.
The reason I like to send daily digest emails is that it allows people to consume the information asynchronously and have their own time to reflect about how the team is progressing. It may be consumed at their desks, on the train, bus or even in the loo.Hey Marcio. What does Daily Digest have to do with collaboration?
Well, it makes the information flow across the organisation. That way, it could trigger the CTO for example to come to Ops space and talk to the team about something he is worried about. Or make people comment on their break about the sprint burndown that was shown in the last reporting and start discussing about it.
Anytime you have people talking about the project, sharing contexts, this is collaboration. Whatever you do to trigger these moments, you are promoting collaboration in your team.
How to do yours
The way I do it is, I have a PowerPoint deck and every day, by the end of the day, I save it as PDF with the date in the name of the file and send it to a list of people interested in it, that includes team members, people from different teams with dependency on this team, directors, and even the CTO.
I have a slide for each chart. The charts in PowerPoint are connected with the charts in a spreadsheet. This spreadsheet is taking the data from an external data source and doing all the calculations (today I have it working with Microsoft TFS and Atlassian Jira).
Let me guide you through it.
Page 01 – Cover. Dah!
Page 02 – Sprint Goal(s) and Timebox
Page 03 – Summary
In the summary, I put the day of the sprint and show a correlation between the Calendar and physical progress.I also show the Flow Efficiency of the Sprint. It reflects the overall efficiency of the System. The way we get it is calculating touch time over queue time. But I won’t start discussing metrics here since this is the theme of the next blog in this series.
The Sprint Focus Factor shows how much they can keep focused on the work of the Sprint and how much they are working in unrelated things.
The Happiness Index show the cumulative happiness of the Team over the Sprint.
The WIP shows how much work in progress the Team has, how many people are working on it and an average of card per person.Page 04 – Sprint Burndown
Straightforward burndown chart. I just added a series to shows how much work is being completed every day.Page 05 – Tasks by state
Straightforward pizza chart. The chart shows the number of tasks per state and how much it represents.Page 06 – Cumulative Flow Diagram
Straightforward Cumulative Flow Diagram chart.Page 07 – In/Out Flow Diagram
This graph helps us to easily see how much work is being completed and how much work is emerging over the Sprint. Having a lot of emergent work may represent a poor quality planning meeting or a very unstable environment.Page 08 – Control Chart
The control chart is an excellent tool to identify special variations in our work system. In my case, I am showing the items in X axis and the lead-time in the Y axis. Having variability in the process is absolutely normal in the knowledge work. We have, though, common variations and special variations. The stories with special variations are good candidates for retrospectives so that we can learn from them. Let’s explore this better in the next blog.Page 09 – Probability of completion
We are working with statistics, relying on probabilistic forecasting. In the following example, we can say with 80% of certainty that any piece of work will be completed within five days, or with 93.3% of certainty in 6 days.Page 10 – Risk Radiator
Straightforward as explained above.Page 11 – Risk Burndown
Here we are taking a slice of the Risk Burndown of the Sprint period. You can see in the chart below that it was expected that the team could burn the exposure risk from 37 days to 28 days in this sprint. What is happening though is that a new risk was raised, increasing the risk exposure from 35 to 41 days.
How to fail
- Send to people not interested in receiving it
- Send incorrect information / data so that people stop trusting it
- Don’t follow up with people to validate the usefulness of each data
Agile Technique: Lean Coffee
I love to run lean coffees. They have a simple structure and are a ‘no agenda’ type of meeting. Participants get together, build an agenda, and begin talking. Conversations are directed and productive because the agenda was collaboratively and democratically generated with topics people really want to discuss.
Run your first and I promise you that everybody will instantly fall in love with it.
How to run yours
Just set up three columns like backlog, discussing, done and you are good to go.
Give post-its and pens for everyone and allow some time for them to come up with topics. These can be literally whatever people want to discuss, or they could follow a theme. Every topic goes on the “backlog” column. Each topic then gets a 1 to 2 sentence introduction. This way people know what to vote for.
Each participant gets two votes. They can vote twice for the same thing or vote for two different topics. Ask them to simply put a dot on the sticky they are interested in. Tally the dots. Prioritise the stickies. Then you are ready to start a conversation.
Allow 5 minutes for each topic. When the time limit is reached, hold a simple roman vote (thumbs up, sideways or thumbs down) to see if there’s interest in continuing the discussion. If so, set the timer for a shorter duration (e.g. three minutes) and continue discussing. You can repeat this step as many times as necessary until the group loses interest in the topic.
When the topic runs out of gas, move its card to the “done” column. Bring the next highest card over from “backlog” into “discussing” and repeat the process.
Optionally take notes of key takeaways and action items from the group. This is usually important if you’re using the meeting to drive retrospectives, decisions or create work.
Agile Technique: Visual Facilitation / Graphic Recording
Visual Facilitation is a great tool for making the abstract understandable. You can facilitate your meetings, helping to put thoughts on paper, transforming the spoken word into the visual using pictures, words and colours. This can be very powerful for collaboration as people can really ‘see what you mean’.
One common mistake is thinking this is just for creative people when in fact you don’t need any drawing skills.Hey Marcio, Visual Facilitation is about Visualising, isn’t it?
This should be in the first blog though. Yes, you’re right. It is about visualisation, but here, I want to call attention how making things visible helps to increase collaboration. Give it a go and you’ll see how drawing makes the meeting more fun, inclusive and helps create a shared understanding, putting everyone on the same page.I recently did a Visual Facilitation training course with Marcel van Hove from bikablo, and what you learn goes from how to hold the pen properly, using abstract graphic elements (such as containers, line elements and arrows) to structure the information, and using pictograms to represent the content and messages. Figures can represent people, their situations, actions and feelings. “Effect lines” support the visual vocabulary to create a sense of motion, as seen in comics.The above images were drawn by me and considering the level of confidence I gained in the training, for me this looks amazing! 🙂
Agile technique: making things visible
Sensible information must be visible all the time, not stored in files somewhere in the network! Thus, people can hang out around it having quick discussions frequently. If you missed it, check out the first blog of this series about visualising everything.
Knowing each other better
Great teams always invest time getting to know each other better and nurturing their relationship. This can make a brutal difference when growing high-performance teams. I’ll share some things you could do with yours.
Discussing Team Values
Give each member a list of some virtues (I used this http://www.wisdomcommons.org/virtues). Let them reflect about their personal values as well the values of the team from their perspectives. Put it all on the board and allow them to go through a fascinating conversation, revisiting and merging the list until they get a short list (5 to 7) of values that most represent the Team.
Diversity can increase team characteristics such as passion, collaboration, innovation and resilience, just to mention a few. Diversity can come from gender, personality, culture (the place they came from), personal intrinsic motivators, personalities, experiences and connections.
Allow the team to discuss their diversity. Is your Team missing women? Suggest to them that they run any personality test (e.g., Enneagram or StrenghsFinder) and share among them. Run the Management 3.0 Moving Motivators, discuss about the previous experiences and connections of each team member.
At Elabor8, we support several initiatives to promote gender diversity, like BOLDMoves, Girl Geek Dinners and Equality Hacks. As of today about 45% of the team are women and we won’t rest until we achieve 50%.
Agile Technique: Learning Games
Learn through games is a very nice way to increase collaboration. For instance, here we were playing the Beer Game to promote awareness about the problems that arise due to lack of systemic thinking. There is a bunch of agile games out there. Try some. If you don’t find a specific one, just create it. If you need help, join any community of Practice and ask for help. If you are in Sydney, join the Agile Coach Meetup.
Random Fun Moments
Sharing good moments together is vital to create emotional connection among the team. Try to promote some random fun moments. What about Ice Cream in the middle of a hot afternoon listening to a loud “Go Johnny Go” music from Chuck Berry?
Outdoor activities also have an incredible power to help create roots in the Team. As a good Brazilian, playing soccer was on the top of my list! What about doing a retrospective in Hyde Park, seated in the grass? And doing walking meetings? Use the outdoors as much as you can.
Lunch & Learn
Lunch & Learn, also known as brown bag sessions, are a great way to have the team learning from each other. We love to go to Conferences to learn from other practitioners. Have you thought about how much each practitioner of your team has to share? I personally like the TED format. 18 minutes of ideas that are worth sharing. 🙂
Agile collaboration in summary
In this blog I introduced a variety of practices that address the principle of Collaboration, one of the pillars of the Agile Mindset.
- In complex domains, no one has a complete picture of the context.
- A team that has empathy with each other works much better.
We need to promote collaboration as much as possible to help create shared vision and to help grow a great team.
In my next update, I’ll introduce the principles and practices to reduce work in progress and batch sizes in order to improve flow. Hopefully, you’re already starting to implement some of the concepts in my last update and you’re well into your own journey to Agile Operations.
If you gain any insights after reading this blog, please comment below! I would love to hear from you! Also, comment if you have any critiques or suggestions. If you like it, share on LinkedIn or Twitter and help others to learn from it as well! Collaborate to Win!