The Agile Hard Hat

When a company has made some inroads to being agile it seems as if something is always under construction.  A process, a team, the software… something. On a real construction site, it’s a hard hat that provides some degree of safety. LOOK OUT!  The same might be said for an agile environment.  But within the context of thinking caps, I think of a hard hat as a mode that seems to be stuck, frozen.  There is something to an agile environment that puts us into the edge and makes explorers and problem solvers. There are always a few that seem to hunker down and are really uncomfortable with the participation.  Sometimes it is trust, sometimes it is a slower rate of acceptance… the reasons are legion.  A good way to take some team members and start them down the road to perspective and context switching is Edward de Bono’s 6 Hats Exercise for a retrospective.  Now this isn’t a Scrum thing, but it is a way to get team members to become flexible thinkers.  To describe it quickly – each of the six ‘thinking caps’ represented by a color has it’s own way of thinking.  Take a look.  Black- critical, Yellow – optimistic, White – factual,  Blue – process, Green – creative, and Red – intuitive.   Scrum masters might want to switch up their entrenched black and yellow thinkers in order to move a team forward and get them to be agile thinkers.  Mix it up, rotate or randomize.  

Lincoln once said that if “I were given six hours to chop down a tree, I would spend the first four sharpening the axe.”  In his wisdom Lincoln was differentiating between activity and achievement.  Something John Wooden as a coach would often tell his teams were two very different and distinct things.  Activity. Achievement.  Scrum teams often have to use this disruptive innovation to focus at a level of thinking.  Are we tasking? Or maybe we are using this next (some-time box of) minutes to talk about and clarify our stories, features, epics, releases, product, or portfolio?

Now, as a manager or a project manager, I occasionally hear something that goes to the effect. ‘Why are my developers in a meeting?  They should be coding 100% of the time”  I try not to sigh noticeably.  This, is after all, where the some of the organizational terra-forming begins.  It can be  a mistake made by some traditional practices.  It is more surprising to continue to uncover this years into an agile adoption.  But make no mistake, I am always glad to bump into it.  We can’t get to the correction which makes it right until we are speaking openly and truthfully.  There is an echelon of QA and test professionals that echo this mantra.  However, I’m not usually the first to bump into the mentality – which means it is rather a rigidness of thought that has a tendency to persist until it meets with its paradigm shift.  Some one buried in activity has little time to change how they work, let alon how they think.  We advocate and support it should be expected instead some time is spent to focus on improving how we work.  Kaizan.

Agile does more than just re-arrange the way we do our work.  It changes how we think.  Software is problem solving and some pretty hard thought work.  If there is a difference between achievement and activity – the axe that we should spend some time sharpening – it is our own minds. Other tools and processes certainly fly into the mix, but the interaction still leverages our ‘thinker’.

A rigidness of thought.  The thinker might have stalled out.  Ever meet that contrarian person?  Just so negative all the time?  To go the opposite extreme and be perennially optimistic can sometimes lead to solutions which might not be robust.  We need everyone to be agile thinkers to get this software to done.  I think I can… I know I can set aside my hard hat as we improve the software, ourselves, our team, and the organization.


The Sprint That Blew Up

Is it appropriate to blow up a sprint?

The Setting
We were several sprints in with a new team and suddenly the team was faced something new.  Something out of their control caused havoc with the priorities in the Backlog. The work that the Scrum team had committed to for the sprint was no longer needed.  In the Sprint Review the scrum teams voiced that we did not meet our original goals.   The teams and the product owners were hard-voiced about having to “blow up the sprint” and having to “re-plan and re-baseline”.  There was a discomfort level and some confusion within the team as to whether we might have done the right thing. The strongest statement was, “The institution of scrum was disrespected.”

The Cliff Notes Answer
Leadership, stakeholders, coaches, and scrum authors say we all made the right decision and behaved correctly. Changing our sprint backlog in the middle of the sprint made sense because it honored new business objects and the desires of our Product Owners. The scrum play book says it is perfectly fine for teams to break the sprint this way as long as this is the rare exception rather than the norm.
The Detailed Answer
As I am talking with the team I will start this out with saying “GOOD JOB”
and end my conversation in the same way. I start asking QUESTIONS.  
When is it appropriate to Blow up a sprint and re-plan/recommit? 
Are we allowed to do it? Sure.
Always I want to ask questions. The first one is obviously Why? 
Is this a BIG Deal? I think it is.  Firsts often are. 
Were our assumptions on the sprint goals wrong?
What risk did we not think about critically?
What wasn’t communicated?
Does this still make sense?
Were the release themes not vetted from above and below? 
Was everyone on the same page for acceptance criteria for the stories?
What changed our assumptions?
How can we prevent this from happening again?
The Team did A LOT of work! 
We adjusted to the highest priority!  
Will the business expect this as common practice?
How disruptive was this? 
What was the impact? Did we lose 3 days of our sprint?
What did we learn? 
How do we improve?
I write this after the fact because we are empowered to make these decisions.
Don’t regret the decision – learn and adapt.  You have also worked through a fairly large and complicated problem.
You have changed, and will continue to change some of the assumptions we have together, as an organization.
Good Job!
————–Here are some external references from the proverbial Agile Library: 
Succeeding with Agile (Mike Cohn) pg 282 “I usually advise Scrum teams to start taking a firm stance against mid sprint changes. This is not because I am Opposed to redirecting a team or because I want to slavishly obey a Scrum Rule. It is because I want to help those outside the team learn that there is a cost to redirecting the team.  Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t think ahead. I relax this hard-line stance against change after I see the organization no longer thinks of every new request as an emergency worthy of a mid-sprint change.   Being responsive is what has made us successful, and users expect that of us.
Exploring Scrum: The Fundamentals (Doug Shimp and Dan Rawsthorne) 1rst ed. pg 268 “Cancelling a Sprint. The product owner may cancel a Sprint at any time, usually because the Sprint Goal isn’t going to be met or because the Sprint Goal is no longer what is needed. In either case, the Sprint’s work is evaluated to see what can be kept, and whether or not a replanning is called for.  This is not considered abnormal, but it is simply an agile reaction to something that has happened. It should not be considered a ‘bad thing’ – it is merely a ‘thing’.”
Scrum Product Ownership (Bob Galen) pg 110 “Adjusting the Sprint. … In fact the leader here should be the Scrum Master. He or she is your partner and should guide you in making any necessary adjustments, etc.  However you do play a significant part in the Sprint recovery process, too!
 CONTENT DISCONNECT. The team is struggling to deliver the Sprint contents. Within a few days of the Sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint.  That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced length Sprint in order to maintain your Synchronization. …  I’ve seen teams significantly recover their progress and often meet the original Sprint Goal. …
 PRIORITY DISCONNECT. … In these cases he (product owner) was more likely to cancel the sprint and then re-plan a new one based on a major shift on the backlog.  However when re-planning we tried to stay open minded about integrating the new work and maintaining some of the original Sprint focus.  Another aspect of this is insufficient look-ahead. I was never convinced that we couldn’t anticipate these changes in some way. Remember, we were on a 2 week sprint model which is fairly nimble.”
Changing direction doesn’t come for free. We are trying to be agile and make adapting lightweight – but a team’s capacity to do so is not infinite.  The time and impact required to pack up what we were focused on, and then re-plan should not be ignored. When we commit to a backlog at the beginning of a sprint, the team is serious about delivering the work and trusts that they have everyone’s support and are allowed to maintain this focus in order to deliver.  Unanticipated work in the middle of a sprint distracts. If a team starts to believe their commitments will be ignored, the erosion of urgency, commitment and trust start to occur. Loss of trust erodes team morale and we’ll eventually find ourselves back to where we started. In quiet silos with being defensive about collaborating.  Our ability to fail early is not a joke.  It is instead a measurement for how quickly can we get to right.   
A message like this should be visible enough to encourage the team we did the right thing.  Some VPs, a few Directors, coaches and half a dozen managers as well as the teams themselves needed to know and think in a manner where there was no ‘us’ vs ‘them’.  There is only “WE”, together.  As in WE will make this better and work together so that it shouldn’t happen again.  As well as, we will be thought-full about the “But if it does…”.   This is what transforms the organization, delivers great software, and as a side-effect, makes some high performing teams.
If you’ve made it this far, thank you for reading through the details.

Team Behaviors

good_teamsI found myself looking over the shoulder of a 10 year old who was watching YouTube videos.  Teams challenging each other in competitively created Minecraft worlds.  I get curious about what other people see.  Maybe an even better word is ‘perceive’. By being so, I also get to learn.  As this particular video series unfolds, the same competition is recorded by each of the two teams involved.  A perspective from each side.  After the winning team series was viewed, he continued to watch the same contest from the losing team’s perspective.  ‘Why’ resounded in my mind.  “What did you learn? What did the team, that won, – do better?” This elicited such a thoughtful look that I then asked if he could write down just exactly what made the winning team a good team.  I share this list with you, not only because I believe that it was good, but it is also how we spend a majority of our lives.  From kindergarten and even after retirement – we interact in groups.  Teams if you will.  Esther Derby noted the good characteristics of a thriving team.  As well as struggling teams exhibiting something different. What do you and your teams strive for?  I am going to go over this young professor’s list.

Splitting Resources

Effectiveness in being visible with what resources we have.  Many of the reality survival shows take a group that will depend upon the openness to share what they have.  Tools, knowledge, food, sources of inspiration.  Everything is fair game.  What if we consider the members of the group itself to be a resource.  We are sharing of ourselves… Pair programming for example. Teaching or helping to perform a task.  Load balancing the team itself and how it works with what it has. Even creating things that the team will need and help it to thrive.


There it is.  We need to plan… we start out with one.  Agile also tells us that this is the starting place, and we cherish our ability to adapt and alter that plan as the struggle ensues.  Some of the goals remain unchanged, but the little adjustments along the way point to our ability to absorb changes as reality proves itself to be divergent from our imagination and preconceptions. The plan helps our expectations converge.  It is something that we leverage to rally the team. Typically we even have multiple levels of planning. Our coordination begins somewhere.

Help Each Other

This is one of the main reasons we are in a team.  It is also why we emphasize self-organization.  What can we do to be a part of the solution and move the team towards success. Helping drives the interaction of the team.  Trust is integral.  I sometimes have to remind members to assume good intent and focus on the goals.  No matter how hectic and chaotic the circumstances are, watching a team calmly work through the tough situations with a focus and clarity allows them to analyze and critically process.  Better decisions and great solutions will result from a team like this.  The opposite end of the spectrum is a team in a defensive or reactive mode as a loose grouping of individuals that simply do what was heard to be the loudest.  It may get you through some short term fires, but there is usually a cost to the team and organization in the longer term. Team building is the best by-product I have ever witnessed as a result of any agile program.

Tell each other what they’re doing – so people can help and support them.  

This sounds exactly like a stand-up.  Even in a larger sense how the entire team is being visible and open with the work we are doing. Especially the problems or opportunities along the way. This is how our coordination continues.  We work on our communication daily.  Being face to face is still the widest broadband form of communication around… but it may not always be feasible.  An active team usually has a buzz or chatter as tasks are worked. There is little trepidation at relaying the information of what is happening and our progress towards our goals.  Everyone here is trying to get the team ahead, through the thought-work, through the software, hardware, processes,tools…  Many people are connected by a headset as part of a team and rely on this coordination to achieve work for the team.  For teams this is another line of sight – making our work visible.  Great teams make decisions based on information passed along quickly.  It is part of their reaction time.  Going off into a mine and being isolated for a very long time may not always be in the interest of the quick pace at which a team needs to be informed, move and react. Speak up, we need ideas from everyone.

Defend each other

Now hopefully, no one on the team is being attacked physically and directly to where we need to shield our mate from the slings and arrows of outrageous fortune.  Yet there are other things to defend against. From the perspective of the author of this original list – this would include bullying.  Software is hard problem-solving. Usually instead, we are probing for work being done on the wrong thing that might not be highest priority. Providing a solution might prove too fragile, or hold us for far too long.  Defending takes the support for someone just a bit further.  Defending is the type of behavior that promotes swarming. Not everyone may start out knowing when to ask for help.   Swarming on tasks the team knows to be critical should come naturally.  What about sustainable pace?  Defending each other against burnout, or helping to ensure the quality of the code is high. Perhaps even ensuring that the acceptance criteria is well understood or that a definition of done is met. What about improving or automating some repetitive task so that another team member can contribute more?

Thinks Creatively

Great teams have a gift for this.  Innovation by it’s nature takes some risk taking, vision, drive and creative tenacity.  Seeing what could be is far more powerful than why it can’t. I often think that this is the singular most powerful characteristic someone can possess as jobs change.  The speed or the rate of technological and scientific discovery will continue to quicken and broaden.  Without creativity, the possibilities, unorthodox connections and navigation of shifting paradigms should otherwise ever prove to be a challenge. Adventure time.

My profound thank you to a growing ‘coach’ that is understanding and looking at teams in a way, that I didn’t start exploring, until I was far older.
What would make your team’s list?

Theory of Constraints

I attended a small workshop on the ‘Theory of Constraints‘.  It is a management perspective on work introduced by E. Goldratt.  There are five steps towards minimizing waste, work in progress (WIP) , and increasing efficiency.  There are some assumptions about the system, such as only having 3 levers of control – expense of operations, throughput of the system, and inventory or WIP.

  1. Find the constraint, where things start to get backed up. Some function, process, change, etc.
  2. Exploit or Focus on the constraint. Figure out how to get the most out of it.  This draws down the WIP, and smooths out the production flow.
  3. When the constraint is elevated – the rest of the process is subordinate.  The constraint is visible, and we subjugate the rest of the flow to it’s capacity.
  4. Elevate and start improving upon the constraint’s capacity
  5. Repeat these steps to continue increasing the flow through the system.  It may even be a new place where the constraint occurs.

Just having typed… I might only keep three.

  1. Identify the bottleneck.  We need situational awareness about what is happening.  Part of this is knowing if it is temporary or a usual suspect.
  2. (You are here) – Improve this. As it is now the most important thing in the process.
  3. After some stabilization, revisit and repeat by stepping back and looking at the process as a whole.

which kind of sounds like plan, do, check.

Great teams have a way of looking at these constraints as opportunities to improve.  The workshop had a small exercise for teams of 5 people that helped each team explore and improve upon what the ‘system’ constraint was.  Manufacturing a ‘product’ that was comprised of index cards, stickers, and marker lines.   Through 4 rounds our team changed and steadily improved how and even what we did.  All in order to assemble the specialized product faster, easier, with less mistakes and without accumulating excess WIP.

There were a few thoughts that occurred along the way.  The theory can equally apply to either a push or a pull system.  Lean has taught us that pull systems are usually the better model to emulate.  Using a rope held by people as an analogy – a rope generates slack (WIP) when it is pushed forward to another person’s hand.  The rope stays  smoothly even when everyone is gently pulled along.  Scrum and Kanban are PULL type systems.  Allowing for the capacity of the team, stage, etc.

A vertical slice explores the system for constraints as well.  When taking a very thin slice from the topmost  user interface to the depths of architecture, with something very small, -we are probing for the part that was most difficult to change.  It is a form of learning, and risk reduction.  Learning about the system, and precisely where it is appropriate to improve.  Since right now this part took us the longest to implement some change with.

Finally, I wonder what constraints we may have imposed upon ourselves,  – simply by not having noticed.

How Close Was The Customer Collaboration?

So I was near a conversation that kind of went like this;

A developer was asking the actual user of his team’s software for some feedback about the product.
I was heartened to see the invitation and he had a lean in to listen better.  He was taking mental notes (I could see the gears moving) on how to make this better. The developer also explained how rare an actual customer interaction had been over the past several years. The user didn’t have much in the way positive to say about the software and was matter-of-fact in conveying that it really wasn’t all that usable and we needed some extra fields and the training needed to be a lot better – to reflect how they were using it. I watched his wonderful continued calm as the developer wasn’t at all defensive, continuing to listen. Then a third person, who thought they knew the next step, interrupted to say that the customer needed to get project funding.

This is where my head leaps in and explores.

The customer really doesn’t care about someone else’s internal processes for funding.  And at time this is going to be some organizational telekinesis that is way too big for them to tackle. The customer may feel alone – like they were left to swim in the middle of the ocean. No Hope.

There are at least three things that need to be said here ….

1)      Good job for the developer – not just to invite, ask and listen. I have the distinct impression that this will continue.  I heavily encourage it.

2)      The ‘Future funding’ is simply a stall tactic to put off our being responsible today.   There is a current project that didn’t even include the customer. Why not open that up and start inviting them to the reviews, as a first step.  Get their feedback. Developing a trust and a responsiveness with the end-user will help in all sorts of ways.  Elicit their help in building and testing it.  Now I am not saying that funding isn’t needed.  Typically however funding never really gets at all the hidden costs within an organization to get the software out the door and into the customers hands. The definition of being done means that it is fit for use.  The requirements aren’t sitting down at some desk using the software to get a job done – a person is.  We should ever cherish and understand that.  Maybe over time – the software, the job, both change. Who knows.

3)      Why would anyone want to continue funding a ‘redo’ when it wasn’t done right the first time.

Now pullback a year or more, and there is a conversation that I had with a director about his organization.  We talked about involving the customer and he wanted to hold-off on doing exactly that.  The argument went something like… my customer is internal since we develop our own software.  My customers are not going to innovate, adopt change, and discover ways to do things better.  Just put it out in the field and they will use it as we leverage external sources for creativity and innovation.

My counter was that we required a balance.  No matter how creative we are, if software isn’t usable – then we have a great big point of failure once we’ve deployed.  The mix of this balance might be slim in the beginning as we learn to work together.  20/80 or even say 10/90 but if we just absolutely brick a Berlin wall and shut out or silo the left hand from the right – we are going to miss the inevitable handshake that is coming.  Over the course of the next year, took a while to grow that relationship.  As the new teams learned from the experienced field about the app, they also grew to trust the deliverable more.  Slowly the field also started not only accepting changes but also leveraged opportunities with more suggestions.  The field started getting used to the idea of being innovative just as they were able to share their experience.

Both sides were far richer for the interaction.  Expectant convergence about the end-results were also happening more often.

What also started to happen was that the teams were increasingly aware of Everything it took to move software through the organization and into the customers hands.  Processes started improving. Requests for infrastructure were aligned to support business objectives.

It is my experience it takes a while to move some big things like an entire organization.  You do it by being part of the culture and then changing it.  A little at a time.  Some things catch on and sometimes you even have a motivational brush fire within an organization that started from a just a few sparks.  The fire within us, helps us along whatever journey we have.

Scrum and Kanban

We run across informative books that tell us just a bit more.  Henrik Kniberg and his coauthor Mattias Skarin  have just such a publication with Kanban and Scrum – Making the Most of Both.  It is a great reference with many examples.  When I started having individuals and teams and ask for the differences between Scrum and Kanban, I wanted to help them by explaining the impact of choosing either. Once I was sure that a team didn’t just want to adopt kanban in order to hide from a scrum master, we were ready to explore the impact of going with one, the other or a mixture of both (Scrumban).  The 3 columns below were a reminder for making a good comparison.  The choice however also included some consideration for the organization and where we ultimately wanted to grow. Hopefully it serves to help the conversation you may have with that team along their agile journey.




Start with Retrospectives

Never stop experimenting

  • Fear vs. empowered
  • Mistakes vs. failures
  • Continuous Improvement

Feedback +/- Long vs. Short

  • Too Long may make it hard to find a root cause
  • Too Short may cause thrashing with no process stabilization

A Short History of Kanban:

1950’s Edward Deming a quality focused statistical process control person form the US is in Japan doing work for the Government.  Taichi Ohno who creates the Toyota Production System (TPS) is similarly working on Just In Time (JIT) and Lean Manufacturing methods.    Kanban results from this crucible of ideas in time.  Both Edward and Taichi die in the 1990’s when Lean Manufacturing is gaining popularity in the US.  Kanban means ‘signal board’ in Japanese.  It is a tool to help drive out waste.  A pull of inventory and work is preferred over a push.  The signal board helps to communicate work in progress and the state of this work.

Muda    – ‘waste’

7 kinds of waste are identified [They still hold relevance from a manufacturing world to an IT world – Read the book “The Phoenix Project” for more comparisons between the two]

T – Transportation [Today I put this in terms of COMMUNICATION TRANSPORTAION – how many emails, tools notes and days have passed rather than just stopping over or pairing up and getting it straight]
I – Inventory [maybe this is license usage, capacity, ]
M – Motion [meetings that weren’t useful]
W – Waiting [Time, feedback lags, process completion]
O – Over processing [duplication of effort in code, replication in different tools or the organization]
O – Overproduction [producing things the customer didn’t want and didn’t align with expectation]
D – Defects [!!!]

Mura     – ‘unevenness’ – [making the peaks and valleys a bit more level with shared resources or load balancing]
Muri      – ‘overburden’ – [still speaks to sustainable pace today]

A Short History of Scrum:

In 1986 Ikujiro Nonaka and Hirotaka Takeuchi write a reactionary paper called the “New NEW Product Development”.  In it, they note that the team behavior that works best is very scrum-like.  This is in reference to the sport of Rugby.  In the 1990’s in the US, Jeff Sutherland and then Ken Schwaber, start experimenting with software development teams and keep this inspirational terminology.

Red Rover, Red Rover The Waterfall Cross-Over

There are still teams running waterfall.  For certain processes – waterfall may work just fine.  For software development, however, this is becoming a rare sighting.  The paper written by Winston Royce in 1970 described a process for getting software through an organization.  The term ‘waterfall’ itself would be coined 6 years later.  We often joked that a point of no return would come and the software would often be pushed off the ledge and into the customer’s hands.  The customer very often saw it for the first time after several months or more were spent hidden in the depths of the company while it was being created.

“But Agile will make it Worse”

– of course it will silly.

Even Shakespeare said it so long ago.   The fear of the unknown causes us to stick comfortably with what we know. Even to fight to hang on to what is comfortable and familiar.  Change and the unknown “…puzzles the will And makes us rather bear those ills we have Than fly to others that we know not of? Thus conscience does make cowards of us all, And thus the native hue of resolution Is sicklied o’er with the pale cast of thought, And enterprises of great pith and moment With this regard their currents turn awry, And lose the name of action.” – Hamlet

Fear stalls and halts us.  Often adapting scrum after running waterfall causes initial chaos, and will make it worse -> because problems will be uncovered and exposed.  We then rely on the teams, THE PEOPLE, to solve those problems. It takes a certain thinking to be agile, to work in teams, and to continuously improve.  Fear doesn’t help any bit of it.  To be agile denotes an active participation in moving forward through some obstacle laden terrain.  A waterfall allows us to sit back relax and simply be swept away by a current until it is too late. So, HECK YA! Get excited about seeing those problems.  Unless we get to the truth and start solving them – we won’t be getting any better at this.

There is never a perfect time to adopt a better process, -there is only now.  

Ever in the middle of a release, or just having negotiated the large requirements for the next release – a program may have reluctance to change.  The risk,  may seem too high when all our requirements for the next six months have our customers in lock down and bound.  Running with agile teams has a certain side effect that you cannot discount.  Besides the numerous ways agile actually REDUCES your risk, your organization is now investing in having some great teams.  Over times these teams will change the characteristics of the organization.  In his book Scaling Software Agility, Dean Leffingwell spends his entire second chapter explaining why Waterfall doesn’t work.  Just after that introduction to agile methods.

Knowing how fearless most quality assurance/testers have been on some of my teams I have come to cherish plain words.  The ability to simply tell it like it is.  Just the facts, while NOT stopping here. It is another starting point.  It always helped to dig into the problem and start moving towards a solution together.    The wisdom in the tests wasn’t to say the software was broken and throw it back over the wall.  Instead it was in the collaboration of multiple roles seeing it at the same time, making it a better solution for the customer who needed it.

Once you are tired of falling off the waterfall in an anachronistic organization, paddle on over and take a climb up towards the peak of an agile mountain.  You may need a Sherpa to guide you, but the advantage is absolutely stunning. Build great teams focused on delivering great software and then build an organization that enables that ecosystem to thrive. All the while, connecting with and earning the trust of your customers. What more might there be to say except…

Red Rover Red Rover.

The Team Physical Task Board

I was once introduced to a new team which was been practicing agile techniques for a while.  As I listened in on their planning, it seemed to blend with other meeting purposes and I came away with an overwhelming sense that everyone was busy.  Especially the louder voices – which would find something for a quieter voice to do here and there.  The team talked about hours.  There were some stories entered into the backlog, and the team talked about a few of them.  Then the team seemed to wind down and proceeded to get back to work.  This is the time for opportunity and to bring a few basics to bear.  To be clear – I get a chance to explain what I see, and what we can improve.

A vision for making a better team.

There is a coach, Bob Galen who talks in terms of pebbles, rocks and boulders…  relative sizing.  pebbles might be equated to tasks – rocks were something bigger such as stories and boulders might be epics.  The proverbial agile mountain would be layered with all three.  The scrum master has to know where their team is on that mountain.  They may even have to act as a Sherpa and lead the team to where they need to be at that moment.  Is this poker planning where we talk about stories, is this the next-sprint planning where we are listing tasks? The scrum master’s gold coin is the focus of the team.  Are we self-examining? resource-balancing? How does this fit into processes? Are we making our commitments?

No room at the inn?

The task board is representative of a teams’ sprint.  There are other information radiators which will scale larger for releases across several sprints – but I’m just focused on the teams’ sprint task board here.   Some teams do not get the opportunity to have a ‘room of their own’s as Virginia Woolf  would advocate.  Instead of complaining and letting it fall into the ether – use this an opportunity to get creative and feel a bit empowered at changing the physical environment.  A team that can walk into a room and move tables without asking permission is far more empowered.  The physical environment acting as a parallel to the thought universe.  There hasn’t been a place yet where we couldn’t make one.  The most creative by far was one that wrapped around two side of a gigantic square column that was ideally situated right in the middle of the team.  They just hadn’t thought of it as usable real estate and took a lemon (sour or negative circumstance) and started making it work for them.  Take painters’ tape and a portion of barren wall.  Use the hallway or corridor – this IS supposed to be about visibility after all.  Try a window, or a rolling board, but try something. Dont get stopped.  Some teams use idea paint, and turn a section of wall into something they can write on with dry erase markers.

3 vertical and one horizontal line.    Stories (Rocks) | To Do (pebbles) | Doing  | Done

The scrum master helps the team spend time together – working and non working. There is much about a board like this that the scrum master takes note of.  Capacity: What is the team’s average velocity at the story-level, and quite possibly how much is being done at one time (task level).  The manner in which it gets done is also telling.  Is the team working highest priority, and swarming as they need to?  Is the team likely to delaminate and each starts their own story?  When did risk surface from the team?  This should be early on and not the day before the end of the sprint. I have my task(s), is it the best thing to be doing right now? Does it contribute to the story?  Does it help the release?  Does someone need help? Large tasks that sit in ‘doing’ all sprint aren’t helpful.  It means we haven’t performed our agile duty and broken it down into something smaller and actionable.  Quick feedback loops.  Are we all on the same page with regards to the end deliverable fairly early into the sprint or are we still thrashing late in the game? Are we improving our interaction? Is the team getting better suggestions from each other and evolving processes and quality of work?

Visibly working and communicating the sprint plan every day in a light touch is important.  Also – Is the plan working? The sprint burn down is a side-effect.  We don’t complete tasks to make the burn down look better – we complete tasks to get the work to done.  The burn down is simply a reminder like a gas gauge – do we seem to have capacity as a team – if not then we need to adjust the plan.  As a scrum master knowing the records for most amount of tasks they’ve ever completed in a day is an achievement worth celebrating.  It gets the team to think as a cohesive group for what they are capable of.  I had an earlier post: Burning Down Not Out

Finding out the the team is experienced and knowledgeable enough to task and tear all the work apart.  Were there any skills or processes or artifacts that would have made the sprint easier?  The scrum master is out to enable the team and remove issues.  This may even take some time to do so.  With enough attention, perseverance and work oysters turn an irritant into a pearl.  The scrum master can even look back on the sprint task board and see how many new tasks were added.   – This is the team learning about what it takes to get everything through the organization and into the customer’s hands.   Always with an emphasis on making the customer delight and re-engage with the experience of how we collaborate and what we deliver.  Some teams may need to call out the preparation for the review as a task for completing a story.  We always want this to be light weight and not overly prepared – more go than show, but some conversation and preparation contribute to a successful review.

We have a plan, and the team has confidence enough that together we can adjust and deliver the work.  What is the team’s confidence in their own plan? Are they engaged and an active part of it or really just waiting around because they know it is doomed to fail.   At the end of the sprint, our plan is pretty much thrown away and the team is left with feedback for how well we problem solved, and worked together to accomplish all of this.  The teams are earning trust by working on high priorities for the business.

Color coding by stickers or by post it’s is often used to convey stage of tasks, if the tasks were added after planning, who might be responsible for a task, or even priorities.  Getting used to Capturing the conversations IN THE MOMENT is an art in and of itself.  It is the lightest weight meeting.  No one leaves with extra cleanup up to do.

Moving a story to Done.

Though tasks are moved by the team – the person doing the work, Teams often like stories moved to done as a ceremony by the product owner.  It conveys they have reviewed and accepted the work.  The product owner should not be surprised by what they see in a review.  The scrum master often acts as a conscious for the team and may probe for definition of done compliance. Especially if this sprint was a new level-up in terms of delivering to the expectations of the organization, role, or the team itself.  “Did we have unit tests completed?”   The team will thoughtfully answer, and we trust them.  Questions should never provoke a team into a defensive posture.  If they do – this is a signal that something else usually requires a bit more investigation and fixing.  Physically touching the work isn’t just an arts an crafts thing – it hits us visually, we feel it, tactile.  This is representing our work that we move with progress from left to right.  It is a visual indicator which radiates information about where the team is at and heading towards.  Within the context of the group – we accept we will make our work visible.  The team talks during the stand-up around the physical board.  Others from outside the team are even invited – but usually don’t speak until after the team is done. You might even judge a successful stand up by the number of break outs that happen AFTERWARDS.   As a team we are also endorsing accountability.  There are some strong proponents for ‘HOLD ACCOUNTABLE’ but I will often say “HELP ACCOUNTABLE”.  Not everyone is good at asking for help, or seeing a possible solution because we are heads down in activity.  Together we rely on each other as a team, and strive to balance in doing the right thing the right way.  No one is perfect every day.  The group together helps, picks up members who might be down, and gets motivated about completing the team goals.  Ever continuously improving to work better and together.

The More Mature Teams

I am looking for everyone in the team to participate.  Problem solving what is needed to get the work done.  This critical thinking is an opportunity to teach and visibly vet what is needed.  It also ends up being a plan for the team.  The team will adjust the plan as it needs to.  This is about driving out risk and unknown.  Teaching the team to be better and better with reliably representing their capability to the organization. Making commitments to the business and customers.    Load balancing the team resources, thinking ahead and envisioning the end game at a couple different levels.  Does this align with our goals for the sprint?> How about our larger goals for the release?  Are there any dependencies we need to address early? Is everyone stepping forward appropriately? Is there some swarming behavior?  Are we focused on the tasks that get the stories to done or are we instead focused on hours which really obscure whether something is simply done.  If you have all that and are a great team, and want to move to electronic forms of tasking, then do so with blessing.  Go faster, improve processes.  Just bring with you the practiced behaviors that you developed together as a team.  Distributed teams rely heavily on this to keep connected. I look for a team to pop – their communication includes each other, their plans for the day are intertwined.  There is a great side effect of having teams like this in every organization.  It is force enough to move mountains.

Scrum Master Series: Team Maturity

There is no doubt that a scrum master’s role is seen as a leader.  A leader should also be prepared to adjust their leadership style to provide what the group may be missing.  This would compliment the team.  Other times the team might be best served by capitalizing on their strengths and instead augment them.  Yes, there may also be times when the team is so empowered that for a short while they may be almost invisible; sharing the leadership with others. A scrum master might consider being lenient with some processes in the cases where the team is showing respect for the agile principals.

A Scrum master will grow a team.  Keep the team and the organization continuously improving.  The ability to identify where a team is in its maturity will help.  To be clear, a team’s maturity has little to do with the time spent together and is more about the characteristics of the team.  How do they interact?  How well do they tackle some fairly thought-intensive work?

Bruce Tuckman described 5 phases to team formation.  All these phases required common tasks or goals for the team to align with. While the product owner’s abilities lay in the analysis of unfolding information; the scrum master’s job is to facilitate the team’s transition through towards becoming more mature, shaping the interaction.


Here the scrum master is a trainer.  This group of individuals may be seeking acceptance and may feel relatively uninformed.  Being more directive while members of the team seek acceptance and start orienting themselves.


Still as a trainer, the team may be expressing some dissatisfaction as they test limits and boundaries.  Many different ideas are competing as they form acceptable leadership behaviors.  How the team deals with conflict will stop them or help them move onward.  Does the team focus on minutia or avoid real issues?  How is time spent?


Now as a coach, the scrum master is helping the team integrate with one another. The team has a goal and a mutually derived plan.  Some of the team members may have to acknowledge and help champion an idea that was someone else’s or perhaps even contrary to their own. All done towards achieving the group goal.


Now as a Mentor, the scrum master is seeing the team produce.  The team has a rhythm and perhaps even a swagger as they operate smoothly and are able to problem solve effectively without much conflict.  There is a high trust among the team members.


Things with beginnings also have an end.  Having closure, ending, celebration, recognition and reflection are all part of this cycle.  If the team delivered, celebrate and recognize the team for the win!  Not every ending is ideal however.  Say that a team has worked 6 months to deliver a product, has a sustainable pace AND met their deadline but the product is never put to market by the company.  There is no closure to the goals that have been the vision of the team for so long.  Motivation will certainly be affected.  It might take a while to get going again.  So too the loss of a team member… even one lost to promotion.  Keep visibility and an openness as teams deliver or maybe even wind down projects, deprecate portfolios, and assign applications to obsolescence.

Being an eternal peacemaker within the team might even inhibit a team advancing from norming to performing.  The largest caveat here is that the journey is not always a linear one.  The team can revert or be thrown into ANY of the stages for a time.  Maybe a new member has been added, or a particular stressor has the team acting differently.

Another way to look at a team’s maturity is to gauge the capability and characteristics.  Every team has it’s own unique identity, and watching an agile team work is  organizational behavior.

12 Criteria for measuring the maturity of a team

  • Feedback Mechanisms (poor -> excellent)  Does the team adapt? How long does it take to adjust?  Does it revert to a defensive posture when questioned or is it more reflective and thoughtfull? Does the team possess and agile mindset where they exhibit iterative, time-boxed and incremental improvement?
  • Decision Making Methods (dysfunctional -> functional)  This is bad when a head is locked up in a little view or single perspective.
  • Group Loyalty / Cohesion (low -> high)
  • Processes and Tools (inflexible ->very flexible)
  • Use of Member resources (poor -> excellent) Does the team exhibit swarming behavior? Is everyone efficient and effective?  Are we challenged and utilized?
  • Communications (unclear -> clear)  Does the team talk? Can I hear them? Does the team participate and help inform the organization? Are they visible with information radiators that are up to date and aligned?
  • Goals (unclear -> clear) The Product Owner will answer what is next, while the team will be able to explain their vision, how we will get there, and how we will know if we are there yet.
  • Problem-Solving Ability (simple -> complex)  Does the team stall out when presented with a challenge or do they forge ahead?  Are the solutions brittle or robust?
  • Participation in Leadership (low -> high) Is the team engaging, challenging and growing the organization around them.  Great teams have and influence others and benefit those around them.  What about outside the organization and in the community?
  • Acceptance of minority views (low -> high) are the quiet ones considered or even invited to speak?  Is is just one person’s opinion again and again? What about all the different perspectives that might use or even abuse this product?
  • Standards (low -> high) Is the quality of work high?  Are there defects or rework that make others avoid this team?  Is this team’s work readily accepted and meet a definition of done that sets a new level of expectation.

Just remember that where your team(s) might be,– is just the start of where they might go.

Scrum Master Series: The Team

Definitions and Back to Basics

Once in awhile I get to look back over some of the notes I put together on topics.    I think about organizations, teams and roles that we have.  Once in a while I have to lay the justification to an organization for one of the roles.  A scrum master included.  For a few people in the organization, as I take them through their valley of disbelief, I like to start very simply, and sometime include some history lessons along the way.  Dr. Winston Rice, the father of waterfall wasn’t all bad, but over time we learned to organize ourselves in even better ways.  New ideas in an organization that is pretty big and set in its ways is never easy, but I love watching the transformation.  I have the patience to see the changes and continue to grow and support the people who are experiencing it as well.

I had a developer say to me that they hated agile.  A very clear and aggressive message with an emotional anchor.  All pre-formed before I even got to know this individual or what his prior experiences were.  I love what I do, and it shows.

It’s not about you.

Organizations are dedicated to using teams.  This means what?   A team is a group of people… pretty basic.  But wait, there is more!

  • Holding themselves collectively accountable
  • For using complimentary skills
  • To achieve a common purpose

Scrum does not assume a minimal skill set.  There is also an assumption that the work is complex enough to warrant a team. Ralph Douglas Stacey who spent a career analyzing organizational relationships had a Matrix which might be adapted to agile as follows…Stacey Matrix

Scrum tends to play really well in breaking things up from chaos and pulling them down into the complex realm, and again pulling complex solutions down into the complicated.  Scrum for it’s simplicity cuts through the noise.  Kanban tends to work really well with simple or repetitive solutions we find ourselves performing again and down into the complicated.

Why a team?

Well, it has the tendency to be good for people.

  • Improves our creativity
  • Can make better decisions
  • Can increase commitments to action
  • Help control their members
  • Helps offset large organization sizes
  • Types
    • Formal vs Informal
    • Temporary vs Long Term

In groups of a certain size we no longer feel lost amidst a very large organization.  Daniel Goleman who wrote Social Intelligence was curious about the maximum number of people to exhibit innovation in groups.  What he saw was natural pairing in groups of 2 then 4 and somewhere greater than 8 the groups tended to fracture and not be as cohesive.  Greater than 8 we don’t collaborate as well.  Seems right in line with what individual scrum teams are used to.

What can Teams Do?

It does seems obvious that we use them to develop software.  Our teams place an emphasis on making or doing things.  Team might also exist to recommend or just run things as well.   I get into teams more and more in the coming weeks as this is really where the scrum master matters most.  The team might be considered the scrum master’s product.

I will end with some immediate Dangers to a team.  Again this is always tricky with people who can have selective hearing. As a basis for evaluation in order to really make decisions with steps towards getting better, there are several terms which apply to groups becoming dysfunctional.

Dangers to a Team:

  • Social Loafing – complacency.  It is GREAT to have fun (There is an awful lots of stress and hard work)  but this points more to appropriateness within the context of accomplishment
  • Group think – the team actually loses its ability to think critically and is making decision from a defensive posture within the organizational hierarchy.
  • Social Facilitation – behaviors that start to become acceptable in front of others.  Teasing and hazing are such examples.
  • Personality Conflicts
    • Antagonizing relationships
    • jeopardize team accomplishments
  • Disruptive Behavior
    • Interrupts the group’s processes
    • Limits the teams effectiveness
    • Impacts the team’s cohesiveness

I have never called out an individual as being an impediment, as I tend to distinguish and separate behavior from a person.  There are certainly some behaviors I don’t care for and wont be helpful to a team.  One of the ways to focus on the good part of being within a team is to call out your working agreements.  Together as a team establish some guiding principles of your own.  There are quite a few examples and it has the tendency to put everyone on the same foot forward as they will come together against some tough thought problems.