This seems pretty straight-forward in terms of wrapping one’s head around things as in software so many of us are very familiar with the general KISS principle.

However, with many teams I have worked with I see a very familiar pattern emerge at times …

Once the team starts the sprint, the developers spread across the tasks on multiple stories (based on skill level or dependencies or any number of reasons). They are working away on the small pieces across multiple features and feel confident in their commitment. Then the clock ticks by …

Then somewhere during the sprint (let’s hope they are coached in the “first responsible moment” approach) they realize that something was much harder than they imagine or someone was sick or generally something derailed their optimistic view of sprint completion. So they take stock of what they have and determine they are going to complete 3 of 6 features but indicate “the others are about 40% complete though so it will take us less time if they are moved forward” or in a worse case scenario they have 6 partial features, maybe not tested or unit tested or whatever …

Sounds familiar to anyone? The value that I referenced above applies to this as well. This is where the “art of maximizing the work undone” also comes into play. All of that partial work (even though it was probably great effort) created absolutely NO value for the end stakeholder.

Let’s use a real world example …

You need to get a few items completed for yourself and your family for an upcoming event. The items are:

Mail 100 letters

Wash all of the windows at my house

Cut the grass

Feed the dog

So you take these jobs and decompose them into tasks:

Mail Letters:

Get envelopes

Get stamps

Fold letters

Put letters into envelopes

Take to post office and place into mail

Wash Windows:

Get cleaning supplies

Treat each window

Wipe each window

Cut Grass:

Get gas for lawnmower

Start lawnmower and cut grass

Do edging

Blow grass clippings off pavement

Feed Dog:

Get dog food

Put food in bowl

Ensure water is in water dish

Place on floor for dog to eat and drink

In the course of working on your commitment, you determine that you will spread yourself across all tasks so you do the following:

Fold all the envelopes

Go to the store and get cleaning supplies

Pickup some dog food

Fill your gas can with gas

Get your stamps

Fill the lawnmower

Stuff the envelopes

Unfortunately, you run out of time to get things done (based on unforeseen situations), which can often happen.

So what have you actually accomplished in terms of end value of your commitment?

Let’s look at it from that perspective. You have:

A full lawnmower but the grass is still not mowed

Letters in envelopes that sit not mailed

Plenty of cleaning supplies but dirty windows

A dog with a bag full of food but very hungry

So what if you had:

Gotten the stamps and envelopes and ensured the mail got sent.

Went to the store, got dog food and fed your dog

Got cleaning supplies and cleaned the windows.

If you still ran out of time, what value have you received? You completed 3 of the four of your tasks leaving only the lawn undone. You maximized the amount of work by moving the tasks to completed before moving on. You minimized the undone work through focus.

How does this apply to teams?

In a sprint, teams often spread out across stories to the individual tasks and when completing all they can complete for reasons such as:

Their skill level does not allow them to pull more advanced tasks

All other tasks are being worked by other team members

Most, then move on to pull additional tasks in another story that they can work on as this seems the most logical thing to do to continue to provide value. But what if I said that we should not do this? What if I said that we should focus on applying our energy to getting items “in flight” to a state of done? Would this seem counter-intuitive? Or, if looking at it from the lens of completed value, would it make sense?

Many people think that people should move on to complete as much work as possible and not become “idle” but I firmly believe that given the focus of completing stories, anyone not “doing” can still find a way to become valuable. What if instead of moving on they did the following things:

Decomposed the next story or stories into tasks (as we could focus on the things we are working on and not try and decompose everything at once)

Assisted in testing, maybe writing scripts or unit tests for the code under development or helping to write test cases

Performed the “just needed” level of documentation for the project

I firmly believe that just like the old adage “if you buy a bigger house, you will find things to fill it” applies to teams. If they are without direct domain work, there are always items to which they can apply themselves to realize the end value.

Why I keep getting told this does not work …

I am often told by teams that this approach does not work as stories have dependencies, it slows them down overall as everyone is “not busy” or creates more refactoring (which is a given in iterative development).

However, in each conversation I have about this, no one is actually willing to try it and see if it actually works or not. Many seemed convinced it will not work.

I speculate that decomposing the work needed and performing this decomposition effort “just in time” coupled with the focus of work can result in a much better end value proposition from a commitment. If a backlog is truly a prioritization of value from top to bottom, I would much rather be informed of the completed value I can receive than the collection of untested (and therefore undone) features I might receive that are “80% complete”.

I challenge people to try this. I may truly be wrong here but I suspect that the focus on the immediate and driving to completion will see things completed and delivered quicker.

Just my thoughts, right or wrong … A game is always won a play at a time, not the whole game at once. And I think this is the same with our commitments to stories to be delivered.

Until next time … Stay Agile!

]]>https://agilecoffee.net/2018/02/20/undone-work/feed/0Commitmenttholden615Scrum master tips – The burndownhttps://agilecoffee.net/2018/02/09/scrum-master-tips-the-burndown/
https://agilecoffee.net/2018/02/09/scrum-master-tips-the-burndown/#respondFri, 09 Feb 2018 13:03:43 +0000http://agilecoffee.net/?p=5828Continue reading Scrum master tips – The burndown]]>I have been working with several entry level scrum masters over the past few years and have discovered that although they may fully understand the general ideas of rituals and artifacts of the scrum framework, understanding the underlying agile value proposition these things support. Gaining insight into how they can utilize them with continued effectiveness with their teams seems to not be something that many do not often explore initially.

So I thought it might be helpful to convey how I view these items and how they can actually create impact for you as a scrum master to up your effectiveness with the teams.

My personal philosophy when I became a scrum master was that my role was a lynchpin in the process overall and that by increasing my understanding and effectiveness of the roles, rituals and artifacts, I could become a better servant-leader to a team overall.

This is merely how I view and utilize these things and hope that they help you as well.

What is the burndown chart?

The burndown chart falls into a category for me to be viewed as an “information radiator. It provides information in a static way that can allow the scrum master and the team to view the current state of product work within the sprint. It radiates information that can then be consumed and acted upon. It is a great artifact for assessment and course correction as well as allows scrum masters to begin to see items occurring within a team that may not be readily apparent, even to the team itself.

It is a chart that is measured by taking the amount of overall effort to be performed (hours of work) and plotting it across an axis of the total working calendar days of the sprint. Often it is coupled with an “ideal line” that reflects the optimum burn of effort equally distributed among days. As the “task hours” are burnt down, it reflects where the team is in terms of hours remaining to complete within remaining time of the sprint.

A typical burndown might look something like this:

In this scenario, the team has 400 hours of delivery tasks over an iteration of 10 days. This reflects work that may be done by the entire team (coding, testing, design, etc) for the 2 week iteration. So, the ideal line is reflecting to the team that at an average burn rate of 40 combined hours of effort by the team that is projected to complete the committed work within the 10 day sprint period.

Typically the burndown charts I have used reflect the days of dedicated effort and do not reflect periods of planning, review, etc as these are bookend ceremonies to provide sprint lift-off and sprint landing. The burndown is focused on the time where team effort is directed towards end commitment.

The basic idea behind this chart is that from an agile perspective the highest value is to be aware of the work remaining undone and not to remain focused on the work already completed. So the responsibility of the product team is to reflect the remaining hours daily to represent the actual burn of working on a given story.

This is a very brief and straightforward explanation of what a burndown chart is so let’s delve into the next level of how it is helpful, how we might utilize the information and look at some ways to interpret patterns we may see inside a burndown to better frame questions or make inquiries to the team to help them.

What does a burndown chart do for a team?

As I mentioned before, it is an information radiator to a team. It gives them a snapshot of the past brief period of work and tasks completed and a reflection point for the work remaining to be done within the sprint. This information allows them to reflect a current team state both internally and externally to convey where they are without a “direct status report” to others outside the team as well. Anyone looking at the chart can get a general idea of where the team might be even if they do not fully understand the chart itself. This, however, can also lead to bad perceptions as opposed to informational learning as we will discuss later.

It is incumbent that a scrum master fully understand the purpose of this artifact, the reasons behind how it actually works and to begin to see patterns of work or potential team dysfunction within a burndown chart.

This allows them to not only accurately convey how to use this information and its purpose but frame questions aimed at potentially keeping the team productive or assist the team to be actively aware of the “first responsible moment” of when a product commitment might become in jeopardy.

Patterns of burndown charts

Visual representation of work often allows an excellent opportunity to the scrum master and the team to reflect on familiar patterns that can be a visual queue to certain information or team dysfunction.

The Ideal Line is merely a Projection

As a scrum master, if you have the belief that below the ideal represents the idea of “being on track” and above the ideal is “being off track” you are taking a far too simple view of the information that the team provides.

The burndown should be seen as a reflection for consideration of current state of a product development print to make inquiry, not predictive like a project schedule. The ideal is merely a projection of all things working with no issues impacting the team. It is a projection used for comparison. Establishing the thought as a scrum master of anything other than this or reinforcing to the team that it means ahead or behind the curve is a bad precedence to set and can lead to future problems.

Effort Swelling

For instance, in the image above, the team starts on day one burning down tasks and within the next 24 hours begins drifting above the ideal. A simple view might create panic and say “HEY EVERYONE! WE’RE BEHIND ON DAY TWO. WE GOTTA DO SOMETHING!!!!” when the circumstances that cause this picture could result from many potential reasons and should be information we can use as a scrum master to reflect on and potentially frame questions such as:

Did the committed work had greater unknowns than the team imagined and tasks are emerging? Normal and very possible. Probably just something to be aware of and see how the trend moves within 24 hours or so. But a basis to have the team reflect on this data maybe as a visual cue to them in your next stand-up.

Is the team struggling? Is there a causation? Has the team experienced a drop in overall capacity from the commitment due to sickness, not accounting for a team member vacation, etc? Many modern electronic tools, such as Microsoft Team Foundation Services, will allow you to adjust the loss of capacity by each team member and the chart will update to reflect this effort recalculated across the iteration.

Are they just stuck? Are they mentioning impediments in their daily stand-up? Is there something you can do to assist or coach them to self-organize around solving the problem through inquiry?

A common symptom of a potential team dysfunction is that the members are not actually “burning down” their hours. They are pulling a task into a working state and working on it until done, therefore reflecting the total hours when there is actually less to be completed and then moving it to done all at once. This can show work not moving and so the work remaining can begin to begin a swelling pattern. One way of getting some insight into the pattern is if you see large drops of work following a swell.

Effort Drops (“work falling off the cliff”)

This pattern may look something like this:

Some questions that might happen when seeing such a drastic drop quickly:

Was the work committed less complex than the team thought initially and they just hit a “rapid burn” (Go Team!)

If following a swell, is the team actually burning down the hours regularly? Are they perhaps holding on to tasks and not updating remaining hours but just pushing it to done when completed? This might prompt a scrum master to look into this information that the burndown provides in combination with the sprint task board and use it during a retrospective for exploration of “what does this mean to the team”?

Again, the key takeaway here is that these types of patterns provide an opportunity to learn, observe and inquire to assist you as the scrum master to help the team remain productive towards meeting their commitment. This information can help you teach the team to use this information to get some insight as to what is going on either during the sprint or used for exploration with the team within the retrospective.

These are merely some simple examples of how this artifact of the scrum framework can be used. It is best to keep in mind the concept of how it reflects back information to the team. Many scrum pioneers have discussed “BVC’s” (big visible charts) of which this can be one to help teams reflect on their current state of work and make adaptations based on insight. I hope this blog post allows new scrum masters a new way to use this artifact and can help them assist their teams with better insight …

I often consider this quote when thinking of a burndown chart in relation to teams …

“Information is only useful when it can be understood” – Muriel Cooper

This will be a relatively brief post but wanted to share something that struck me in my early morning reading (which is my habit to feed my mind a little to start the day).

I am currently reading the new Chip and Dan Heath book, “The Power of Moments” in which they explore the idea of what defining moments are in terms of people and how people can make the shift to begin thinking in moments so that they can capitalize of the impact.

Doug Dietz, an engineer from General Electric spent roughly two years designing a new MRI machine. The book describes how he was so excited to see the first patient in a children’s hospital be able to utilize his creation but was absolutely dismayed when the experience was met with fear. He said this was the point that he “saw the room through the child’s eyes” which was cold and sterile and his machine sat inside like a “brick with a hole in it”. As a result, many children had to be sedated to undergo the use of the machine just to allow them to stay still and overcome the fear of the experience.

This heart wrenching experience fueled him to take this “pit” (low point or negative experience) and strive to make it a “peak”. So he worked with a vast cross functional team and was driven to redesign the user experience for children. The end result was he and his team created MRI rooms in children’s hospitals that resembled a pirate ship, a space ship or a amazon adventure (this one encouraging the child to stay still as not to tip the machine painted as a canoe). He careful observed the difference in the experience and was delighted when one small child tugging at his mother’s leg asked “can we come back tomorrow”? He had taken a “pit” moment for these children and transformed it into a “peak”.

I read this and thought to myself, “this is so applicable in organizations”. How may “pits” are we aware of as an organization for people (poor performance, bad service, bad product interaction) for which we have no plan or allow it to sit without putting passion behind turning it into a peak?

Conversely, how many “peaks” (employee first day, retirement, significant life events, transitions in career or life) do we place the minimal effort into a miss the power of creating the moment of connection between people and our organization.

This brief story really impacted me and I began to think (and I feel like I will begin to formulate known moments that I think I am missing for my organization) about what I could do to “think in moments”.

How about you? Are you thinking in moments? Are you turning “peaks into pits” or “pits into peaks”? I have not finished the book so I cannot give you a full review just yet but I can say that this small concept resonated with me and I am sharing it with you in hopes that it might with you as well.

“Failure seldom stops you. What stops you is the fear of failure”– Jack Lemmon

I had an interesting coaching moment with a scrum master today. He came to me with a dilemma he had for his present team. He has a new team that has a new senior developer on it and they are in the process of storming as a team. Given this state of team development, it is only natural that they are in a growth period.

In their prior sprint, the team had a plague of sickness spread across them and they did not meet a significant amount of their sprint commitment due to the unexpected loss in capacity. This significantly concerned them as when they reviewed their product at sprint’s end, the stakeholders who attended did not seem to understand what the idea of “undone work” was nor how it was typically handled by the team.

The product owner managed the stakeholders relationship well and explained how the undone work would roll forward to the next sprint as the highest priority (given that was still the case) and be addressed by the team. But the team became very worried about the perceptions of the stakeholders. Fear of failure had reared its head within the team.

The scrum master, being conscientious about this engaged the team as based on some severe inclement weather had forced them to see the possibility of a failed sprint looming again. The team had asked, maybe we should change the process to only demo those features to the stakeholder that actually work. Being a relatively new scrum master, he wanted to explore this with me to help guide them. He came and met with me and told me what the team had suggested and admitted he felt uneasy about this change but wanted additional guidance. Instead of “giving” him an answer, we explored the situation and circumstances surrounding this request once he related the situation of the undone work in the previous sprint and the feeling of dread by the team with their current sprint.

I asked a few questions of him:

“So the team feels confident that they will not complete their commitment”?

“Do you feel this is a reaction to a fear of failure”?

“Do you think the compromise to hide this undone work compromises the agile value of transparency”?

“Is this the first responsible moment to speak with the product owner to indicate the work that will be undone so expectations are set with them rather than surprise”?

These four questions helped him find his own answer. He realized that he did have time within the sprint to engage the product owner and set the expectations of him and in doing so release the pressure of the team without finding some method to place transparency to the users into the shadows. He determine he could help the new team more by helping them understand that failure is opportunity, not a point of suspicion, ridicule and derision. He found a solution within his own problem by thinking through his problem so he could help his team do the same.

As a result, he engaged the product owner to indicate to them the work that may be undone so that they could discuss this with the team, ensure that the items worked on were the highest valued among the undone work (which they were) and kept the issue of fear of failure as a point of opportunity as opposed to the crushing blow of defeat. He helped them find relief and refocus on the things in progress without continuing to worry about the items that they knew they might not achieve.

In the end, they completed their commitment as it was the fear of failure to the stakeholders that made them concerned not the reality of doing so. They were so caught up in not appearing to be failing that they saw the loss of capacity as a reason to react. He guided them to understand this principle as well as one of the “first responsible moment” so that they could create transparency and strengthen the openness and relationship with their product owner. He turned this situation born of fear into one of working more closely together to succeed.

And he did so by just stopping to consider a few questions to allow himself to explore the possibilities. Fear of failure is a real thing with teams, especially teams that are allowed to select work within capacity to deliver as they feel they are driving the work. But failure is an opportunity to learn (although I know many executives who may not agree).

But through inspection of the underlying reasons behind this fear we can often find ways to gain clarity and help shape it into a learning point and create stronger relationships and stronger teams.

We all fear failing. But it does happen and often as a result of things far beyond our control or sometimes when we are doing everything right. So when this happens, it’s easy to just react based on this but the more challenging thing is to examine the fear and determine if our failings can be something that makes us better moving forward.

One of the things I always found particularly stressful in a standard software delivery model was the visibility and context of information. I found myself time and again asking for information only to be shown a project schedule or some other document and was admonished with “but there may be some changes not in here” or “this is not the latest version”. And coupled with the fact that I had to know who to ask or where the secret location of the latest and greatest resided, it was even more frustrating.

We have solved some access issues by making all sorts of cloud based access to files and there are tools that recalc everything based on newly provided information that can be stored. But what we have not seemed to solve is the communication and context under which we share that information.

This is why I like the agile approach of BVCs (big visible charts) as a part of product development. The goal is to keep it current and the impetus is on allowing me to pull information as I need and adapt it to my contextual goal. Sounds like a reasonable approach. But, as technology is want to do, we want to be smarter …

As a scrum shop, I started with 4 corkboards (Product Backlog/Sprint Backlog/Doing/Done) and index cards. These sat in an open area that anyone could walk up to and view. So, at a glance, anyone could see what was in the backlog, what we had committed to work on this sprint, what was in flight in terms of tasks and what work had been completed. The burndown chart itself was hand calculated by myself as a scrum master each morning before the team arrived. There was visibility and simplicity in this approach. But it required someone to physically walk over to the team area and view this information. So we decided that it was a good time to make the shift towards a more electronic model so that people could view the information from the comfort of their own desk. So, what was the outcome?

Convenience

We did create a broader sense of ease to get to the work items for the team itself. Boards were now accessible to team members without leaving the computer in which they were working, product owners could work on stories from anywhere and there was the potential for anyone to still “virtually wander up” and see where things were. It now calculated the burndown for the team so one person did not have to ensure it was up to date each day.

Sounds like a rousing success right? For all of the things it did right, there are some things that it actually made worse in my estimation.

From Information Radiator to Information Refridgerator

One thing that this move from a manual process and chart approach did was slowly to begin to turn information into something that was always visible into something that had visibility when sought. It began to recreate the initial problem that I was so frustrated with in the former system. It created an “information refrigerator”. What I mean is that like a fridge, it became again incumbent to look inside just to get information as to being something that radiated information to be consumed or ignored. It became like opening the fridge door to just see if the light was on. Not very transparent in my estimation.

Whereas personas, visions, backlogs, burndowns were formerly pieces of paper plastered out for anyone to see who came to the team room, product planning items often became non existent due to lack of general visibility or decoupled from the work being done. The idea of feature roadmaps and release charts began to occupy the space of people’s heads and not available to be consumed. Other items began to splinter and I began to see strategic planning items begin creating their own silo locations

What started as a transparent and visible approach slowly wove its way into retention of information with limited visibility and therefore limited learning and focus on that information.

You may think that at this point I am blaming a tool for this problem. If so, you would be incorrect. The tool did not create the problem but without the proper institution of transparency into the culture itself, the removal of the physical manifestations that drove being transparent, the organization opted to use the tool and “assume” that it was being transparent. Because teams and product owners had visibility into these tools (those doing the work) and that it was “available” to anyone else, the idea of transparency was generally assumed by all. But upon closer inspection the cracks were there. Team information was there for the team, product owners were able to work their backlogs through this tool but when it came to the overall transparency to the organization as a whole, it was more shaded as it was not the world that the rest of the organization necessarily worked in. Sure, we could provide the link and they could see stories, burndowns, sprint backlogs and such but did it hold meaning for them? Did we explain what they were seeing? Did we make it as frictionless as possible to gain the information by a pull system as opposed to a push?

So what do we do?

First, stop. Take a moment and consider your current level of transparency. Does the organization know what you are planning, what you are accomplishing and is it as frictionless to them as possible? Are you pushing information to them or have you created an environment in which they can pull information at will. Is the information visible in general? Can anyone in your organization gain insight to ask questions they may have? Do you have a strategy for visibility and transparency into your work? Have you instilled a culture within your organization that makes it acceptable that failure is an opportunity to learn or have you mitigated this by hiding the work?

Start with visibility as a primary goals for your teams. Instill it in the culture and how you work as a whole.

I go back to my original days of the corkboards and asked why this was good. It was because it allowed anyone to wander up, look at what’s going on and derive meaning and formulate questions. It kept the work as transparent as possible given the physical nature of the boards. With tools that can be accessed anywhere, how can we make this even better?

I recently had a conversation with a colleague in the industry that was struggling to gain information about where the teams were in terms of their commitments and the overall features and was met with resistance by a scrum master in providing this and provided insights like “they are on track” or “everything is fine”. As a former scrum master, I know that a primary duty is to protect the team and to allow them to focus but in my estimation, a scrum master who would be immediately resistant to being transparency is actually demonstrating somewhat of a team impediment and not helping the agile culture as a whole. Instead of taking a hard stance, maybe they should have sat down with the director and the people to whom he was having to supply information and unpacked the information they needed. Some might have been reasonable, some maybe not. But until they truly understood the context and the concerns, they really could not assess if this was reasonable. If they had just taken a moment to have these conversations, they may have been able to determine the “why” behind the need and found a way to increase transparency. Just drawing a hard line in the sand created a more contentious relationship between the scrum master and director and may have raise questions of the agile transformation itself. Finally, considering how to make this frictionless to those people seeking information could have helped the organization better understand the team’s work. A little transparency can actually go a long way.

So when met with these types of requests, how can you understand, assess and facilitate the best transparency of the work of the team? I am not saying compromise your work to create mindless or lagging indicators but what do you know today that you can share in a more actively visible and transparent way?

I know that even within my own organization, transparency and recurrent visibility is a struggle. I constantly try and think of ways that can make information more meaningful and more visible. Just taking one more small step to do so may make a huge difference for your organization and my own.

“The past cannot be changed, forgotten, edited or erased. It can only be accepted.” – Unknown

Let’s Define some metrics!

I had a conversation with a relatively new scrum master recently who was working to help establish some base level team metrics for their organization. They had made the journey to scrum from the role of a project manager and seemed to really transition the mindset of driving to create an environment of trust and transparency within a team and shunning the ideas of controlling the time/budget/scope and “resources” (word I hate when it comes to talking about people) viewpoint of traditional project management.

So my initial question was “who are these metrics being designed for”? This is something we often do not consider. There is a different need for reporting transparency and one to help teams improve. If oversight is the driving goal then the assistance to the team may become minimized. If the goal is to create metrics that are learning opportunities for the team or generate insight for a conversation then the construction of these may be much different but may provide less insight into what management may be seeking.

All metrics are not created equal …

Except, when it came to metrics it seemed. Most of the metrics they were developing were centered around trailing level metrics (lagging metrics for those who are KPI inclined) for the team. A lot of the focus was on the past as a predictor. So I raised the question; “why are you so concerned with the past” in terms of metrics? They explained to me that this is how he could help the team improve by knowing where they failed or made bad decisions beforehand. So I asked again “given the dynamic nature of iterative development, how can you ensure that the same cause will generate the same effect”?

We discussed in detail that they were extremely proud of was the tracking of “estimated” versus “actual” hours on tasks. They worked really hard to convince me that learning the difference between the two would help them more accurately estimate the work to be done. I let them go for a while and then I had to call bull%^#$ on this.

In my opinion, the only way an “actual” at a task level will be a predictive metric is if the the same circumstances occur exactly the same way the next time. Estimation is just that. It is not predictive in nature, it is a best guess based on the knowledge known at the time. And before anyone says it, you can make a better estimate by reducing the unknowns but you can never eliminate the unknowns.

If I have a headache, I had road rage on the drive in, I had more meetings than normal, I volunteered to help someone, I was tired … A whole lot of things could impact the differences between my estimation and delivery. So in my “estimation”, this metric is a “narcotic metric”, it tends to make you feel good but it actually could be very damaging when using it.

And what if we do know this information? The key is to be able to take information learned and make it actionable. How do we do that? Send an email and tell the team to estimate better? Begin to question their estimates? Make them sign off? I cannot see how you “use” this information to help them actionably improve.

Refinement Metrics

One type of metric I always recommended for consideration is one I consider a refinement metric. This type of metric is designed to allow the team to perform self-reflection on a recent event given the context of more knowledge and apply that knowledge to a past decision. Instead of comparing the past to the outcome, it asks “given the things we learned, do we think we made an accurate assessment of the work”? Sounds similar but with a couple of differences. 1) It’s never at a task level. 2) It’s a team level rather than a individual developer level as the goal is that the team learns to become better as a team, not as just an individual member.

So what I suggested is something we would often do as part of a retrospective with a team. We would examine the stories for the sprint just delivered and look at the assigned story points. Then we would have a discussion and asked if given the knowledge today, would we apply the same story points. This typically leads to a discussion of dependencies, issues, etc and the team centers pretty quickly around a “stand/raise/lower”. This does not help them get better in defining the individual number itself but helps them reflect on this type of work and the hidden complexities that can be present to determine questions that they may ask themselves or the product owner to create a better consensus around an item in the future to the potential complexity of the work.

Just in Time Metrics

One metric that I have read about after working as a scrum master that I liked was a daily vote of confidence. If you have ever been in a U.S. hospital and had surgery there is a common tool used by nursing staff to determine the level of pain you are in to report and administer treatment. It is called the “pain assessment tool” often and looks like this:

This allows the patient to quickly indicate the level of pain that they are perceiving and reflect this to the nurse, doctor, etc. The blog post I had read (which I wish I could recall the link) suggested using a similar scale for each team member to allow them to forecast their confidence level to meet the current sprint commitment. This allows each team member to express their confidence on a similar scale from “Yep, we rock!” to “Hey guys, I am really, really worried where we are right now” so conversations can be had to determine what’s going on for the purposes of communication at the first responsible moment or to allow the team to swarm around and issue, etc. A simplified version of this has been used by teams that involved “Roman voting” (thumb up affirmation, thumb down condemnation) as well. This type of metric gives you perception of the current state of work in a very real form and let’s you make it actionable. This is often easier to use than seeing potential patterns within a sprint burndown (which is another post).

So just as I asked this scrum master, I ask all of you. Do you have metrics? Who are they created for? Are they actionable or are they just data? How do you use them? Are they actually helping you and even more important are they bringing value back to your team(s)? How do you know?

I leave you with a quote about the importance of knowing why you are actually measuring something …

“It’s like everyone tells a story about themselves inside their own head. Always. All the time. That story makes you what you are. We build ourselves out of that story.” – Patrick Rothfuss, Author

How did it all start?

My journey started with a personal quest to transform the way I work and delivered value. I was deeply embedded inside a V-model culture in which the end result not meeting customer expectations was typically blamed on the customer.

I started my journey by annoying my manager to allow me to create a pilot project (of little significance to appease me) for my organization after reading about the scrum framework. I knew that this was going to be the wave of how organizations began to work and saw a clear path as to how it could benefit the government sector. So I prepared, I studied, I learned, I asked questions and became immersed in how this worked.

I was given a small team of what I will call “the usual suspects” which were made up of long term employees who were pretty adverse or afraid of change, an assigned “product owner” (who they decided a project manager fit the bill) and a stakeholder who had no idea what I was trying to do. My goal had been stated to conduct this pilot and deliver my findings on if it could benefit this public government organization and what type of staff would be needed to sustain it. So here I was, new team, no idea what this crazy person indicating he was a scrum master (with no experience) asking them to work in a new way in which they would drive their own work, a product owner who needed to understand the role and learn to “lead a team without authority”. This seemed like a real challenge. So, I was all in.

How I got started with my first team …

I started by gathering this new team together and explaining very simply the framework, the roles and rituals and how sprint cycles worked. I was met by questions such as:

What do you expect us to be able to deliver in 2-4 weeks?

Where are the requirements?

How will I test an application without requirements?

You want us to sit together and work collaboratively? What about my cubicle?

What do you mean we determine the amount of work we will deliver? Who manages the project?

And many, many more. I addressed each question as best as I could, remained confident and worked to gain their trust. I assured them that I would be right there with them and help them work through any problems as they arose. I assured the product owner that I would work directly with him to become “team ready” so that he could build his product.

Everyone left the meeting unsure of what lie in front of them.

The initial process …

Needless to say, it was tough the first few sprints. I had to guide the team to understand what “potentially releasable” meant. I had to teach a project manager an entirely new set of skills and way of working and how to establish trust in his team to turn his needs into product without use of command and control. I had to reassure stakeholders as they saw partial software being built out along the way. I had to teach a team, how to conduct a daily stand-up, use a task board and burndown hours. I spent countless hours coaching nervous team members who were so far from the way they worked that they were doing this amazing thing that had never been done before.

Although there was a lot of fear over how they were working, through coaching and support they began to move as a team.

The end result and learning

In the end, the product delivered was a success. It was not that it was a highly prized award winning software package that carried the value that we would have liked but it lit a small spark for some people as to a new way to work.

This team had learned to work together, enjoyed the work they were doing and felt in control of delivery once they found their rhythm as a team. The newly anointed product owner saw benefit in the way he worked in this situation and began asking me how he could “be more agile” in what he did. The stakeholders were happy with the end result and the software was delivered in weeks instead of months.

So, I sat down and typed up a summary of the experience, the overall process and how it shifted roles and needs within the organization, an estimation on what type and level of staff would be needed as well as a recommendation to start small and grow over time as opposed to a large scale shift.

The report was presented to the director of the organization who summarily dismissed the approach indicating “we are never going to do this” (firmly believed in the waterfall approach). I think he may have even thrown it in the trash.

Although disheartened, I knew that this was the right thing to do, especially within the government sector to bring more value through focused iterative work. So, I began to plan my exit from the organization in search of somewhere that I could actually make a difference.

The Partnership …

Coming off of this pilot project and more determined than ever to see this way of working take a foothold. Some leadership shifts had begun to occur and I knew of one other individual within my group that seemed to work slightly differently than the standard PMO. His background was in product management and he treated his product in a different manner than the other project managers. So I approached him and told him about the framework and said “I think you should look at this, you are doing about 80% of it now. You just need the discipline of the other 20%”. He read through it and was intrigued but struggled to get through the scrum guide as it felt like it was more engineering focused. I referred him to the agile manifesto upon which it was built and these values had a much more resonating effect. He became curious. He was a marketer and I had a vision for working in a better way. We were the perfect storm brewing.

As we were both ready for the next challenge, we created a skunkworks project with a new assistant director sanction. We created a team room and sat about to deliver the first product of larger business need using scrum. My new product owner new of a 109 page report delivered to the Commissioner that outlined business related projects (both in planning and “in flight”), their timelines, their progress, etc. It was in an effort to support his regular visits with community leaders with a group of organizational leaders so that he could hold conversations about items specific to the area and be aware of current status as he held the conversations. This report, we later found, had never been looked at by him.

My product owner had the idea that we should produce an interactive map application that could be used on a mobile device so that executives could review this status anywhere and use location as a way to get to these items prior to meeting without going through the hoops of asking a cadre of other people to compile and sanitize the data. I believed that domain data should remain where it lives and that this application should be decoupled from these core business systems yet reflect real-time changes to the data. This had been the debate for many years within unsuccessful committee after committee of how you “connect” the information into a unified view always resulting in “it cannot be done” or using mechanisms to scrape data from one system to make it visible to another. The problems were:

Once scraped, the ownership of the data in question became transferred to the new owner who was unlikely the owner, therefore would not recognize errors within that domain or ensure that it was accurate.

This was something that actually forced a cross organizational work effort within the business and a base level understanding of owners and consumers of data.

Our theory was through the building of this application we could do several things:

Eliminate a 109 page report that people rarely looked at.

Create a locational context to the data making it more meaningful

Solve a long standing business issue into connecting multiple domain sets of data and giving them visibility.

Create a lightweight tool that since it did not create data but use the data at rest, would allow for quality control in terms of how the data was actually reflected.

So my experience of all of a few months and my colleague of zero months sat about to do the impossible at the time. Create a product (which was not the term used, it was always project in our world coupled with plans, committees, governance, etc) built using the agile framework of scrum with a small but motivated rag tag bunch of team members wanting to do something different and believing they could bring value to the organization. Sounds like a tall order. It probably was. But why was it a good choice?

The product we chose had immediate business value and visibility to the highest level of leadership. It could be a product they would actually use.

It solved organizational problems by connecting disparate data sets and visualizing them in a geospatial context.

It rallied a team. Teams were being demoralized each and every time they worked so hard on a product for many many months just to be told “this is not what we wanted”.

It was focused on value, transparency and visibility. We welcomes anyone to observe how we worked, what we were doing and communicated openly and often. We littered our area with BVCs (big visible charts) indicating who we were building the product for, what the features were and the current progress.

So after putting some solid time into product planning (understanding the need, identifying personas, creating a vision and decomposing high level needs into features) we started with a cross functional team of developers and I played a dual role of scrum master and tester (which I do not recommend of possible). Being cautious, we selected a horizon of 30 days for our first sprint (which probably ran slightly longer as we were learning).

At the end of this cycle, we had a releasable product. Did it do everything wanted? No. Was that the point? Yes.

We demoed the product for the director (who as you recall said we would never do this) who was looking for a win with management. As my PO reviewed the features, the director asked several times “and you built this in a month”? He had no idea that this level of work could be accomplished like this, without the tomes of documentation, the endless committees and death-march approach of a 9 month waterfall effort.

Excited by what he saw and eager to show his leadership value to the executives, he arranged a demo with us and the COO and CFO (even though I am unsure of he understood what had been done or why). Although the first iteration was primitive, they saw the value of this product and method of solution delivery. A rapid innovative solution meeting a business need by people who wanted to respond to change. They immediately scheduled a meeting for us to demo to our commissioner.

Demo day with the Leadership Team

We arrived and setup our demo for the room. We had gone through how we would demo the features and planned to show how it worked across multiple devices so that it could be accessed anywhere. We, perhaps naively, assumed this would be IT, the COO and CFO and Commissioner. The room filled to the seams. Apparently we had stepped on a lot of toes of people who had been promising a solution to this issue for years. They all stopped in to see and, in my opinion, find that one gaping flaw that proved they were right in the impossibility to solve this. Our top leader entered with his staff and off we went.

I produced the 109 page report that this replaced and was immediately struck by the confusion on the commissioner’s face. He had never seen it or if he received it, never read it as it was like a car manual that was designed for the people doing the work, not to help people understand. We continued our demo and I handed him an iPad with the application displayed so he could play with the application and replicate what we were doing on screen. He became more engaged. We were excited and wrapped up the demo for the room.

With a brief pause the commissioner asked “who told you to build this”? We replied “no one, we knew it was an open question that the business had and we wanted to provide value”.

He then proceeded to do what I would call “beat the application with a proverbial baseball bat” telling us all the things it did not do or he wanted it to do. The PO and myself hung on his critique and I scribbled notes so we could process them later. The director looked like we had just shot him in the middle of the room. His perceived “win” seemed to be going south and here were the two guys to blame.

Once the review finished, the commissioner rose and said “I’ve got another meeting but you guys are 100% on track” and left and all of the spectators (many of whom probably felt we got what we deserved) filed out leaving the COO, CFO and IT staff behind. The C level executives apologized for the reaction and the IT director seemed to be disappointed we showed “incomplete software”. But we responded in a way that shocked the room … “This was great! We now know what he did not like and we can pivot and begin adjusting those features”. We explained that this how this worked. We review regularly with stakeholders, receive their feedback and adjust course as needed. They may have though we were a little nuts. I know a lot of the IT leadership did but with the excitement of the executives, we were given a reprieve to continue.

Within one more 30 day sprint, we had a version that met the needs and it was being used in the field. It was the fastest delivery ever done from a team of 3-4 as opposed to 5-12 over a 9 month period after 9 months of requirements gathering beforehand. We held conversations surrounding value and need, not features.

My PO was made CIO following the success of the product and asked me to stay on and transform the organization to work like this on every product. 4 years later and we have 4 scrum teams, 5 product owners and other pockets of agility. Even our own HR for the organization has become trained in kanban and uses it for their HR projects. The business extrapolated the idea of the scrum team to create “business studios” made up of all of the team members needed to complete a business function for a core business line.

How I planned to Build Something New Here …

When the PO moved into the CIO role he asked me to stay and help him build something new. I agreed under 2 conditions:

I needed to be able to always call BS when I sensed it.

I needed to be trusted and left to build it right.

He agreed (although he may have thought I was a bit nuts, and still may).

First, I knew I could not do this alone. Although I had a significant technical background in all aspects of software delivery, I had to follow the advice of “getting the right people on the bus”. So the initial team for this organization was hand picked and recruited. They were either excited to do something new or brought in superior technical skills and strategy to build out a solid technical architecture. I remained personally involved as a scrum master and tester (as we did not have much depth) and we stayed strictly adherent to the framework (look at the Shu-Ha-Ri principle).

Once I was able to move into more of a leadership role, I set about doing a few things that I think, although small, made a big difference.

This new organization would be align as flat as possible to encourage self-management and self-organization. Everyone reported directly to me to support the people doing the work determining how the work would be done. This did not change until the group had significantly grown and it became necessary to add a layer.

Continuous learning for the group would be core to the values of the new culture. We identified a great online technical education resource which we procured for every staff member and the idea of a “lab day” in which they built upon their own skills following each sprint became standard practice.

The idea of team protection and focus from distraction was also a core principle. We minimized disruptive impact to the focus the teams and encouraged, coached and empowered them to take commitments seriously by ensuring that the people doing the work indicated the commitment of work that could be done.

I hired a couple of eager team oriented scrum masters to be servant leaders to the teams and help them mature.

Ensuring space was available for the team members to innovate and exercise personal creativity. Outside of the standard lab day within the cycle, I self-funded and piloted a hackathon which is growing into a larger and wider event for the broader organization.

Hiring became focused and central to our growth. We broke out of the typical mold of the state process in which an applicant performed a 1 hour interview in which they regurgitated their resume and convinced you to hire them. We implemented 3 hours interviews that combined not only behavioral based questions to gauge how they had responded in the past to situation or might do so as well as a 2 hour technical interview in which the expectation was that they demonstrate the skills needed to do the role for which we were hiring. This has been something we have maintained focus on changed over time as opposed to making it a standard approach. I strictly adhered to the rule of “hiring the right person” and if they did not show up, I hired no one (much to the dismay of my leadership as the public sector hiring process can be cumbersome). I truly believe that this helped us create sustainability by making good hiring decisions.

I placed equal focus and attention to the cultural and technical growth aspects of the group. I hired people that were “culturally additive” in terms of value and with the help of strong technical leaders we defined and adhered to an architecture complete with design patterns, branching and merging strategies and promotional process. Defining this initially but leaving it to the technical people to grow has done well. I tried to be very intentional to create some growth paths by not hiring for every position so that people felt they had to leave to get ahead.

Instead of overloading a lot of processes (outside of the rules that were outside my control in the public sector) I imposed a litmus test for decision making composed of (2) key elements of consideration. Is what we are seeking to do “reasonable and responsible” to ourselves, our team, the citizens, our organization? If it met this litmus test and we understood and accepted the personal responsibility of the risk, remained transparent to those involved or impacted, the people doing the work had the complete freedom and support to make good choices without committees, work groups, management hierarchical approval, etc.

I established the idea of creating tribes within the organization composed of people with a passion to solve a problem that they created themselves and managed. This applied to everything from how we celebrated birthdays to our recurrent staff meeting to process improvements.

Everyone had a voice. Starting with everyone reporting to a single point it was easy to establish that anyone had the right to speak out. I reinforced this to staff by being an advocate for meritocracy, not democracy. “Good ideas come from where they come from” was the guiding idea.

In doing all of these things, I learned a lot. I challenged a lot of preconceived ideas of how people operations worked and how work got done. I have to say, although there is always room to improve and grow, I am very proud of the teams that are here today. I have had a few people move to new opportunities (always in a positive way) and seed groups of their own or seek to take aspects of the culture and apply it to new organizations.

While I have always hated to see people leave, I treated this as a good thing that they were growing and not dwelled on any gaps it left behind, which I think has been encouraging to them and not created undue organizational stress. So many public sectors operate in fear of “that one guy” leaving as they carry so much legacy knowledge. They do not stop to realize the problems is in the silo of knowledge as allowed by the organization, not the person themselves.

So why did I share this journey?

Some might think it is for the purpose of braggadocio. Nope. While I am proud of where I am and where this organization has grown, I see miles of potential unrealized before us. I think we are where we need to be today and hope we continuously inspect and adapt to get us where we need to go to become truly high performing.

I have heard many stories that amaze me on how people shaped their work world and I take personal pride in what I do and am impressed by the strides of many others. I have tried experiments that have succeeded and some that have failed miserably. I am very fortunate to be in an environment that has allowed me to do this as they know that I am aware of risk without sacrificing the need to experimentation. I truly am grateful for this opportunity.

Personally, I am grateful for everyone I work with from the most agile person within the organization to the person that is struggling just to figure out how they fit in the agile space. The former because they focus on value as a driver in the way they work and the latter because they want to learn, adapt and grow most likely or find the way they can connect with something different.

I take pride each and every day knowing my teams are in control of the work they do, take their commitments seriously and work to deliver quality products to the best of their ability. I take pride in seeing the depth of people we have and how those differences make them a more solid team as a whole. I am humbled by the fact that a great deal of people took a chance to try something different and trusted that we were building something great. I take pride in building an organization in which and every person has a voice in their work no matter their role and that teams are protected when they fail from being vilified and are asked to use these as learning opportunities. I am proud that my teams know the value of the “first responsible moment” when encountering problems and raise the flag to draw the attention when it happens so that risk is managed in real-time as opposed to being based on a risk register outlining risks that may or may not ever occur.

I spoke at an agile leadership summit about 6 months ago and one of the other speakers said “you should tell stories more, you have a knack for it” (unsure I agreed but appreciated the compliment). I actually did tell the organizer that if they had a rocking chair available, that is was best not to place it where I could sit when giving my talk or I might keep folks for a while. Yes, I love to share things with others. Perhaps it is in my nature and wired within my regional DNA in general.

The reason I share and this story is that I want people who may be struggling with a transformation or even just getting started to have hope.

Hope that you personally can do something different and affect change. I helped drive the implementation of agility in the most unlikely of places at a time when “death marches” of project failure were accepted in the culture as the standard practice of work and the value add by IT in general was viewed as very low by the business. From this small product, we transformed an organization and a culture and started a broader conversation that continues today. I often tell people when I started this conversation, I was the only person in the room (which meant a lot of talking to myself). I recently attended a meeting where 10 people engaged in a conversation of how to apply agile conversations more broadly and have coached, mentored and shared this story with a lot of folks over the years.

I alway recall a quote that inspired me early on from Mike Cohn.

“Agility is not something you become. It is something you become more of …”

If you’re stuck now or things are less than optimal. Stop. Take a breath. Figure out where you can pivot and where you can persevere. If you are unsure where to start, find that thing that you can make valuable and start “starting”. Be as agile as you are able to be given constraints and then push to become more agile. Learn from failure, embrace feedback, push yourself and do not compromise or collapse in the face of adversity. Show people a new way to work and build a culture that drives to empower and trust those doing the work, not operating under command and control.

I am going to end this quote with a passage from Apple’s “crazy ones” ad campaign created by Rob Siltanen and hope you all stay agile!

“Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.

They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things.

They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”

The resistance that one surface or object encounters when moving over another.

The action of one surface or object rubbing against another.

Conflict or animosity caused by a clash of wills, temperaments, or opinions.

I want to rephrase and examine it as the base term of “resistance to fluid motion” and apply it at an organizational level. Are we aware of it, what strategies can we apply to it and why it may exist.

What brought me to this topic? Very simple. Home repair.

My better half asked me to disassemble something for removal to the dump. Tools in hand I approached the task only to find that the bolts with which the item was put together had become rather fused through years of usage (and possibly over tightening to begin with). So I struggled. I strained. I tried to focus the inner superhero inside of myself to well up enough adrenaline to move this immobile object.

Nothing. I tried and tried and made no headway. I dropped tools, I cursed the item and even began to question and lament my own physical strength to being the reason I could not get this task done. I was exacerbated, exhausted, frustrated and felt the task was not only ridiculous but even a little resentment for being asked to even do this. In a huff of lack of progress, I walked away from this activity to sulk over the lack of progress.

My wife, being caring and trying to be supportive asked me “how’s it coming”?

A status report? Really? That was not the best time as you can imagine. This resulting in a re-telling of the epic battle of “man vs. bolt” in which the end result was man was laid to waste in the shadow of the all-mighty power of the impenetrable bolt. This story was told with the flair of a new Star Wars movie complete with arm gestures, sound effects and emotions ending with a culmination of “I suck at tools”.

Continuing to be supportive she listened patiently and allowed me to regale her with the tale of the mighty bolt to which she said encouragingly, “I know you. You’ll figure it out”.

I shrugged, grabbed an ice cold refreshment and sat in my chair to mull over my defeat.

As I sat, I began to think more and more about the situation. What would my dad have done? He was the consummate master of all things tool and repair related. If you needed a tool, he had it. If you were unsure how to approach a problem, he could envision the solution. It always seemed like he just “did it” with far more ease than I could ever do.

One thing he taught me about tools (although a lot did not stick) was “son, always have the right tool to get the job done”. I had the right physical tools. But I recalled a similar situation when we were working to replace an alternator on a car. He reached on the shelf and grabbed something and BAM the bolt magically loosened. I remembered him telling me that “sometimes when you hit bolt resistance, they just need a little lubricant”.

Eureka! I sprang from chair, grabbed the can I had in the garage, sprayed the bolt and within 30 minutes the item was disassembled. I strutted proudly back into the office announcing “all done” to which I received the adulation of the conquering hero of the dreaded bolt! But what did I really do? I applied the same tools and the same strategy as before but with one difference, I reduced the amount of resistance. I eased the friction and as a result, I saw immediate value.

This got me to thinking … what is that magic spray that I might be able to apply to organizational stickage or organizational friction?

Friction within Organizations

The prior story took a long way to get us here, however, I wanted to share the levels of physical and emotional impact that the inability to overcome this simple case of resistance took on me personally.

Organizational friction is not unsimilar. When we as a member of an organization hit a point that impedes our progress to an end goal, we almost immediately (as we are wired by the human condition) enter a “fight or flight” mode. We either become frustrated and angry at the process/person that is stopping the progress or we back away in frustration to brood/complain to others or just sulk about the situation. We experience feelings not uncommon to the same way I felt when I encountered the physical resistance of that bolt.

I think if you can stop for a moment, you can probably easily identify your own areas of “organizational friction”. As I sat and thought about this, I identified a few broad areas that seemed to be good indicators for a potential for organizational friction:

Exchanges between siloed functional areas that although they may work together are relatively autonomous in their process and function.

Exchanges between groups that have deeply ingrained and conflicting work culture or deeply defined organizational missions, sometimes in opposition.

Interactions between groups that typically work together and therefore have processes and or policies that may be heavy to one another.

Can’t you just loosen the processes?

This seems a natural “kneejerk” reaction when one encounters something they feel is stringent. However, this like my first experience cooking with natural ginger root. I just cut off a block to season my dish and in the end it was all I could taste. The key is remaining “value focused” and applying just the right amount to meet the need (just like ginger root) when approaching adjustments due to friction. And just like my cooking experience, you can make one’s self “gun shy” to the experience if a bad outcome is had in your first experiment.

Using the historical perspective of a “moment in time” bad experience often means we can end up creating process around a “people problem” as opposed to a “process problem”.

A natural “knee jerk” reaction is to shun all process as we believe that is the core issue to the problem at hand. Sometimes a process can actually be problematic but I am a fan of always inspecting how you work s opposed to abandoning something merely because and . Sometimes abandonment is the right thing to do as circumstances have changed or the world around us has shifted.

Too many times I see people stop asking if the new and progressive process that they created still works for the organization at hand. They lie dormant on a shelf only to be pulled out and dusted off to clarify a situation.

Couldn’t it be more productive for review of these things and see where improvements can be made and ensure that we are not optimizing the past for the sake of having a process in place? I guess my opinion is that as often painful as it is to implement a process change, doing so without regular intervals of effectiveness creates future pain.

The “invisible process”

I worked for a company once that when I asked about a specific situation or implementation, I received the same canned response “that’s our policy”. I recall receiving this response over and over again when inquiring about everything from organizational change to aesthetics of page design. So one day, being the curious sort I am, I asked “may I see these policies and processes”?

This was met with a lot of back peddling at which time I was told these were “accepted practice” of the business. I pressed on this issue and asked how we held employees accountable to these ideals if they were not available for them to be aware. I was told that each employee was deeply versed in these when hired (which struck me as odd as most of the requests were based upon questions I received from a team for which I was the lead).

But what the organization had done had insulated itself by creating these invisible processes and calling them “standard practice”. This allowed them to deflect items in which they sought not to address through their quote as needed. I worked very hard with this organization to see the value of the transparency of these processes and utilize the strength and creativity of their staff to determine which invisible practices may actually be hurting them either through overall credibility or staff confusion.

If you find that your organization has “accepted practice”, increase the visibility. Communicate them so that they can be inspected like any other process. There is absolutely nothing wrong with having a way in which you work but doing so without a mechanism to communicate understanding internally and externally can be problematic.

So how do I combat organizational friction?

Realize it potentially exists. An organization is a complex system of moving parts and as so local edicts which may impact those outside the group may result in friction. Don’t bury your head into the sand over this fact.

Be as transparent as possible. Shy away from not having a communication channel in the way you work. In the book Traction, one mechanism is indicated as creating your organizational “way” of how you conduct the function you do. But be mindful here. These cannot live in a vacuum, you must regular revisit this to know if you are a) working as you state you do for organizational accountability and b)ensure you are effectively communicating how things change over time.

Make a cultural shift to being one of a problem solving organization. Create a culture in which across your organization you get the affected people in the room so you can 1) ensure that there is good alignment between affected groups and they shift from a culture of “doing my part” to one of seeing the end goal as a whole and 2) create a culture of “shared understanding” which develops people to not necessarily understand the depth of another domain but gives them context to the pains and end goals of the various groups involved.

If you need a process for guidance, make it as lean as possible and instill mechanisms to review on a regular horizon. Remember the natural reaction for anyone when encountered by an obstacle is to seek to get around it. So if you have optimized your process for a single group without understanding impact or ongoing effectiveness, you may find people finding creative ways to avoid it altogether.

Work to reduce risk and friction by making room for recurrent small horizon activities. By making things at a more micro level you can a) have a much more manageable level of work, put in place more timely rollback plans in the case of failure for recovery and ensure that the system in place remains light to better encourage people to “follow the rules” in place.

Create a mechanism and bandwidth for regular feedback upon which you can take action when friction occurs. Receiving feedback decoupled from any way to make actionable changes discourages people to even raise an issue of where friction may be occurring.

Realize that some processes may be cumbersome. Really dig into them for the end core value. Visualize the workflow and why each step and the surrounding rituals and artifacts are needed. Be open to challenge and eliminate areas built up around historical mistrust and reflect on how it’s actually working.

And last, don’t try and eat the elephant all at once. Find a small collection of things to review and potentially improve. Put in the mechanisms to monitor the changes (can be a simple as a retro to as “better/worse/fiasco”) to see if you are still on track. Avoid bending to the LVITR (“Loudest voice in the room”) syndrome through facilitation and ensure that the right people are there and give input of the impact of friction, trust the people doing the work and encourage them to solve the problems and make their work even better.

Hope everyone has a great upcoming holiday! Stay Agile!

]]>https://agilecoffee.net/2017/08/31/friction/feed/0tholden615Team Icebreakershttps://agilecoffee.net/2017/07/19/team-icebreakers/
https://agilecoffee.net/2017/07/19/team-icebreakers/#respondWed, 19 Jul 2017 12:13:39 +0000http://agilecoffee.net/?p=5742Continue reading Team Icebreakers]]>I am a big fan of using small team exercises to just people out of their “head space” for a moment before refocusing back to the area of work. Sometimes it can be a physical (just stand and stretch, take a team stroll) or be just a small thing to let people begin talking about non work focus items to just relax for a moment. I also appreciate, as does my team culture, the value that humor affords in work.

A great way to start teams talking before a daily stand-up or retrospective is with an icebreaker. I have come across a few simple ones (some I have used in the past) that I think is a great way to just stimulate spontaneous response and to allow the teams to loosen up and get ready to communicate.

One Second Trivia

Prep Time: 5 minutes or less dependent on how quickly a scrum master thinks on their feet. Questions can be prepared on index cards or scrum master can make them up on the spot.

Run Time: 1-2 turns per team member

Goal: To just relax people with potential humor and “prime the communication pipeline”.

Rules: Only 2.

You must provide an answer within one second.

There is no wrong answer in this game.

Play:

As each team member a question and allow them to give an immediate response (much harder within one second than you think),

Examples:

“What can you not grow in a garden”?

“Why did you borrow $20.00”?

(Fill in the blank) “You superpower is …”

“What is a vegetable that should not exist”?

“What is Beyonce’s middle name”?

(Fill in the blank) “The code word for this product is …”

“Where are you keeping that candy bar”?

The objective is just to get the team relaxed and ready to connect. Often time hilarity will ensue as coming up with answers for these in one second typically results in whatever pops into your mind.

You can change things up by allowing team members to run the game and prepare their own questions. It does not take very long and it engages them.

Yes. And …

Prep Time: No real prep time needed, just the ability to seed a conversation.

Run Time: 1-2 turns per team member

Goal: To help team members develop engagement and listening skills with one another as well as reinforce being value additive.

Rules: The objective is to listen to the statement made by the previous team member and continue the story by adding “Yes, and …”

Play:

Seed the conversation to start with a topic or lead-in. Examples:

“Yesterday, we went to the zoo …”

“When I was preparing for my career as an astronaut I went to Walmart”

“Today began as the worst day ever”

“I came home last night and decided to bake a cake”

“I met my evil twin yesterday in a coffee shop.”

Power Animals

Prep Time: 5 minutes or less. Requires either drawing animals on index cards or finding small pictures to tape on cards, etc so that they can be placed into something to draw from by each team member.

Run Time: 1 turn per team pic member

Goal: To just relax people with potential humor and “prime the communication pipeline”.

Rules:

Respond as quickly as possible.

There is no wrong answer in this game.

Play:

Set the stage – “This is the power animal game. In this (bowl/box/hat) are many types of exotic and amazing animals (make a lot of them really odd or very mundane animals). This animal has specifically selected you to be able to channel some of their special abilities in any time of need.

The goal of this game is for you to relay to the team why this animal picked you specifically to be your power animal and what power(s) did they grant you.

Have each team member reach into a shoebox or bowl and draw out a picture of an animal and respond. It’s often not only humorous but can often be insightful into gifts that a team member has or wishes they possessed. Good information for strengthening team member connections with one another and with the scrum master.

This is something in business we all struggle with in my assessment. How to sequence “just the right amount of work” to deliver value and still all the desired ability of an organization to remain responsive to shifting value needs. My organization has struggled with it as I feel confident many of you have as well.

There are a lot of techniques, both agile and not, to determine capacity and we’ll look at a few and I will express my own opinions here and what effects poor capacity planning can have on teams and organizations.

Somebody call 911!

A lot of us live in a world of “firefighting” as an organization. Not literally, but what I mean is that we become reactionary as an organization as opposed to responsive. Organizations often confuse responsiveness as the ability to handle each fire as it occurs when it reality this is chaos at its core. Often, these organizations are so busy fighting the blaze that they never take the time once the situation has passed to ask why the fire actually started in the first place or they confuse every flare up on the same level as the entire city in flames. This is not responsive, it’s reactionary and although you may be defined as the “hero of the day” in the moment, it eventually raises much deeper problems that can become exposed and have to be addressed.

Being a reactionary environment is inefficient. It means that there is a significant amount of waste happening waiting for the disastrous event or worse yet it is a sign that work is improperly sequenced to allow a balance of responsiveness and performance. Signs of this are often team member turnover, sick time increases, increased deep policy to attempt to be preventive (the “ban all matches” approach) or just a general negative outlook to solving a problem. Be vigilant in observation for these types of issues as one you define yourself as this type of an organization, it is often very painful to change.

Capacity, Performance and the myth of being busy

One of the things that I have always believed is “do less better”. Ensure that you are meeting the highest value items for an organization but in the face of emergent needs you have to deliberately create slack within your work capacity for numerous reasons. Things like actually being responsive to the emergent pet project that comes up, capacity to nurture your teams and team members to allow them to grow and give back to the organization in doing so and generally to improve performance throughput

Basically capacity boils down to “how much something will hold” from a true math reference bt in our terms it means how much time and work can we consider and remain effective in our performance. Finding area and volume of a given shape to determine capacity is a relatively simple formula but when it comes to people and time, it often gets tougher (although I know many PMP folks who would explain to me formulas of resource management, resource being a word I strongly detest when referring to “people”).

A general rule of thumb is that you will never receive the maximum capacity of a given person or team. Accept this. If a person works an 10 hour day, the best you can hope for us 70%-80% which is roughly 7-8 hours at the high ends. The reason for this is that people are social creatures and have needs like going to the restroom, checking emails, diverting their attention after prolonged focus, casual conversation, meetings, etc.

If there are CIOs/CFOs/COOs/CEOs reading this in awe and shock, welcome to the reality of people. And it is even possible that 10% of your overall workforce is performing suboptimal based on lack of skills, poor work ethic, sickness, burnout or whatever reason. So how do you handle this and still maintain a level of performance without remaining in a constant hiring frenzy of cycling burnout workers?

First, accept your reasonable capacity levels and plan strategically. If you do, you will find that you optimize the flow of delivery within that capacity and you often see higher percentages executed (which can be a different topic to watch for … “dark work” that has no visibility and creates strain but as things are delivered on time no one questions).

If you think more bodies are the answer. You’re wrong. Read the Mythical Man Month. As you increase complexity to any systems you fragment pathways making performance degrade. Think of a small intimate dinner gathering and how conversation can flow well between 2 couples (as they can keep up with topics or break into smaller sub groups and still reflect to the group). Now introduce 2 more, and 2 more, and 2 more. Make it a large dinner party and afterward come home to discuss the topics of conversation. The pathways are too complex. You cannot keep everyone in the loop on all of the conversation occurring.

The same thing occurs with software development. As you introduce more and more staff you increase the complexity in the forms or handoffs, communication pipelines, individual or small group decisions that get made, etc which make it slower as rediscussion, rework and deeper changes are often a result. This is often why I prefer product feature teams as opposed to component teams whenever possible.

Secondly, if you want to be responsive; be deliberate in building in slack to your approach. Let’s take 3 examples; road networks, servers and teams.

Road Networks:

You are driving to work. There are 30%-50% of other cars on the road. You make your commute in a reasonable amount of time. But we are not utilizing all of the capacity of the road! So let’s crank it up to 100% and make that same commute. What is the expected result? Traffic jams, delays due to accidents, road rage. We actually decreased our performance by trying to fill all of our capacity.

Servers:

This is a little tougher as in the day of invisible scalability of cloud networks it may seem a poor example, however, if a server capacity is maximized to 100%, performance degrades; it is a given. It results in unneeded swapping just to meet all requests. It may seem negligible but if you have ever been frustrated waiting for a web page to load, you may have been experiencing exceeded capacity.

Teams:

Filling a team capacity to the brim can result in whiplash when trying to meet those emergent needs With that allowed focus, you have teams that maximum their throughput through selection, self-organization and a regular cadence. If they have other responsibilities (support, meetings, etc) not building in that capacity that is aware of these things will result in feelings of being high performing but in fact often degrade performance and hide a lot of work being done on an employee’s own time (which can result in a whole host of issues).

But we have to keep people busy

Do we? Did we hire the individual with a specialized set of skills to ensure they remained “busy” or did we hire them to ensure that we had the necessary skills to realize the end result of value?

If a manager pops into a team room and a team is relaxed, having a conversation about Dr. Who or some world event is that ok? Sure it is. If they are personally making their commitments and failing to deliver value, then you might sense a problem which could be everything from they are sandbagging to they are being disrupted externally for other work to the guidance they are receiving is creating deep and counter productive conversations at the time of delivery from a lack of understanding. It could be lots of things.

The point is not to keep people busy. In trying to do this based on observations of social interaction as a sign of low productivity, you toss the idea of capacity out the window. For me, I want a highly motivated team that wants to come to work and deliver because they know they have a direct voice in setting and communicating reasonable expectations for feature delivery. Does this not mean that occasionally the team may not be forced to ramp up commitments to meet a deadline? Absolutely not. But if you trust the people doing the work to be reasonable and responsible in communication, transparency and of the delivery of that work; often times I find teams will rally to address the hard need.

Otherwise they are back in firefighting mode.

Seeking to ensure teams and team members are “all busy” is a false goal. It equates people with server throughput. People should be cultivated and grown if you want to create longevity of any sort in your company with employees. They will become your greatest champions and advocates if you embrace this. They will tell others of the great company they work for and they will work hard to deliver of their commitments.

I write this post today not out of any personal or professional frustration but from an observation that many organizations focus on “busy” as opposed to intentionally creating space to be responsive to emergent needs. Just like a home’s unused space get filled, professional people fill the unused space (through skill acquisition, environment improvement, idea sharing, etc). But just like a home; should you inherit your grandmother’s giant steamer trunk if you have filled all of your capacity of space it gets placed in an odd location or you “make room in the attic”.

Be honest and kind to yourself as an organization, your people and reflect a true understanding of capacity by considering more than just “delivering more” or “being busy”. Understand what other impacts that people have that impinge on capacity and to become truly responsive, be intentional in creating slack within your overall capacity.