Do you have the Product Team Mindset?

Product Team Mindset 

Are you ready to go beyond the comforts of an Agile mindset to a Product mindset. 

Over the years in IT, teams have been organized more as component teams or feature teams. Component teams were more formed around the IT investments like the mainframe group, the DBA team, the website team etc. Terms like UI teams and backend teams were the more familiar structure. 

Shown Below is an example of Component teams. Depending on the platform or IT investment like Salesforce CRM, 

These teams also tend to have ownership of the components and get funded yearly to get work done on whichever component they are responsible for. 

This structure has its own pros and cons. Pros being people become experts of a certain area over time and the main con being the automatic dependency when anything needs to get done. The agile movement of cross functional teams led to the formation of feature teams. Feature teams are still heavily IT driven initiatives where instead of having teams around features or value streams. For e.g Search feature may have many pods each pod having representation of skills that can work on the UI, the platform and a data team.  This resulted in what is now famously known as a T Shaped team. The work for both component and feature teams were funded by business teams and were prioritized mainly using gut feel by the role of a product owner. This also led to the term Full stack developer, someone who can work in many layers of the code. 

Over the years with technology like React, Angular , AWS, Azure , Kafka, Microservices , Containers etc.   It is now impossible for any one person to be a master of all stacks.The skills of the team balances out the overall skills needed to deliver the feature. 

Siloes of Product Ownership, Design and Engineering and Ops.

The feature team and component team model solved the problems for developers and testers. However product ownership, UX Design , engineering and Ops continued to work in Silos and have teams of people working in their own teams. This creates 

How do Project Based funding models work with Component and Feature Teams?

The predominant funding model for both component and feature teams is project based funding model. Each year the company sponsors key initiatives through a portfolio prioritization process. This allows for various key initiatives to be completed. 

Each portfolio is made up of initiatives/ projects which then get funded. The initiatives/ projects are then estimated and then driven by product managers and product owners in product backlogs. The approach till it gets to the backlog is very much a waterfall. 

Since the funding typically happens once a year, that becomes the general planning horizon and everything revolves around it. 

Teams end up pulling from the different backlogs and in the end everything comes down to a prioritization exercise as capacity for most organizations is generally considered fixed for any given time period. 

So the project based funding models have become shorter and organizations are taking a proactive approach to relook and prioritize the portfolio at least one a quarter. 

So here the funded entity is the Project and that pretty much drives what goes in the backlog. While it is true that funding models are not any more once a year activity in organizations, the amount of such organizations tends to be very less in no. Most still do a large scale once a year exercise. Can we rethink our teams and make them truly customer facing. The answer lies in Product Teams and also how they get funded. 

What are Product teams?

Product teams are a startup within an enterprise. A collection of teams that are aligned around a product area or a value stream. They own the entire end to end lifecycle around that area soup to nuts. This will also include sales, marketing and other functions in this group itself instead of them being in another part of the organization. Mainly there are no more two separate groups within the company business and IT. 

An example is a large investment bank in the east coast that has completely restructured its investments group where each POD consists of the sales and marketing functions, and then many teams in a POD that are aligned to a specific feature on their product like Search. 

The main difference between Project and Product teams is that

	Product	Project
Funding	Based on delivery of outcomes to the business and funding is many times a year. Funded entity here is the Team.	Projects are funded based on milestones and are typically funded once a year.  Funded entity here is the project
Teams	Long lived teams that own the entire business outcome. More like the Amazon model of teams with a Single Threaded Leader	Teams are formed around projects,
Who owns	Team is part of the business unit.	Generally IT owns Projects
Customer facing	Yes , this is the big difference	Sort of through the proxy of business stakeholders and product owners
Silos	Same team has business, product, engineering and design and team members are encouraged to learn each others skills	Clear separation between Business, Product, Engineering, & Design Siloed skills

Many IT organizations that are now doing agile and devops practices well, are still struggling to deliver value and aligning teams around the product areas and giving them full responsibility is not new to companies like Amazon, for large enterprises this is still a challenge yet to be solved. This requires a complete mindset change from the entire enterprise and also needs teams to step up and learn newer ways of working so that they can directly engage with customers, own specific areas in the value chain/ user journey. This also brings new challenges to large monolithic architecture in favor of more microservice driven , micro front end architectures that enable rapid development at scale. This also requires leaders to reimagine how they have designed the organization, and trust the teams more to deliver to outcomes than output. 

Are you ready to imbibe the Product Mindset?  Learn more about moving your group to a product mindset ? Learn how to redesign your portfolio to create product teams aligned around customer journey / value streams. 

Contact us at contact@agilists.co and learn more how to go about this change in a predictable way. 

Scrum Your Meetings

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

Conclusion

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.

–Go for it , be the change and make it happen

How much of Agile is too much?

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.

• SAFe
• LeSS
• Nexus
• ….

• Certification bodies sprung up
  • ScrumAlliance
  • Scrum.org .
  • 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.

But i guess only time will tell.

What is the role of HR in the Success of an employee in an Agile Organization?

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.

Employee Lifecycle

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.

Recruitment:

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.

Professional Development

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.

1. Goals to help grow self.
2. Goals to help the team
3. 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

Retention

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,

Exit

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.

Can Agile work for Infrastructure and Ops Groups?

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

1. 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.
2. Identify one or more product owner for the service lines.
3. 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.
4. 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.
5. 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.
6. Education for leadership and middle management is key.
7. 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.
8. Set up leadership impediment board to relentlessly remove impediment across the organization.
9. performance measurement systems should be changed to encourage more cross-functional learning than a siloed expert based learning the culture.

Scrum Essentials

What is Scrum?

Role:  Scrum Product Owner

Role: ScrumMaster

Role: Team

Artifact: Working Agreement?

Artifact: Product Backlog

Artifact: Sprint Backlog

Artifact: Definition of done?

Artifact: Definition of ready?

Event: Sprint Planning Defined

What is the most important role in the Scrum team?

Paper napkin design?

What is MosCow Rule?

Measuring success in agile projects?

How do we do effective Daily Scrum?

How do we select velocity?

How do we measure productivity?

What is 13 forms of leadership?

What is the relationship between user stories and use cases?

What is a story point?

Can we change the length of a sprint?

How soon can we see improvements when we start using Scrum?

How can I estimate on something I know nothing about?

What are different techniques to size stories?

What is a ScrumMaster mission statement?

What is a book list for agile teams?

Is there an Agile meeting cheatsheet?

What is a ideal source structure for a .NET project that is agile?

What are product owner teams and how do we set them up?

What is metascrum?

What is the relationship between story point and complexity?

1. What is a self-organizing team?

What is Sprint Planning?

Why Sprint Planning:

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.

Agenda:

1. OPENING   – Welcome, Parking Lot, Working Agreement, Action Items  for meeting
2. 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.
3. THINK ABOUT PLANNED vs UNPLANNED WORK
4. DECIDE A SPRINT GOAL- Collectively the team and PO write a sprint goal defining the purpose of the sprint.
5. TASK BREAKDOWN- The team members work in groups to break down tasks for each Product Backlog Item. (This can take a while)
6. SPRINT FORECASTING AND CONFIDENCE VOTE. Scrum Master checks with the team if they feel comfortable with the work they have planned.
7. 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

1. The team pulls stories that do not have acceptance criteria
2. The meeting finishes really quickly
3. The meeting goes forever 6 to 8 hours
4. Everyone has laptops open and no one is talking to each other
5. Team members are being told what to do
6. Stories and Acceptance Criteria are being written for the first time here
7. The team is estimating the story here for the first time
8. The Scrum Master is controlling the entire meeting
9. New Team members feel lost
10. 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.

 

Paper Plane Game

Purpose:

To demonstrate the power of time-box or Sprint that makes the heartbeat of an agile framework like Scrum.

Type:  Team Game

How many can you build in three minutes?

Time Needed: 45 minutes

Number of people per team: 6

Supplies Needed:

1. Used Printer Paper 50 per team
2. 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.

One fold at a time

1. 3 minutes for planning,
2. 3 minutes of actual build ( test included) time,
3. 3 minutes for review/retrospective – 

Rules for playing the game:

1. Build as many paper planes as you can in a 3-minute time box.
2. One player can only do one fold at a time. That rules stays true for all three time-boxes.
3. The planes should be built

   

   Rules

   and tested in the 3-minute increment

4. Only planes that cross 30 meters will be counted
5. Each team should give a count of how many planes they are going to build before the time-box starts.
6. 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
7. The team has to come up with one idea of improvement at the retrospective. Have one member in the team be the counter.
8. The front of the plane should be blunt to avoid injury to the team members.
9. 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.

Disclaimers:

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

 

Unlike Monopoly – The Best Scrum Simulation Game for Workshops

Overview:

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 

Learning Objectives

1. Learn how to use the Scrum Framework
2. Learn the power of Timeboxing
3. That architecture evolves over Sprints.
4. The power of working increment at the end of every sprint
5. Experience high-performance teamwork
6. Learn about how learning about the product in each sprint is essential to build better products
7. Learn how early  Customer feedback is critical to the success
8. Learn that even adults can have some fun and draw, paint, dance etc

Supplies needed:

1. Something for board
2. Glue sticks
3. Playdoh
4. Voting Dots
5. Crayons
6. Clear Tape
7. Scissors
8. Rubberbands
9. Any kinds of Arts Supplies

 

Rules of the game: 

In a flip chart write down the following simple rules for this game:

1. 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.
2. The game should have a clear start and end.
3. Minimum game time should be 10 minutes at the end of three sprints.
4. There must movement in the game for the players. For e.g, they could be jumping, running, moving around the table etc.
5. Each team can come with its theme for the game. For eg. One version of a game they built Woofopoly – a game for dogs
6. 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.

1. Sprint planning –   3 minutes
2. Day 1 – 8 minutes
3. Daily Scrum – 2 minutes
4. Day 2 – 8 minutes
5. Sprint Review – 3 Minutes
6. 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

1. Did the do their stand up? Did impediments emerge
2. Did Scrum Master remove impediments
3. 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.
4. Did they create a working at the end of every sprint?

 

 

Meetings – From Hell – Part 1

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

1. Write down for one week all that you do. Write down all the meetings you went to and how you contributed to this meeting
2. Notice how much of the work you did that week is actually what you were hired to do. How much was a value-add?
3. 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.
4. Last step. Write down all the things you do
   1. Go to the Planning meeting
   2. Weekly Design session.
   3. Cross-team planning.
5. In the list above mark the ones that are customer facing vs just internal process.
6. Put a plan to simplify all the work that is an internal process.

Help remove the Meeting Epidemic. Be the change in your organization..

.