Being an Agile team is all about adopting the Agile frameworks to the core – both in project management and team collaboration. It is all about efficiency and effectiveness, which means adopting methods to optimize resources, make the most out of teamwork and, especially, mitigate or avoid loss of time and costs.
But whether you adopt Scrum, Kanban, XP or any Agile framework, in the end, it all depends on the teams involved, the leaders managing the project and the customers at the receiving end. In order to make any project successful, the foremost thing you need is a competitive, skilled human resource.
As a project manager, credible sources of information hold significant value in terms of knowledge acquisition. Aside from all the books and certifications, social media platforms are equally beneficial. One such platform to gain fantastic insights is Twitter. We’ve hunted down some of the top project managers that you need to follow on Twitter.
We’re all well aware of Twitter as a popular medium of gaining and sharing information. As we’re speaking, there are around 335 million active users utilizing the platform for exchanging information according to their interests.
I was teaching a module on Scrum Roles to an Agile Scrum Overview class recently when a learner asked for clarification as to how the role of the Scrum Master changes over time. In my experience, I see three major phases that describe the progression of the Scrum Master’s interaction with the team. In each of these phases, the Scrum Master gives up some control of the mechanics of the framework to enable the team to move ever closer to becoming a well-formed, high performing, self-managed team.
Scrum Masters are the defender of the framework. When spinning up a new team, they are entrusted with the care and feeding of a team of members who are often experiencing their first contact with Agile Scrum. The Scrum Master has the training and experience to model leadership within the framework, while giving the team room to drift and self-correct. The Scrum Master wants to see the framework used correctly to ensure a healthy feedback loop from the demos and retrospectives. They want to improve the product and improve the team. In this phase, the Scrum Master will most often facilitate the events with the hope the team will learn by observation and grow to absorb many of the leadership habits.
If you’re in the middle of a Digital Transformation initiative and planning your next release – stop! I want you to take a moment and ask yourself: “What is my focus?” Is it making sure technical staff are busy or delivering real measurable customer value?
An organization’s main driver is to deliver value to the customer, so ask yourself again: “Is my transformation program truly focused on achieving customer value? And more importantly, is my next release?”
I’ve been in IT for 25 years and was introduced to the Agile mindset in 2006. I embraced Agile immediately because many of its principles were how I already worked. I like simplicity, I developed software in iterations so I could get feedback and make course corrections, I preferred communicating face-to-face, and I put my customers and developers in the same room often so they could collaborate and ensure we were on the right path.
Fast forward to just a few years ago, when a company brought me in to help them on their Agile journey. Day one, the IT Director told me that they were “already very Agile”. They had all the right roles in place, their ceremonies seemed to be well run, the artifacts looked clean and up to date – they looked like they had it all together. But when I began digging into how they interact with each other, I saw distrust between IT and the business units which resulted in no real collaboration, almost all their communication was by email for “CYA” purposes, and there was a heavy status reporting burden due to a lack of transparency. On the surface it looked great, but underneath was a huge mess. They were doing the easy parts of Agile – the Scrum practices – but weren’t paying attention to the harder parts – the Agile principles. I’ve learned that prioritizing practices over principles is one of the key reasons for Agile failure.
Change is inevitable when it comes to project management. That’s why many project managers are electing to use Agile methodologies wherever possible. Agile project management doesn’t just accept changes, it embraces them, making it more than ideal for tracking the delivery of a project.
In this article, we’ll show you how to create new Agile projects and apply Agile views on Microsoft Project.
In my early days of computing back in the late 70s and early 80s, having an interest in microprocessor design was unusual. I remember getting almost monthly updates from Motorola and Intel on their latest chips and my shelves were filled with technical manuals.
Information flowed freely and it felt that we were part of a community figuring out how to use microcomputers in our daily work. There was a common feeling of camaraderie and it wasn’t uncommon to be able to pick up the phone and ask a technical question of a person who worked at a completely different company. We often posted what we learned on bulletin boards so others could benefit.
I’ve been practicing Agile methodologies for some time now. The most common ceremony that I’ve seen Agile teams do is stand-up also known as daily Scrum meeting.
I’ll not go into what a stand up or daily Scrum is and the value it brings. I appreciate the value it brings and would encourage teams to follow this ceremony religiously.
Every team that I’ve seen having this meeting does it in a similar fashion. They stand around in a circle and everyone gives their updates. This method sounds good, but when practised, it has a lot of problems.
I’ve listed some of the problems that I’ve seen.
One can argue that all these can be solved by one or the other way. But all those methods are difficult to implement and requires everyone to be on their toes.
One other way to fix all these problems is to use an instant messaging application like Slack. Create a group or channel where everyone will post their updates as bullet points or checklist.
Some benefits that I see:
There are Slack bots as well to streamline this process. You can explore them as well. Or you can post updates as messages.
This is how a thread in Slack looks like. People can reply and discussions can happen. Creating threads for discussions clears the clutter and make reading the updates a breeze.
Having said all that, I haven’t actually tried using Slack for the daily stand up. But I’ve fantasized whenever a discussion kicks-off during stand up meetings.
Do you face similar challenges during your stand up meetings? Would love to hear what’s working for you.
If you enjoyed this article, please like & share to help others find it! Feel free to leave a comment below.
Learn how to create whiteboards: Whiteboards are magic as they support foundational Agile principles such as interaction, collaboration, face-to-face communication, or transparency. They facilitate adapting to change, continuous improvement, and the self-organization of team. You can create meaningful software with a few index cards, pins, pencils, and a drywall—you do not need Jira or any other Agile process tools.
The first application of a whiteboard that comes to the mind of an Agile practitioner is probably a sprint board. Too often, though, our imagination is limited to the available “whiteboard space.” It turns out that whiteboards are not just well suited to display a sprint backlog or the workflow and workload of a team.
Whiteboards make excellent information radiators in general: from product backlogs, product roadmaps and experimentation and hypotheses backlogs, to visualization of technical debt or architecture diagrams, to impact mapping or user story mapping. Whiteboards provide instant transparency and invite collaboration with other team members or stakeholders. Also, whiteboards prove particularly useful in explaining team processes to stakeholders and new team members. By comparison to printed posters that seem to be both static by nature as well as “approved” before printing, whiteboards invite others to challenge the depicted status quo, as they can be changed both quickly and are reversible.
Lastly, a “whiteboard” in the sense of this article is not necessarily magnetic although those are more versatile. A drywall will do, as will a thick layer of cork.
There are four basic techniques to get offline boards:
Buy movable whiteboards on wheels and place them somewhere in the room. (There is a variety of choices, from stylish to crude will get the job done.
Of course, windows and doors are probably usable as improvised whiteboards, too, depending on what is acceptable in your office. (I am aware that asking for forgiveness is presumably easier than asking for permission. However, if you are in doubt, I suggest asking the facility management. Some of those folks are really protective due to numerous safety and governance rules.)
There are apparent whiteboard supplies such as magnets, pins, index cards or PostIts/stickies. While index cards need to be principally motived to stick to the surface of the whiteboard, stickies may work temporarily without additional means depending on the surface and the quality of the stickies. (I suggest using “super-sticky” stickies anyway, but even those submit to gravity sooner or later.)
Whiteboard markers that can be removed from whiteboard without a cleaner should be the only markers around your office. (I am aware, that there are fewer colors available for whiteboard markers.) The trouble regularly starts with mixing whiteboard markers with permanent markers for flipchart paper. Honestly, I find it hard to understand why the latter is still purchased given the high removal costs if they are used on whiteboards without being removed immediately. (Have a bottle of cleaner handy for that purpose; the ones containing alcohol are usually up to the job.)
Drawing lines on whiteboards, for example, to mark columns or swim-lanes can be a tricky thing. Using whiteboard markers is not helpful as you will need to redraw them often. Also, team members tend to wipe lines off the whiteboard when working with the board. While it is easy to remove whiteboard markers from whiteboards, removing a black or red whiteboard marker from a white shirt or blouse is a different beast. My favorite line marking tools is hence a very thin, flexible yet sticky tape that is used for painting jobs.
Another essential component of useful whiteboards is magnetic avatars. (We have them printed by a service provider.) We use them for every team members to mark the tasks someone is working on during a sprint. We also use them on the product backlog board to match tasks with teams. (We have a unified product backlog that multiple teams use.) Finally, we use them to visualize the architecture of the application.
Given that whiteboards probably are most often used for sprint backlogs or Kanban boards, here are some practices that have been useful in the past:
As always, you can observe anti-patterns when teams use tools from the Agile toolbox. In the case of whiteboards, for example, the most critical whiteboard anti-patterns are:
Let us close with another fun part of whiteboards — gaming:
One of my former teams used to identify the team member representing the team at the Scrum of Scrums ceremony by throwing little magnets at the whiteboard — give it a thought, there are endless opportunities!
Whiteboards are one of the most versatile tools from the Agile toolbox: simple to create, even quick to improvise, radiating information, and inviting everyone to collaborate and thus becoming a part of the solution.
What experiences — good and bad — have you made with whiteboards? Please share with us in the comments.
There is another webinar scheduled before the summer break:
Note: Webinars are aired from 06:00 to 07:00 PM CEST. (That is 12:00 to 01:00 PM EDT or 09:00 to 10:00 AM PDT.)
The Agile Transition – A Hands-on Guide from the Trenches e-book is a 212-page collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to Agile practices.
Within a short span of time, Agile frameworks have proven their worth in the field of project management. Termed as the best-kept management secret on the planet by Steve Denning, the director of the Scrum Alliance, Agile projects are found to be 28% more successful than traditional projects.
With a defined set of rules and roles, an Agile framework not only streamlines the project flow but can also enhance team collaboration. In fact, according to Manny Gonzalez, CEO of the Scrum Alliance, “Agile is now much more than a revolutionary approach to work for the software development industry.
It’s transforming a wide variety of industries and specialties from marketing and human resources to financial services”.
The most common practices of Agile have been summarized in the 2017 State of Agile Report. The report was compiled by VersionOne and a summary extract is pictured below.
A simple process by design, the implementation of this framework has been met with different perceptions in different organizations. From defining roles in the existing organizational structure to devising methodologies for managing workflows in different departments, implementing any framework needs time and trial. It is no different for Agile.
In order to make this concept easier to understand and provide ideas for its smooth and swift implementation, here are some tips we have gathered from experts along the way:
One approach that some organizations adopt is to be all in or all out. When it comes to the implementation of any framework, it is usually attempted to go by the book. This approach is ineffective.
XBOSoft CEO Phil Lew recommends being flexible with the Agile implementation, working with it according to the pace and requirement of your organization. He believes it should not be implemented out of the box; rather, companies should focus on the purpose – which is the access to feedback.
As long as that purpose is being served, you can be flexible with the sprints, be it two weeks or three.
Clear communication is key to success in every project development cycle. The same applies to Agile methods.
David Alsbury has over 20 years of experience and serves as the CTO for StartCHURCH. According to Alsbury, clear communication regarding the framework is imperative.
In order for the team to stay in sync with decisions and to avoid confusion, he recommends appropriately documenting stories, which are one-sentence descriptions of work. These stories should be easy to understand and should be followed up on after team meetings.
The management of any organization plays an important role in Agile implementation journey.
A lack of belief in the adopted framework can negatively impact the chances of the framework’s success. For instance, if the upper management does not believe in Scrum and does not take it seriously, it is highly unlikely that scrum will work within that organization in the long run.
That’s what Stijn Van Loo, Development Manager and Product Owner at Netlog, believes. Stijn recommends that the management proactively take part in Scrum implementation. This participation will reflect well in the corresponding teams.
Change is inevitable, but, with a good strategy, organizations can make change management easy. Adopting a framework or transitioning from an old system to a new one takes time and effort.
Employees strive within the change, which is why it is important to implement it through a systematic approach.
Scott Dunn, CEO of Rocket Nine Solutions, considers training a key element in implementing Agile framework in any organization. These trainings, according to Dunn, should not only be limited to teams but should also include management.
The Agile team needs to be clear about the concept from the beginning for easing its way into the new structure.
The importance of training the management is undeniable, as the management is responsible in implementing the change over the entire organization, in essence developing a culture for long-term success.
The role of a Scrum Master is to help streamline the Scrum framework by guiding the team. Daniela Field, a technology professional with 10+ years of experience, considers the role of the Scrum Master as one of the core determinants of the project’s success.
According to Field, some Scrum Masters tend to go off-track and resort to dictating and micro-managing activities. This, in turn, can damage the team confidence, reflects lack of trust and can serve as a potential roadblock in achieving goals.
On the other hand, some Scrum Masters are detached, leading to lack of involvement. This leads to lack of knowledge regarding the team or the project and affects the role as well. Field recommends that the Scrum Master should be approachable, well-updated on the work patterns, and have a clear idea on issue resolution.
Intricate and complicated projects can consume a great deal of time and make it difficult to not only identify but also tackle potential issues. Field recommends breaking up complex requirements into smaller, more manageable stories that can be iterated over time.
Furthermore, planning is important. There should be well-devised backup plans for all likely issues that could arise. Even if all the issues cannot be resolved at a time, the process should be carried out in a way that allows for simplified monitoring of costs incurred by implementing changes.
Project management tools have made a mark along with the evolution of other project management elements. In fact, according to research by PwC, the use of project management software increases performance and satisfaction.
Depending on the requirements, budget, and ease of use, the perception of the ideal tool varies within each organization. David Alsbury of StartCHURCH believes that investing in good software can be a game-changer.
He endorses project management applications that can help visualize the status of a sprint, such as a Kanban board. This will help the project more streamlined towards successful completion.
Your turn – do you have experience with Agile implementation? What are some of the practical tips you adopt in your Agile implementation journey? Let us know in the comments below.
Agile Methodology is a people-focused, results-focused approach to software development that respects our rapidly changing world. It’s centered around adaptive planning, self-organization, and shorter delivery times.
While it seems that nowadays most software developers claim they are doing Agile, it is also a well-known fact that many teams are only following part of the practices that characterize Agile software development.
Join the Continuous Engineering Experts’ Bryan Smith as he welcomes IBM Solutions Architect, Amy Silberbauer to the show, as she shares with us some tips, tools and templates that you can use to ensure a successful Agile deployment in your organization.
Short on time? Just click on any of the links below and jump to that section of the interview:
0:01:32 – How popular are Agile practices in a place like IBM?
0:04:10 – What are the most important concepts to grasp for organizations to implement Agile successfully?
0:06:04 – What are some of the tools specifically in the Watson IoT suite that help support Lean, Agile & SAFe Development?
0:09:25 – Why did IBM adopt the Scaled Agile Framework (SAFe) in their templates and toolset?
0:12:40 – Why would an organization choose IBM tools to adopt Agile and specifically the Scaled Agile Framework?
0:13:14 – How does the IBM CLM suite specifically support SAFe? You mentioned there were SAFe templates built in? How do you apply them and how much does it cost?
0:20:35 – Can the tools and templates provided calculate things like “Definition of Done” or “Retrospectives? — things of this nature?
0:27:32 – Can you share with us a success story from a customer who wanted to Scale Agile and use IBM’s tooling?
Have questions? Feel to contact us anytime!
Product Backlog Refinement or grooming is a vital technique to successfully deliver a valuable product to customers and users. Actually, it includes far more than requirements processing, but also strategy, planning, estimation, architecture and design, and risk mitigation. Let’s have a close look at what a Product Backlog Refinement is and how to succeed with this technique.
The BABOK Guide states:
“The backlog is used to record, track, and prioritize remaining work items.”
“In a managed backlog, the items at the top have the highest business value and the highest priority. These are normally the next items to be selected to be worked on.”
So, the Product Backlog is a collection of work items which is valuable from the Product Owner’s perspective and which needs to be done to complete the project. Product Backlog items (PBIs) may have different nature and level of detail:
The Product Owner holds responsibility for the Product Backlog. At the same time to efficiently manage the Product Backlog this activity should be done collaboratively with the Development Team.
Agile Extension to the BABOK Guide states:
“Backlog Refinement is a continuous technique used to prepare product backlog items for an agile team to deliver.”
This technique plays an important role in product development as it allows to:
Generally, the Product Owner on a continuous basis adds new PBIs, adds details such as the acceptance criteria to the existent PBIs, prioritize PBIs, etc. Nevertheless, it is highly important to have a separate Product Backlog refinement meeting each Sprint where all Scrum participants (the Development Team, the Scrum Master, and the Product Owner) can gather, review and do proper work on the Product Backlog.
The best time for such meeting would be a few days prior to the next Sprint planning meeting. This way the Development Team will have more time to understand new User Stories, do some analysis of them if needed and better prepare for the Sprint Planning meeting. The Product Owner, in his turn, can better understand the Development Team’s view and properly write/amend acceptance criteria for the highest priority User Stories, which are the main candidates for implementation in the next Sprint.
The Product Owner may write acceptance criteria collaboratively with the Development Team representative, for example, a tester.
There is no strict procedure to follow, but to leverage the Product Backlog Refinement meeting the most, it would be good to go through the following steps:
The Product Owner presents the plan for the meeting.
The Product Owner presents changes done by him in the Product Backlog since the last Product Backlog Refinement meeting (if there are any) and explains why they are needed.
The Product Owner presents the feedback and data collected from users and customers after the last Sprint delivery and discusses with the Development Team what should be changed/added to the Product Backlog based on this information.
The Development Team suggests PBIs which are of technical or quality value for the product (for example, configuration of a new CI tool which will greatly improve the product development process and make it quicker).
The Product Owner amends the Product Backlog to reflect the results of the discussions.
The Product Owner re-prioritizes the Product Backlog to have the highest priority PBIs at the top of the Product Backlog.
The Development Team may provide estimates for new/amended PBIs.
The Product Owner together with the Development Team refine the highest priority PBIs in the Product Backlog:
– Decompose Epics and big User Stories into User Stories sized properly to fit into the Sprint. (Use the INVEST criteria described in here to create good User Stories)
– Add/amend details to PBIs to make them ready to be worked on in the next Sprint.
Remember, all PBIs which are candidates to be worked on in the next Sprint should be detailed enough (have properly written acceptance criteria), small enough (to fit into the Sprint) and estimated! Use Definition of Ready criteria to produce good PBIs for your next Sprint.
Lots of teams started to use the term “user story” after moving to Agile. A User Story is a simple and elegant technique to gather customer requirements. Nevertheless, it requires a certain understanding and practice to build great software with User Stories.
Let’s have a close look at what a User Story is and how to succeed with this technique.
The User Story is a short and simple description of a piece of functionality which brings value to the user or customer, and which the team can deliver in an iteration.
The User Story should answer 3 questions:
Following this, a typical format of the User Story is:
As a <type of user>, I want <feature>, so that <value or benefit>.
Example of the User Story: As a registered user I want to be able to download my picture to my profile so that other users can see what I look like.
There is no formal procedure to create the User Story. Nevertheless, there is a guideline which should be followed to create a good User Story. It’s called the 3 C’s and was proposed by Ron Jeffries, one of the founders of Extreme Programming.
A good practice to make sure the User Story is of proper quality is to adhere to the criteria of Bill Wake’s INVEST acronym. INVEST also helps to determine whether the User Story is well understood and ready for the development team to start working on it.
Let’s be honest with ourselves: the User Story cannot be a “technical User Story” by its definition, as in such a case it will not bring direct value to the user/customer. Still, lots of teams like to create User Stories when they need to do some technical task like code refactoring. I recommend to use other work items for such tasks, and agree on this type of work with your Product Owner for him to see why it is necessary. The same relates to nonfunctional requirements tasks, interface design tasks, complex user interaction tasks, or bugs. You are free to create other work items for these tasks. For example, a Constraint Story may be used to represent nonfunctional requirements. The User Story is a great technique to capture product functionality, but we are not obliged to use it for all purposes.
Prior to writing User Stories, there should be a clear understanding of who is the user for whom the User Story is created. Sometimes it is overlooked by teams new to the User Story technique and they end up creating software with needless features. So, do a proper user research to have all your user types or user roles or personas writing down and described. Two techniques that can help you with this are User Role Modeling and Personas.
Generally, customer representative such as a Product Owner is responsible for User Stories. Nevertheless, User Stories are not specifications given from the top level to the team, but more a collaboration technique between the Product Owner and the team. That’s why it is better if User Stories are written collaboratively. A great way to do this is a story-writing workshop.
As User Stories are not specifications, details are conveyed in a different way:
Use the Definition of Done technique. Simply put, Definition of Done is as a shared understanding between team members of what it means for work to be complete. Definition of Done is usually created in the form of the checklist of activities, which demonstrates agreed value (user acceptance tests to satisfy user acceptance criteria) and quality (to satisfy quality criteria). Teams sometimes neglect the last one, what can make the User Story not potentially shippable to the customer at the end of an iteration. Definition of Done technique helps to avoid this.
Example of Definition of Done:
Done is when:
At the beginning of a project, we need to define a rough scope of a product to have a global vision of it. This can be done with Epics. An Epic is a big chunk of work that has one common objective. The Epic can be thought of as a placeholder for more detailed User Stories which are created later. The Epic usually takes more than one iteration to complete.
Use the Story Mapping technique, invented by Jeff Patton. Story mapping represents a top-down approach to requirements organization and also is a great way for prioritization and planning.
Agile Extension to the BABOK® Guide v2 states:
“Story Mapping provides a visual and physical view of the sequence of activities to be supported by a solution. It uses a two-dimensional grid structure to show sequence and groupings of key aspects of the product on the horizontal dimension, with detail and priority of stories on the vertical dimension. Story Mapping is a decomposition technique which allows for the evolutionary understanding of a solution starting with an end-to-end view and drilling down to the detailed user stories.”
Example of Story Mapping (created by Steve Rogalsky):
It’s a wide term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.
Based on priority, solutions evolve through collaboration between cross-functional, self-organizing teams utilizing the required practices.
The majority of organizations do have a basic idea about agile software and its implementation benefits. Increasingly the challenge we see moving through 2017 and into 2018 is how to scale Agile beyond the just initial point to maximum potential.
Organizations choose agile so they can respond quickly to changes in the marketplace or feedback from customers without derailing a year’s worth of plans. A shared vision and coordination between agile teams, then, brings it to life the way they know is best. Our own standards for quality, usability, and completeness is been set by teams.
Waterfall, or traditional project plans, are often developed in advance based on the best information available at the time. In order to reduce the risk of the unknown, the team lays out the entire project and assigns all of the work so nothing is forgotten. This results in a highly detailed plan, often scheduled down to the hour, stretching sometimes six months to a year out into the future.
In the case of agile development, it is addressed carefully at multiple times. At the high level, it is a release plan which highlights what functionality the team is planning to deliver for the next several iterations. Agile project plans are organized into 2-4 weeks in length. During those iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies.
Agile should always remind the customer what will be done and what customers are expected during the sprint. Teams are communicated constantly so as to improve the quality of the product and to achieve customer satisfaction.
For Agile-based teams, the amount of work possible to be done is selected on the basis of the available hour’s team. Simultaneously, the team decides what it is able to do based on their capabilities and experience from the previous iteration.
Note: Iteration is the generic agile term for a single development cycle. Sprint is Scrum specific, hence Sprint is an iteration but not all forms of Iterations are Sprints.
The duration of the sprint is stiff and takes place within a specified timeframe, which ranges from two weeks to a month. SCRUM meetings, which last about 10-15 minutes each day, are also stiff in nature. As the project progresses, the cone of uncertainty narrows and the team gets a more accurate estimate of the amount of remaining work on the Product Backlog
This is done on two principles. First, define the product based on user stories, which are based on his analysis of the business. Then define dependencies between the business and technical functionality.
Functionality is described and defined and communicated to the client and the product description is defined in a specific way. They contain mostly three main sections: description, acceptance criteria, and estimation of the time, based on complexity. If the User Stories are too complex, they are broken up into smaller pieces, so as a whole would be processed within a few sprints.
Short morning meetings are held, lasting about 10 minutes. The whole team is present and led by the Scrum Master. In this meeting, three main issues are addressed: to remember what was done yesterday, to define the goals for today, and check to see if there are any obstacles to peaceful work. Additionally, in the case when you program in pairs, we need to define who is who in the hand.
By implementing Agile improves organization productivity, engagement also helps to avoid conflict with teams. Many organizations adopting agile practices are seeing an increase in productivity and customer retention.
Regularly, InfoQ applies the ‘Crossing the Chasm’ metaphor to engineering practices, thus covering a part of the agile movement to create learning organizations. Its recent ‘Engineering Culture and Methods InfoQ Trends Report – January 2018’ edition found that new converts to Scrum, for example, will recruit themselves most likely from the late majority and laggards. (The early majority of organizations is already adopting Lean, Kanban, and Scrum derivatives.)
Those laggards — or legacy organizations — are easy to spot: some form of applied Taylorism, usually a strict hierarchy to command & control functional silos with limited autonomy, made it into the postindustrial era. Often, these organizations were created to train farm boys into assembly line workers within a standardized industrial process churning out standardized products in the name of output optimization. Human beings became cogs in the machinery, rewarded for functioning well without asking questions. Too bad, when nowadays diversity, autonomy, mastery, and purpose become the driving factors in a highly competitive environment where more of the same for everyone is no longer creating value.
Copyright notice: InfoQ, 2018. All right reserved.
The conflict at the stakeholder level in such legacy organizations is apparent: mostly, the stakeholder is a manager of a functional silo with objectives that do not necessarily align with those of a product or scrum team. Where the organization needs to morph into a kind of ‘team of teams’ structure with a shared understanding of purpose and direction as well as the need to create value for the customers at heart, the reality of a legacy organization attempting to become agile is often very different. For managers is means moving:
Abandoning yesterday’s game – and probably its symbols of power, too — and accepting that an agile transition may provide job security, but most certainly not role security, is a monumental undertaking for the majority of the management of a legacy organization. Probably, many of these managers will not adapt and even quit the organization sooner or later.
After defining the context, let us consider scrum stakeholder anti-patterns in detail. Most often, scrum stakeholder anti-patterns result from a training and coaching void accompanied by not changing individual career objectives. Thus, they manifest themselves in the continued pursuit of local optima or personal agendas. In both situations, the incentive structure of an organization most likely still fosters a predictable behavior that contradicts the organization’s goals at a system level.
The following list of scrum stakeholder anti-patterns addresses scrum ceremonies, system related issues as well as issues of individual players.
Most anti-patterns in this category result from perceived information needs — think of them as withdrawal symptoms:
Anti-patterns of this sort point at stakeholders’ ignorance of the core idea of scrum — self-organizing teams:
Again, this category is often a combination of ignorance, fighting a perceived loss of control or pulling rank to override scrum principles:
Here, it is mainly about control and line management issues:
These anti-patterns result mainly from a half-hearted approach to becoming an agile organization. Typically, it ends in the form of cargo-cult agile:
There are numerous ways how stakeholders can impede the progress of a product team. Four of the most common ones are as follows:
For more information watch the webinar: Product Discovery Anti-patterns.
There are a lot of different reasons why scrum stakeholders do not act as expected. Some result from organizational debt, particularly in legacy organizations from the industrial area. Some are intrinsically motivated, for example, by personal agendas, while others originate from a lack of training or anxieties. Whatever the reason, though, scrum stakeholder anti-patterns need to be overcome to make an agile transition a success. Otherwise, you might end up in some form of cargo-cult agile.
Which scrum stakeholder anti-patterns have you observed? Please, share with us in the comments.
This ebook covers over 160 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patters Guide” now!
My introduction to the underlying Agile principles started in the manufacturing domain, not software. This taught me to appreciate continuous improvement ideas even more, especially the retrospective practice. Here’s why.
After studying Lean manufacturing, I understand why Agile projects are 28% more successful than traditional ones. A huge part of this is Agile retrospectives.
Unlike software, failed physical products are usually unfixable. You can recycle ideas, but materials – only partially and in rare cases. If your physical product fails to sell, you can’t simply go back and fix the code.
In the software development world, however, we can always go back and fix the product. Agile retrospectives enable us to prototype faster, deliver new updates more regularly, and be totally in control of our quality assurance.
This is the power of Agile. And all it takes is a serious systematic approach to retrospective meetings.
In Agile, retrospective (“retro” for short) is a kind of post-production meeting, usually an hour-long, that a team holds after each week or sprint (for SCRUM projects). During retrospective, developers discuss the successes and failures they faced during the stage.
The purpose of Agile retrospectives is to identify the root causes of every issue and find ways to avoid them in the future.
It’s true that continuous improvement should be practiced during production just the same as after it. However, when people are already busy working it’s harder to start any new initiatives.
Retrospective, on the other hand, gives breathing space for ideas and time to regroup before the next stage. Your team can relax and focus on improving collaboration and efficiency.
After the retro, it’s a common practice to list points outlining the improvement areas and ideas. Each retrospective the team turns back to the previous list and adjusts the new one accordingly. Meeting at regular intervals is the key here.
Daily processes love continuous improvement but usually leave us no time for a second thought on how to actually implement it.
Also, when team players work on improvements separately, suboptimization occurs. Individuals perform better, but the overall project still may fail.
Agile retro-spective allows us to put things into per-spective. As the final principle of Agile Manifesto states:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Which is indispensably connected to another Agile principle:
“Continuous attention to technical excellence and good design enhances agility.”
People who can rely on each other and together pursue technical excellence create best-performing teams. They save a lot of time and resources both for themselves and the company.
Teams that practice retrospective meetings eliminate recurring problems, improve their workflow, and deliver better products faster. They also set the pace for the rest of the company, motivating other teams to improve.
Looking for the most efficient ways to deliver value together creates a catalyst environment for the changes.
Retrospective allows team players to make their own decisions accept responsibility. As a result, your team will grow in maturity and self-motivation.
Retros bring people together, and if done correctly – train them to be more understanding and helpful towards others.
Any issues at the workplace are either human issues or they affect someone personally. Agile meetings create a comfortable space to talk about and ease those frustrations.
Retros are awesome, but they are also very easy to screw up.
Don’t let your meeting become toxic. Let people speak out about their frustrations, but keep it constructive. Finding solutions to the problems is more important than talking about them.
You don’t have to entertain people, just help them stay focused. Long projects burn enthusiasm – it’s normal. Make routine interesting with new retrospective exercises and approaches.
Make sure that every team member feels safe to share their insights. It’s better to keep some things in the family.
Trying to improve everything at once is dangerous. Set priorities and use short, practical action plans.
The project manager or Scrum Master running the meeting has to prepare the agenda beforehand. You also have to plan regular future meetings.
Actively lead the retrospective, encourage discussion, and take notes. Make sure that every team member feels welcomed to participate.
Arguments against personality is a logical flaw, and they rarely help anyways. Focus on what, not who – identify behavior issues and help solve them with understanding.
Giving the right example is the best way to build authority. Accept and keep responsibilities. Own your decisions as much as you own the meetings.
As a manager, you can observe the workflow from top to bottom. Seek for the points in the process that need improvement. Think about the main obstacles in the daily workflow and how they can be removed.
We’ve touched on this earlier, and much more can be added. Just remember that “the P in PM is as much about ‘people management’ as it is about ‘project management,’” as Cornelius Fichtner has put it.
Productive retrospective means that you get a practical to-do list at the end of it. Use the Who-What-When method – it will be easier for you to manage responsibilities on schedule the tasks.
Hopefully, by now you understand enough to organize your first Agile retrospective. And if the magic doesn’t happen, don’t give up – focus on the continuous improvement. After all, that’s exactly the point of Agile methodology.
Product backlog defense — make no mistake: your product backlog is the last line of defense preventing your team from becoming a feature factory. Figure out a process that creates value for your customers. Moreover, have the courage — and the discipline — to defend it at all costs.
In my keep-it-simple and thus two-dimensional product world, the product backlog defines the near-term planning as the lynchpin of the product creation process:
The near-term planning horizon in my mental model covers about four to eight weeks. It is where the product discovery phase delivers validated ideas of valuable product increments to the product delivery phase. (I shy away from calling it a hand-over as this term has a negative connotation, and rightfully so.)
At this moment, there should be no longer doubts why a product increment is valuable to your customer and your organization — the “why” question has been answered at this stage. You will probably still discuss the scope of the idea for its first delivery, and the engineers will think about how this product increment will fit best into the application. However, the discussion among the team members should no longer revolve around basic questions from the “valuable, feasible, usable” perspective. That has been accomplished further to the left side during the product discovery phase.
If you are practicing scrum, the near-term planning will cover something between two to four sprints:
This transfer from product discovery to product delivery is a serious moment from the investment perspective. Now, the team gets real and allocates resources to product delivery, for example, the continued collaborative refinement of the related user story. Or sketches are turned into designs, and probably some preliminary work is required on the tech stack side.
Now the team becomes accountable for spending money and producing a return on investment. If you fail to deliver this return because you accepted some work that bypassed our team’s product creation process for whatever reason you will be rightfully accountable for this failure, too. And no one will be interested in reading the fine print why this happened. It is on you.
Crossing the before-mentioned threshold is also the reason why the near-term planning or the product backlog part of the product creation process is so attractive to stakeholders who try to bypass the process and sneak in requirements or features.
Entering a competition of ideas and hoping that an idea will pass validation is a considerable effort and bears a significant risk of being rejected. The shortcut of targeting the near-term planning phase instead is hence less risky.
Typically, you can attribute a stakeholder’s attempt to evade the competition of ideas part of the product discovery phase to his or her incentives provided by the organization. Or as Charlie Munger puts it:
“Never, ever, think about something else when you should be thinking about the power of incentives.”
There are various patterns of flanking maneuvers, depending on the nature, age, and the size of the organization. For example:
There are at least seven flanking maneuvers that make the product backlog defense mandatory for any product team:
A note of caution: Do not outflank yourself during product backlog defense. The discipline to defend your product creation process from stakeholders’ attempts to bypass it needs to be applied with the same rigor within your team. For example, do not use the product backlog as a repository of ideas and requirements that might be useful at a later stage. Apply the same rules indiscriminately to everyone.
If you want to be taken seriously as a product team and if you want the organization to accept your product team as the go-to team that solves critical customer problems and identifies opportunities for the organization, then defend your process with tooth and claw. Making exceptions from this rule is a slippery slope leading to becoming a feature factory.
The Agile Transition – A Hands-on Guide from the Trenches ebook is a 212-page collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to agile practices.
Over the past year, I had the chance to be quite close to a significant project in terms of scope and team size. All in all, over 100 people were involved, with more than 60 working full time on the project.
Out of those 60 people, over 40 were involved in engineering, while the others worked as the Technical & Solution Architects, Business Analysis, User Experience Engineers, and Project Managers. Out of the 40 engineers, over 60% of the team was involved in mobile and frontend implementations while the rest were focused on backend and QA automation.
The methodology selected for the project was Agile, more specifically Scrum. Multiple teams have been assembled with Scrum of Scrums high-level sync between teams. Everything looked good and ready.
Fast forward six months, the progress looked good compared to projects similar in terms of scope and team size, well above average. Still, there were things that could’ve gone better at all levels.
Looking past the inherent challenges of the newly formed team and the time to find its own rhythm, the communication process within large organizations, the delays from integration with dozens of external systems and the typical overhead when managing a large team, here are some of the things we’ve learned, that anyone should be aware of when dealing with a similar situation:
A Scrum recap before project kickoff–while the vast majority of the team members were familiar with Scrum, each had some variations in understanding the process based on personal experience. Aligning team members as well as key stakeholders before the meeting might be a useful practice before kicking off any project, regardless of its size.
While there are millions of articles on how to implement Agile within a team, the topic of what should stakeholders / top managers expect from Agile probably still needs more exposure. While it is usually part of the digital transformation programs or part of the whole process of making an organization Agile, setting up expectations through a very specific alignment session, can help a lot along the way: “Here what it means for you, how you will interact with the product development, how it can affect deadlines, etc.”
Agreeing on a Definition of Done is fundamental to successful agile. What happens, however, if the live environment is gonna be ready in 5 months? Over the course of 5 months, no user story will respect DoD, and the product owner’s perception is basically that nothing is actually done.
Adopting and adapting an intermediary DoD, valid for a certain phase of the product is key to setting the right expectations. Ideally, any project should have all its environments ready before project kickoff. The reality is different and it’s not just about the typical multi-stage deployment of one solution, but also the various stages of other external systems. Within this particular case, a critical external system hasn’t had its staging (or live) environments ready for over more than 5 months since development kickoff.
When dealing with dozens of good engineers, project governance should also include a way to address the typical healthy technical tensions that can come up in time. Setting up a technical escalation point per technology from the beginning is critical in preventing the potential delays from various team dynamics. Technical leaders for mobile (iOS and/or Android), frontend, or backend should smoothen things as the project progresses.
A lot of time is spent integrating with external systems. As specifications become more and more clear, API changes make team members go back and forth, and can be a headache for both the team and the agile coach. A good architectural choice is to use an SPA framework that would allow mobile and desktop versions of an application to consume the same API implementation from the backend team.
In such a case, backend and frontend (be it mobile or desktop) can often be regarded as two different systems integrating through an API. While for this project the initial choice of cross-functional teams with 1-2 Backend engineers, 1-2 iOS, 1-2 Android, 1-2 desktop-frontend seemed like a good one given the flow of the input from the Business Analysis team, as the project progressed it became clear that the delays were mostly from the back and forth communication between frontend/mobile, backend and business analysis team.
One way to optimize this is through better planning in the backlog grooming meetings, trying to get the team to agree on API signatures as early as possible.
A second way is to try and have the backend move one sprint faster than the frontend/mobile teams since, as in most cases, there are still issues when doing the actual implementation that a grooming/planning session cannot foresee. Hence, the system cross-functional teams moniker. While three engineers (one iOS, one Android, and one frontend) could work on the same functionality, having the API agreed and preferably ready before the sprint starts can drastically improve the overall team efficiency.
A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.
Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.
Burn-down charts have become popular to provide team members as well as stakeholders with an easy to understand status whether a sprint goal will be accomplished. (Critics of the burn-down chart may note, though, that a scrum team should have a gut feeling anyway whether the sprint goal is achievable.)
Hence, this post is focusing on another useful aspect of burn-down charts: they are equally well suited to provide additional insights into all kind of impediments, both at a team level and at an organizational level.
The following graphs visualize four of the typical anti-patterns that can be easily detected with burn-down charts:
The product owner accepts or rejects tasks only late in the sprint:
This behavior may be rooted in various issues, for example:
In this case, the graph is located above the line of the expected progress for the complete sprint length:
There are several reasons why this might be the case:
The scope of work increases over the course of the sprint:
Most of the time, this pattern can be attributed to inadequate preparation:
The team accomplishes the sprint goal way earlier than expected:
Of course, an early finish is the anti-anti-pattern if the team figured out how to deliver a task with much less effort than expected. Or the sprint goal could be achieved with fewer tasks that planned.
However, the positive news might also hint at some problems. Again, the reasons for this phenomenon are multi-faceted. My two top-candidates are:
It is a good idea to use burn-down chart patterns for the next retrospective as they easily identify team problems or systemic dysfunctions. And utilizing burn-down charts in that capacity does not even require switching to story points per se—equally sized stories can just be counted to create a dimension for the y-axis.
Enhancing burn-down charts with additional data, for example, context and occurrences, as well as lead time and cycle time values, will increase the benefit of burn-down charts even more.
Speaking of which: At the team level, I would suggest creating a rotating scheme of team members to update the burn-down chart daily. It is a team exercise and not the job of the scrum master.
Lastly, no matter what purpose you are using burn-down charts for, avoid falling into a common trap: Start counting subtasks. This accounting will quickly lead you on the track of abandoning your definition of done. Instead, you will start marking tasks as 90 % complete. Welcome to cargo cult agile—how would that differ from the waterfall approach?
What scrum anti-patterns that burn-down charts can reveal are missing? Please share with us in the comments.
This ebook covers over 160 Scrum anti-patterns, and it is available for free right here:
Agile brings a lot of benefits, provided it is used in the right way. I thought I’d share my experiences. Feel free to comment with your thoughts and experiences!
Agility (the ability to move quickly and easily) helps in making software development lightweight, easy, simple, minimizing the process and overheads, allowing you to meet and beat the market.
It majorly focuses on two parts:
At a high-level, Agile looks very rosy, but, it all depends on the people using it. The Agile matrix is very important to execute the cycles, otherwise, the entire project could become tough to manage.
Agile is not about expediting things with rush or adding more pressure. Agile is for expediting the development and releases to meet and beat the market by augmenting the efficiency levels in the system.
Agile is not just splitting the whole work into some number of Sprints/iterations and starting development or trying to increase your number of meetings somehow. Agile is about bringing in more accuracy, predictability, and addressing needs early and quickly.
Agile is not about dragging out projects with rough estimates and constant change. Agile is about estimating with peers, allowing logical decisions to play a vital role.
Agile is not about burdening the engineer and trying to somehow get more features. Agile is about empowering the engineer to get his job done more efficiently.
Agile is not about just defining some process and follow. Agile is about individual interospection and retrospection as a team on what works and what not and drive towards the goal.
Agile is not about doing something and taking corrective or preventive actions. Agile is about avoiding stereotypical work and creating more bandwidth in order to create more business. For example manual testing.
It is important that we understand the major Agile frameworks in use. This article, I have covered more at Agile level (which can be customized to a framework) and not covered at the level of any Agile Framework.
Scrum teams work in iterations called Sprints, a duration with fixed start and end dates, to accomplish a set of tasks. These iterations help teams to give more accurate predictions, allowing them to effectively say when they will be able to deliver a piece of code. A time-bound commitment rather than an open-ended one, with daily update meetings (Daily Scrum), helps in creating early feedback cycles.
Kanban is like Scrum but the iterations may or may not be symmetric. The duration of the iteration will be defined by the team and there is no role(s) specifically designed for Kanban; though roles like Product Owner can be taken from Scrum – this is basically a matter of individual preference. Meetings are held on an as-needed basis.
Scrumban is combinations of Kanban and Scrum wherein, typically, roles are taken from Scrum and iteration models from Kanban. Meetings are basically held on an as-needed.
As a team, identify a model that works. Basically, choose a series such as Odd/Even, Fibonacci, or T-shirt sizing.
I have kept very high level on the below topics but otherwise each and every area can be an article byitself.
Once this platform is in place, on top of it, value/functional stories can be developed. So, have Sprints for all the engineering work to be done (Sprints are not just only for functional requirements).
Agile is not a better word to use if any or none of the below are in place:
Quantifiable Code/Test Metrics
Many tools available help in executing Agile practices, but it all depends and matters on how easy they are to use and if we are really using them.
Finally, Agile allows us to have less process overhead and work more on the engineering.
Refer to my article that could help in building a part of an Agile development environment.
The Scrum Guide does not mandate the use a burndown chart to monitor progress. Scrum requires only that Remaining work for a Sprint is summed up and made known on a daily basis and that trending toward completing the work of the Sprint is maintained throughout the Sprint (Scrum Guide). Although the Scrum Guide, even not in the 2017 update, does not mandate the use of a burndown chart, I do advice Scrum Masters to use the burndown chart because it can tell you so much about the Scrum team.
Because I found myself repeating a lot of what the burndown chart can reveal, I decided to write down the most common patterns I have.
This is how the burndown chart usually looks for teams just getting started. This is, of course, assuming that the team can reach the Sprint goal at all. Teams who have a similar burndown chart usually have team members assigned to a story. This is also the reason why the first stories which meet the Definition of Done (DoD) are pretty late in the Sprint. It could very much be that testing is still done by a specific team member and not by the whole team. I usually advise the Product Owner to ask the team at the beginning of the second week (in a two-week Sprint) how they feel about realizing the Sprint goal and which of the stories they feel confident about and which ones they are a little worried about. In this situation, the Scrum Master has to challenge the team on meeting the DoD. This is very important to take into account, it is not uncommon that team members ignore the quality standards of the DoD to finish before the end of the Sprint.
Most teams start laughing when I tell them that Super Mario has joined them in the Sprint. Luckily, the team then quickly starts to analyze what happened in the Sprint. Usually, two main reasons are mentioned for the Super Mario burn down. The first one is that the team has added new stories to the Sprint. Digging deeper, it is not the team which has added new stories, it is the Product Owner who has asked, read “demanded,” to add new stories because … well, there are enough excuses to add new stories to the Sprint. Scrum Masters must be aware and discuss this behavior with the Product Owner and challenge the backlog to eliminate the need to add stories to the running Sprint. also, it is wise to coach the team members to say NO to interruptions and additions to the Sprint.
The second common reason is that there is still a lot of discussion about the DoD. Team members have closed the story and after discussion, they reopen the story because the story does not meet the DoD. Firstly, the Scrum Master must be happy that the focus on quality is at the front of the team’s mind. Additionally, the Scrum Master can challenge the team to improve the process of the DoD so that the whole team agrees on what the DoD should look like.
Even if the team starts the Sprint off strong by finishing a couple of stores, a big challenge still lies ahead. Usually, such burndown charts reveal that the team did not succeed in breaking all stories into smaller stories. Obviously, the team can be challenged during the refinement sessions to make the stories smaller. Another reason can be that the team did not realize that bigger stories are risky to save for the end of the Sprint. It could be that the team is focussing on finishing the stories based on the priority set by the PO. However, the team must not only focus on the initial priority but create a strategy to finish the stories, or anything needed to realize the Sprint goal. In that case, it is better to start with the bigger stories and leave the smaller stories for later in the Sprint.
The ultimate dream of each Scrum Master and Product Owner is the nearly perfect burndown. This burndown reveals that the team has the Sprint under control. The user stories are small enough that they can each be finished within a few days. The chances are that the whole team is working on one or only on a few stories at a time. For the Product Owner, this burndown provides the predictability to update the stakeholders and to prepare for the Sprint review. Although I really like the nearly perfect burn down, I do get suspicious when I see this kind of burndown pattern for a few Sprints. I usually advise the Product Owner to challenge the team and “force” them to commit more.
I hope this article helps you to look differently at the burndown chart and see what is really going on within the team. And I am also curious which patterns you have encountered and what it tells you about the team.
71% of meetings are considered unproductive. Let’s fix that.
“If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be ‘meetings.”
― Dave Barry
We’ve all been there. We get to work at 9 am (or 10 am if you’re on the West Coast), and open up our calendars to check the agenda for the day. Yup, looks like another day where 50%+ of the time will be dedicated to a meeting.
The ironic thing is: no one loves meetings. In fact, we all complain about them: too many, too long, too often. But, we still schedule them, we still join them, and we still go with the flow.
And why is this? Well, meetings are represented and ingrained in our work cultures. More progressive cultures will have strict meeting policies, but the majority of workplaces have no meeting policy or a bad one.
So, what do we hear day after day?
Wasn’t able to get anything done yesterday, had to go to a bunch of meetings.
— The Developer
Find a slot on my calendar if you can, though I’m pretty booked up.
— The Director
Oh my god. A one hour meeting just for that? They could have just sent an email!
— The Marketer
Ugh.. I have meetings all day… to schedule more meetings.
— The Sales Rep
This article is focusing on the more formal type of meeting — where a defined block of time is set aside with a defined purpose (standups, formal business meetings, formally arranged conferences, recurring meetings).
Often, we conflate the word ‘meeting’ with a normal workplace interaction, whereby you will discuss work-driven objectives with your coworkers in a more informal capacity. These are typically more organic interactions without a set time interval and can happen spontaneously.
Let’s look at a sports analogy: football (American). There is continual interaction throughout the entire game: players on the sidelines, coaches, players on the field, the quarterback, etc. The players interact with each other the entire time. The players on the field huddle up prior to the play, but only for less than a minute. Those on the sidelines are still interacting and preparing for their time to play. Coaches are chatting with individual players or with small groups of players here and there.
At halftime, there is a more formal meeting where all players go into the locker room. This is the longest meeting and it only happens once per game. It is a chance for leadership to have an all-hands sync up with the entire team to discuss objectives, strategy, and reflect on the first half of the game.
Teams have a limited number of timeouts per game, that we’ll call ‘elective meetings.’ These timeout meetings are used only when necessary in case extraneous circumstances call for a change of plans.
Every meeting has a very defined purpose with an equally strict timeline and every meeting must result in some sort of decision to move things forward.
So the question is: should our workplaces treat meetings like a football team does? And, if so, why aren’t we and what are the consequences?
Back in the days of landline telephones, no computers, and no cell phones, meetings were much more of a necessity. You couldn’t Slack someone in a different building or coordinate an email thread with multiple participants.
In the early 20th-century, the friction to coordinate a meeting was much higher.
In fact, the friction to coordinate a meeting was much higher. You had to schedule in advance, make sure everyone was properly notified, and make sure everyone could attend. There was no Google Calendar to sync invites and reschedule with a push notification.
I don’t want to claim that meetings were necessarily more or less productive back in the pre-tech days, but I can imagine that the opportunity cost and planning cost were much greater.
As the 20th-century pushed forward, companies grew and grew to massive sizes —in multiple regions with multiple different teams. Coordination became a widespread organizational challenge.
In the later 20th-century, multi-region companies inherited the culture of long and frequent meetings, but now at scale.
Inheriting the culture of the early-20th century, these companies still embraced a culture of long and frequent meetings — where decision-makers transition from one meeting to the next, making or deferring decisions based on very limited information.
Now with the introduction of simple video conferencing, meeting schedulers, and automated calendaring, meetings have become frictionless to coordinate. You simply select your participants, find some time where most or all are free, and plop it on their calendar.
In the modern tech age, scheduling and organizing meetings have become frictionless — meaning more meetings, more often.
Scheduling and organizing meetings have become frictionless. Ironically, the toughest part is finding a time that works for all the relevant stakeholders because they are booked in so many other meetings.
71% of meetings are considered unproductive— meaning that they had no clear outcome and no productive next steps — Microsoft Study
92% of respondents confessed to multitasking during meetings — Source
36–56 million meetings per day in the U.S. — Source
15–20% of an organization’s collective time is spent in meetings — Source
$213 billion per year is spent on unproductive meetings — Source
71% of meetings are considered unproductive — Source
In an organization where meetings are long and rampant, they become ingrained in the organizational culture. Suddenly, being busy does not mean you are doing a lot of work or being productive… busy means that your time is dedicated to meetings.
In a meeting-driven organization, being ‘busy’ does not mean you are being productive — it typically means your time is dedicated to meetings. Therefore, you are time-constrained, but not necessarily busy producing value for the company.
Ineffective and cursory decision-making — Due to the frequency and length of meetings, preparing adequately for every meeting becomes daunting and near impossible. So, what happens is that teams are making abrupt and poorly-informed decisions based on limited information. Or, teams will just agree on an outcome just to end the meeting early.
In meetings, teams will agree on an outcome just to end the meeting early — often leading to ill-informed decisions.
Task Interruption — When an individual contributor has meetings scattered throughout the day, your ability to concentrate and work on your tasks becomes interrupted. There is a ramp-up time to start working at a steady cadence, so every time you are interrupted, you have to re-ramp up.
Time Gaps — Building on task interruption is the notion of time gaps. If you have a meeting that ends at 10:30 am and one that starts at 11:00 am, then are you really going to try to churn out productivity in that 30-minute slot? At most, you’ll get 10–15 minutes of work in before you need to go to your next meeting. Most likely, you will just decompress and relax during that time gap before your next meeting.
Energy Drain — Remember that boring class in school? Where you watch the clock and your mind wanders? You struggled to stay awake and struggled to entertain yourself. You aren’t sure what the teacher is saying, so you just agree with the class and hope that you can get excused early.
Morale Drain — When everyone is bored, lethargic, or distracted around you, then it drains the morale from the room (see the cartoon below).
The perfect meeting is one that is:
If the paradigm for a ‘perfect meeting’ is implemented organization-wide, then you may start to see the following cultural shift:
80% of meetings should be no more than 15 minutes long.
Meetings should enhance productivity, inspire creativity, and enable teams to move faster — not the opposite.