What Does Sustainable Pace Really Mean?

IMG_0077

Agile values and principles are the core foundation by which Agile organizations operate and make decisions. Everything we do is based in these.  With that being said, viewing every principle through a holistic perspective is absolutely necessary.  Every word in the principles we live by has value and impact.  So, when we reduce a principle to a three word summary, I believe we do ourselves a disservice.  This practice often results in focusing on part of the principle without the balance of the other side.  Through this oversight, we inadvertently create environments where there is unbalance that leaves people frustrated and confused.  They begin to believe that Agile is the problem.  But, the real problem is our failure completely embrace the Agile values and principles and settle for anti-patterns instead.

Today, I’d like to take a deeper look into Agile Principle #8 which states:  Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 

People often refer to this principle as the sustainable pace principle.  The most common description given of how we practice this principle is that the development team should not be expected to do more work than they can complete in a normal business day.  We don’t want people working 70 hours a week because they are forced to do more work than is possible during a normal work week.  Working at that pace is something a team may be able to do for a sprint or two but they cannot work at that pace indefinitely.  When people are tired and overworked they make more mistakes and it actually slows down their ability to produce work.  It also impacts motivation.  When people are overworked and have no work/life balance motivation dwindles.

But there’s another part to this principle that I don’t hear quoted as often.  It’s the part that talks about the constant pace at which the sponsors, developers, and users should be able to maintain.  This is about the consistency of our delivery, sometimes referred to as predictability.  Developers should be able to trust that sponsors and users will allow them to work at a sustainable pace.  In return, sponsors and users should be able to trust that developers will consistently provide a continuous stream of valuable software.  The team has a responsibility to be transparent with the sponsors and users regarding how much work they can complete in a certain timeframe.  They also have a responsibility to be transparent when the forecast must be changed along the way due to new information or unforeseen problems.  This gives the sponsors and users the ability to communicate and make decisions regarding the impact of the forecast change.

How does this impact the way the team conducts planning and communicates their forecast?  Teams should plan for as much as they can realistically complete and communicate that forecast.  Then, they should strive to complete 100% of their forecast every sprint.  If something happens to prevent the completion of the forecast they should communicate as soon as feasible to stakeholders so they know what to expect.

Should teams forecast 125% of what they believe they can realistically complete and be happy if 80% of the work gets finished?  No.  Why?  First, because it sets unrealistic stakeholder expectations to communicate more work than the team can realistically expect to finish.  Second, because it contributes to a lack of trust between the stakeholder and the team when the team keeps promising work they consistently don’t deliver.  Third, because the extra time planning and tasking stories that aren’t likely to be worked creates waste and adds unnecessary time to the planning process.

Then what do we do with “stretch” stories?  It is my belief that “stretch” stories are not a part of the forecast.  Plan and communicate what you believe you can complete.  If the backlog is groomed properly it will always have at 1-2 sprints worth of work in “ready” state.  So, if the team runs out of work they can always agree to pull in another story.  The solutioning and tasking for that story can take place when the decision to pull it in happens.

If the team consistently gets 100% for 3-5 sprints, stretch yourself and bring a few more points into your sprint forecast.  It may take you a couple of sprints to get to 100% again but it will stretch your ability to produce work and push you to incorporate practices like automation in order to move faster.

There should be an understanding that no team will always complete 100% of the work forecasted.  This is another part of the concept of trust and transparency.  Stakeholders and customers trust that developers will always strive to complete 100% of the forecasted work.  Developers trust that when something happens and they can’t deliver 100% and communicate openly to stakeholders and users there will be grace and understanding extended.

 

Advertisements

Is More Really Better?

IMG_3265

One of my favorite things about being and Agile coach is connecting with the Agile community through conferences, meet-ups, and other networks.  Because of these connections I get to interact with  Agilists all over the world.  Over the past few months I’ve noticed a concerning trend coming from the Scrum Master community.  They are telling me with excitement, “I’ve finally worked myself up to two teams!”  Some have said they are now working with three or four teams.  The thing that concerns me is that they seem to view spreading themselves across multiple teams as an accomplishment.  I am hearing pride in “being busy” and “being able to handle more” and that tells me that we still have work to do.  It tells me that there may still be an anti-pattern running rampant in our Agile organizations telling us lies.

The belief that “the more I can handle and the busier I am the more valuable I am to the company” is left over from days when sustainable pace wasn’t a part of the culture.  The truth is that busy does not equal productive.  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  It is not to ensure that everyone is at least 100% (or more) utilized.  Agile processes are supposed to promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  When we are running at 100% (or more) of our capacity we cannot maintain that pace indefinitely.  At some point, we burn out mentally, physically, and emotionally.  We cannot afford choose utilization over productivity.  Our primary measure of progress should be working software, not how much more we can get done with fewer people.  The efficiencies in an Agile organization don’t come from piling more work on fewer people.  They come from improving our technical practices, increasing automation, increasing quality, lowering technical debt, collaborating, and learning to continuously improve our processes.  These things give us the ability to produce more without adding employees because we stop tripping over ourselves and can run along a clear path.

I read the following question from a user on stackoverflow.com:

“Does running your servers at 100% CPU usage cause any issues or is it just good CPU utilization?  My servers have 8 physical cores constantly running at near 100% for “open hours”/10 hours per day.  The program is architected to run on 8 threads – and it fully uses them. Performance is good but the infrastructure guys are worrying about the “maxed out servers.”  I think it’s just good use of available resources. What’s the point of having lots of core if they are not all fully utilized?”

The problem with this line of thinking is that when resources are fully utilized they don’t get more done.  Contrarily, less gets done.  They move slower, wait time increases, and so do errors.  Here’s the response someone gave to this question:

“Almost without exception it causes issues, or will cause issues down the road (as demand grows).  100% CPU utilization on a web service server is not good.  If your CPU utilization is at 100% it means that each time the server gets a new request there is a 100% chance that the work will have to wait some amount of time before the server gets started on it.  The typical performance sweet spot is about 70%.  Does that sound low?  If so, remember that 70% utilization doesn’t mean that 30% of the CPU is being wasted.  Instead, it means that 70% of the CPU’s capacity was used over a sample period.  For CPU measurement metrics, a sample period is something like 2 seconds.  During that 2 seconds the breakdown of that 70% is uneven.  In other words, it may be something like 100% for 1 second and 40% in one second.  For short bursts like that, 100% utilization is okay because we know that if a piece of work is delayed it is only for a brief period. (One that won’t make the human waiting upset.)”

I’m wondering, if we adhere to this rule with our hardware resources, why don’t we realize that the same rule applies to our human resources?

I’ve been in the position where I was a scrum master on one team doing an excellent job.  I knew the pulse of my team and they were growing rapidly and performing better than ever.  Then, I was given a second team.  Sure, I had enough down time in my average week to handle facilitating Scrum events for two teams (in theory) but because I was toggling between two team rooms I missed a lot on both. On sprint end/start days I felt very pressured.  I ran from one retro to the next on and often couldn’t compile the improvement plan into a consumable format until two days later.  I fell behind updating information radiators and had less time to think analytically through what was happening with each team.  Over time I saw that both teams were maintaining, even growing some, but the rate of growth was slower than when I had only one team.

Then, something tragic happened.  I was “doing such a great job” that I was asked to take on two more teams for a month to fill a hiring gap.  I felt like a total failure.  I had to choose which teams I was going to work with and leave the others stranded.  I had no clue what was going on in any of the four teams because I wasn’t spending enough time with any of them to catch the important conversations.  My teams all felt abandoned by me and had to pick up the slack felt by my absence.  While in my manager’s eyes nothing fell to the ground because my teams were mature enough to fill in the gaps without me, my teams felt all the pain and none of the benefit.

I learned a very powerful lesson through that experience.  Being utilized at 100% (or more) capacity didn’t make me a super Scrum Master.  It made me a terrible Scrum Master.  On a ledger somewhere it may have looked like the company saved money by utilizing me to full capacity but the impact of the hidden cost was much greater than the financial gain.  We would have done better to allow the third and fourth teams to work without a scrum master for that month.  Instead, we caused four teams to operate without a scrum master by spreading me too thin.

What message do we send as an organization when we tell our teams we expect them to plan their sprints at 125% of their capacity?  It’s a message that says we do not value sustainable pace.  What message do we send when we tell our employees we want them on multiple teams so we can fully utilize their capacity?  It’s a message that says we do not value sustainable pace.  What message do I hear when Scrum Masters tell me proudly that they are working on multiple teams?  I hear that they have forsaken the Agile principle of sustainable pace.  I hear an anti-pattern.  It makes me know that though we have come far we still have more work to do before becoming truly Agile.

This Shouldn’t Be a Status Meeting … Improving the Daily Scrum

IMG_0785

How can I keep the daily scrum from becoming a daily status meeting? But if we are all answering three questions then who is supposed to be asking the questions?  If we are gathering to give our updates on these three questions every day on what we are doing then that sounds like a status meeting to me – what am I doing wrong?

These are all questions that I have heard new scrum masters ask.  The daily scrum seems like it should be the simplest thing we do, right?  The team self organizes daily for a time box of no more than 15 minutes and talks about three things:  What I did yesterday, what I am going to do today, and what is standing in my way.

So, why is it so hard?  In my experience … mindset.  Often, scrum masters learn a process to implement but they don’t recognize the mindset that must change in order for the process to have any value.  Being self organizing and collaborative, like being agile, is a mindset.  It’s not just something you do – it’s something you are.  It’s something you become.  It’s about individuals and interactions over process and tools. What I’m finding is that when teams are struggling with the daily scrum it’s about them putting the process and tools over the individuals and interactions.

When I encounter the struggling scrum masters I find that they have been given a process that they are trying to implement:  Meet for 15 minutes, everyone on the team answer three questions about what they are doing, don’t talk about anything else, break ~ scrum master you are responsible for making sure that the process is followed and that the team understands how scrum works so go make it happen.

But the thing they seem to miss in the equation is that the daily scrum is about the team coming together daily to collaborate and plan how they will work together to deliver the highest priority user stories today or as soon as possible.

Are you struggling in this very thing?

What would happen on your team today if instead of everyone taking a turn answering three questions about what they did on some random user story yesterday and will do today towards the sprint goal, you would all look at the scrum board together and focus on only the top priority one or two stories?  Then, collaborate and discuss what you can do as a team to get those stories completed today or tomorrow?

Tomorrow you can do the same only start by adding to the conversation any progress you made since the last time you met or what stopped you from making the progress you each thought you would make.  Then figure out together what you will do as a team to remove those roadblocks and how you will get the remaining work on the story completed before the next daily scrum.

If one or more of the stories gets finished by tomorrow’s daily scrum celebrate that success and add the next priority story to the conversation.

The advice and method I’ve just described is really nothing new, it’s just putting the individuals and interactions over the process and tools.  It’s all about what we focus on.  When we focus on the questions and the time box and governing the scope of the conversation to make sure we don’t deviate from the questions we lose the collaboration and the true heart of what the daily scrum should be.

Agile Manifesto — What it means to me

IMG_9825

The Agile Manifesto talks about uncovering better ways of developing software by doing it and helping others do it.  It goes on to state that through this work and helping others, four consist values have developed.  To me, these values go far beyond software development and set a platform for making decisions and forming thought processes.  For me, these values form the mindset of agility which spills over into every area of life.  Because my mindset is one of agility, I can’t help but take agile out into the world beyond software development.  Everyday, I work with people and see agile changing mindsets and impacting lives for the better.

We value:  Individuals and interactions over processes and tools

This value represents that understanding that an agile life is filled with humans!  Humans are interesting, complex, intelligent, diverse, ever changing, and FUN!  Processes are important and so are the tools that we use to get work done.  But, when processes and tools become more valuable to us than the people who use those processes and tools they have over-stepped their boundary.  Processes and tools are created by people to solve problems, work more efficiently and to bring consistency.  They should not be jails of solitary confinement where we get locked in and become slaves to the thing we created to help us!  We cannot replace people with process and tools.  When individuals interact with one another, creative ideas form, problems are solved, momentum can is gained, new perspectives are shared, and growth occurs.  People learn from interacting with each other.  We become more aware of the world around us and more aware of ourselves when we interact with individuals of various types.  When we take people out of the equation and rely on the processes and tools, our work suffers.  Processes and tools are meant to assist people and should be used in this manner.  They should never become a replacement for interacting with people — Text messaging is a prime example … Texting is a tool that can be used for quick communication when direct conversations are impossible but if we allow this to take away our ability to speak to and directly interact with individuals we become a slave to the tool and it has more (negative) power than originally intended.

We Value:  Working software over comprehensive documentation

To me, this value says:  Let’s don’t just talk about it.  Let’s do something about it!  Let’s build it!  I can spend a lot of time writing a document that tells you every detail of what I can do and what I want, or I can write just enough to make sure you get an understanding of the direction we are heading and provide you with something you can touch and feel to see if it makes you happy.  I don’t want to waste your time or money and I don’t want to waste mine either so lets build this thing together.

We Value:  Customer collaboration over contract negotiation

I’ve got two choices when serving customers.  I can make them outline every detail of everything they will ever want from me and hold them to it rigidly – charging them for every slight shift.  OR, we can agree to create something great together and set some boundaries in a contract that protects us both and start collaborating to ensure that we get to the finish line together!

We Value:  Responding to change over following a plan

 Plans are good.  They are needed.  They are necessary.  But, change is reality.  Why do we pretend that we don’t know that change will occur?  People change.  Circumstances change.  Budgets change.  Markets change.  The world around us changes every single day.  Instead of being ruled by a rigid plan that we know becomes obsolete and unrealistic just moments after it is created, lets plan to change.  Plan in shorter periods of time that we are more likely to be able to predict for success instead of multiple months or even years down the road.  Get feedback and don’t be mad when the customer realizes that they didn’t know what they wanted until they saw what you provided.  Be flattered that what you showed them generated enough interest and excitement that they could see it become something great that met their needs and provided great value.  Isn’t that the end goal?  If executing upon and controlling a plan is the primary goal, producing a valuable product that satisfies the customer must take a back seat to this objective.  But, if customer satisfaction is the target – our plans must be flexible …. agile even!

The Agile Manifesto Original Signers:

 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas