How can we make our meetings productive. This is a billion-dollar question. Even if each one of us improve our meetings by 1% we save $$$ s for our organizations.
In this article, we look at one such technique called Scrum Your Meetings:
Why Scrum Your Meetings:
In the first few pages of the book called Design Sprint, there is a picture which is worth million dollars. ( Picture modified a bit based from the book)
Normal Work Day for Most Companies:
Scrum Your Meetings Version
In the teams I have been recently we have been trying this and seeing really great results.
How do we Scrum The Meetings :
Work the Work is one way to think of this. The host of the meetings invites people. Recommend time not more than 60 minutes for a session. The goal is what can we get done in 60 minutes.
Step 1 - Goal Setting 10 minutes
The hosts present what is the goal that we are trying to achieve as a team in the next hour.
Notice the way the doing column does not have any more than one task for the team. This style of work is called Single Piece workflow.
Sometime you may do more than one task but as a general rule Don’t to start anything that cannot be done in an hour.
Step 2: Close IM, phones , chats etc.
Step 3: Start Task ( Swarming around the first task )
The entire group works on the first task. Sometimes this means we are talking, sometime we may be writing a document, it depends on the work.
Suppose our goal is to create some document, we can start a shared document on google docs, or word docs and share it on a large screen. The first person types and others contribute to the document. You can also try a variant of this called Mobbing.
At 10 minutes the keyboard moves to the next person. Complete first task and pull next one. This way everyone has to work and no one gets to chill back and just talk.
Step 3: Close with action items or parking lot items
What if we can actually go home and eat dinner with the family and not worry about work. Imagine how much we can save by not context switching Every time someone randomly pings you in a chat, you are going to get distracted from the work you are doing now.
This kind of working even if your teams can practice once a week and once a week do a no meeting day. You will see infinite improvements to productivity and you will see many satisfied employees returning back home with a smiling face every day.
Many years ago, by which I mean 1996, I got attracted to something called Extreme Programming. I loved the fact that we could work in small teams, created tested products.
People like Martin Fowler, Uncle Bob, Dave Thomas made things more real. Using Scrum was easy as Scrum mostly works nicely at the team level.
I have seen Scrum work really well up to groups of 100 or so people. Beyond that, in theory, it’s supposed to scale. I was part of one of the largest and best implementations of Scrum at scale, I believe that the program had 1000 or so people, and after 2 years, the product died. It was the best process implementation I had ever seen of Scrum at scale, Scrum of Scrums, distributed Agile and yet it failed for one reason – They delayed the shipping of the product, by trying to gold plate it with more and more features. Then bad things happened, people were fired, many have now become agile coaches in other companies.
Then came Agile transformation. – To me, it meant applying Agile at a large program or portfolio level. When large companies started adopting Agile, they found immediate issues in terms of scaling. With that was born a billion dollar industry. Scaled Scrum Frameworks.
Certification bodies sprung up
Lean Kanban Training etc.
So far I have not seen even many successful implementations of any of these large scale frameworks. The reason no framework can fit is our organizations are complex adaptive systems.
Even in the phase of Agile Transformation mostly everything was still in the IT side. One of the financial giants I know after 8 years of trying agile, many millions help from consulting companies, just closed down their agile coaching office.
And now the year 2019 seems to be the year of Business Agility. Essentially running the agile business in an agile manner. While these are fundamentally sound principles, the agile community has not had much success in Agile beyond IT level.
At the core, if we follow simple rules that small teams work better, form many two pizza teams and have each manager to have not more than two pizza teams. Give them the autonomy they need to solve the complex problems of the business.
I am curious to see the certification bandwagons like SAFe now add new tracks for business agility. I am convinced that small groups, cross-functional armies are better. Too much structure in scaling may not yield the desired results
We can create learning organizations, we can use systems thinking to learn from our organizational units, however, I don’t think there is enough data yet to prove that running everything under the banner of agile may be a wise thing.
These theories may be proven wrong in some years, who knows.
In Organizations that practice Agility, there is a growing need now to reimagine the role of HR. In this article, we see just from an employees perspective areas when HR interacts with an employee during the employee life cycle.
Mark has worked for 12 years. He has a masters degree. He is well respected in his field. His skill is sought out in the industry and he is really happy with what he is doing.
Let’s look at this lifecycle where typical involvement of HR happens.
The term human resources is a challenging one. Irrespective of what we call this group its what this group does that can make a huge shift to an Agile Organization.
In most cases, if you are really good at what you do, you probably have a good job. So if you are a recruiter who is hiring for experienced professionals you need to do a lot more than just searching for profiles on job boards or LinkedIn. Most experienced recruiters have a tactic of approaching candidates, and over a period of time, getting them to think about possible future opportunities.
A few years back, I had hired one of the best Agile recruiters ever. As soon as she joined, all of a sudden our recruitment pipeline would look really good. She would organize events that looked more like meetups, and in those meetups, she would invite some of the candidates she was targeting either as a speaker or an attendee.
Good recruiters make the whole process seamless. Every small detail would have been thought through. Each email that goes out or the phone call has a fun human touch. Even when people are not hired, they would get an email why they were not hired, and what would they have to do to get hired. We have had numerous cases where people would come back after months saying, I completed all the items in the list, now hire me.
On-Boarding New Employees
Why do we celebrate only when people leave the company? While we should do that, why not make a lot of noise and make someone feel awesome. on the day they join the company.
Here are some ideas to make Mark’s first day memorable.
Send Mark something he/she likes a few days before they start.
Stand with your team and clap and invite Mark as he joins the organizations.
Keep paperwork on day 1 to a minimum.
Laptops should be ready when they arrive not after a few days.
Keep a task board of things they have to do and give them a few days to complete the work.
Don’t bore them with corporate training on the first day. let them do the work they joined to do.
Most work not always but in many cases has come down to teamwork. Every employee needs to set for themselves a few goals and they should be measured on reaching those goals.
Goals to help grow self.
Goals to help the team
Goals to help the organization.
Separate feedback systems from Financial Incentives. Dan Pinks Drive Drive: The surprising truth about what motivates us. Are you creating ways in the organization to encourage Autonomy, Mastery, and Purpose?
Minimize Titles, Promote roles instead. All organizations do need some sort of internal numerical systems, which should only be used for salary purposes. In some organizations, these levels are given so much importance that it ends up killing creativity
It’s easier to hire new employees but tough to retain them. Each person has many reasons to work. Most of us work to get paid. But beyond that, we work to use our creative mind and make a difference to the community around us.
People leave when they have a bad boss, and when work does not motivate them anymore. This is where leadership role is critical in creating organization systems where people have the freedom to work, but are working towards clear goals for the group that they are working on.
A big part of retention is the ability of an employee to feel like they own the organization.
There is a difference between happy employees and engaged employees. What you want are employees who are engaged in what they are doing and hence happy doing it.
HR can play a critical role in creating 360 feedback systems, happiness surveys, enabling organization-wide collaboration tools. video conferencing systems, work from home policies, timesheet only for billable work, open PTO,
When people decide to leave, support them. Don’t try to stop them. There is a reason they are leaving. Treat them as future customers, future employees. Ask them in the exit interview what the company could have done differently . In some cases, employees do leave just because they are following the money, and those kinds of employees who are only motivated by money are better off to leave.
What you don’t want to lose are those dedicated employees who would not have left, if they felt they had been heard, they felt their work mattered and when work gets fun, people often don’t leave.
In all of this having even one strong leader in your HR team who understand that can bring agile values to the work they do, they will make a huge difference to your workforce. Find the right leader to lead your HR group. And as you do so maybe call it Resources for Human not Human Resources.
Yes. Agile can work with Infra and ops groups. This article outlines some basic principles during your agile transformation journey.
When an organization gets more and more Agile soon they realize that one of their bottlenecks in their own IT operations department. With the concept of physical datacenters slowly moving to the cloud the nature of work done in operations groups are also changing drastically with time.
The DevOps movement has been successful in moving parts of the operations, upstream so that the engineering teams can mostly be self sufficient and not have to deal with handovers and delays due to large wait periods before things get deployed. Concepts like SAAS, IAAS, PAAS, Cloud etc fundamentally changed the notion of network engineers, DBA and many roles that were typically there in classical IT operations groups.
Organizations that have tried Agile in Operations are moving from processes like ITIL and are heavily invested in specialized skills, network engineers, DBA’s etc.
Here are some pointers to transforming your Infra and Ops group to an agile organization.
First things first
Identify all the Service Lines that your group supports and align cross-functional scrum teams around these service lines. For large services, consider using the concept of PODS which compose many small cross-functional feature teams. Set up Scrum of Scrums across PODS. These teams can follow a Scrum or Scrumban model of working. Use dedicated Scrum master for a team or an agile coach for a POD model . Teams need help during the change. Don’t ignore this role.
Identify one or more product owner for the service lines.
Move some of the operations folks upstream to directly work with engineering teams to enable DevOps and provide the necessary automation required to seamlessly deploy to production.
For incidence response teams, involve the actual dev teams in the process. The first level response teams may not be able to use Scrum as most of the work they do may be demand based.
Streamline ticketing systems so ticket duplications in systems like Service Now are removed. The same ticket should be used by teams to solve the incident. In earlier organizations since the org was siloed each group had its own ticket ending up in a lot of duplication and coordination of work.
Education for leadership and middle management is key.
Consider rolling this change to the entire org in some sort of structured manner using internal and external coaches so that there is minimal disruption to the operations.
Set up leadership impediment board to relentlessly remove impediment across the organization.
performance measurement systems should be changed to encourage more cross-functional learning than a siloed expert based learning the culture.
Remember is Scrum we work in baby steps. Sprint Planning is the event where we plan what we can achieve as a Scrum Team in Two weeks. We need all members of the team in the Sprint Planning. Giving a sports analogy this is the meeting on the day of the big game in the locker room.
OPENING – Welcome, Parking Lot, Working Agreement, Action Itemsfor meeting
WHAT CAN WE DO IN THIS SPRINT –This is a discussion between the PO and the team to decide how many Product Backlog items can be completed in this sprint.
THINK ABOUT PLANNED vs UNPLANNED WORK
DECIDE A SPRINT GOAL- Collectively the team and PO write a sprint goal defining the purpose of the sprint.
TASK BREAKDOWN- The team members work in groups to break down tasks for each Product Backlog Item. (This can take a while)
SPRINT FORECASTING AND CONFIDENCE VOTE. Scrum Master checks with the team if they feel comfortable with the work they have planned.
CLOSE – Clear Parking Lot. Assign names to Action Items and do a Retrospective on how the meeting went.
10 Smells of an InEffective Sprint Plan
The team pulls stories that do not have acceptance criteria
The meeting finishes really quickly
The meeting goes forever 6 to 8 hours
Everyone has laptops open and no one is talking to each other
Team members are being told what to do
Stories and Acceptance Criteria are being written for the first time here
The team is estimating the story here for the first time
The Scrum Master is controlling the entire meeting
New Team members feel lost
Managers are sitting idle watching the plan instead of participating in it
Note: In Distributed teams sometimes the sprint planning is done over two days. Esp when you have PO in one country like the USA and the team in completely opposite time zone like Singapore.
To demonstrate the power of time-box or Sprint that makes the heartbeat of an agile framework like Scrum.
Type: Team Game
Time Needed: 45 minutes
Number of people per team: 6
Used Printer Paper 50 per team
One flip chart and a marker to keep score
The goal of the game:
The goal of the game is for each team to create as much high quality tested planes that can fly a distance of at least 30 meters . The world record holder last checked in June 2016 was somewhere in Germany
Each iteration last 9 minutes.
3 minutes for planning,
3 minutes of actual build ( test included) time,
3 minutes for review/retrospective –
Rules for playing the game:
Build as many paper planes as you can in a 3-minute time box.
One player can only do one fold at a time. That rules stays true for all three time-boxes.
The planes should be built
and tested in the 3-minute increment
Only planes that cross 30 meters will be counted
Each team should give a count of how many planes they are going to build before the time-box starts.
Subtract the final count of planes that actually flew from the planes that were built but were not tested or completed. Eg: Team A said they will make 4 planes, 7 planes flew all the way but 5 were WIP ( work in progress). Subtract WIP so the actual is 7-5 =2
The team has to come up with one idea of improvement at the retrospective. Have one member in the team be the counter.
The front of the plane should be blunt to avoid injury to the team members.
You cannot crush the plane into a ball and throw.
Please recycle the paper once done
Debrief: ( pick any two )
Each table talks about what made them improve over the three iterations
Talk about what would have happened if the time box was not there
Talk about how waterfall may be different from this.
Talk about who made the final design decisions in the team.
Talk about any wastes they removed from the system that helped them get better.
Original Creator: Not me. I am still trying to find out. I learned it from another trainer.
There are many variations of this game. This is one way I use it in my workshops
I have been teaching Agile workshops since 2007. I have experimented with various games over the years. In 2014 or so I modified the Scrum Simulation game which I do in day 2 of my workshop and found that people got hooked into this.
Some twists this game has makes it a real learning This article is a facilitator guide on how to run this game. I have played this game more than 100 times and always had amazing results.
Name of the Game – Unlike Monopoly – A Scrum Simulation
Length of this game: 3 hours
Learn how to use the Scrum Framework
Learn the power of Timeboxing
That architecture evolves over Sprints.
The power of working increment at the end of every sprint
Experience high-performance teamwork
Learn about how learning about the product in each sprint is essential to build better products
Learn how early Customer feedback is critical to the success
Learn that even adults can have some fun and draw, paint, dance etc
Something for board
Any kinds of Arts Supplies
Rules of the game:
In a flip chart write down the following simple rules for this game:
The game should be unlike Monopoly. Monopoly is still one of the most sold board games. However, it has its own issues, long gameplay time, a winner in this game takes time etc.
The game should have a clear start and end.
Minimum game time should be 10 minutes at the end of three sprints.
There must movement in the game for the players. For e.g, they could be jumping, running, moving around the table etc.
Each team can come with its theme for the game. For eg. One version of a game they built Woofopoly – a game for dogs
Once we build the game, people in the workshops including invited guests will play the game for at least 15 minutes.
There are three parts to this game:
Part 1 – Ideation– 1 Hour 10 minutes
Part 2 – Build And Ship – 1.5 hours Three sprints to get the game ready to ship
Part 3 – Play the game
Part 1: Ideation – 1 Hour 10 minutes
This part when I have skipped ended up in more mess in the actual sprinting process.
Step 1- Pick a theme – 10 minutes Tell the team that they should pick a theme that can compete on the shelves with Monopoly. Encourage them that first they collect all ideas on sticky notes, and then pick one concept from the list.
Step 2- Product backlog Refresher. – 15 minutes Explain What is a Product Backlog, That each item should be an increment of value ( for e.g.) if they write an item called to build a dice, that is not of value as by just building a dice. Introduce Epics, Theme.
Introduce what is a user story and concept of Acceptance Criteria
Step 3 – Write backlog items and get some of them ready. Let the team sit down and write product backlog items – 45 minutes
Given the team time to write some of the stories, have the Product owner in the team order the backlog, and they write acceptance criteria for at least 3 -4 items to start with. One template to use for acceptance criteria is –
What does it look like
How does it behave
What should it not do?
Tell them to capture the discussion around these three questions as acceptance criteria.
Challenge the team if you see stories that do not add an increment of value or look more like tasks. I have them completely restart at times.
Part 2 – Build and Ship
Setup – In this phase, the teams will build the product in three sprints. Each sprint has 27 minutes.
Sprint planning – 3 minutes
Day 1 – 8 minutes
Daily Scrum – 2 minutes
Day 2 – 8 minutes
Sprint Review – 3 Minutes
Sprint Retro – 3 Minutes
Keep a visual indicator for this.
Also generally playing some lively music during the sprints day 1 and day 2, will keep the energy high, ALso before starting sprints take a break. That way you can go all the way
Giving instructions: Tell them how the time would work. Identify a facilitator in each team and tell them to self-score and tell them to follow all the Scrum Practices they have learned so far. Show them how the big timer works. See timer eg below
Start a timer( google one is good) for 27 minutes on a big screen
Let the teams start Scrumming. After the first sprint is over, I give a coaching report of what I observed about how the teams did as far as following the process goes. Not more than a minute per team.
Part 3 – Play – Tell each team to pick a marketing person on the team and do a 30-sec pitch and answer one question – “Why should we play their game”. Once every team has pitched, asked everyone to move to some game and start the timer for 10 minutes. After 3 minutes ask those who played the game their instant feedback to those who built on what they liked about the game and any ideas they see for improvement.
That is it, the simulation ends. As a coach observe for these things
Did the do their stand up? Did impediments emerge
Did Scrum Master remove impediments
Were they following the Scrum Process, sometimes in the fun they have they forget completely about the main reason for this simulation is to practice Scrum.
Did they create a working at the end of every sprint?
If you take any average size company meetings are a given.
Be definItion ( dictionary.com )
a meeting is an assembly of people, especially the members of a society or committee, for discussion or entertainment
I wish here what it said was something like
A meeting is a pointless gathering of employees in a room or phone, where we discuss reasons for why another meeting is to be created
A meeting is a place where leaders try to force their agenda on employees so that it looks like they are forcing collaboration
A meeting is a gathering of wandering minds who are not sure how to come to decisions and they need someone else in the company to take the risk so that the blame does not come on them
Here are some common dysfunctions of meeting that we all have seen
– Safety Shanker wants to decide if a certain decision is a right thing to do. He wants to make sure he does not get someone later blaming him for the decision he could have taken. So he calls a meeting of all the people he thinks to weigh in on this topic. His goal is simply to make sure that he tells this groups what he is about to do
– Panic Mike finds out that the project schedule has slipped. Instead of going to the team room where work is happening, he calls the entire team to a meeting to get status. His agenda is clear he wants to put pressure on the team so that when the project eventually fails for some reason, mikes boss Clara does not point fingers at him.
This problem of THE MEETING has now become an epidemic. I know people who feel their day was useless if they are not in back to back meetings.
In a typical meeting from hell, there is some sort of conference room, either physical or virtual and more than 8 to 10 people and one person who is trying to get their agenda through.
Why have we created such organizations where we allow these dysfunctions. Do we really understand the cost we are incurring in meetings and not creating an organization where decisions can be taken without calling a meeting?
What if we create a culture of Collaboration without meetings.
Calling a one-hour meeting of 10 employees is an exceptionally expensive affair. If you were the owner of this company would you tolerate your employees sitting for hours together in meetings?
Collaboration is important but not committees and meetings. The last decade of me leading teams, coaching organizations shed light on some basics
Collaborations are often like a daily standup, huddle. These are more informal and done as needed only. They are also not done in a conference room
Telling a bunch of people to decide on their own does not work, neither forcing them to decide.
What you need to create in teams is a sense of ownership. They need to own the problem and the solution. They may go wrong many times but they are making decisions quickly. A good measure of understanding an organizational agility is how quickly a new employee gets productive i.e
gets a laptop, login credentials
Starts to learn from his peers what he or she is supposed to do
Delegate Decisions down. Here is a way to start
Write down for one week all that you do. Write down all the meetings you went to and how you contributed to this meeting
Notice how much of the work you did that week is actually what you were hired to do. How much was a value-add?
Observe what may have happened if you did not to the meeting. I am guessing they may have gone ahead and done something about it.
Last step. Write down all the things you do
Go to the Planning meeting
Weekly Design session.
In the list above mark the ones that are customer facing vs just internal process.
Put a plan to simplify all the work that is an internal process.
Help remove the Meeting Epidemic. Be the change in your organization..
This article presents guidelines and examples of metrics you as a leader can help set for the group or team
It is really important that an organization does not measure only to demonstrate to others in the company that things are getting done. There is a false sense of comfort in these metrics. It is important to measureless.
“Remember – What you measure gets done”
5 rules when selecting metrics: ( VOIRS Rule)
Make what you measure, is Visible. Everyone should be able to see what is being measured. Customer satisfaction survey results -outcome metric, velocity – output metric. A good mix is always required.
Outcome driven metrics always produce better results that output driven metrics.
Make it Inclusive – let those who you want to measure have a say on how they want to be measured. Get input from teams. If you get buy-in from teams then metrics makes a lot of sense
Make it Real-Time. – If metrics need translation by humans in an excel sheet there is something wrong with such metrics.
System metrics are better than People metric. Measure more of how the system is doing and less of how people are doing.
Measuring Process Effectiveness
Measuring ability to reach Strategic goals at a regular cadence
Any product or service organization has business goals. These goals are often things like ( in this case we have shown an airline example )
One Integrated Airline Booking Experience
Reduce customer complaints by 30 %
The launch of 4 more cities for new flights.
When it comes down to the teams these goals are compounded with so many other little internal goals etc that somewhere along the lines, the big picture goal is lost. So leadership job is to regularly communicate these goals and make sure everyone in your organization is focused around these key goals. There will be other things but many times those other internal work items slow down the more important strategic priorities.
In the example above 9 different epics have to be done to get the three goals achieved. Each epic could be made of many many smaller epics or smaller user stories or backlog items.
So how do we measure things from here?
Metric – Lead Time – This is the time when the requirement was first identified in the organization and added as the core component of the strategic initiative to the time it was actually delivered to the customer. Tools can do this easily. The difference of end and start is the lead time.
Monitor “Cycle time”.
Cycle time is the time taken at each step. in the doing column. Time from the time some work start till it is finished. The customer does not see it
Lead Time is = Sum of Wait Times + Sum of Cycle Time. In this case, we are taking Cycle Time to be the actual Value Add time. Really go and figure out where waits are in the process and help remove these waits. Waits are often seen
when people are waiting for approvals,
Only a few people in the organization can get some things done. Remove the silos.
All the work note ” All of the work” a team does should go from one list.
Show a live report of where these epics are at any given moment
How do we know how Agile we are. It’s surely not a gut feeling or some massive assessment. Assess systems, not people. Using Agile Principles as a measure of Agility.
Shown here is an Agile Principles Card. Have each team sort through the 12 principles from “Yes to do it” green or no we don’t do it ” Red”. Collectively prioritize the red ones and then come up with action items as story cards to move items from Red to Green.
Measuring Product Effectiveness
If you have a good product you should see higher customer satisfaction. Regular customer feedback collected real time from customers should be shared as is with teams that produced that feature. A much-debated technique is called Net Promoter Score. It is just one measure and should be used for what its worth. A point of reference.
Amount of features in the product that is actually used.
Mandatory Features – Customers are quite indifferent to must-be featured. For Eg Do you ever buy a phone because it makes a phone call?
Linear features – Customer satisfaction is more around linear or performance features
Exciters or Delighters – These are huge pluses to customer satisfaction. For eg the first time Gmail said, Hey you have forgotten to attach a document when your document says something is attached.
Collect data about all the features in the product broken down by the three categories in real time. This can be achieved when you tag epics as a Linear, Mandatory or Exciter in your Product Backlog tool.
Measuring Leadership Effectiveness
A #1 reason for Agile to not be as successful in the organization is due to lack of middle management support. See State of Agile Survey By Version One.
– the picture above is from State of Agile Survey By Version One
As you look through the list, it is clear that effective leadership can actually help resolve a lot of these challenges listed. So how do we measure effective leadership?
Are leaders solving daily the biggest impediments of the organization? Are they helping daily?
Are they delegating decisions down where information exists and don’t punish people for making decisions?
Are they setting clear boundaries for teams to operate in?
Have they separated feedback from performance reviews? Feedback should be routine not drama.
This can be collected from teams from regular automated surveys or 360 feedback. Leadership effectiveness is a much bigger topic that we will surely address in a later blog.
This article presents very few metrics mainly around three categories Process Effectiveness, Product Effectiveness, and Leadership Effectiveness. Note that velocity is an output indicator and not good to measure effectiveness. It can simply be used to predict future dates that is all and it is a lagging indicator. Also, note that it is important that all of this be automated and be touch-free leaving nothing to interpretation. Also, this is the main metrics that should measure and it’s really up to you as long as you pay attention to VOIRS rule.