agile best practices

6 Tips to Boost Team Motivation for Your Agile Team

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.

Original Link

Top 10 Project Managers to Follow on Twitter in 2018

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.

Original Link

How the Role of the Scrum Master Changes Over Time

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.

1. Facilitator and Teacher 

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. 

Original Link

Is the Customer at the Center of Your Current Development Project?

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?

Optimize for 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?”

Original Link

Are Agile Principles More Important Than the Practices?

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.

Original Link

Keep Track of Your Project the Agile Way Using Microsoft Project

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.

Original Link

Sharing Knowledge

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.

Original Link

What if We Do the Daily Scrum Over Slack?

Image title

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.

  • Stand-up is a meeting. Everyone joins in-person or on-call regardless of convenience. Someone might prefer a meeting later but everyone else might want it at 9 am. Pushing that meeting to a later time can be a challenge. Why? Read the next problem.
  • Stand-ups tend to become the start of a day. Every team that I’ve worked with had this problem. Most of the team members came to the office just before the meeting or mid-way. Even if they came early, they don’t start work as they know there is a meeting in another 15 minutes or so.
  • People might forget important updates as they showed up at the last minute or were late and aren’t prepared.
  • Anyone who doesn’t show up will miss everyone’s updates. And everyone misses their updates.
  • Stand-ups take a lot of time. They are intended to be short but generally go beyond the time limit. I’ve seen small teams dwelling on updates and large teams having too many people with vague updates.
  • Not everyone is interested in everyone’s update. This is especially true for larger teams.
  • People start solving problems or spark discussions in stand up meetings. Someone might know a solution to a blocker and they feel compelled to explain it. Someone might use it to discuss new ideas. An issue can cause people to replan things in the middle of the meeting.

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:

  • The biggest benefit is that it makes one less meeting to attend.
  • The flexibility of when to share/read updates. One might want to share update at the end of the day, when it’s easier to remember what you did, or in the morning. 
  • No start of day ritual. Those extra minutes of everyone add up to a lot.
  • People don’t forget updates when writing them down, and they get time to think.
  • No one would miss anyone’s update.
  • Members who were on leave can also read older updates and get on speed.
  • One can skim through irrelevant updates.
  • No one’s time is wasted with long meetings and untimely discussion.
  • Members can use Slack for discussion over updates. Also, sometimes those updates and discussions are important and now you have a place to look back.

There are Slack bots as well to streamline this process. You can explore them as well. Or you can post updates as messages.

Thread in Slack

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.

Original Link

Create Whiteboards for Transparency and Collaboration

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.

Create Whiteboards for Transparency and Collaboration

Use Cases of Whiteboards

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.

Create Whiteboards for Transparency and CollaborationGetting Practical: How to Create Whiteboards

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.

  1. Install prefabricated magnetic whiteboards on walls. It is the most expensive option with regard to cost per square meter. Moreover, often ready-made boards are either too small, or the boards do not fit the available wall space. Setting them up in the middle of the room can become a wobbly installation.
  2. An excellent alternative to ready-made whiteboards is plain non-magnetic drywall. It is great for index cards as long as you are willing to use pins. You can achieve a similar effect with covering a wall with cork or other soft materials.
  3. Lastly, another alternative is turning a wall into a magnetic whiteboard. A client recently transformed about 20 meters of drywall into a huge whiteboard — almost 3 meter high — at the cost of about $ 70 per square meter. (We run meanwhile also product backlog refinements in front a part of this mega-whiteboard.)

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.)

Create Whiteboards for Transparency and Collaboration

Whiteboard Supplies

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.

Image from

How to Use Sprint Boards

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:

  • Team name: Put the team name or team logo on the board.
  • Team members: Create a list of team members. If you use avatars, match names and avatars here.
  • Basic dates of the current sprint: Start with the sprint number, start and end date, the standup time, and probably other ceremonies as well.
  • Sprint goal: What are we fighting for this time? Make it visible prominently, written in large readable letters.
  • Swim-lanes: Create swim-lanes to make information intake easier. These can be regular lanes, or maybe your team likes to separate non-functional tasks and bugs from other tasks. It may be useful to have one swim-lane per tasks to avoid cluttering the board with unaligned stickies or cards.
  • Use templates: Standardize the cards or stickies on the board by creating a basic design. This design applies to color-coding cards and markers. For example, always use the same color for bugs and write or print the ticket number at the same spot on the index card or sticky. Reduce the cognitive load and thus make it easy to read a card or sticky from a distance.
  • Daily Scrum: Run standups in front of the boards and move cards. (This should be a no-brainer, but does not seem to be one. There is a reason why salespeople want you to touch new clothes before buying them. The resulting haptic experience already instills a level of perceived ownership. Putting an avatar to a card, moving a card makes it your card, too, supporting self-organization and creating a sense of accountability.)
  • WIP — limit the work-in-progress: There are several ways to limit the amount of work-in-progress physically. For example, limit the number of magnetic avatars and make it a rule that you cannot work on a ticket without putting an avatar on the stickies. Or limit the available space to place cards — no stacking of cards allowed, of course. Mark stickies with red dots that are not moving to visualize the work item age. This way, the team can reach out to remove the impediment that is preventing progress in time.
  • Leading system: If you are using offline and online boards, make sure that there is a leading system and that the boards are synced regularly, for example, right after the standup. (This sync is a job of all team members, not a task specifically for the Scrum master, by the way.)

Whiteboard Anti-Patterns

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:

  • Abandoned boards: A team started using a board and then stopped doing so, leaving the old board to rot.
  • Dropouts: It is necessary to remind some team members regularly to take care of the board(s).
  • Lack of transparency: Not all cards are placed on the board; there is a shadow accounting, blurring the picture.
  • Lack of motion: Stickies are not moved regularly, and hence your team experienced sync failures with the other boards. (If this whiteboard anti-pattern persists it renders both boards unusable.)
  • Leading system ignored: The working agreement on the lead system is not respected by every team member.
  • WIP limit ignored: The team members do not honor the working agreement — reflected in the design of the board — on the work-in-progress limit.Image from

Whiteboard Games

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!

How to Create Whiteboards — Conclusions

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.

Upcoming Webinars

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.)

Agile Transition – A Hands-on Guide from the Trenches

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.

Original Link

Agile Implementation: From Theory to Practice

Image title

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”.

Most Common Agile Implementation Practices

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.

Image title

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:

Stay Flexible

Image title

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.

Keep It Clear and Documented

Image title

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.

Lead by Example

Image title

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.

Emphasize Training

Image title

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.

Facilitate, Don’t Dictate

Image title

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.

Keep It Simple

Image title

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.

Use the Right Tools

Image title

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.

Read the original post on the nTask blog by clicking here.

Original Link

Agile in Practice: Tips, Tools and Templates [Video]

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?

Additional Resources:

Have questions? Feel to contact us anytime!  

Original Link

Product Backlog Refinement: Make the Most of It

Image title

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.

What Is a Product Backlog?

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:

  • Epics – high-level items, which need to be broken down into User Stories.
  • User Stories – user-centric low-level items.
  • Non-functional requirement items like Constraint Stories.
  • Spikes – research stories that will result in learning, choosing proper architecture or design, creating prototypes, etc. to fulfill the goal of the Spike, based on which proper User Stories will be created later.
  • Technical items  (like refactoring, configuring Jenkins, etc.) – these items should be separately discussed with the Product Owner for him to see the value of them.
  • Bugs, etc.

Who Is Responsible for a Product Backlog?

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.

What Is a Product Backlog Refinement and Why Is it so Important?

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:

  • Make the Product Backlog reflect feedbacks from users and customers from the last Sprint – to know that we are building the right product which is really valuable for users and customers.
  • Leverage our learning about the product and best ways of its implementation.
  • Keep the Product Backlog fresh, concise and in order.
  • Keep the Product Backlog properly prioritized.
  • Make sure that high-priority PBIs are ready for the Sprint Planning – they should be sized properly to fit into the Sprint and detailed enough for the Development Team to do the required work.

When Should Product Backlog Refinement Be Done?

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.

How to Hold a Product Backlog Refinement Meeting Effectively?

  • The Product Backlog Refinement meeting should be time-boxed – usually around 2-3 hours for a two-week Sprint. Generally, the Scrum Guide suggests that Refinement should consume no more than 10% of the capacity of the Development Team.
  • The Product Backlog Refinement meeting should be facilitated by the Scrum Master to keep on track.
  • All Scrum participants – the Development Team, the Scrum Master and the Product Owner should attend the meeting.
  • Everyone should have access to the Product Backlog and see what is going on.

What Is the Procedure to Follow during the Product Backlog Refinement Meeting?

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:

  1. The Product Owner presents the plan for the meeting.

  2. 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.

  3. 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.

  4. 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).

  5. The Product Owner amends the Product Backlog to reflect the results of the discussions.

  6. The Product Owner re-prioritizes the Product Backlog to have the highest priority PBIs at the top of the Product Backlog.

  7. The Development Team may provide estimates for new/amended PBIs.

  8. 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.

Original Link

Best Practices to Succeed with User Stories

Image title

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.

What is a User Story?

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:

  • Who are we building it for? — As a <type of user>
  • What are we building? — I want <feature>
  • Why are we building it? — So that <value or benefit>

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.

Is There Any Procedure for Creating a User Story?

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.

  • The Card is a written description of the User Story. It does not capture all details about what should be built. It is instead a reminder, a promise for subsequent communication that must take place.
  • The Conversation is used to discuss details of the User Story. It may be supplemented by some documentation.
  • The Confirmation is represented by user acceptance tests, which ensure that the User Story satisfies acceptance criteria of the user/customer.

How to Write a High-Quality User Story

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.

  • Independent – the User Story should not depend on another User Story, so User Stories can be developed in any sequence.
  • Negotiable – details of the User Story are negotiated in a verbal conversation between the Product Owner and the development team.
  • Valuable – the User Story should bring needed value to the user/customer.
  • Estimable – the User Story should be understood well enough by the development team to estimate it.
  • Small – the User Story should be small enough to fit in an iteration.
  • Testable – proper acceptance criteria should be written for the User Story, so it can be validated.

What is Not a User Story?

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.

Who is a User?

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.

Who is Responsible for Writing a User Story?

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.

Where are the Details?

As User Stories are not specifications, details are conveyed in a different way:

  • The second “C” in the 3 C’s guideline is Conversation. Conversation is one of the most important aspects of Agile. So, most details are conveyed via verbal communication between the customer representative and the development team.
  • The third “C” is Confirmation. User acceptance tests are confirmation that the User Story satisfies acceptance criteria of the user/customer, and they serve as formal documented details. BDD (Behaviour Driven Development) is a great technique to write acceptance tests.
  • Some User Stories may contain additional written details if needed.

How Do You Know When a User Story is Done?

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:

  • Unit tests are passed
  • Code is peer-reviewed
  • User acceptance tests are passed
  • Integration tests are passed
  • Regression tests are passed
  • User guide is updated

How to Start Defining a Product Scope?

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.

What Is the Best Way to Organize User Stories?

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):

Image title

Original Link

Best Practices to Scale Agile

Agile Software Development

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.

Image title

Reasons for Choosing Agile

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.

Traditional vs. Agile for Software Development

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.

Some Agile Practices Include:

Customer Cooperation

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.

Iterative Development

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

Value Stream Analysis

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.

Image title

User Stories

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.

Scrum Meetings

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.

Do share your opinion!

Original Link

Scrum Stakeholder Anti-Patterns

Scrum Stakeholder Anti-Patterns by Age-of-Product-1650

The Scrum Stakeholder and Organizational Excellence in Legacy Organizations

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.

Agile Audit: Engineering Culture and Methods InfoQ Trends Report - January 2018

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:

  • From WIIFM (what-is-in-for-me syndrome) to team playing — the team wins, the team loses;
  • From career planning as an individual to servant leadership in a team of teams structure;
  • From knowing it all and being the go-to person to solve problems to trusting those closest to the problem to come up with a solution;
  • From ‘failure is no option’ to embracing failure as a means to learn fast;
  • From claiming success as a personal contribution to stepping back and letting the responsible team shine.

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.

A List of Scrum Stakeholder Anti-Patterns

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.

Charlie Munger: “ Never, ever, think about something else when you should be thinking about the power of incentives.”

The following list of scrum stakeholder anti-patterns addresses scrum ceremonies, system related issues as well as issues of individual players.

Scrum Stakeholder Anti-Patterns at Scrum Ceremony Level

The Stand-up or Daily Scrum

Most anti-patterns in this category result from perceived information needs — think of them as withdrawal symptoms:

  • Status report: The stand-up is a status report meeting, and team members are waiting in line to “report” progress to the scrum master, the product owner, or maybe even a stakeholder
  • Talkative chickens: “Chickens” actively participate in the stand-up. (I think it is acceptable if stakeholders ask a question during the stand-up. However, they are otherwise supposed to listen in merely.)
  • Anti-agile: Line managers are attending stands-up to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-organizing teams.)

The Sprint

Anti-patterns of this sort point at stakeholders’ ignorance of the core idea of scrum — self-organizing teams:

  • Directly pitching developers: The stakeholders try to sneak in small tasks by pitching them directly to developers. (Nice try #1.)
  • Everything’s a bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ (Nice try #2. A special case is an “express lane” for bug fixes and other urgent issues. Every stakeholder will try and make his or her tasks eligible for that express lane.)
  • Disrupting the flow: The stakeholders disrupt the flow of the scrum team. (See above, scrum master section.)

The Sprint Review

Again, this category is often a combination of ignorance, fighting a perceived loss of control or pulling rank to override scrum principles:

  • Scrum à la stage-gate: The sprint review is a kind of stage-gate approval process where stakeholders sign off features. (This anti-pattern is typical for organizations that use an agile-waterfall hybrid. Otherwise, it is the prerogative or the product owner to decide what to ship when.)
  • No stakeholders: Stakeholders do not attend the sprint review. (There are several reasons why stakeholders do not go to the sprint review: they do not see any value in the ceremony. It is conflicting with another important meeting. They do not understand the importance of the sprint review event. No sponsor is participating in the sprint review, for example, from the C-level. In my experience, you need to “sell” the ceremony within the organization.
  • No customers: External stakeholders—also known as customers—do not attend the sprint review. (Break out of your organization’s filter bubble, and invite some paying users of your product.)
  • Starting over again: There is no continuity in the attendance of stakeholders. (Longevity is not just a team issue, but also applies to stakeholders. If they change too often, for example, because of a rotation scheme, how can they provide in-depth feedback? If this pattern appears the team needs to improve how stakeholders understand the sprint review.)
  • Passive stakeholders: The stakeholders are passive and unengaged. (That is simple to fix. Let the stakeholders drive the sprint review and put them at the helm. Or organize the sprint review as a science fair with several booths.)

The Sprint Retrospective

Here, it is mainly about control and line management issues:

  • Line managers present: Line managers participate in retrospectives. (This is the worst anti-pattern I can think off. It turns the retrospective into an unsafe place. And who would expect that an unsafe place triggers an open discussion among the team members? Any line manager who insists on such a proceeding signals his or her lack of understanding of basic agile practices. Note: If you are small product delivery team at a start-up and your part-time scrum master (or product owner) also serves in a management function, retrospectives might be challenging. In this case, consider hiring an external scrum master to facilitate meaningful retrospectives.)
  • Let us see your minutes: Someone from the organization—outside the team—requires access to the retrospective minutes. (This is almost as bad as line managers who want to participate in a retrospective. Of course, the access must be denied.)
  • Encore — no suitable venue: There is no adequate place available to run the retrospective. (The least appropriate place to have a retrospective is a meeting room with a rectangular table surrounded by chairs. And yet it is the most common venue to have a retrospective. Becoming agile requires space. If this space is not available, you should become creative and go somewhere else. If the weather is fine, grab your stickies and go outside. Or rent a suitable space somewhere else. If that is not working, for example, due to budget issues, remove at least the table so you can sit/stand in a circle. Just be creative. Read More: Agile Workspace: The Undervalued Success Factor.)

Scrum Stakeholder Anti-Patterns at System Level

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:

  • Lack of transparency: The organization is not transparent about vision and strategy hence the teams are hindered to become self-organizing.
  • Lack of leadership: Senior management is not participating in Agile processes, for example, the sprint demos, despite being a role model. Instead, they do expect a different form of (push) reporting.
  • Cargo-cult agile by cherry picking: Agile processes are either bent or ignored whenever it seems appropriate, for example, the scrum product owner role is reduced to a project manager role. Or stakeholders are bypassing the product owner to get things done and get away with it in the eyes of the senior management, as they would show initiative. There is a lack of discipline and thus support of the agile transition.
  • Agile light: The management abandons self-organization the moment a critical problem appears to form ‘task forces’ instead.
  • Agile on a tight budget: The organization does not spend enough time and budget on proper communication, training, and coaching to create a shared understanding of purpose and direction among all members of the organization.
  • Telling people how to do things: In the good old times on the shop floor, it was a valuable trait to train newcomers or workgroups in the art of assembling a Model T—as the manager probably did herself. Nowadays, as we invest most of our time building products that have never been built before this attitude becomes a liability. Just let the people closest to the job at hands figure out how to do this. Guidance by objectives and providing support when requested or needed will be appreciated, though.
  • Steering meetings: Unimpressed by the agile ways of working, the manager insists on continuing the bi-weekly steering meetings to ensure that the team will deliver all her requirements in time. This one has a quick remedy, though: just do not participate in meetings that have no value for the team.
  • Limited to non-existing feedback loops: The sales organization and other functional silos guard the direct access to customers, thus preventing the product teams from learning.

Personally Motivated Scrum Stakeholder Anti-Patterns

There are numerous ways how stakeholders can impede the progress of a product team. Four of the most common ones are as follows:

  • The ‘My budget’ syndrome: Stakeholders do not pitch for development resources but claim that they allocate “their” budget on feature requests as they see fit. (That process leads to the creation of local optima at a silo or departmental level. The effect can be observed particularly in organizations, that tie additional benefits to individuals. Instead, resources need to be allocated in the spirit of optimization for the whole organization. Note: ‘Pet projects’ also fall in this category.)
  • ‘We know what to build’: The is no user research, nor any other interactions of the product delivery organization with customers. (There are several reasons causing this phenomenon ranging from a founder or entrepreneur who pursues his or her product vision without engaging in customer discovery activities. Or the product delivery organization is solely briefed indirectly by key account managers. Probably, the sales department deems a direct contact of product team people with customers too risky and hence prevents it from happening. What these patterns share is either a bias that is hurting the learning effort or a personal agenda. While the former can be overcome by education, the latter is more difficult to come by as the culprits typically reject the idea that they are guided by selfish motives. For becoming an effective product delivery organization it is essential that the team directly communicates with customers at a regular base.)
  • Selling non-existing features: What features do you need us to provide to close the deal? Sales managers chase sales objectives by asking prospects for a feature wish-list and provide those to the product delivery organization as requirements. (The problem with customers is that they usually lack the depth of knowledge required to provide useful answers to this question. Most of the time, they also lack the level of abstract thinking necessary to come up with a viable, usable, and feasible solution. As the saying goes: if the only tool you are familiar with is a hammer every problem will look like a nail. Pursuing the sales process in such a way will lead the product into a feature comparison race to the bottom, probably inspired by bonuses and personal agendas. This is the reason why product people like to observe customers in their typical environment using a product to avoid misallocating resources on agenda-driven features. At a systems level, reconsidering individual monetary incentives for salespeople is helpful, too. In a learning organization, teams win not individuals.)
  • Bonus in limbo: We are nearing the end of a quarter. Bonus relevant KPIs (key performance indicators) are at risk of not being met. The responsible entity demands product changes or extensions in the hope that those will spur additional sales. (This behavior is comparable with the ‘what features do you need to close the deal’ anti-pattern, but it demanded in more pressing fashion, typically four weeks before the end of a bonus period.) Financial incentives to innovate: The organization incentivizes new ideas and suggestions monetarily. (Contributing to the long list of ideas and thus the hypotheses short-list should be intrinsically motived. Any possible personal gain might inflate the number of suggestions without adding value.)

For more information watch the webinar: Product Discovery Anti-patterns.

Scrum Stakeholder Anti-Patterns — Conclusion

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.

Download the Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patters Guide” now!

Original Link

Agile Retrospective: The What, Why, and How (Quick Guide)

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.

Agile Retrospective – The What

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.

The Why

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.

More Benefits

Nurtures continuous improvement culture

Looking for the most efficient ways to deliver value together creates a catalyst environment for the changes.

Empowers teams

Retrospective allows team players to make their own decisions accept responsibility. As a result, your team will grow in maturity and self-motivation.

Helps team-building

Retros bring people together, and if done correctly – train them to be more understanding and helpful towards others.

Vents frustrations

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.

The How

Retros are awesome, but they are also very easy to screw up.

Here’s What You Want to Avoid:

1) Useless complaining

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.

2) Boredom

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.

3) Information Leaking

Make sure that every team member feels safe to share their insights. It’s better to keep some things in the family.

4) Checklist Overload

Trying to improve everything at once is dangerous. Set priorities and use short, practical action plans.

And, lastly, make sure that as the leader you:

Have a plan

The project manager or Scrum Master running the meeting has to prepare the agenda beforehand. You also have to plan regular future meetings.

Be the facilitator

Actively lead the retrospective, encourage discussion, and take notes. Make sure that every team member feels welcomed to participate.

Criticize process, not people

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.

Practice what you talk about

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.

Analyze the workflow

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.

Build the team

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.

Don’t forget to summarize

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.

Original Link

Product Backlog Defense

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.

Product Backlog Defense — Age of Product

The Product Backlog in the Context of the Product Creation Process

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:

Product Backlog Defense — Age of Product Product Creation Process — Age of Product

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:

Product Backlog Defense Near-Term Planning

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.

Product Backlog Defense: Expect Flanking Maneuvers to Bypass the Product Creation Process

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.”

The Motivation Behind Flanking Maneuvers

There are various patterns of flanking maneuvers, depending on the nature, age, and the size of the organization. For example:

  • The case of the sales manager who believes his or her bonus is at risk and hence wants to throw some features urgently at the wall to see what sticks (and generates revenue) is evident.
  • The case of someone who is pursuing a specific (pet) project to improve his or her CV for the next career step—probably with another organization—is more difficult to spot.
  • Often you can observe local optimization efforts by stakeholders valuing the results of his or her department higher than another’s
  • Then there is the drive to determine what the “internal software agency works on because it is our budget and we know our needs best.” Here, an organizational mindset — based on functional silos — of the industrial age clashes with the post-industrial value creation process.

Common Flanking Maneuvers

There are at least seven flanking maneuvers that make the product backlog defense mandatory for any product team:

  1. Pulling rank or HIPPO-ism: There are different reasons for this kind of behavior. Some people believe that hierarchical status has privileges and rules do not apply to them. Others think that they know best, probably fueled by a paternalistic mindset. Often, it is a sign of lack of trust in the team’s capability. No matter what makes an individual behave this way, it is a sign of poor leadership qualities. Product Backlog Defense HIPPO-ism — Age of Product
  2. Brute-forcing it: The bully at work, now probably plowing through a corporate hierarchy. What worked in the school-yard might still work today — differently packaged, though. Don’t expect this behavior to leave a trail of artifacts or email threads.
  3. Have daddy fix it: The magic of outsourcing the solution of “issues” — here: the product team asks the stakeholder to accept the process like everyone else — to a higher hierarchy level. (“My boss will talk to your boss, and then we will see…”)
  4. Bribery: I scratch your back, you scratch mine.
  5. Direct ticket creation: Why bother the product owner? He or she might be overworked anyway. Instead, your stakeholder shows initiative and creates the ticket for the required feature herself. (Not controlling access rights to the ticket system is a rookie mistake, just saying.)
  6. Dispatcher mode: Why not assign a task directly to an engineer bypassing the product backlog altogether?
  7. Labeling feature requests as bugs: By comparison to the other maneuvers sneaking features via bug reports is almost a thoughtful approach — someone tries to hack the system. Nice try. Try harder next time, though.

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.

Conclusion — Product Backlog Defense

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.

Agile Transition – A Hands-on Guide from the Trenches

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.

Download your copy of ‘Agile Transition’ here.

Original Link

Agile Delivery in Large Teams

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:

Methodology Recap

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.

Agile for Management

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.”

Progressive DoD

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.

Technical Governance

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.

System Cross-Functional Teams

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.

Original Link

Use Burn-Down Charts to Discover Scrum Anti-Patterns

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.

Use Burn-Down Charts to Discover Scrum Anti-Patterns: Ideal Case

Scrum Anti-Patterns Visualized by Burn-Down Charts

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:

1. Late Acceptance

The product owner accepts or rejects tasks only late in the sprint:

Use Burn-Down Charts to Discover Scrum Anti-Patterns Early Finish Late Acceptance

This behavior may be rooted in various issues, for example:

  • The absent product owner: The product owner is rarely available for the team to clarify matters and accept work. This is creating an artificial queue that has a diminishing effect on the team’s ability to deliver value by delaying the necessary clarification of tasks or the shipment of tasks themselves. (Note: LeSS susceptible for this effect when the product owner when not willing to delegate responsibility.)
  • The proxy product owner: The team is working in a remote setup and the product owner is not onsite with the rest of the team. (Note: A proxy product owner is usually not a solution as he or she will just increase the time for feedback and add to the communication problems.)
  • Consequences: There will likely be a spill-over to the next sprint as the feedback loop does not provide enough time to fix issues during the sprint. The team will probably not meet the sprint goal. If this not an isolated incident but a persistent pattern, action needs to be taken.

2. Slow Progress

In this case, the graph is located above the line of the expected progress for the complete sprint length:

Use Burn-Down Charts to Discover Scrum Anti-Patterns Early Finish Slow Progress

There are several reasons why this might be the case:

  • The ambitious team: The sprint goal is too ambitious and the team realizes only during the sprint that it will not deliver the sprint goal. (Note: It is okay to aim high and fail, however, it should not be the regular pattern as it is negatively influencing the trust of the organization in the team.)
  • The submissive team: The sprint goal is too ambitious from an engineering perspective. However, instead of speaking up, the team tries to make it happen thus failing at the end of the sprint. 
  • Capacity issues: The capacity of the team changes after the sprint starts, for example, team members get sick, or they give notice and leave the team. (Note: Admittedly, this is hardly plannable anyway.)
  • Change of priorities: The team needs to address a critical issue—probably a bug—which leaves less capacity to accomplish the original sprint goal. (Note: Depending on the magnitude of the disturbance it might be useful to consider canceling the spirit. At least, the team needs to reduce original sprint scope—which may require a mid-sprint re-planning to determine whether a reduced sprint backlog will still deliver the original sprint goal.)
  • Outside dependencies: The team faces dependencies outside its sphere of influence not foreseeable during sprint planning. (Note: A classic systemic dysfunction.)

3. Scope Increase

The scope of work increases over the course of the sprint:

Use Burn-Down Charts to Discover Scrum Anti-Patterns Early Finish Scope Increase

Most of the time, this pattern can be attributed to inadequate preparation:

  • Refinement failure: The scrum team fails to refine tasks accurately only to discover that the effort to create a valuable product increment is higher than originally expected. (Note: If this happens multiple time during the sprint then the team accepted stories into the sprint the team has not fully understood. This points at serious issues with the product backlog refinement process or the collaboration with the product owner in general.)
  • Dynamic sprint backlog: Urgent tasks are pressed or find their way into the sprint without compensation. (Note: Depending on the magnitude of the tasks, canceling the current sprint and focusing on the apparently more valuable new issues might be the better alternative. Unless, of course, those new issues are hacking the scrum process of sprint planning. There are several examples of this behavior: A manager pulls strings to get his or her task into a sprint or tasks are disguised as critical bugs that need to be fixed immediately.)

4. Early Finish

The team accomplishes the sprint goal way earlier than expected:

Use Burn-Down Charts to Discover Scrum Anti-Patterns Early Finish Early Finish

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:

  • The overly cautious team: The team probably overestimated the effort to be on the safe side with its prediction. (Note: This could indicate that the management tracks, for example, velocity as an important metric for the contribution of the team members despite its limited usefulness. Or the organization is output oriented and does not accept ‘failure’ as an option. In these cases, the organization is setting the wrong incentives. See also the Hawthorne effect.)
  • A hack for slack time: The team included buffer time to be able to address technical debt, its need for pairing or other issues that do not regularly receive attention and hence managed to finish early. (Note: This might indicate that the current allocation of resources is neglecting the long-term health of the team as well as the code base. Also, watch out for the feature factory syndrome where team utilization and output matter more than the long-term outcome.)

Conclusion—Use Burn-Down Charts to Discover Scrum Anti-Patterns

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.

The Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here:

Download the “The Scrum Anti-Patterns Guide” now!

Original Link

Agile: My Experience

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!

Why Agile

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:

  • Ease the development process.
  • Incrementally releasing completed work.

Understanding Agile

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.

Agile Frameworks

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 vs Kanban vs Scrumban

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. 


  • Product Owner/Manager:
    • A cross-functional team member who can envision the market needs, not just an analyst.
    • Does market studies, gap analysis, minimizes customer pain, and works to make the product easy to use.
    • Defines the features in terms Stories/Epics with exit criteria and stack ranks.
    • Conducts functional workshops, explains the business needs, gives a detailed walkthrough of the final product, answers stakeholder questions/provides clarification.
    • Asks for frequent, intermittent releases that can be tested hands-on and signs-off on the releases from the functional point-of-view.
    • Overall, accountable for Product Success/Failure.
  • Team:
    • A team, typically, is made up of 8-9 developers, who are expected to be self-organizing.
    • Does detailed feature study/analysis, and estimates and defines the low-level tasks and development features.
    • Picks up an estimation model that works for them – could be choosing even/odd numbers, t-shirt sizes, Fibonacci sequence, card game style, etc.
    • Split the work into granular levels, come forward, pick the items, and get it done.
    • Designs, develops, tests, and supports the product.
    • Updates daily progress in stand-ups on what is done, in-progress, and what’s next.
    • Individuals are responsible for accomplishing the tasks as per the estimations agreed upon by the PO, Team, and EM.
  • Engineering Manager:
    • Typically, a techie who understands technology a lot or could be hands-on, and management/functional to some extent.
    • Helps the team in all technical, functional, and managerial aspects. Works along with the team owning end-to-end deliverables.
    • Coaches the team on the execution model. Works closely with Product Owner and Team to help them agree on the deliverables.
    • Ensures team necessities, requirements, eliminates unnecessary overheads, processes on teams.
    • EM is not a Project Manager. Do not mix with other methodology roles/responsibilities as this could change the whole game.
    • Gather info, identify and eliminate impediments, shields team from external/internal influences.
    • Makes decisions at floor level, helps the team on technical/functional/managerial aspects.
    • Experience in architectural, design patterns, open source platforms, frameworks, technologies, and standards.
    • Accountable for design, development, quality, timely releases, consultancy, support, and generally making the product better from an engineering point-of-view.


  • As a team, identify a model that works. Basically, choose a series such as Odd/Even, Fibonacci, or T-shirt sizing.

  • Individuals come up with estimations for the stories/epics. Logic should win (not authority/voice/influence/reference powers).
  • Estimation works well when the actual contributor estimates the work and it can always be cross-checked within the team.
  • Do not try to mix-and-match estimations and try to compare them. Do not try to compare component based vs functional point vs story point estimations, it will not work and will not help.
  • Any changes in the estimation model will not give accurate data for predictions.
  • Any major changes in the team could bring a change in the estimations and release predictions.
  • Do not try to compare estimations across teams. Most of the times, it won’t work.

What if…?

I have kept very high level on the below topics but otherwise each and every area can be an article byitself.

  • There is a lot of engineering work to be done? Such as:
    • Technology stack selection.
    • Proof of concepts.
    • Framework and utility development.
    • Design and Integrations

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).

  • Are there a lot of testing cycles involved?
    • Agile will not succeed without proper automation, continuous integration and testing, and a lack of these could end up in huge spillovers, and the project would become unmanageable.
    • Automate as much as possible as this would help the team to focus more on value stories than routine testing work for every other change.
  • Are there a lot of meetings involved?
    • Avoid too many meetings. Try to connect directly or have more workshops to work closely and help to close things early.
  • Bigger team?
    • Have multiple Scrum teams, each with about 8-9 people, and do a Scrum of Scrums. The overall update will be at the Scrum of Scrums.
  • Too many communication points and channels?
    • Do not try to somehow match the numbers in the tool to maintain velocity and burndown for the sake of doing it or for the reports.
    • Involve the team to update the data in the tool as they progress.
    • Data keyed into the tool by the contributor should reflect the overall status.
  • In the support and enhancements phase:
    • Come up with capacity planning and bucket them into areas you might need to work on.
    • Plan Sprints for the enhancements and on any important customer issues, bargain/swap the internal development tasks with the issues.
  • Services?
    • The whole game starts with the RFP to win the customer.
    • It helps if the organization has already executed projects like this, as it will allow for better estimations. The challenge remains for the first-timers. So, if the project is given the green light, a blueprint would help here.
    • There’s a good chance that people will estimate only for value stories and could miss the underlying design, framework, and integration engineering work involved. So, consider the engineering and functional work involved.

Agile is not a better word to use if any or none of the below are in place:

  1. Continuous Integration

  2. Automation

  3. DevOps

  4. Right tools
  5. Quantifiable Code/Test Metrics

  6. Frequent releases

  7. Early feedback

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.

Original Link

The Burndown Chart Reveals Many Secrets

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.

Hurry Up!

Image title

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.

Super Mario

Super Mario

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.

The Big Finish

Big finish

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 Nearly Perfect Burndown 

Nearly perfect

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.

Original Link

Meetings :  A Culture of Excess That Hurts Our Productivity and Morale

71% of meetings are considered unproductive. Let’s fix that.

Visualistan — The Ugly Truth About MeetingsI believe in a world where meetings enhance productivity, inspire creativity, and enable teams to move faster — not the opposite.

“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

Adopting Football Meetings

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?

The Evolution of Meetings

The Olden Days

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.

The Growth Days

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.

The Tech Days

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.

Are Meetings Productive? Let’s Look at the Stats

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

Consequences of Excessive, Unprepared Meetings

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.

Here Are Some Other Consequences:

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).

Should You Have a Meeting?

The Perfect Meeting

The perfect meeting is one that is:

  • Device-free (cell phone and laptop bans except for the presenter) — Due to the rampant multitasking in meetings, banning distractions will help expedite decision-making, attentiveness, and the meeting’s resolution. Teams will be more ‘present’ and it will enable more effective outcomes.
  • Time-conscious — The meeting should only be scheduled if it absolutely requires real-time conversation at a time that does not unduly impact the workflow of the attendees. 80% of meetings should only be 15 minutes or less.
  • Appropriately scoped — Only the absolutely relevant stakeholders should be invited to the meeting. Optional attendees should receive the meeting results in an email, but often do not need to attend in person. In fact, these attendees could give input prior to the meeting for discussion.
  • Discussion-driven—Your meeting collateral (like slides or handouts) should be tailored for real-time discussion. The meeting should have more time set aside for discussion than for the presentation. The meeting facilitator should ask attendees directly for their opinions in order to encourage active listening and participation. All tangential discussions should be tabled immediately.
  • Necessary — Does the meeting actually need to happen? Or could an email, chat, phone call, or in person chat resolve the issue? If it’s a topic that requires more thought, then maybe the meeting is premature and all stakeholders should do more research prior to formalizing a meeting.
  • Prepped in advance — Ideally, all important stakeholders should weigh in on the issue prior to the meeting or have time to do research. The meeting should be about decision-making and outcomes, not about discovering new knowledge. The knowledge and research should be sent prior to the meeting as homework so that everyone has had time to think about the issue prior to making a decision. The focus of the meeting should be a productive, real-time discussion.
  • Clearly defined — The purpose of the meeting should be clearly articulated and understood by all attendees. It should have a defined objective that keeps the discussion on point.
  • Scheduled with appropriate frequency — Recurring meetings are one of the greatest fallacies of the modern work culture. Often, these meetings are knowledge sync-ups, where stakeholders are just exchanging knowledge. Any sort of bi-directional exchange of information does not require real-time discussion, so a meeting is likely not appropriate. Rather, you can create a living status document or sync up via email.
  • Demanding of a real-time conversation — The purpose of a meeting is to cultivate real-time conversation. Does sharing a PowerPoint require real-time conversation? Possibly, but often times these presentations are very knowledge-sharing focused and could just be prerecorded or sent out to the relevant stakeholders. The stakeholders can then determine if a real-time conversation is necessary.
  • Results-driven — The purpose of the real-time discussion should be tailored to a specific outcome. The outcome should never be “to have another meeting.” The outcome should also be codified and emailed to the stakeholders (and those who did not attend) so that the relevant stakeholders are aligned and have written record.
  • Further reading: NY Times — How to Run an Effective Meeting

A Cultural Shift: Shorter Meetings, Less Often

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.

  • The number of formal meetings reduced by 75%.
  • A 15 minute maximum for 80% of meetings, 30-minute max for 15%, and 1 hour+ max for 5%.
  • A 15-minute optional extension if more real-time discussion is needed.
  • For the average individual contributor, less than 10% of your time should be spent in formal meetings (this doesn’t include one-on-one discussions, quick sync-ups, and normal workplace coordination).
  • When there is no longer need for real-time discussion, the meeting should be adjourned and a summary/next steps email should be sent to all participants by the meeting host. This has two benefits: (1) it holds hosts accountable for the meetings they organize, (2) it provides a codified result.

Main Take Away

Meetings should enhance productivity, inspire creativity, and enable teams to move faster — not the opposite.

Original Link