Have you been in daily stand-up meetings that were not well run? Believe me you are not alone if you can visualize a bunch of headless chickens in your head when you attend a badly run daily stand-up. So what can you do to improve the daily stand-up, other than pressing the reset button (which you should consider)?

Here is my list of top tips to energize and strengthen a Scrum team’s daily stand-up meeting. Some of these are general rules that apply to all meetings and others are specific to stand-ups:

  1. Actively find and remove impediments – Many team members think meetings are a waste of time. Usually, this is because they find doing their own work more meaningful and meetings take them away. If they do not understand what’s in it for them, team members are likely to be less attentive. One way to change that is by showing results. If you are the Scrum master, strike short conversations to help identify the impediments. Ask the team what is impeding their progress, who can help remove the impediments and when. By helping to identify (and thereby remove) impediments, your team is guaranteed to improve its performance and gain more confidence.
  2. Clarify purpose and rules, but keep it informal – It is hard for team members to be attentive and participate when they don’t know what the meeting is really about. I urge you to beyond asking the team members to answer the three questions of a daily stand-up – I urge to let them know how important it is to sync up and ask each other for help and provide help. If your stand-ups are mechanical and just revolve around Scrum master collecting status updates from each individual, clearly your team does not understand why they need to attend the stand-up.
  3. A short daily stand-up – Here is another extreme that some teams might wind up into. In their love and passion to talk, they ignore the 15 minute boundary of the stand-up and forget that it is a short sync point in a day, where everyone is getting visibility and highlighting impediments and asking/offering help. A stand-up is not an endless chat, and extensive discussions should happen elsewhere.
  4. Keep chairs away – Do you have a stand-up in your work area or in a meeting room, where every one has to come in and find a chair? Do you have a stand-up standing up or sitting down? All of this makes a difference. Standing up helps people to get back to work and keep conversations short. Getting in a room to have a stand-up means more time lost in getting into and finding a chair in the room.
  5. All pigs must attend – What happens when a team member does not join the stand-up? The team as a whole loses visibility into the progress and challenges of that team member. The team member loses the ability to ask for help of the whole team. The team member also loses the opportunity to help other team members who are facing difficult tasks.
  6. Ensure remote participants get value – Special handling is required for remote participants. Since they are remote, this is their time to get a direct sense of what is happening. Remote attendees are likely to use an online collaboration tool such as GoToMeeting or Skype. Ensure that their audio and video (if you use camera) works. If there are problems, that can derail the entire meeting. When there are problems ensure they are addressed promptly and prevented from occurring again in later meetings.
  7. Ensure new team members get up to speed fast – Often new team members may join the team. While new team members bring in new knowledge, they could also lag behind in their understanding of how the team operates. While most new team members learn to adapt, it can be harder for some and at times disruptive. Assuming your stand-ups are running well, pay special attention to needs of new team members and identify what they bring to the party. Consider if they need training. Make an effort to prepare them to participate in the stand-ups and you will usually be fine.
  8. Use physical or virtual boards – I have noticed that teams that review a stand-up board with a sprint backlog get better visibility on progress. Personally I prefer that the board with physical – with real stickies and real wall. This encourages collaborative nature of the stand-up and allows anyone to move around the stickies. Sometimes that is not possible – For example when a team member is remote. In that case, using a tool like JIRA, VersionOne, Rally etc. is an alternative.
  9. Supplement with solver sessions – This can be tricky and can take a good amount of skill. In order to keep the meeting short and keep the team focused, the Scrum master may be tempted to shut down the conversation. At the same time, the conversation may be really important for the team to get on the same page. You may have to choose what to do depending on the conversation. Intervene when necessary and help setting up solver sessions to go into details of the issue that requires a deep dive.
  10. Inform in advance (if you miss, but miss rarely) – At times there are situations when team members can’t avoid skipping a stand-up. There is no good solution to this. In such situations, I recommend working with the team on how they can inform each other about their daily updates and plans, in advance if possible.


I hope some of these tips will help teams run better daily stand-up meetings. As always, I am interested in learning more. So if you have other tips to share, I would love to hear about them – leave a comment! And I will inspect and adapt.

You may also be interested in:

Would life be easier if we did not have to think about planning? Let’s face it, whether it is about running our day to day routine or even something as simple as paying a visit to the neighborhood grocery store there is planning involved. Imagine taking a vacation without planning where you will go, what you will do while you are there, how long will stay and what you need to bring with you. Or imagine not thinking about how much you need to earn, to save and to invest to meet your worldly needs.. Well lets just keep those worries aside for a few minutes shall we and think about how planning can actually help! Yes that’s right, no matter how much burdensome it might sound, planning can help.

What is planning?

The simplest definition of planning that I have come across is “decide on and arrange in advance”. I like this because this definition is light, it does not say how much detail we need to plan in, but an important thing that it does say is that planning happens in advance.

Why plan?

There are many reasons why we plan. Our limited information about the future and vision of what we want to do with that information in order to achieve a specific objective gives us an opportunity to play with creative alternatives and paths to get there. Applying constraints helps us narrow down our search of solutions, breaking them down into chunks or steps that are (hopefully) easy to understand and sequence as necessary. When steps and solutions are not known we put on our experimentation hats and navigate our way to discovering the possibilities.

Use the plan as a defense strategy

So what should I tell my teams when they get planning? What are the things I need to keep in mind but don’t come easy, specially with Scrum? In my note to self, I include the following.

Plan just in time, and just enough..

Plan early but not too early. Have a high level roadmap that (can change and) tells the team the path we will take if things went all-right. Planning too much too soon could mean a lot of wasted effort and repetition. Planning too little could mean little predictability in outcomes for initiatives that span multiple sprints. So lets groom our backlog stories and have them ready for a few (may be two to four) sprints to come. Lets find that right balance for our team where Sprint planning sessions do not become painful and burdensome.

Plan based on data..

More often than note, teams are asked to meet an “aggressive targets”. In other words, there is a huge tendency to ask for deliveries tied to dates without understanding scope and effort involved. These dates are usually based on business constraints and are tight (more often than not). So, organizations and teams find themselves in situations where teams are unable to deliver as some say – “on time” and “within budget”. Lets avoid that for our team through scientific and consistent use of measures such as velocity and cycle time. Lets make forecasts based on data so that business understands our non-trivial effort and can make realistic, prudent decisions on scope and priority.

Maintain discipline, Estimate or #NoEstimate..

There is much debate on whether to do estimates or not. What seems more important to me than that debate is to agree on an approach that works for our team and for your organization and follow it with discipline. When we estimate, lets spend little time estimating, after all estimates do not produce value for customer, working software hopefully does. Estimates are just that – “estimates”, they are “not actuals”.

High priority, High risk first..

What should the team work on first and what should it work on later? There are multiple factors that decide this, chief among them are dependencies, customer feedback and risk. The product owner plays an important role balancing all aspects while deciding the order so that team delivers value while making continuous progress. So lets keep in mind the problem we are trying to solve, and order our backlog on the basis of that. Lets identify those things that are not clear and run spikes. Lets reduce the risk early as early as we can, so that we do not embarrass ourselves in front of our stakeholders and customers when the time comes.

Minimize hand-offs, eliminate technical debt..

Lots of times, teams work with other teams to deliver an experience or functionality. Many times this needs dependency management, and back and forth discussions. This can lead to side effects such as reduced velocity, need for additional testing to retain quality, development of interfaces and/or APIs etc. When we get into such situations, lets find out if we can minimize dependencies through techniques like creating mockups, and integrate early and often. Let us ferociously automate testing and deployment (at all levels) so that we can identify and resolve issues quickly.

Plan often and monitor, welcome change..

Lastly, should planning be one time? Absolutely not! The team should be ready to embrace change as they get better insights into customer needs and potential solutions. Lets dispassionately accept new stories, reject old ones that are no longer useful and update ones that need to be updated. Once again, an active Product owner and Team partnership can make a big difference. It is not as important to stick to the initial plan as it is to fulfill needs of the customers.

Related reading:

Thinking about being a Scrum Master? Have you thought about:
1. What is your motivation and do you think you are the right fit?
2. Would you like it to be a career choice?
3. What is in it for you? Is this role really attractive for you? What kind of growth are you looking for?
4. What does this role mean to your organization?

If you have thought about any of these questions and chose to be a scrum master, you are among the few scrum masters I have come across, who had the chance to do so.

In many cases I have come across, being a scrum master has been a matter of chance, many times imposed, rather than a matter of choice. To me that is an indication of how much (lack of) thought we devote into our role in a team setting as we probably should. As a result, we have multiple cases of job done badly, the role being viewed as “just” an administrative role, or something so easy that “anyone” can do, etc.

Before you jump into the Scrum Master Role

Here I list a few things to think about when you are contemplating this role for yourself.

1. Start with motivation. Ask yourself why you want to be the scrum master, and what do you think you will achieve through that role. If you are a good scrum master, your services will be rewarded through your team’s successes (or fast-fails, which should also be considered as successes). Highly successful teams will shine and through them, you will shine. Be aware that scrum master is only as strong as the team, so the primary job of the scrum master is to build a strong, learning team and actively sense and remove impediments that come its way.

2. Proud and Happy Teams – Do you love that? Will you make it your mission to make your teams proud of the work they do and how they do it, so they can predictably meet their commitments to business, deliver quality output keeping technical debt under check? If you answered these questions as yes, you get full marks!

3. Are you looking for glory for yourself or for the team(s) that you will serve? Can you be self-less in victory of your team’s success, will you let them take the credit and can you teach them to learn from failures? Will your organization reward you if you served selflessly? Will your manager understand? If your answer to these questions is yes, you have hope.

4. Do you understand Agile manifesto, Agile principles and do you subscribe to XP values of simplicity, communication, feedback, respect and Courage? If you answered yes, think again. If you answered yes again (and again), think about situations that could get you in trouble with stakeholders, management, and even the team that you might be serving. Would you be able to manage expectations and still help the teams succeed? Yes means you are in business!

5. Are you ready to learn, unlearn and learn again? Different situations require different responses and solutions. Are you willing to experiment with different approaches, solutions and options with different team members, different teams, different projects, and different managers? Are you willing to engage with your audience and fail-fast, take responsibility for your team’s decisions, actions and results (god or bad, specially bad ones)? Are you willing to be open, positively debate with your team, take responsibility of (poor) team decisions even if you disagreed with the team before the decision was made? Yes indicates you have it in you to be a great scrum master.

6. How does your organization view the role of a scrum master? Does it recognize this function as requiring special skills, training and coaching or is there a tendency that Scrum Master is a side-job that anyone with little time can do? If your organization recognizes the importance of this job, you are in luck and the probability of your success will increase dramatically! If it does not recognize it this way, your hard work, diligence and success will surely influence the organization, do not lose hope.

Bottom line, if you want to be a good Scrum Master, wear your servant-leader hat, be well grounded and open to learn, and experiment your way to success.

Related reading:

A discussion I started on Linked:

Breaking Scrum: Scope changes within the sprint…
Looking a “list of reasons” on why product-owner-pushed scope change during the sprint breaks scrum…

Few I can think of (please add):
– Takes away the focus from the current functionality
– Reduces team ownership
– Impacts Quality
– Impacts Velocity
– …….


3 months ago

Prasanna Raghavendra • The basic essense of agile to me is getting joy in the journey (see here: http://2srp.blogspot.com/2010/06/joy-of-journey.html). One should be successful in the small steps to make sure there is continuous passion and teaming, If this fails, everything breaks!

Mike Caddell • A scope change during a sprint – which is a contradiction in terms – invalidates the fundamental agreement and commitment that bounds a Scrum iteration. The team commits to complete a set of functionality as prioritized by the Product Owner and agreed to by the team. The Product Owner in turn commits to helping define and elaborate the agreed on scope in a timely manner to enable the team to do it’s work; and only the agreed on scope, nothing else unless the team finishes early and then picks the next highest priority Release Backlog item.

If the team is asked/required to accomplish a different scope of work during the sprint, the mutual commitment to the previously agreed to scope is thus invalidated. At this point, the sprint should be terminated and a new sprint with the new scope begun – starting with Backlog Grooming and Sprint Planning.

Julie Hendry • I agree Mike, although it often depends on what is meant by ‘scope change’ – is is the overall deliverable or is it simply that we discover more detail?

I’ve seen successful teams accept some changes within scrum as long as the changes are agree and communicated, and do not change the underlying goal of that sprint.

Rahul Sawhney • Thanks all for comments.
@Julie, To clarify I mean “goal changing” and “deliverable changing” sort of changes. I do not mean discovery of some more details.

Mike Caddell • @Julie – a great clarification!

I meant as Rahul indicates, a change in the objective or the actual content.

As this discussion clearly illustrates conversation almost always illuminates more detail – which is why we value Individuals and Interactions more than Process and Tools!

Derek Neighbors • Is the reason why they do? or the reason why they shouldn’t be allowed to?

The reason they do… the team allows them. The don’t enforce some penalty in breaking the contract.

The reason they shouldn’t be allowed to. A key premise of agile resolves around trust. Changing course mid sprint breaks trust and deteriorates the relationship.

Prasanna Raghavendra • I am seeing this discussion going similar to building a stringent chinese wall between the product owners and the team and closing doors on genuine yet possible changes within iterations. Like I mentioned earlier (brewity killed clarity in my earlier note, I guess!), the focus should be on small but quick win at the end every iteration for the entire team (including product owners). That would mean there should be constant communication and acceptability of what can be done for the changes coming-in while appreciating concerns from both end. A “genuine” change coming in within an iteration should be discussed and accepted when possible while showcasing what it means for the dev teams to pick it up. This is when teaming and binding becomes stronger. Product owners should also have strong reasons why the change envisaged cannot wait until the next iteration.

I would discourage a generic and rigid process coming in the way of teaming. Agile is not a process but it is a set of natural tendancies teams follow to bond, and that should take precendence. it is interesting to note that we are losing our this natural behaviour and find it hard to let those take precendence.

Rahul Sawhney • @Prassana – I agree with you completely.

Just to bring the discussion back towards my question, refining it a bit….
What are the after-effects (short term and long term) of having the “sprint-goal changing” scope changes, which would take the focus away from the team to deliver what they committed?

So far, we have seen some points indicated above, would like to learn more perspectives, experiences when this happened etc..

Jeff Smathers, CSM • Rahul, If I understand your question, I think that Derek and Mike have great answers. I will try to summarize for my own benefit. If the scope change is so large it changes the sprint goal then the team cannot meet its commitments and the sprint is no longer valid and should be ended. A new sprint needs to be planned and started to address the changes. Depending on the maturity of the team, the trust between members and the quality of their relationships could suffer. Keeping to the commitments defined by the sprint goal is very important.

Jason Little • I wouldn’t worry so much about the after-effects as I would in trying to figure out why the scope keeps changing every sprint.

Some context would be helpful. Is this team supporting an existing product? Are the interruptions due to customer complaints or support issues? If so, Scrum doesn’t work well in that situation.

Is the PO having problems grooming the backlog to get stuff ready for the sprint? Is there a lack of overall product direction? Are different stakeholders pushing conflicting priorities?

A sprint being constantly interrupted is often the symptom of a deeper problem. Focusing on Scrum as dogma isn’t going to solve the problem and you’ll end up creating more dysfunction and trust issues between the team and the PO.

John Clifford • In Scrum, the team’s commitment to accomplish the items on the sprint backlog that starts the sprint is matched by the Product Owner’s commitment to observe and respect that commitment by not trying to change the agreed-upon scope for the duration of the sprint. One can’t work without the other. I would argue that a Product Owner who continually wants to change scope during the sprint isn’t following the Scrum process and doesn’t respect the team or their commitment. In my experience, this happens because the Product Owner fails to take ownership of the product backlog; either he procrastinates on prioritization until the last moment and then overlooks stakeholder commitments that drive prioritization needs, and/or fails to take responsibility for ensuring backlog items are groomed and prepared prior to sprint planning.

Not having objective, quantitative, and binary acceptance criteria for sprint backlog items is one of the problems leading to scope change; if the team has no defined criteria for the complete story then what is to stop the Product Owner from whipsawing them around? Therefore, the Product Owner should ensure that sufficiently-defined acceptance criteria exists for all stories that she will bring to the sprint planning meeting… and the team should refuse to consider any item lacking this. This isn’t to say that the team and the Product Owner should be at each others’ throats, but instead to say the team may need to spend some time during the sprint planning meeting working with the Product Owner to create sufficiently-defined acceptance criteria.

(Product backlog items with valid acceptance criteria and that have been estimated are often referred to as ‘Ready-Ready’, in the way that sprint backlog items that are completed according to the Definition of Done and all acceptance criteria are referred to as ‘Done-Done-Done-Done.’ Effective Product Owners always have at least one sprint’s worth of backlog items in a ‘Ready-Ready’ state before the start of a sprint planning meeting.)

I’m a huge believer in not hiding dysfunction, because you can’t fix it if you refuse to see it. In the above situation, the sprint planning meeting timebox will most likely end with only one or two items that have valid acceptance criteria; so be it. The Product Owner will need to accept that bandwidth may need to be reserved during the sprint to work on additional items’ acceptance criteria in order to be ready for the next sprint; if the team finishes with the committed items early, they can either drag additional items into the sprint or end the sprint early and re-plan/re-launch. At any rate, this should be discussed at the sprint retrospective and a solution devised that will prevent this from happening again should be implemented.

As others have mentioned, if the team believes that an item’s scope has changed to the extent that the original commitment is invalidated, then they have the authority to reject the changes and not complete the item… and this should be discussed at the retrospective. Or, if the Product Owner really wants to change scope, e.g., substitute a new sprint backlog item for an existing one, even if the item estimates are identical, then the team has the authority to accept or reject the change, to the extent of cancelling the sprint and re-planning. Again, to expose dysfunction, I counsel against accepting ANY sprint backlog changes, not to be a jerk or uncooperative, but in order to force the issue to the surface… Product Owners who continually fail to prioritize and want another bite at the apple, for whatever reason, are a common issue.

Andy Dent • A few thoughts on this, against a background of multiple scrum teams collaborating internationally, spanning 24 hour time differences. We have architectural separation of much of the work but that translates into one team having the other two as customers.

We could take the bloody-minded approach of just saying “no” but that risks some bugs being blockers to another team for an entire sprint.

An alternative is for the team to identify one or two people as responders to handle urgent cross-team requests. They can have a task allocated in the sprint which is basically a budget of their time, to be whittled down over the course of the sprint and leaving them free to do other tasks of moderate size.

When it comes to tasks being inserted into the sprint, another pet idea of mine is to mandate that tasks with twice the number of story points have to be removed.

This reflects the loss of velocity from something unplanned being included and emphasises the seriousness of the interruption to the product owner. I’d love to know if anyone applies this, how they get on!

Raul Xavier Neto • I´ve got a little intrigued with that many arguments being so dogmatic about scrum. I think that one of the best points of agile (in this case, scrum) is to help teams cope with change. Change that is a big reality on every software project.

I´ll go with Jason and Prasanna telling you that the best thing for your team is to find out why the owner is changing that much and try to bring him to the team, where those changes should be agreed by the team with good discussion.

Speaking of dogmas, maybe the initial phase is too dark in the owner´s head, maybe the team is not sure about the concept or something else. To ease that kind of thing, that usually comes in the beginning of the project, you can try to reduce the sprint duration, bring the owner closer to the team, try different approaches to put the team as one peace. Scrum is not a Religion, it only guides teams to achieve good results, but the principles are the important thing, not the “rules”. If you have to, adjust the “rules” to your needs.

Prasanna Raghavendra • @ Raul, @Jason: Bingo!

@Rahul: It is less about worrying about after effects than accepting it as another pragmatic anamoly and see why it occurs and how it can be fixed.

Rahul Sawhney • Thanks John – I enjoyed reading what you have written here.
Thanks to everyone else too – great insight!

Cuan Mulligan • @Rahul, the impact for me is one of cost.

for example, lets say the PO has aprpoval to spend $x on the delivery of a project. It is the role of the PO to ensure the best spend of the companies money.

If the PO keeps changing their mind, this will consume time (cost) and reduce the teams ability to deliver the project benifit for the agreed amount of money.

If the changes are small , ie refeinments, then this should not be an issue. However I have worked with PO, who make quite dramatic changes during a sprint, and then wonder why the project did not deliver. The upside was that they learnt a valuable lesson, and stopped this behaviour.

Gail E. Harris • The fundamental question in this discussion thread is about product-owner driven scope changes during a sprint breaking Scrum. Well, as someone else wrote, Agile approaches like Scrum are all about being agile, and, as it turns out, changing the scope during the sprint doesn’t break Scrum at all.

In Ken Schwaber’s book “Agile Project Management with Scrum” he describes exactly how to handle this. He says that “management could abnormally terminate the Sprint” at which point there would be a new Sprint planning meeting. Ken further notes that this new planning meeting would make the action highly visible and thus hopefully product owners would not make a habit of it.

It’s also worthwhile to note that a new opportunity to change the scope is never more than four weeks away. Once they realize this many product owner’s find that four weeks from now is more than soon enough.

Griffin Jones • We have a very small team, working in a start-up.
Priorities change.

When targets-of-opportunity appear, ownership will pause the sprint as we deal with the new higher priority. The owner makes the informed choice.

Long pauses force a clean re-plan of the sprint. Too much switching reduces velocity. But the owner values responsiveness from development, and is willing to accept reduced velocity in exchange.

Rahul Sawhney • @Cuan,Gail and Griffin, Thanks I was looking for exactly these inputs!

I do believe that this does not break Scrum as a framework. When Scrum is done incorrectly, (i.e. when PO makes significant changes without agreeing with the team and does not allow terminating or pausing the sprint, and does so regularly), the team gets demotivated and starts falling apart. And as Cuan mentioned, not learning from experience escalates costs and reduces team’s ability to deliver and impacts collaboration.

Agile candor, practical agility and other thoughts

This article was published on Scrum Alliance in Oct 2009.

Challenging inertia through Scrum

Inertia is defined as a state of being lazy, sluggish or indifferent. Challenging inertia is about challenging status quo in an organization. It is about how things should be done differently compared to how they are done now. Organizations sometimes become susceptible to failure as they are unable to challenge the status quo due to various reasons. This is as relevant to software development as it is to any other aspect of an organization’s functioning. In this article, we will examine the following reasons for organization inertia, the consequences for software development, and see how Scrum can help with the following:

  • Size of the organization
  • Inefficient structure
  • Too much or too little process
  • Poor performance management


Agile candor, practical agility and other thoughts

Size of the organization

How does it cause inertia

Slow decision making

As organizations grow in size, managing scale becomes an issue. Bigger organization means management decisions have a bigger impact. Wrong decisions can put the organizations at risk and therefore it becomes necessary to consult a variety of stakeholders within and outside the organization. This implies that the time taken for arriving at key decisions becomes longer. The increased timeframe for making decisions is understandable for issues that impact core functioning of the organization. However, it is definitely not suitable when the organization needs to adapt its products in a dynamic and tough market.


Many organizations do not understand this problem and fall into the trap of slow decision making, even for product development. When innovative ideas fail to reach the customers on time, competition gets an undue advantage. Slow pace of decision making can result in missed opportunities, lost revenue and increased customer attrition. Thus, regardless of their size, organizations need to deliver the right functionality at the right time to their customers.

How Scrum helps

  • Ownership of the product backlog and prioritization encourages faster decision making and responsiveness to customer needs even in large organizations. Controlled, yet responsive management of changing requirements helps managing scope with improved turnaround time. The product owner makes sure that the team does not lose sight of what is most important for the customer.
  • Reviews and product demos at the end of each sprint gives the customer representative more clarity on how the end product should work and look. This helps in reducing wastage of effort and money into development of low priority features, when high priority features need more functionality that has yet to be developed.
  • Early feedback from these demos ensures the team makes necessary changes related to the most important functionality of the product in the early stages instead of struggling with issues later when it is too late.
  • For large organizations the cumulative impact of late identification of issues can be very costly and difficult to ascertain. However, as multiple units within the organization implement Scrum, the positive effect is amplified and inertia is reduced immensely.

Agile candor, practical agility and other thoughts

Inefficient structure

How does it cause inertia


Inefficient organizational structures lead to wasted time, effort and money. The wastage mostly results from poor communication channels between people regardless of their team, unit or department. They are also a reflection of an organization’s lack of sensitivity towards customer needs. Traditionally, team members are forced to work as analysts, designers, user interface developers, middle tier developers, database developers, and testers. Work is divided depending on specialization, and it moves from one person to the other in a sequential manner. Such structures create artificial boundaries between people that are difficult to cross. They create a decision vacuum, wherein the buck passes from one person to the other forever, and the issues are resolved at such a slow pace that they would lose their relevance by then.

Power Politics

Inefficient structures promote power politics. They create an environment where people are made to compete with each other endlessly. This often results in situations where they cross each other and spoil relationships in order to get ahead of each other. In such situations, collective ownership is not given its due importance. Often work assignments are driven by authority and processes rather than teamwork and collaboration. Reduced innovation
Inefficient structures make innovation difficult. Since everyone is focused on their own activities rather than delivering complete functionality, few in the team can see the bigger picture of how what they are doing impacts the end-user. Therefore, sources of new ideas to create innovative products are few. Lack of collective ownership We have seen this with step-wise approaches to software development. Business analysts and business owners are responsible for requirements, Architects are responsible for high level design, Designers are responsible for low level design, Developers for coding, Testers for testing, Integrators for integration, and Project Managers for planning, tracking and coordinating their activities. In such a situation, it is the project manager who is blamed, not the team, when a project is delayed. Usually, one way or the other, team members can easily find excuses for not delivering on time by pointing in another direction. Although this works well for everyone other than the project manager, it is the customer who ends up paying for all the inefficiencies. And no one likes paying more than the real value of the product.


The problems with inefficient structure are too many and too difficult to resolve. Due to inefficient structure, customer interests take a back seat as everyone involved views his/her interests as top priority. There is often mistrust of the “other” groups and team members as the blame game can start anytime if anything goes wrong. Due to this people play safe. They only do what they are “supposed” to do, or as per the “defined” compartment to which they belong. The dysfunction is easier to observe at the team level. Some examples are: “Coding can only start when the design is over,” “No changes can be entertained in the requirements since design is already over.” However, the issue extends beyond the team level. When the team size is large or when multiple teams, units, departments and organizations are involved in creating a product, it becomes even more difficult to acknowledge and resolve. It is also possible that there are vested interests in ensuring that the conflicts remain and politics and emotions prevail over common sense. Ultimately, if these issues are not addressed, the customer pays an extra price or gets a delayed product.

How Scrum helps

While there is no easy answer to solving these structural issues, an advantage of Scrum is that it helps in making the dysfunction visible and allows the organizations to take corrective actions. Other than that the following points are worth mentioning. Keeping the team cross functional
  • This reduces bureaucracy and time lag from making decisions at the team level. A cross functional team does not have artificial walls and naturally communicates better internally and with external stakeholders. Teams change focus towards delivering the functionality as a whole instead of delivering one part of the work (e.g. Design, User Interface, Middle Tier, Test etc.). This not only helps team members learn multiple skills, but also aids in immensely de-risking the projects through collective ownership.

Daily Scrums and Scrum of Scrums

  • Focus on resolving impediments quickly improves collaboration and avoids getting into blame games. Scrum meetings keep the entire team engaged in the discussions and provide a clear list of impediments towards progress. These meetings also help team members in supporting each other to meet their joint commitment to the product owner. They enhance teamwork and collective ownership, thereby improving communication. When Scrum meetings are conducted well, structural separations between the team members, which slow down the process, tend to fade away.

Sprint planning workshops

  • Prioritization of requirements in the product backlog provides better visibility to the team about what needs to be developed and improves transparency in decision making.
  • Since the overall scope can be changed at the beginning of every Sprint, business concerns for new requirements are met. Likewise, the IT team’s concern about giving upfront commitment on a plan is also addressed, since with Scrum, it is understood that plan needs to be revisited in every Sprint.
  • Sprint planning workshops improve collaboration between the business, development, testing, user experience and other groups. These workshops align the entire team towards customer needs and make them give a joint commitment to plan.
  • Since all concerned stakeholders are involved in the exercise of scoping and planning, there is a substantial reduction in power politics and improvement in communication, collective ownership and innovation. This eventually benefits the end customers and the organization.

The role of ScrumMaster

  • ScrumMaster plays an important role by serving the team and protecting it from outside interference. By helping the team in following Scrum practices, the ScrumMaster ensures that issues are resolved as fast as possible. The role of ScrumMaster helps in improving communication and collective ownership of the team.

Too much or too little process

How does it cause inertia

Artificial Lags

Lack of appropriate levels of process introduces lags that have an undesirable impact on team performance. For example, too much or heavy process leads to an excessive waiting period due to unnecessary checks at every step in delivering the system.


While lag is introduced by heavy processes, chaos is introduced by too little process. When there is chaos, team members do not know where to go and whom to communicate about what. Without processes, it becomes a free for all. It is easy to understand why typical software projects need a process wherein communication is well managed and roles are well defined.


Heavy processes promote bureaucracy and reduce productivity because, due to the lags they add, things move slowly. As a result, the team is unable to deliver results with low turnaround time and eventually it results in customer dissatisfaction.

How Scrum helps

Just enough documentation and continuous collaboration

  • Documenting the needs of users in a concise, yet informative manner and supplementing it with planning workshops, gives the development team a good perspective on end user needs. This eliminates the need for documents to float around within the team for multiple review/rework cycles and reduces a lot of waste.
  • Collaboration during planning workshops ensures that all stakeholders have a better understanding of the requirements. This helps in designing better test cases and better code. Eventually it reduces the amount of rework required during later stages due to poorly understood requirements.

Short feedback cycles

  • We may encounter several situations where the functionality developed in a Sprint needs to be revisited. For example, we may find that user needs have not been implemented to satisfy the business goals due to bad design/coding, or the requirement was poorly communicated to the team. We may also find that the customer representative changes his view on how the requirement should “actually” be delivered by the time Sprint ends.
  • Scrum makes dysfunction visible and encourages bottom-up feedback. Short feedback cycles of Scrum allow corrective action to be taken almost immediately and satisfy the needs of higher priority functionality in the product backlog.

Team Retrospectives

  • Just as short feedback cycles help us in revisiting the contents of product backlog regularly, retrospectives allow team members to periodically inspect their ways of working and adapt their processes locally.

Poor performance management

How does it cause inertia

Ineffective goal setting

Sometimes individual goals are set with a view to encourage competition within the team. In software development, this could be counter productive if the parameters selected do not encourage team work and team performance.

Improper status tracking
Monitoring status is an important activity from the perspective of team performance. If the team does not track progress or only tracks activities that have been completed, it could be in for a surprise when the project nears completion. Moreover, if tracking progress is more of a centralized activity instead of team activity, there is a high likelihood of status not being reported regularly or correctly as team members may stop seeing the true value derived from status tracking.

Infrequent reviews
Tracking performance after large intervals makes it difficult to assess performance accurately. Due to this the feedback can be incorrect and/or ill-received.


Ineffective goal setting could lead to unnecessary conflicts in the team. It might not perform to its fullest capability in normal situations and could even fall apart in critical situations. Late surprises due to improper and infrequent status and performance tracking could cause the team and its members to slip from their goals. They might deliver later than committed, deliver with lesser scope or deliver by cutting quality.

How Scrum helps

Metrics focused on team needs

  • Working software is the true measure of progress for an agile team. Measuring and setting goals against working software provides the largest benefit. In addition, metrics that focus on day to day activities help the team in assessing its performance against its way of working. For example, the team could track number of build failures and number of acceptance test failures in the integration environment. It could also track how well it follows Scrum and other agile practices it might be using.
  • By measuring metrics that are related to team performance and setting goals with respect to those metrics, the team can continuously improve its way of working and give better output.

Burndown charts

  • Burndown charts provide visual progress of team’s activities and make status tracking a de-centralized and fun activity. They not only track what is completed, but they also track what is pending on a daily basis. This improves the team’s chances to deliver on time, thereby enabling them to fulfill customer needs on time.

Frequent reviews

  • Frequent delivery of working software with Scrum allows the team to review its performance frequently and make course corrections as needed. Frequent reviews of the team’s performance reduce the room for lethargy and provide an incentive to deliver better regularly.


Scrum focuses on results, quick turn around time, short feedback cycles, and collaboration and relevant metrics. This helps an agile team in influencing issues related to size and structure of the organization, software delivery process and performance management. When the use of Scrum spreads at the organizational level, it helps in challenging organizational inertia and making the organization more agile.