The monkey in the middle

Marital therapists earn their living, in large part, by creating a neutral space within which 2 “challenged” or possibly even antagonistic parties come together to explore issues, find harmony, or seek common ground.

Ten years ago, as an agile coach working on a Fortune 500 Financial Services Company’s Lean-Agile initiative, I found myself “holding space” for two distrustful and distant partners — the product group and the development team for the Pre-activation Marketing initiative. The dev group had a history of slipped deliveries and the two parties lived in separate buildings of their campus.

Establishing the shared vision, building the backlog, and sizing the release was the “therapy” in which these partners engaged. And all the while, I (as scrum master and agile coach) was neutral and facilitative, allowing the Product Owner to be vocal and present as the development team self-organized into a powerful unit.

The scrum master being the neutral, facilitating force between these two historically challenged parties (in this case the PO and the development team) made sense to me back in 2005. And in many ways it still does today.

What seems to have changed over the past decade is how people refer to and think of “the Team”.

The scrum guide published July 2013 talks of two distinct “teams”:

HERE’S ONE TEAM:

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.”

“They [development team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”

AND HERE’S ANOTHER TEAM:

“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”

SOME QUESTIONS

So when you (the reader) say “the team”, who are you referring to? Dev Team? Scrum Team? Something entirely different?

And what does self-organization look like within these two very different groups (scrum team and dev team)? Can self-organization occur at both of these levels?

Asking the Scrum Team to self-organize by itself (no neutral party but instead a “monkey in the middle” of the action — that would be the SM) feels very much like the marital therapist inserting him or herself in the middle of the couple — kinda weird!

Can a Scrum Team self-organize if nobody is watching? Nobody is listening? Nobody is facilitating? I’d like to know!!!

Give the Gift of Code on National Pay It Forward Day!

Originally posted on the blog of Curving North, Inc. 

Did you know that today is National Pay It Forward Day? Curving North is committed to giving back and helping those who are dedicated to building and furthering Computer Science programs and offerings in schools. We have donated to CodeVA ourselves and we’re also offering a match up to $500.00 in hopes that others will help to broaden this organizations impact. Once you donate, please send an e-mail to info@curvingnorth.com with proof of your donation and we’ll match it.  Tomorrow, we’ll report back and let you know the results.  Thank you for taking the time to make an impact and a difference.

 

“CodeVA is committed to expanding public school computer science offerings all across Virginia. Based in Richmond, our teacher training efforts and outreach to districts, parents and policymakers assumes a statewide footprint. We are grateful for the partnership we have developed with Code.org, a national organization with a similar mission. We look forward to making computer science education a reality for all Virginia children and for all Virginia communities.”

Lessons About Teams I’ve Learned From My Kids

I’ve been watching my son play team sports for the last 13 years. My daughter just started playing them this year. My son is graduating from High School next month and I’ve been in a very reflective mood lately – especially as his last game gets closer and closer. There’s a lot to be learned from watching kids play and I’m sharing some of my observations with you today.

1. Don’t underestimate a player based on appearance.  Time and time again I have watched this play out.  People (myself included) make assumptions based on how someone looks and behaves only to find out how terribly wrong they were.  I have seen “gangly” kids go toe to toe against “stocky” kids on the offensive line in football and have had to close my eyes – certain someone was going to be injured – only to watch those stocky kids blocked over and over again. Will, determination, understanding their job on the team and the impact to the team if they don’t perform and the simple joy of playing goes a long way.
2. When you get knocked down, get back up (unless of course you’re seriously injured).  Sometimes, players on the opposing side do things that test the other sides mettle.  Getting back up shows your teammates and the other team spirit and drive.  It also serves to challenge the other team to really focus on their game and not their play.  Getting up requires individual strength and determination that everyone appreciates – coaches, fans, officials and teammates.  When you get up, in effect you’re telling the other person to “bring it” and that unspoken message radiates from the rest of your team.
3. Recognize and celebrate great players and teams whether it’s your own or not.  All teams work hard together, over a long period of time and give their best on the field.  As an opposing player or team respecting and admiring what’s great on the field is special and shows that you care about more than the win.  If you do happen to be on the winning team, you earn the respect of the other team.  If you’re on the losing team – same thing AND you win in a different way.
4. Don’t be the team who is clearly better and run up the score on the less-experienced teams. Those teams suck. Instead be the team who is gracious and shows true sportsmanship. You will earn the respect and admiration of the teams you play and those who are watching.  Also, the teams will learn a lot from you that goes far beyond skill. Sure, those amazing teams can be fun to watch initially simply due to how well they play together, ultimately they end up being the team everyone roots against (except the parents of the sucky, winning team).
5. As an observer (aka: parent in the stands) your job is to support and celebrate. Anything else is wasted energy and counter-productive. If you happen to actually know something about the sport because you have played it yourself and you think you have something of value to share, share it after the game and, preferably in private. Sharing it during the game just crushes the player and team spirit which serves to NOT HELP AT ALL.  Plus, all the other observers feel embarrassed for you.
6. Be the veteran who celebrates the rookie.  When someone who is new to the sport tries out or plays, the veteran players who teach, help, coach and encourage the newbie are the ones who are seen as and become team leaders. They are the ones who create a unique and special experience for the new player and the team.
7. One the game ends, focus on your team and the next game. The team who immediately disperses and goes home isn’t a strong team.  When the game is over get with your team, celebrate your successes, focus on where you want to improve immediately and get ready for the next game.

Have any of your own to share?  Would love to read your stories in the comments.

Agile Hardware

So much in the Agile world centers on  people and software.  Ever organizing around developer iterations and quickly integrating the knowledge, feedback, and cross functional improvements.  There is now a force multiplier to this effort.  Not just in scaling bigger – We now are able to leverage as equally quick turns in hardware.   Hardware and software are again matching in a way that allows creativity and innovation explode like never before. It used to be when we were manufacturing we would spend months in design and then more months just waiting.  Spend a princely ransom in the tooling and dies needed just to do limited runs, and then get in prototypes to test how ergonomic, how appropriate for fit or rugged abuse a casing might be. Circuit boards were all or nothing propositions which rarely matched the pace of software development.

3 Dimensional Printing

3D printing has seen an explosion of the type of printers available on the market. These printers are challenging the way we thought about assembly, manufacturing, prototyping, materials, fit, cost, and the list goes on and on. From an idea to physical form is no longer taking the weeks or months it used to.  Some designs can now be reality in hours.  I am going to list just a few of the things that slapped me across the eyes as I got further and further into the world of hardware.  As a burgeoning 3D printer owner – the game of manufacturing is about to change.

Materials

The preponderance of materials come in a filament form.  Types of plastics like ABS and PLA are melted in thin layers to create models.  It doesn’t stop there though. Filaflex is more like a stretchy rubber that enables the printing of more wearable items like sandals or durable phone casings.  Paper, Hershey’s chocolate or sugar, metal powder melted with lasers, resins, carbon fiber and special concrete mixes are just the beginning of an exhaustive list.

Machines

Local motors unveiled the first 3D printed car with plans to be able to manufacture with a 24 hr turn around time.  Microfactories allow consumers to personalize, design and customize.  What does this do to inventory, supply chain and lots?  New and innovative designs get noticed in a hurry.

Voxel8 looks to revolutionize circuitry.  Allowing printing with traces and room for electrical components.

MakerBot is quickly adding features to every printer it creates.  The community of thingiverse has grown tremendously and allows many to share designs.  Not only are many playful, but categories to replace broken parts or get re-mixed with other hardware parts (Ikea is popular).  Many models get remixed as evolutionary design improvements from others.

The Mcore IRIS printer makes 3D models full of life-like color. Paper-based model  construction also makes the consumable materials cheaper.

Formlabs printer uses a laser hardened resin and produces some of the most finely detailed models.

Look at up and coming machine designs:

The Griffin Delta printer is defining a new standard in a printer that can be assembled as a home project.  This printer also scales in size for the your intended use.

A 15 yr old is now designing the Orb.  Using a record player like turntable, his modular approach and new modeling language aren’t the only innovations.  Heating and material changes promise to speed the print times by a factor of 10.

Software

Sketchup, Tinkercad, Inkscape, Repetier, Blender, Slic3r, Cura, Skanect, Makerware.  Software is enabling us to capture our ideas more quickly.  The import and export,  formats  and fixes are really driven as the some of the most important features.   Surface Tessellation Language (.stl) is a way of geometrically dividing and describing a surface. The .STL file is common but not the only way to capture 3 dimensional information.   Meshes and object capture are also common. HTML5 and Fusion tables allow interaction with different types of 3 dimensional information.
Measurement is predominantly in metric as it scales so much more easily.  mm and microns are common units.  Software also starts being predictable at model supports, material needed and time to print.  Speeds (for the moment) are mm/s.  All this easily translates into predictable micro transactions of a few dollars.

If You Can See It

Hardware and software allows 3-D scanning of objects around us.  ASUS Kinect is often used with a 3D printed handle to scan in art and people.  A  cosplay or Halloween costume becomes an action figure. Possibly even a chess piece as an aggregated 3D model of a family portrait. Makerbot’s Digitizer sells alongside their printers.  Another amazing must have in this year’s laptops and phones is Intel’s RealSense.  This camera will scan, measure, translate objects into models and give us that long awaited Minority Report interaction with the screen.

Remix Ideas

Take some relatively disparate areas and start enabling a 3D mindset.  Letting kids use a Sharpie for drawing can easily translate into a 3D toy.  Video Games already hold 3D models.  Popular pokemon figures, Minecraft buildings can all be exported and create a personal model to inspire and spark the imagination.  NASA topographical data and even Google Earth buildings can be used for sections of landscape or cityscape models.

I am very much looking forward to the innovative “WOW” factor as 3d printing continues to affect so many products, so quickly.  Personal in a visual and tactile way; ideas are more agile than ever.

Make It So

It has been too long since I have written anything here.  The number of draft posts is a little embarrassing and frustrating.  The advice I give to my clients definitely applies to me too:

–  Stop starting.  Start finishing.

–  Limit your WIP!

–  Focus!

Easier said than done right?  It’s easy to observe and throw out those words of wisdom for others and, frankly, I feel a bit like a hypocrite for not applying them to myself with the discipline and rigor I ask from those I coach.  I am not perfect.  No-one is.

I have a vision for myself and it’s beyond idealistic.  I crafted it over three years ago on the advice of my friend and mentor, Dan Mezick.  I continue to re-visit it and modify it with new information and goals.  2014 was an interesting year for me and, admittedly, I went a little off track.  The shift wasn’t intentional and I didn’t even realize it until before the holidays, when I was reflecting on the direction I was heading against my vision.  I was on the verge of being grossly off-course.  That said, sometimes, a major course in direction is a good thing right?  It depends on the goal or vision you’re trying to reach and that can change.

What I realized is my vision had changed but, the path I was on was taking me further away from my original vision AND the modified one.  I had to adjust and, let me tell you it was not and will not be easy.  When I think about what I want to achieve it makes me nervous.  Actually, it scares me. I question if maybe I’m being too idealistic and putting something out there for myself that just isn’t possible.  But, I’ll never know unless I try.  Trying means I have to do things which are far outside of my comfort zone and current knowledge base.  It means that I am getting on a path which could, very likely, lead to several failures (learning!).  I had to really think about how ready I was to embark on this adjustment before I made it.

The deciding factor had nothing to do with how ready I was and MUCH more to do with how much I wanted my vision to become my reality.   Then, the decision was clear even though the path to get there wasn’t.  The path will emerge as I go (sound familiar).  Right now, it’s clear.  Further out…not so much but, every day, with new knowledge and learning, the runway is becoming more clear.

This experience has served multiple purposes.  First, it has put me back on my path.  Second, it has re-affirmed my true north.  Third, it has made me challenge myself more.  Fourth, it has reminded me of the importance of having a vision.  Finally, it has made me remember the experience of individuals and teams starting on their Agile journey.  What a lot of goodness!

I’m not thinking about all the things standing in the way of realizing my vision.  Instead, I’m focusing on how to “make it so”.

Clock Time, Event Time, and Bullet Time

When becoming agile, there are many ways that we start to look inward in order to change how flexible we can be.  We start to think about work differently.  We think about how we collaborate together.  We think about task, story and epic level things.  We also ponder time itself.    Is there a placeholder event for that?  Is this the appropriate time? Is the time-box up? I remember the high school teacher’s frustration at having students look eagerly at the clock – anticipating the moment when the bell would sound the end of class. Ultimately later in the year, the note underneath, which was posted and read “Time will pass.  Will you?”

 Clock Time

There are things that are run by clock time.  In the agile world we set limits on meetings and sprints Many organizations still account for hours. Things that are run by the clock.  It lends a sense of urgency and there is a certain puzzling in order to fit activities and interactions to fit appropriately.  Time does not stop. It marches.  What does change though – is our perception of time.  Some moments whiz by or instead as Shakespeare said slowly drags on and “Creeps in this petty pace from day to day, To the last syllable of recorded time”.  When our days are managed by the clock, I often wonder if this alien and measured arbiter of fate sometimes robs us of an empowered position.  Some teams often measure a sprint burn down with hours remaining (Which I’ve previously talked about here) .

Event Time

When timelines are populated by events they often give us a sense of achievement and better context than Chronos‘ stamp of numbers.  I am looking for a task to complete rather than time to run out.  Choosing achievement over activity and hallmarking instead by the memorable actions which have culminated in a sense of completion.  Sometimes ending a day in a ‘good spot’.  Event time seems to allow for creativity and innovation that spark and motivate just a little more.  Doing something Better than before, not just the same way over and over.  Is event time always better? probably not as with all things there is a balance.  It will Clock time that helps us determine if something ‘unsustainable’. But, again, only because we haven’t achieved the desired events. A Team might measure tasks, not as hours remaining, but rather as events – only wanting to know if they are in progress or done. A retrospective timeline will often be measured in 3 ways – the chronological timeline (1) earmarked with events (2) and our reactions (3).

Bullet Time

The matrix first coined the term, being fluid and moving faster than we thought possible.  Unfortunately it always seems to be during crisis moments.  Whether on a six story drop on an amusement park ride or in front of a release review.  Our brain registers everything and goes into a hyper protective mode.  It’s sometimes hard to remain calm and in a problem solving in a panic driven environment.  At times the uber-urgency brings out some of the best in our teams in an almost Apollo 13 type of way.  There are no lives on the line, but the sense of responsibility doesn’t seem any lessened.  It usually takes longer term investments in teams of people to make critical and good decisions.  To support those teams we invest in infrastructure and technologies.  We let them adopt lightweight processes which enable them to move quickly.  Bullet time is not a sustainable thing. But some of the best days are briefly ventured here, when the team pulls together and works itself out of a crisis.  Even better when the team plans to avoid the same thing from ever happening again and moves back into Clock or Event time.

The Agile Manifesto Pictionary

In 2001 something happened. A document was drafted and called the Agile Manifesto. It is wonderfully simple and requires just a bit of thought-full-ness  in order to consider a favored balance of someone or something OVER something else.    In order to help bring the point across I often draw a small picture of the document that goes something like this…

                                                                                                     The teams seem to remember it much, much better.

Individuals and interactions over processes and tools

My drawing for a person is simple and quick.  a stick figure.  the emphasis is that they share the same thought cloud.
Over
a hammer and a wrench or some gears….  processes and tools were meant to enable people… not fetter them.

Working software over comprehensive documentation

A train made out of 1’s and Zeroes.  = working software.  In the old days we didn’t have enough 1’s to go around.
Over
pieces and stacks of paper

Customer collaboration over contract negotiation

Simple Stick people – but one of the is holding a ‘$’… Just as in a USER buying our software.
Over
Jail.  Locked down and imprisoned by paper that seemed to hold everything we wanted but quickly grew heavy and burdensome.  protecting a prior understanding rather than representing how we work together.

Responding to change over following a plan

A chameleon – and this is how I think of adaptability. Responding to change.  If I have some colored markers I’ll stripe a few bits if rainbow in there. We are teaching teams with an emphasis on problem solving skills.  They must adjust and respond to change, as no situation is ever ideal.
Over
A treasure map.  A plan.  I Love me a plan. – Yet most experienced coaches and veterans will tell you that plans seldom encompass or foresee every detail when in the thick of action.  So you train your team to adapt, adjust, and be problem solvers in order to overcome the things that get in our way and the difficulties along the path.  Buried treasure, by the way, is not valuable. Like in software – if it is hidden and no-one uses it or knows it is there…  it is not worth much.

Try it and see if the 4 principles are easier to recall.  Even if you are recalling a gecko pirate…  wait another second and it will lead you to ‘adaptability over plan’.

 

The Dreaded, Embedded Coach…

There’s a disturbance in the Agile force.  Consultancies and coaches who look for clients with a vacant coaching parking lot.  A place where coaches can roam the halls by the hour and bill for it without actually adding value.  I call this Embedded coaching and it’s something we, as coaches have a responsibility to eradicate.  Embedded coaching is great for people who want to make money and, from the business perspective, I can understand the draw.  I mean, if an organization is willing to continue to pay money and not realize value, why not?  Embedded coaches aren’t great for organizations who really want to improve nor is it great for Agile coaches overall.

Now, there can be several reasons why a coach isn’t adding value.  Things like:

1. The coach isn’t a good fit for the organization and/or the team(s).
2. The client really isn’t certain what they want to achieve so, then, the coach isn’t either.
3. The client isn’t willing to be coached or do any of the heavy lifting so there aren’t results despite the best efforts of the coach.
4. The coach isn’t good.
5. The coach ceases to be a coach and becomes a player.
6. The client doesn’t take advantage of the coach when he/she is there.
7. The coach has embedded.

Dan LeFebvre (aka: Coach Dan), a coach whom I admire and respect a great deal, offered a definition of an embedded coach:

“I define embedded coaching as someone who is there 5 days a week working with a handful of teams or may be occupying the SM or PO role (either explicitly or implicitly by usurping the actual SM or PO authority) while being called the coach.” – Coach Dan

It’s the embedding I want to focus on.   I have a theory there’s about a 6-9 month maximum span of efficacy for a coach.  Granted, if the organization or number of teams is large and/or the problem is incredibly complex (transformation) more time may still be valuable and warranted as long as value is being added.  The reason I say this is because the more time you spend in a place, the harder it is to remain completely objective.  You come to expect and excuse certain behaviors – the “it is what it is” mentality can creep in (if you’re not very careful).  And, it’s after this time a coach is in danger of becoming embedded.

The embedded coach attends events and meetings, throws out some advice or observational feedback and vanishes down the hall.  He doesn’t collaborate – he pontificates.  He throws out a thought-provoking question and makes noises of interest in the responses, shrugs his shoulders and shakes his head.  Meanwhile, clients wonder “What, exactly, does he do and how is he spending his time?   At this point the client is wasting money and the coach is wasting time.  Not only that, the value of a coach and, perhaps, Agile is called into question as well.  And, this (calling into question the value of coaches and Agile)is NOT okay.

Coach Dan also offers the following for your consideration:

“I think coaches should work with the teams for a sprint or two then exclusively work with SM and leaders to improve their ability to operate with the agile mindset. Enterprise coaches also focus on establishing what I call the 3 necessary mechanisms to re-enforce agility: 1) impediments removal mechanism where slowdowns in the flow are rapidly identified, escalated and resolved; 2) building the capacity for internal coaching through internal people opting-in to the coaches role or through communities of practice; 3) agile portfolio management where the entire product/value flow is pull-based rather than push. A possible fourth is the “opt-in” cultural aspects that all good self-organizing systems need to truly multiply the effectiveness and delivery of value.” – Coach Dan

Dan Mezick, another coach whom I admire and respect, contributed the following Coaching Values which, I believe, are worthy of mention and introspection.  He also details supporting principles.

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

Ideally, coaches have chosen this profession because they love it and, happily, are able to support themselves and their families.  As coaches, we owe it to the profession and the clients we serve to ensure both are set up for success.   There are things we can do:

1. Align on the goals of the engagement and the definition of value.  Meet regularly to openly discuss the progress and re-align.
2. Ask the client “What value have I provided this week?”.  If he can’t answer, immediately diagnose the root cause together and agree on actions.
3. Actively communicate what you’re doing, why you’re doing it and the results – realized or expected.
4. Don’t establish a need for physical presence 5 days a week where you become a regular fixture of the environment and are taken for granted.
5. Be honest and true.  You know when you’re not adding value.  Remove yourself with offers of alternate coaches or course of action.

Thank you for your time.

Yes. Size DOES Matter.

Contrary to popular belief Bigger is NOT better.  Big organizations want BIG stuff.  Whether it be projects, programs, releases, teams, scope, architecture…you name it, they want it BIG!  Even Org charts.  The more levels and boxes, the better.  But, when it comes time to getting things done the people you need to execute now have to jump through BIG hoops to make it happen.  And, after all of that BIG effort, the end result ends up being not so big.  Despite this notion of bigger not being better being proven time and time again, it’s still a challenge for people believe it.  I’ve blogged about this before and I offer my apologies for being repetitive.  Events have put this top of mind – again – and I just couldn’t control the urge.  Big <insert item here> leads to BIG problems.

Team Size – More people means more potential communication gaps, lack of alignment – to the commitment, the work and the vision, inability to unify into a single entity and difficulty collaborating.

Scope Size – Everything and the kitchen sink means greater risk.  Risk to what you ask?  Risk that what finally gets put into production is no longer relevant.  You put too much out there, something doesn’t work and you have no idea what that something is.  The problem you initially set out to address is diluted and gets lost in the shinier things people have managed to shove in.  There’s so much you have to move quickly and quality and deliberate decision making goes out the window.

Story Size – Well, the hood’s open so we may as well….. Wait.  What was this story delivering again?  There’s no way we can complete that in a sprint.  Now, what you thought was a quick fix ends up taking a quarter.

Process Size – Rather than addressing the root cause, we have a process to make sure that – what was it we were trying to prevent again?  Big Process is indicative of an inefficient organization/system.

Decision Size – You can’t empower anyone to decide to decide anything b/c the potential impact is (also) TOO BIG.  This means everything takes way too long.  The date you’re shooting for?  Add 6 or so months to it.

WIP Size – There’s so much in progress that focus is lost.  Congratulations, you now have 20 things in progress and completion of any one of them is no where on the horizon.  Makes for some BIG reporting though.  WOOT!

Want to scale?  All of the above applies times a gazillion.  Size matters.  If you’re seeing problems with being able to deliver quality software frequently and efficiently, dig into the size of everything.  Be warned.  You could find yourself standing in a very BIG hole.

 

The Burn Down – Using it for GOOD vs. EVIL

As  a Scrum Master, some of my teams resented the burn down and me for pestering them to update their time.  Sometimes, teams feel the updating of hours and the burn down are ways to make make micro-managing easier.  And, sometimes, that’s EXACTLY what it is used for.  It’s sad but true.  So, what happens when this “evil” scenario is true?

1.  Managers have a false sense of security that all is right with the delivery team.  They really like that.  As managers, it’s a bragging point.

2.  Teams don’t get a sense of what might be off easily.  This means a delay in realizing there’s a problem.  This is good when teams don’t want their managers to know there is a problem.

3.  The environment teams work within doesn’t improve enough to foster honesty and transparency.  This means no one really wants to learn about problems much less prevent or fix them.

4.  The evil cycle continues because without transparency, you can’t build trust.  A good burn down isn’t, by itself, a reason to trust.  Also, teams who have managers who manage to the burn down may have a hard time trusting their manager.  Does the manager REALLY want to know about, care about or help fix a problem?

5.  The Principle “Working Software is the Primary Measure of Progress” isn’t ever true.  I mean, as long as the burn down is pretty, who cares about working software? No ONE b/c the burn down is perfect!

 

When managers show value for the burn down rather than meeting the Sprint Goals and the team commitment, the team will ensure what the manager values looks AWESOME thereby completely missing the point.  The burn down is a great tool when used for good and a Scrum Master can help educate teams and managers on the goodness.  Frankly, when a burn down looks too good, I’m a little skeptical.

A daily burn down is an easy, quick, daily graphical representation of how the team is doing against their plan.  The key word there is THEIR plan.  If something looks off, it’s a signal for all of them to take a look.  There’s something taking longer than they thought.  Time is being added at a rate equal to or greater than time is being burned.  The team isn’t updating their work rendering the burn down inaccurate. There are other possibilities as well but, the point here is the team needs to take action.

They own their commitment right?  They also own the plan.  If something is taking longer, what is it and what can be done – now – to correct it?  There’s no need to wait for retro.  They can jump on it and get back on track.  It could be scope creep introduced somewhere.  It could be an impediment they’re spending too much time trying to resolve and need to escalate outside to get help.  It could be something they’re making more complex than it needs to be (perfect is the enemy of good).

Time being added faster than the burn down means they’ve learned more as they dove into the story further and there’s more to it than they thought.  They can work with the PO to see what modifications to scope can be made.  They didn’t really take planning all that seriously and need to re-visit their plan quickly to correct and let the PO know what has changed and what it means.

The team isn’t burning their time down.  This could be because they don’t see the value as a result of never having used it for its intended purpose.  If teams aren’t using it and aren’t taking action to refine and adjust as they go, surprises await the PO and stakeholders at the end of a sprint which is no good.

Helping the team see the value and teaching managers to value the accuracy of it rather than the ideal and actual lining up nicely is a good first step.  The team demonstrating their value for it through the actions they take – when necessary – to address it builds trust with the PO and the managers.  Reminding managers of the true goal – WORKING SOFTWARE and the importance of hitting the established sprint goals – and focusing on those rather than the burn down is preferred.

I like to leverage the demos to do this.  Review the sprint goals with the audience.  Speak to the target and actual velocity.  Show the burn down and walk through the learning points of the sprint with everyone.  If the burn down looks good  but the goals and target velocity were missed THAT is what managers need to spend time on.  I also like all of the above to use in Retro too.  Let the team consider the data to inform their growth opportunities and actions coming out of retro.

Burn downs are good…unless they’re obsolete and not used correctly.  Then, they’re evil and can impediments to Agility themselves.  Manage to the burn down and you will get a pretty burn down.  Manage towards a team’s ability to reliably and frequently deliver working software and meet their sprint goals and you will get a team who cares about that, takes their commitment seriously and ensures you are never surprised and are always aware of what’s going on.