The Fierce Urgency Of Now

This title is a quote from MLK.  It reminds me that time can burn and consume like a fire.  With the awareness that something needs to be done, we are challenged with taking action. It is the underlying motivation, logical reasoning, moral compass or character which will sustain that action should it meet opposition, resistance, impediment or chaos.  Anger can be a great short term motivator, but even Lincoln noticed that he destroyed an enemy every time he made them a friend instead.  How does an organization or an environment change?  The answer is usually one person at a time.  Having an optimism to be able to do that is what Powell called a force multiplier.  Going even further, in order to strengthen individuals we form into teams.  Larger or smaller – groups scale, coordinate, communicate, and converge on goals.

How is your organization organizing?

Valerie posted about having the right reasons to adopt scrum.  It makes worlds of difference since everyone’s active participation gets a team to the goal, the winning side of the struggle.

Just like a sustainable pace – Is our Vision sustainable?  This is the end goal, the proverbial chess endgame. What is our progress? Is this realistic? How quickly do we just give up or remain the armchair critic? Did we truly give it everything we had and then some? What did we try?

I once was with a team for a sprint planning session.  The scrum master led them through a visualization exercise for the sprint.  What would have to happen to get the work done.  Bit by bit with a few more questions, all the tasks, the order, the priority, and a plan emerged for the next two weeks.  The team was charged, energized and started the next day with diving right in.  On day two the plan fell apart with a problem the team didn’t expect.   Some people left with a memory that the plan failed.  Instead the plan was a start and the REAL wisdom was in a different spot.  Not the ability to follow a plan, but in the team’s ability to adapt, adjust and overcome.  With experience the team becomes better at critical thinking, and hence makes better plans.  What if this happens at the organizational level with leadership plans?  Does it all just fall apart or do we have a great team with the trusted ability to adjust and adapt?  We are out to improve not only the capacity but the capability of organizations.

How many times will we need to turn inwards and answer ourselves with a clear and immediate response that this effort is indeed worth it? If this is every day then it better be a VERY good answer.  An organizational ‘gut check’ for the proverbial fire that inspires us all to work towards that result.  Improving ourselves, our craft, our community.   A process shapes interaction.  Sometimes we grasp onto and leverage it just like another grip in scaling towards a mountain top.   Especially when we get scared, we can often cling and hold to it.  Moving nowhere until we are left so exhausted that we simply give up.  To change a process takes something else; a continuous desire to move towards something better. To improve upon our position we look for some purchase, or hold that affords us better (ad)vantage.  Teaching someone a best practice isn’t enough.  Without any investment, curiosity, willingness to participate and improve this is a check box action at its best and is still just a facade.  Even the Shu, Ha, Ri maturity model suggests something a bit better.  Emulate, Learn, Teach.

A Scrum is not always a pretty thing.  Prepare for it.

Watch one sometime.  Learn the Rugby analogy we use for software development team.  This is huge effort to move past a mark against an obstacle, a direct resistance.  The effort allows the team to take the ball and run with it. We train for it, participate in them, and improve upon our ability to perform them.  Be prepared to deal with problems and conflict and enable the team and organization to move towards resolution, mitigation, acceptance, or displacing the burden, even taking some iteration at a combination of any of these.  Melville said that if continual success is proof that one may wisely know their powers,–it is only to be added, that, in that case, they know them to be small.  There was never any risk to grow beyond where we were comfortable with control if we didn’t fail somewhere. Minimal frameworks tend towards maximum exposure.   Also, without the right supports things crumble away.  Care and maintenance are aimed at supporting an existing level.   What supports are a team, a program, or the entire organization willing to put in place to make this not only sustainable but incrementally better? Are we out to change the reputation of the company – or perhaps this is simply a side effect.  What can we let go of? Was it control, discomfort, or visibility into our vulnerabilities or insecurities?  Did we just move around the problem spots or did we instead reward and emphasize and grow our strengths?  Did we settle when it became someone else’s problem or did we make it better for everyone?

The wisdom at WHY we do all these things is found in the ability to answer ‘why’.  It is at the very heart of everything that gives us the willingness and drive to get close to the problem, be able to engage and grapple with it.  Where does your answer to ‘why’ lead you to share in a dream?

Where is Scrum Comfortable?

scrummyWorking with a Scrum team can be many things.  Along a spectrum from Comfortable, to Capable, Challenging, and up to Confused,  Calamitous or maybe Chaotic. I ask of myself where I might be.  Where is the team at?  Always I end up where I can’t blame Scrum, instead I point to something within myself. I will often go one step more towards some actionable improvement.  If there is a feeling of comfortable – is this time to strive for greater contribution?  There are moments of calm and quiet that hit just before storms, in the eye of it, and then afterwards.  So many times I pay attention to the storm that I forget to make use of those times of calm.  Change becomes a pain point instead of a welcome opportunity.  It is also why so many people who see the opportunity in a difficult problem have an easier time with agile.   Is the comfort level that I have derived from consistent cohorts, the familiar type of work in the backlog, my skill level, my contribution, etc.  Comfort too often derives from staying the same.  A much better comfort characteristic indicator, however, is being at ease when these things are changing.  Doesn’t continuous improvement always push us ahead, exploring to the edges of our known comfort map?

Critical thinking is a skill

Constantly this demands we be engaged in the moment.  It cannot emphasize confrontation but rather the ability to be candid. Can we recognize, understand, evaluate, communicate, and in the end have some consensus among ourselves?


Be ready to receive.  Even those moments of insight can ever be honed for their delivery.  Inflexibility of consideration often caches impediments and contention.  Am I coach-able and correctable?  Kindergarten taught us to get ready and be open to learn from everywhere.  Are we improving and getting better?  Perhaps, we have been content and things seem to slip and decay just a little bit.  The small slips are covert until they accumulate into a moment of catastrophe and cataclysm.

In the Cards

The product owner often represents the team to the organization.  The work that they are doing is valued, valuable, and visible.  The conversations about this work is captured.  The expectation is convergent and aligned. There is definite commitment by the team. There isn’t any magic concealed in the cards – it is instead within our own character. Our capability as an organization, our capacity as teams, and our collaboration as individuals.


Challenges taken as a team or as a program of teams means that we are trusting others to help attain a very important vision.  That vision is comprised of a great many smaller achievements.  This means no hiding, no distracting, and the correct type of enabling.

The feeling of Safe isn’t the same as comfort.  A safety harness or belt allows us to do things with inherent risk.  We still require preparation and still exercise caution. The safe part allows us to achieve, and excel in a different context, while not falling too far.  A psychological safe space conveys innovation, creativity, and condones some risk towards reward.  Without empowerment, safety, and some closure, change often comes at a high revolutionary cost.

A quiet and calm mind during a storm will help.  I remember one of the first public runs I went on. It was part of a team event and I paired up to run with one of the members.  It was a 10k.  My endurance was starting to ebb.  I remember my mind grasping at the thought that if only my teammate would slow down to make it easier on me.  Anger would not have been far behind.  I knew I had to control the unfair contagion of criticism and instead celebrate their ease of achievement.  I stopped mentally accusing and switched context.  I focused on digging within to examine my own form, gait, and breathing.  It was sloppy and it definitely helped to adjust and self-correct.  The effort allowed me to stay in pace, and finish far faster than I could have on my own.  It is a lesson I carry whenever working with others.  Where do I sense comfort coming from?

The 7th Sense – A SeNsE oF HuMoR

cheshireYou walk into a conference room and there is absolutely something you didn’t expect.  An artifact from some one’s sense of humor.  Are you prone to get angry or does a smile break out?  Every so often I find myself getting into the details and weeds, or even a bit stuck because something is a little more difficult than first suspected.  We are working pretty hard, we are also trying to do the right thing – the right way.  Along that journey, are we sharing a great experience or are we just wearing ourselves and others down?  I’ve seen storming and norming take place within a team, again and again.  I’ve even seen direct competition.  What is difficult is aligning and focusing on some of the same goals, and even making the means to that end a shared one.  Just as ergonomics suggests we take a break now and again to remain healthy, we should remind ourselves to look up, and find something to smile Cheshire about every now and again; enjoying the work that we do, the value and service provided, the team around us.

Another Way to Communicate

Whether I have shared or listened to someone who has just surprised me with humor, There is an encoding and a decoding and a feedback loop which says I understand your message.  Laughter or even a subtle smile conveys a language all its own.   Not only do we establish trust, percieving something in a similar manner we are sharing analogies.   A speaker will often play off the audience not just to see if  you are paying attention, but that you understand the story or concepts that are being related in the same way.  Also, if you’ve laughed with someone, you may be far more likely to share, be open, direct and honest with them.

Tempo and Interrupt


Humor is often pulling from one context into another.  Something new.  It can stop us in our thoughts, or bring us to a new level of understanding or perspective.  Laughter,and the breathing pull us from a deep thought, or boredom and into a very active moment. The pace and pulse are quicker.  Edward Yourdon’s book Deathmarch, used the term to describe the massive effort needed by the people on the tail end of a release process.  The tempo never changed, there were no interrupts, no change of context, just endless work without reprieve.  It burned people out.  The reason we changed development frameworks was so that we would never experience this again. Being Agile means we should be able to change tempo, interrupt, and consider the impact to balance our appropriate response. Is our mental process able jump, skip, run, walk, and not just march to navigate the impediments on the proverbial mountainside?


Humor is often SURPRISING.  A different point of view is conveyed. This could be innovation.  Play is often a way to do this. There are companies that have ‘creative’ rooms and dedicated idea spaces.  Take a look at some companies like Epic System’s who have made a tree house conference room, or Google’s famous office slides.  These organizations clearly want to innovate, create and have fun while also working.  Often a fairly innocuous way to introduce new ideas is through a shared humor.  Whenever a coach, scrum master or team member shares this with us it is FAR more effective than constant criticism which often aligns people defensively against new ideas.  The ability to try, explore, and balance as appropriate should always be valued and cause us to remain open to doing something better.

Simply Laughter 

Characterize the communication for the team – Is a high percentage of their conversation about work and sprinkled with some fun and laughter… if so – congratulations.  Breathe, blink and look up from the flat screen and what you are doing. Have a rapport with the people around you. We are sharing, growing while problem solving some fairly complicated work.  I am not advocating any extreme, but as ever a balance.  All work and no play isn’t much of a balance.

AgendaI once asked a team what they wanted to do for a team outing.  I was not prepared and maybe a bit fearful of the answer. While I thought perhaps all of us might volunteer for Habitat for Humanity and build something together, -the team responded with paintball.  I am a great enabler, and I can honestly tell you, that although I had some trepidation – I have never witnessed from this group such acts of valor, aggression, nor laughed so hard in a very, very, long time. Though just like in our real work we show off our lumps and bruises – the fun can be unforgettable. I certainly learned a thing or two about everyone that day, sharing an experience with the team, and never forgot to thank someone who had surprised and ‘taught’ me something.  We are still focused on building software together, and we work pretty hard at it. That sense of humor is something that keeps us smiling while doing it.

A Philosophy of Metrics

Long ago, I had the opportunity to work with a team that was really adamant about not using metrics. As I explored their reasons, it became evident that they were uncomfortable with the visibility.  A few more wanted to ‘hold up’ on any metrics as well, but for a different reason.  They didn’t want to standardize on anything that would be ‘gamed’. This prompted quite a few conversations about what we were trying to accomplish.  If I have discovered anything, people can quickly become defensive around a metric.  At this point I start wondering about the environment and the visibility, trust and openness we need for agile teams to thrive.  This is my list to keep mindful, as I use and even explain metrics.

1.     Not the finish-line, but the start.  Any metric is not a goal; it is a side-effect. Treated as a primary goal it can probably be cheated or gamed. As a side-effect it simply is a characteristic of the work done.  Doing something right has its own characteristics.   Reminding the program, pointing the focus of the teams towards something to improve upon is usually the gold coin of the scrum master or coach. If we are not measuring without bias,  it is often difficult to be thought full and ask ourselves a few more questions.  When the results are empirical they may not always be intuitive.  Especially at an organizational level. Before we even begin some may demand a target. Before giving a reasonable target it may be wiser to spend some time characterizing our current ability.

2.     Are You A Pirate? Are we fearful, do we know the person monitoring compliance. So much concern for metrics revolves around how it can be used against me. No one should be looking to play hangman based on other’s fear of accusation. Nor should this be received as anything but information. I ever prefer the teams to be in a problem solving position rather than in a defensive posture. So how do you know if you’ve really improved if you don’t bring in some standards or a backstop to help prevent your teams from sliding? Metrics can be useful to identify, explain, question and problem solve. These metrics REALLY are for all of us.  You are the person, as part of a team, program and product that is trying to continuously improve AND using the metrics. As much information as we have at the time to make the right decisions. Don’t just give yourself a pass, or even beat yourself up, just do something small to improve it.

3.     Fast and Light Sailing. Is this an automated data collection? I get leery about anything manual unless it is very light weight! This is intended to be a side effect, unnoticed as we go. Large manual data collection is a pause and requires effort from someone every time.  Tools often have features to integrate and import/export data in many formats.  John Wooden tried never to mistake activity for achievement, and he certainly knew that if you didn’t have time to do it right, you should ask yourself when you will have time to do it over.

4.     No Metric Is An Island.  A metric hardly stands alone. It may be part of a larger picture that can indirectly be addressed. What questions might this metric answer? Why is it important? Details like this on the report itself often helps teach others.   Is the information actionable? What is acceptable?  Do I have enough information to improve it? Were there exceptions?  Can the metric be corroborated, or correlated?  Does it prove out what initial assumptions may have been? How does the behavior it should promote, affect other metrics?  e.g. What about the average number of days to address bugs by severity; which seems much more useful in assessing our capabilities than a current bug count. Could we ever measure that in hours?  Lastly, how do we balance the impact and prioritize these initiatives?

5.     Buried Is Not Treasured.  Make this visible to everyone in the company in 1 or 2 clicks.  Find a place for it.  Scrum is all about being visible to encourage feedback for improvement and a convergence that draws alignment.  Being visible also includes being in a format that is intuitive. Many times, even in some task boards, information is so disorganized as to be buried.  If I look for 5 seconds and then close my eyes, do I know and understand what was trying to be conveyed to me. Although the measurement may be empirical, the results should be fairly forward to understand.  The teams should also be used to these metrics, know they are supported, and fearless about having everyone’s help.

6.     Level Up. Take the time periodically to review and update the metrics based on the behaviors, and improvements you want in your organization.  What level is it appropriate for… the team, the program, or the organization? How mature are we? Once a quarter we should ask of ourselves if this metric has been useful. Perhaps other metrics might actually promote better program behaviors. Iterate and update to a different set of metrics if you have to. Scrum is a  continuous inspect and adapt. Are we improving? Which way is the needle trending?

Scaling By Analogy: Using Story Points

As the story goes… A city once kept a knotted piece of rope so intricately entangled that it was impossible to untie.  For all who tried.  Alexander the Great walks into town, and when he tries, he can’t even find the ends of the rope…so he uses his sword to cut the knot in half.  A solution from the battlefield brought into rope work.  The Gordian knot is now a problem that has been solved, although in a very nontraditional, unexpected manner. We used to get hung up on hours- how long something took to complete.  We were usually wrong.  The human species needed clocks because temporal management may not be entirely instinctive to us.  We changed the focus to get up out of hours and instead focus on task completion.  Doing the right thing and in alignment with the business.  Having an urgency for a time box that is the same cadence, always helps with our urgency, commitment and focus.

Analogy.  It is a way of thinking which transfers meaning or insight from one topic into a different realm, subject or topic.  From analogy we problem-solve, make decisions, explain, communicate, compare, create similes and say this thing is like some other thing.  It is often very useful when the work we do constantly changes – and yet we still need to compare when this work is BIGGER or smaller than some other type of work we did.   Humans long ago knew to size up danger from a big bear immediately and differently than from seeing a little rabbit.  Same with problem solving.  Stay with me… this all ties together eventually.

Scrum uses story points to estimate work.  That’s right.  Something that sounds made up and imaginary to be told to young children at bedtime.  This method also works really well for estimating work. Also, just like anything else – at times can be misused and misunderstood. Teams may have a series of cards, or use cell phones to display a number that is somewhere close to the Fibonacci series.  0,1,2,3,5,8,13,21,34,55 or maybe 0,1,3,5,8,13,20,40,100.  We talk about the work or ‘story’ that needs to be completed, and then we vote a sizing.  If we disagree then we talk about why we voted as we did, what we may have missed.  We typically capture this conversation for future reference.  It is one level at which we will assess the work before we actually commit to doing it, as a team, later.

I wanted to point out some common bumps in the road that teams can have.  Irregardless if they are just starting along their agile journey, or if they have been estimating stories for years.

Troubles with Story Points – what to avoid:

Anchoring. Don’t  let one person consistently shout out their determination before we all vote at the same time. – This typically anchors the rest of the group, absolves them from any critical thinking or questions and does not help teach what may be involved to others… Don’t anchor the estimate – just speak to what is involved, and effort.

Consensus.  Do we all need to agree and stay till the wee hours of the night or is a simple majority OK? Does our majority make someone consistently irrelevant? Does this team member still not seem to get it? I want to emphasize the team working together quickly and well.  Moving forward.  If you want to see and compare some other teams that either charge in and problem solve or seem to stop and thrash when presented with a problem or challenge – I usually like showing teams these videos.  These are teams going through an LRC – Leadership Reaction Course.  I often stop along the way to ask what they see is happening. LRC1 (How do the 3 teams compare?, Is one team placing emphasis on blame or where they succeeded?) and LRC2 (Did they change their process along the way? What did the team forget?)

Bidding.. This is not lowest bidder. – If Madam X does it then it’s a 21, if Mr. Z does it, then it’s a 55. Discontinue the delamination of your team. Discourage the work of the roles ever separating, not mixing, learning, improving until we are no longer a team.  A team leverage resources, trusts and exhibits a swarming behavior that everyone will pitch in to help get the work done.

Re-estimate the past.  Don’t.  Just keep moving forward.  Emphasize to the team that I want you better on the estimates were are making from this point forward.  There are also exceptions to almost every rule.  The only re-estimation I might do, is if this is a special reference story that your team can use to compare the size of OTHER work that it will estimate in the future. Perhaps this work is significant and sticks out in tribal memory of the team.   This story was really a 20 – and since it is sooo vivid in the team’s consciousness, it is now a standard for the next quarter to compare the SIZE and effort of different types of work to this particularly memorable one.

 – Making in-between values to be more precise… Don’t.  Once we start using 3.5 and 26, then we are right back to arguing hours.  The results are just as successful.  Be comforted in the thought that statistical distribution of all a team’s size ‘8’ stories – some were bigger, some were smaller but most will be pretty close.  In fact i might have had an 8 that turned out to overlap a  smaller 13. – Again don’t re-estimate.  Just become better and keep moving forward.  Trust that there is a variability to these mutable, intangible, team specific story points.

Other Factors

 –The team is constantly changing.  A team that is allowed to stabilize, go through storming, norming and performing, will have an easier time and more consistent estimates.

The team is judged by velocity only.  Don’t.  Take a look at the work they are doing even without the estimates.  Is it challenging, is the team growing to take on different types of work? How predictable are they for their commitments.  How robust and reliable is the solution they create?

The team just has 1 big story.  Really? all the time? This might point to a team’s lack of ability to critically break work down, narrow scope, or improve processes.  1,2,3,5, are fairly close, as they should be.  At a smaller scale we should be more accurate.   The Scrum master acts as a historian for the team and should be able to answer – What was the most amount of stories we estimated in an hour? What was the biggest story we ever completed? What was the most (number irregardless of size) stories we ever completed?  What is our average number of story points?  These aren’t to prevent a team so much as to ask the question, and have the team ponder, think differently for a moment and either confirm or change their answer on whether they feel this work can be completed.

Recycling.  Normally a good thing right?  This has to do more with the story that with the sizing.  We do iterate to improve things. Except when it is the SAME old story again  and again. Even kids pick up on this one. – I have known some teams to hide in a particular story and do the SAME work over and over and over.  They never finished a good deliverable.  Not a good way to represent value.

No Guess. No Conversation. Sometimes this is a matter that the stories are a bit too fuzzy.  Perhaps some time has to be set aside to make these a bit more ‘mature’, better vetted, or formed if this is not happening naturally in the moment.  Don’t allow team members to consistently abstain either.  There is nothing to be wrong about – this is a lean in moment to help problem solve and see from everyone what might be involved in doing this work.

Cards – Have some made for your team!  There are websites to do this or just get to a printer that has a good card stock.  I would put things on the back of the cards that meant something to the teams.  This could be personas – typical of those different people that use the software.  It could also be reference stories of typical work the team has estimated and done before for that number size.  These tended to be more useful and easier to guide the tempo of the voting than everyone using cell phones.

Flexibility is far more valued than rigidity.

For the project managers: Money burn down – yep we can still do it, even with story points.  This is done indirectly by empirical analysis once the system (team, time box)  has a chance to stabilize.  A project manager might take an average salary and at a sustainable pace (40 hrs a week), this means that our average velocity actually has a $ amount.  Though I don’t like doing this – it can bring in a sense of perspective for cost and priority. Is the team’s attention on this for a week worth the cost?   There are a LOT of intangibles though – like better quality and trust of the end-user. Sometimes there is an acceptable higher cost – because a team with the talent to do this more quickly is busy working on something with a higher priority and we are balancing the capacity of the program to complete the must haves in a release.

ANALOGY AND COMPARISON – This is helping us at one-level, think critically about what can be completed in a sprint… and the team teaches ourselves to become better problem solvers and know our capacity.

What we are learning how to be honest with ourselves, to tighten up sprint boundaries for what we can accomplish and show to the business as being complete and done.  We are earning some trust when done successfully.

It is the delivery of working software that truly matters.   The story point estimation is simply one level of thinking in order to view and assess the risk and size of the team’s commitment or forecast for several chunks of work.

 At first my concern for a new team is the commitment for this sprint.. but over time… we emphasize and cherish even more, the ability of the team to problem solve and right fit the stories into the sprint.  Then we get bigger about the work that fits into a release, and across a couple teams.

As ever, here’s to everyone being able to cut through a Gordian knot of their own.

Communities Of Practice

The Prelude:

Our teams include a mix of functions.  We used to think the all code-programmer team throwing something over to an all Quality Assurance (QA)-tester team when they are done was good.  It wasn’t. We instead elected to have a mix of QA and Developers on the same team.  If possible we had a technical writer, a designer, and surrounded the team with availability to subject matter experts for security, architecture or whatever the need was.  This re-mix of a team met with resistance in some places because ‘my people’ and ‘your people’ wasn’t as neat and clean as it was on paper.  Especially when we took these teams and co-located as many of them as we could.  This is what we found:  Feedback was Quicker as we created software. We aligned our expectations on what we needed to deliver and how. We had many eyes with many perspectives examining and contributing to make the solution better.  Many times we were able to deliver more of the solution – than just a piece of it.  We learned more of everything it took to get that solution through the organization and into the customers hands.  This also meant we could improve the organizational processes and tools as we went. There were also the difficulties…  some teams matured faster than others, skipped or adopted practices without sharing the best of them across the other teams.  Sometimes it might have felt like a role was isolated or not supported within a team.

The Practice:

Abbreviated as COP – a Community Of Practice targets something specific.  This can be more persistent and dedicated for a role such as a QA or Dev COP, or spin up and only occur when needed such as a Database COP.  A scrum master and the program lead or subject matter expert can form an effective effort in establishing one in any program.   For the more persistent role-based COP, I will often hold this at a regular fixed interval.  Some organizations may prefer weekly or once every two weeks in order to:

  • Discuss and Decide
  • Learn
  • Coordinate

Continuous improvement for quality and best practices for the role across all

  • Teams
  • Technologies
  • Features

The meeting content and method can change from time to time – the intent to grow this role or domain knowledge remains the same.

As a Working Session

This time is used to address a particularly large program problem. Remember,  in-sprint work will often rely on cross-team communication as well.  So a working session might be appropriate.  Here are some examples:

  • All testers moving test cases from one tool to another.
  • A demonstration or ad-hoc testing of a feature together.
  • Regression testing – handing out tests and recording bugs on the spot.   Perhaps a good old-fashioned ‘bug-stomp’.  (Usually I  invited developers here too.  The same could be done on a team level)

Discussion and Decision

This might be a role retrospective, communication for a process change, or sharing of a teams specific problem/decision.  If for instance a program was adopting a process change for the first time I might solicit and list some good and bad practices, generate some examples, and afterwards post these as a wiki.  Any decisions might not need consensus, but I certainly wish to get everyone’s input and involvement.  Decisions by the group should be noted, as well as some reasons.  We are not only developing some training material for anyone new to the program, but lightly remembering why we tried something.  We want continuous improvement, so if in the future these reasons no longer apply we can again ask the question.  We WANT to move forward and get to something that is actionable.  Agile Scrum when done correctly is active!  These decisions aren’t necessarily set in stone, they do however help guide us for the moment.  Good empowered teams naturally try to improve tools and processes.

Coordination and Learning

Empowered teams are actively learning.  If across the program the we are actively adopting a new tool, technology,  best practice,  process improvement, and simply wish to share a learning experience, the COP is a great place to do this.  It can also be a place to foster shared leadership.  Different members of the COP might take turns presenting or leading the group on particular topic.   Teams will often exhibit this shared leadership behavior from time to time.  Even visiting SMEs can have a chance to teach. This might be an opportunity to set expectations for the next sprint.   This helps grow responsibility for people within the role especially when there are so many responsibilities to be .  It is a chance to level up.  Aside from the day to day sprint activities, what additionally enables us to make the program better with the perspective that this role brings to every one of the teams?  Examples might be:

  • Test Driven Development
  • Best Practices
  • Security
  • Automated Testing

Usually a wiki or a shared OneNote sufficed to keep track of useful information. Some meetings were even recorded as future training sessions. Any whiteboard drawings might be replicated or photographed for purpose of teaching, improving upon, or communicating outward.


  • Give everyone some individual support.  How can they grow? What might be their next role in helping the program?  What are their concerns?  How can I help?
  • Have some fun!  Someone said I cannot look at the sun, but by it all things are seen.  It is often when we are not directly working on something, and instead allow a bit of time for creation, risk and innovation – these endeavors will help the program in the long run.  A bit of ‘lightening up’ now and again before getting back into the trenches helps the team form and do their best work.
  • Thinking ahead.  Pull everyone up just a bit.  It is usually harder to learn when your head is down.  Too much activity might point to an unsustainable pace.
  • A visit? How close can we get to a customer or a remote site?
  • A Sense of Balance.  I ever ask of myself – am I distracting or am I enabling?  Is everyone so buried this particular week that actually cancelling would be wise?  Cancelling a meeting was something I did not want to fall into the habit of doing, but at times made perfect sense based on need of the program.  Here I questioned a simple timing mechanism and am stressing the ability to be flexible.
  • Tactics for involvement such as a round robin, rotating topic presentation, asking for a group list of top concerns and letting everyone have two votes for which priorities to pursue as a program, a ‘fist of five’ for confidence in the product, or a completely different activity (volunteering in the community) to bring them together as a specific team.

Make it your own!   You are a there for a reason, with the qualities and leadership you bring.  Stressing what was next, to go after, often relied upon some timing and maturity of the program.   Knowing how to manage growth is often one of the hardest things any organization can do.  Different areas of capability, scale, new skills, using a tool differently, or even discarding a process that wasn’t working.  Higher quality in software is not always an immediate speed boost in the velocity of our teams.  It is however a long term speed boost because we make less mistakes and wrong turns.  Keeping architectural concerns or a roles growing strong across several teams can be a challenge; a COP can help.

Critical Paths

Critical Path

I saw one of our projects put into the usual tool for displaying a critical path.  After 5 or 6 boxes – the path ended in one big long box that really said “BIG UNKNOWN” and stretched into an end date.  It made me smile, and I waited.  The project manager got to that box and expressed to the group his immediate need to have the group break this down and detail the contents of that box.   Now although this particular person worked around 6 Scrum teams in an agile program; he was mapping to a tool, understanding the work in a way he could relate to.  He is also a really good guy.  I asked him to wait until we got a little closer and the teams would address everything that was big and unknown.

Get Closer to the Work and You Typically Have More Information. In Scrum there is a particular level of thinking that is appropriate to a story.  There can even be a level of maturity to a story… Is it well-formed? Does it have acceptance criteria? Are all dependencies addressed?  We estimate the bigness of the work.  We pretty much accept that the work might be ANYTHING.  We trust it is valuable.  Then, right before the team commits to doing the work, we task it all out.   We are now thinking at a more detailed level, appropriate to getting this work done in a time box we are used to. I call this disruptive innovation, because it can cause us to have a placeholder in time for that future work.  We estimate the size of it, which figures along with what the capacity of the team is for getting this work done.  In essence this is a risk assessment that the critical path diagram will never give you.  What is the ability of the team to address this work when they begin it?  Scaling on a larger level – what is the capacity for the organization to get this into the customers hands?  Ideally the end of the sprint work is potentially shippable, but reality of our situation may have additional transactional cost to move this into production.  We have not yet changed our organization into something that can accept this work and with immediate response and light weight  processes – use it.

There can be only ONE? Larger projects which coordinate several teams on a release can have soooo many pieces in motion that we emphasize constant prioritization, regular touch points, matched cadences, and set events with appropriate levels of scope and focus.  This also means that are critical things might be tasks, dependencies, knowledge, availability, …  not just time.  and Hey, we are delivering the right thing in the right way…. if not .. lets quickly adjust and iterate! I am also a student of probability – and if we address a problem in three or four different ways, or have three or four different people involved and swarming, or have mitigation/contingencies, and make this visible to a larger cross-functional group…  We have behaviors that will make our solutions better, appropriate, and acceptable.  No matter the hidden unknowns.  We can slice the work vertically through all the layers to get up to the user interface, or perhaps we need to build out a little bit of architectural runway.  We are emphasizing the actionable solutions.  A plan is great to have – but a teams ability to adapt and be flexible along the way is a much better indicator of whether the end game is achievable.

Emphasizing  at times the Destination and at times the Journey.  It is our own ability to adjust, respond that we look ever to improve.   The date will pass. Project management used to have time, scope, and resources… Time and Scope used to be fixed… Very often all three were changing and up in the air.  More than three independent variable might be something close to chaos theory.  In scrum we emphasize that time intervals are fixed, and these will aggregate.  The resources are fairly fixed, but the scope of the work changes.  Work is highly varied, and yet flexible.  How many ways are available to perform this work? Are we doing this in the most effective way possible?  Not only will we have the work done, but we will improve the organization around us, our tools and our processes.  More importantly, we will also emphasize the growth of the people and teams that perform this work.  You will never see that in a critical path.

Does This Feel Like We’re Fighting The Scrum Master?


Invariably the time comes.  Hopefully it is a passing moment rather than a normal state of contention.  A team is trying to relegate their scrum master towards insignificance.  There are lots of ways to do so.  In fact, perhaps this is fairly easy since it is many versus one.  When we talk about the scrum master in software development – this is a role that is part of the team and yet has a very special  charge.   Teams that I come across are ever unique.  However, there are still patterns to behaviors that trip the ‘spidey sense’ and make me ask a bunch of questions.  In fact it is far easier for team members to attack than it is to consider, engage, problem solve, and change.  It is all right to disagree.  What should emerge from disagreement is what one thing we cherish over some other thing though there may be value in both.  Here are three team behaviors or attitudes to watch against.

Tag You’re It.  This is the hot potato role that the position of scrum master can be passed around the team.  Short interim, sure it can. No situation is ideal.  Longer term though, and we risk degrading the role so much that we lose our team advocate.  This role holds a unique perspective on how the team is interacting.  Someone to map to the framework and agile principals.  It might be a darker side, but I have the tendency to think that most things in the universe are in a state of decay. That vigilance and endeavor are needed not only to repair and sustain – but also to improve.  A person dedicate to the role is afforded the time to grow with it.

You Don’t Know Me. Anyone tasked with needing to change our focus, or the way we are thinking about things may have a really rough time. Admittedly my high school teachers are owed some profound apologies and thanks.   In a similar manner, if our scrum master doesn’t code, this doesn’t mean that they have no ideas on how to help in some way.  I’ve heard Quality Assurance testers say that their brains were far different than the scrum masters’ or even developers’ and that two would never meet.   I had to counter Really? Although we may think along different paths, the brain (when used properly) never ceases to amaze me when at it’s best, how flexible, creative, and genius it can be.  A team, ideally, might represent everything it might take to get the software through an organization and into the customer’s hands.  While doing so, they leave nothing untouched.  The team itself, the organization, the software may all be changed for better by the experience.

Believe it or not, the team includes the scrum master.  For the team to improve, this also means the team including, involving and being honest with their scrum master. Usually the scrum master helps motivate the rest of the team.  The reciprocal is also necessary – we all have our moments of hesitation.  We share in this experience and all should be left better for the having of it.

Are we all growing?  The scrum master usually watches for level of thinking – are we in the details, the general work, or the larger and longer release goals?  Is now the time to be talking about this or can it wait until a more appropriate time?  How are we interacting as a team?  How efficient and effective are we? Are we growing? Are we heard?

Fight the System. The scrum master, or even a coach is identified as a sole representative of ‘the way’.  We fight ‘the way’.  I can think of 3 or 4 other REALLY heavy release processes which are far less effective than Scrum.  I even saw the havoc these processes created with their false sense of security or the heavy burden and burn-out placed on a few people in the last phased functional role for the deliverable.  We might pin our failure on advocates or simply check out.  Process isn’t a bad thing, we just need to keep it in context and ensure that we control the process and not that it limits us. Perhaps we are too overwhelmed and everyone is operating on fumes.  This says something about our sustainable pace.    When we as a team place emphasis on the fighting, the passive-aggressive, or passive-defensive… et al. we are only fighting ourselves.  Fighting our own ability to change and be agile.  It is a funny thing which Phil Goldberg noticed and wrote Get out Of Your Own Way.   This self defeating behavior is as prevalent within ourselves just as it can manifest within a team.  I am mindful that I like people, and that there are just behaviors I don’t tend to find particularly helpful. Thinking can be a biological high energy state to form new connections… habits are entrenched, comfortable pathways.

I’ve brought up the point before, that in sparring with someone, we are partners.  We are both trying to improve ourselves together, testing, practicing, trying new techniques together.  We are really gearing up to tackle some rather difficult challenges and thought-work.   The best teams are balanced, across their members, in their ability to do this. Great teams also exhibit a tempo across differences or unknowns that allow them to adjust, learn, adapt, and try.  I want my team to improve and level up, as I expect no less from myself.  A great scrum master is not only an asset, an advocate and an ally for any team – they spark and fan the flame that every team inherently possesses.