Sustainable Pace: Trusting Your Teams

6 December 2011

Endless business requirements, desired features, market pressures… There is always more work that needs done. Sometimes, it may feel like endless sprints where you thought you saw the finish line, but every time you round the track they tell you there’s another lap. You dig deep and pull together the energy to continue to sprint, but again, you round the last turn and push forward toward the end and people on the sidelines are yelling “another lap, another lap” and you check to see if you can find the energy to keep going, but you can’t. You keep thinking you’ll have a break but it never ends. The sprints are seemingly endless back-to-back cycles and you see no end in sight. You need to catch your breath, you need water, you’re getting blisters… You’ve burnt out.

There comes a point when you realize that if you put down the work and go home for the day, it will still be there when you come in the next morning. Though, with pressure from stakeholders and seemingly endless pressure to deliver every two weeks, if the team is not operating at a sustainable pace, they may feel overwhelmed and lose motivation. I recall some wisdom I received from a project team I was working with a few years back where I came onboard with new energy, but not everyone could maintain the same pace long term. For those that had been working there 20-some years, they couldn’t always run; they had settled into a pace where they could last for the marathon. I was complimented on my efficiency, but warned about burning out if I didn’t find a pace that was sustainable. This was a traditional project management environment that ended up converting to Agile and the principles hold true regardless of the environment. Sustainable pace is essential to long term well being.

When planning a sprint, teams often take on more work than they can complete within that dedicated time period. I’ve done it, most all of us have. Why do we do this? Is it a superman syndrome, an eagerness to please, overestimating and forgetting to leave room for uncertainty or just blatant disregard for reality?

There seems to always be pressure to get more work done. Teams being challenged to do more, then being asked why they took on the work if they couldn’t finish it. Managers and stakeholders disappointed when they didn’t get what they thought the team was going to deliver.

When a team finds their sustainable pace, right sizes the work to deliver within a sprint and can meet the sprint goal, they can find a sense of empowerment and accomplishment. The teams will begin to set better expectations with their customers on what they are delivering. Stakeholders can count on the team to complete what they said they could because it is realistic, not just an ambitious attempt. At the root of this concept is trust. Trust that even though stakeholders are pushing for more, when the team says this is what we think we can accomplish the stakeholders listen. Providing the full thought process around what is reasonable and including the “why” can help in providing this understanding. Trust from each other within the team and trust from those around the team sets the stage for stability.

The team needs to be comfortable speaking up and pushing back; the Scrum Master needs to help shield them and Product Owner, to listen. There needs to be a safe environment for honest feedback. We still want to have dialogue on concerns, challenges for new ideas or other considerations, but the team needs the place to be heard. Trust your experts.

The defeat of carrying over work from one sprint to the next can be accompanied by frustration and stress. The sense of accomplishment of completing all the work planned within the sprint and being able to deliver can have a positive impact on the team’s morale. Becoming Agile is about a better way to work. Building a trusting, open environment, not an endless death march, sprint after sprint after sprint.

It is important to have regular communication at many levels from within the team to the external stakeholders. Product Owners need to be empowered and trusted by the stakeholders to balance the priorities with the capacity of the team, keeping stakeholders informed with frequent touch points. There is always more work on the table than can be done. Stakeholders should find more satisfaction when they know they’re going to get what the team committed to. Cramming more work into a sprint does not mean that it will get done. It just makes it harder to estimate what will be done. The sprint backlog should reflect reality, not what the stakeholders want to see. Product Owners should be able to make the call, but we need to empower them to do so.

There seems to be a common theme that arises when teams feel overwhelmed yet still trying to meet unrealistic business demands. There isn’t room to take on much else or think outside of their current focus. The teams need to be trusted and there needs to be a safe environment for them to say when requests are unrealistic. Allowing extra time can enable more creative thinking and lead to higher productivity. Achieving a sustainable pace is a step closer to an environment that fosters innovation.

Article Rating

Current rating: 4 (1 ratings)

Comments

Jan-Egbert Hamming, CSM, 12/6/2011 3:00:29 PM
Good article. I also think that the sustainable pace should be interrupted from time to time to give teams a chance to be even more innovative, for instance: after a couple of sprints initia a couple of 'off days' : no standup, do what you want. I believe that teams will use that time to make things even better.

Regards,
Jan-Egbert
Srinu Tamada, CSM, 12/8/2011 10:23:54 PM
Good article. With my personal experience I learned the same. When we converted from basic process model to agile, we faced lot of issue with sprint planning. We were over burden because of 2 weeks deliveries. We were taking more story points than what we can and client also never looked at whether we can delivery it on time or not. Then 2 of our team member got trained in CSM and new product owner joined in the organization. Then things started working smoothly. Scrum master used to stop over commitment and if he overlooks our product over is damn good and she never let team to do over commitment. So we never faced tiredness.
Regards,
Srinu Tamad
Maria Matarelli, CSP,CSM,CSPO, 12/8/2011 10:58:27 PM
Thanks, Jan-Egbert! I've heard teams express the desire for time or a break too. Sometimes when teams are feeling like there is alot of work to do, they may finish a sprint and want to jump right into sprint planning and skip the retrospective. The retrospective is so important to take the time to revisit how things are going. It doesn't have to just be a reflection on what worked well and what didn't work, it could be a celebration of successes or a team building exercise. The team could take a longer period of time for reflection. Agree that there needs to be time to allow for innovation.
Maria Matarelli, CSP,CSM,CSPO, 12/8/2011 11:03:11 PM
Thanks for sharing, Srinu. That is so important for the Scrum Master and Product Owner to support the team in finding their sustainable pace. It's such a better environment for the team to work in. When work gets consistently pushed from one sprint to the next, it can be very disheartening. Finding a way to change that behavior is a big improvement. Great to hear of your success!
Jan-Egbert Hamming, CSM, 12/9/2011 1:07:46 PM
I have learned that the retrospective is the most important meeting of scrum, and indeed it is, the retrospective is the birthplace of improvements. I try to make the retro fun and change the setup now and then. The last retro i introduced the sprint timeline that includes a mood line, very refreshing and an eyeopener for the team! We also celebrate successes and failures. Never forget to celebrate failures, its the best way to learn from failures and improve yourself!
Regards, Jan-Egbert
Patrick Heller, CSM, 12/21/2011 4:41:17 AM
Good article! It is important the stakeholders and the product owner have faith in the professionality of the team. That faith has to be earned. Part of the earning process is speaking up. The team should let the others know what its professional insights are. Once the stakeholders and product owner realize that the team knows what it's talking about, the trust will follow.
Padmalochan Patnaik, CSM, 12/29/2011 1:42:58 PM
A very good and relevant article. I have often found with my teams that the development and testing activities get focus and are estimated for the sprint while the other activities related to security, operations, release planning, etc. get left out and we are suddenly spending time on those activities in the sprint. One reason for this is that often these areas are not represented in the project teams. If that is the case, during sprint planning the Scrum Master must bring forward these activities on the board and get their estimates so that the right level of development and testing gets included in the sprint. Regards, Paddy
Chand Warrier, CSM, 12/29/2011 4:01:32 PM
Excellent! article and a true picture of most Agile teams. What I have done for my team is have Time-Boxed Release schedule leaving no space for endless sprints (at least the team does not get the feeling). We don't go to production at the end of every Sprint (instead make the increment production ready), after every 4-6 sprints is when we release the product into production and with every release the team gets a 1 week cooling period for production support and sprint 0 (Planning for next release).
David Bennington, CSM, 1/3/2012 1:41:47 PM
Thank you Maria for such an insightful article. Something I have seen newer teams struggle with is trying to find that balance between over and under commitment in a sprint (their sweet spot). It is a constant challenge. I advise these teams to try and take on stretch items occasionally, just to see if they can accomplish more, especially if they have established some track record of meeting all of their sprint commitments, but not to make a habit of it. I think it is important to reach beyond one's grasp occasionally, just to test yourself.
Miguel Ángel Abreu Ferrer, CSM, 1/7/2012 6:19:47 PM
Excellent article Maria, I have experienced with my teams most of the things you have mentioned in the article, I like the paragraph talking about the superman syndrome or the eagerness to please, since I have had situations like this. One of the messages I usually send to my teams from time to time is that our customers won┬┤t be happy because we are the ones estimating the less time for a certain story or task, while in the end we don┬┤t meet such an estimate. Our customer value predictability, this is the key, so they can be sure that if the team says this is going to be done, then it will be done. Predictability is extremely important to gain trust and being able to be heard by the stakeholders when the team needs to say ΓÇ£no, this can┬┤t be accomplished, we need to reduce the scopeΓÇ£. It is also the key to be able to establish the sustainable pace you mentioned, that is vital for keeping the productivity of the team in a long term basis, otherwise the team will end burnt out as you mentioned. Thanks for sharing such an insightful article.
Justin Hennessy, CSM, 2/12/2012 6:13:10 PM
Thanks Maria, great article. I have a question, you are correct the pressure from the business is always going to be intense. The issue im facing at the moment is management's idea is we just need more people and more teams to get the work done. What is your view on this?
Maria Matarelli, CSP,CSM,CSPO, 3/31/2012 1:22:05 AM
Hi Justin, we have encountered this same challenge time and time again where management has wanted to add more people to the project team in hopes of increasing the output. There are a few concerns with this as it is not always effective. There is a point of diminishing returns where adding more people ceases to add more value, rather it begins to slow down the team. When the teams begin to get much larger, the communication channels begin to break down and the team can be more sluggish than efficient. Another thing to watch out for is the level of skillsets of the additional people being added to the project. If the people are not up to speed on the technology or do not have the skills needed for the project, they can actually detract from the progress and slow the team down further. In one encounter of this situation, an attempt was made to explain to management and stakeholders that it was not possible to get all of the work done by the arbitrary date identified. Management was insistent that it "just needed to be done" and they said "what do you need, more people?" and added more people to an already large team. When talking with the Product Owners, it didn't seem feasible to be able to complete the work that was requested within that time period, though the pressure to include more work was too insistent to deny. After exploring other options and explaining to management, we came to the conclusion that the best thing that we could do in this situation was to document and communicate the concerns, accept the additional people and move forward despite the impossible nature of the request to complete everything. We drew pictures and displayed the velocity trend to make the work visible. After all other attempts did not work, it appeared that we would need to fail before management would believe that it could not be done. The team still did their best however were unable to complete all of the work that stakeholders had pressured the Product Owners into including. After the work was not completed and it was shown that it was overestimated from the beginning, the team retrospected on the root cause of these factors and was able to use this as historical support when they planned their next iteration. They were able to show management and stakeholders the amount of work the team could complete as indicated by their velocity. In this scenario, I believe the team had to fail in order for management to believe that they were over their capacity. If the work can be broken down among more than one team, with work listed in the backlogs and using Scrum of Scrums for coordination then it could be possible to get more of the work done. However, I have also seen this done where the people for the additional teams did not have the right skills or experience and again, this doesn't help increase the amount of work done. Another item to watch for.
Bill Rinko-Gay, CSM, 10/19/2012 1:54:01 PM
In my experience, people get the desire to excel beaten out of them by thoughtless leaders and/or circumstances. What you wind up with are people who need to be "pushed" to do their best. They don't start out that way, but they learn that voluntarily giving 100% is a huge risk. So customers and managers learn to press for more to offset this fear that the managers and owners have created. It is far better to simply remove the fear. If you can remove the fear, you will be surprised at just how fast a "sustainable pace" can be.
Tom Mellor, CST,CSP,CSM,CSPO, 12/6/2012 7:14:52 PM
This matter has been discussed for more than 30 years - by Fred Brooks (from which emanated "Brooks Law" that postulates that adding more people will make a project later), Jerry Weinberg, Tom DeMarco, Tim Lister, Ed Yourdon (author of "Death March") and many others. Of course, the miserable history of death marches and poor project results has not seemingly changed our behaviors over that duration of time. It seems to me that much of that constancy in poor behaviors stems from a continued irrational "belief in magic" (well described in "The 7 Laws of Magical Thinking" by Matthew Huston.) Ken Schwaber thoroughly described the consequences of magical thinking in his classic 2006 Google Talk (http://www.youtube.com/watch?v=IyNPeTn8fpo.) The issue was so poignant for the signatories to the Agile Manifesto that they assigned to it one of their 12 principles.

Ms. Matarelli's article is elaborate and descriptive, but it lacks reference to the one Scrum value (of the five) that has to be present in people who resist the pressure of the death march and overburden of work: courage (the others are commitment, respect, openness, and focus.) It takes a whole lot of personal courage and perhaps even some propensity for career masochism to defy the people who display this pejorative behavior (mostly managers and executives.) The biggest misbehaviors occur prominently in one particular role in my opinion and experiences: the project manager. Removing the project manager from Scrum was intentional and aimed at mitigating the various wicked tricks used by them (e.g. death marches, overtime, cajoling, demands, threats, etc.) to coerce and bully people into "doing more with less."

Facing down contemptible managers and others who rule from a throne requires a gallon of bravery and a pound of mettle, and the acceptance of the risk that goes with that. Robert Quinn talks of this in his classic "Change the World: How Ordinary People Can Accomplish Extraordinary Results" and in The Arbinger Institute's "Leadership and Self-Deception." The author writes "Becoming Agile (sic) is about a better way to work." For sure, but that is not typically the defacto culture in many organizations. In fact, in many it is purely idealistic and resisted for a whole host of reasons. That adds to the dilemma that is resisting the onerous death march and "unsustainable pace." It is not an endeavor for the faint of heart.
Glen Wang, CSM, 2/18/2013 1:39:48 AM
Maria,

Thanks for pointing out the relationship of sustainable pace and trust. Scrum Master plays an important role to make sure sustainable pace and trust happen. This is a natural responsibility of Scrum Master, just like how a mother supports her baby. PO is a father and Scrum Master is a mother, aha!

Glen Wang
Allen Ollendorf, CSP,CSM,CSPO, 2/28/2013 8:04:14 AM
Thanks Maria! I am forwarding a link to your article to my team. You have great insight into a vexing challenge in Scrum. Many stakeholders want to 'drive' results without regard for longer-term thinking and sustainability. Many of us realize, however, that the true gift of Scrum is having some measure of predictability. Once a team is able to grasp the formula for their own 'Special Sauce' and the lights turn on for stakeholders, then true innovation is possible.

You must Login or Signup to comment.