The Triangle of Support for Great Software Teams

One of the key approaches of good software development is building software iteratively and incrementally. Iterating over our process and software gives us a chance to reflect on how we are working, while building increments of functionality allows us to begin to deliver functionality and value (in the form of working software) early. This feedback loop is critical to good software development.

What I see less talked about are the thought process and roles necessary for this kind of approach – especially in large scale systems. We want slices of value which cut through the various layers – Database, Services, UI, etc. That’s the goal of incremental development. But a common pushback comes from the notion that in working this way we throw out the vision, guidance and architecture discussions. I think this couldn’t be further from the truth, but how we implement it is a little different.

Systems Thinking, Business Thinking, Technical Thinking

In the diagram above, there are three key bubbles – Systems Thinking, Business Vision and Technical Vision. Systems Thinking is responsible for How We Work. In a Scrum implementation, this is going to be your ScrumMaster. From a Lean perspective, we’re all responsible for visualizing how we work to improve it.

The second bubble is the Business Vision. This person is responsible for driving out the What We Need of the solution. In Scrum, this is likely your Product Owner.

The final bubble is the Technical Vision. The goal of this role (or roles) is that they set the vision for the various components that will work together – database, services, systems, etc. But instead of dictating a vision, they work closely with the teams with each slice through the system (also known as a tracer bullet) to see if the overall solution is moving towards the vision, and whether the work – or the vision – needs to change.

These three roles form a critical element of vision and leadership for the teams, enabling a highly fertile container where great software can grow. So next time you are working with your teams, think about who is driving the technical vision, the business vision and the vision of how the team should work – and see if explicitly defining some of these improves your process.

{ 3 comments }

The Safety Net of Retrospectives

Stop Planning - ExecuteOrganizations are filled with decisions. Well-run organizations enable decisions to be made at any level – ideally at the level closest to the work being done. But sometimes it can be difficult to know if a decision is good or not. As a team, you can talk about the challenges, the benefits, and the goals, but you just don’t know what you don’t know. This fear of not knowing can lead to inaction – especially in cultures which value risk management and mitigation over innovation.

When I come across teams stuck with inaction, I usually see a tool missing from their toolbelts – retrospectives. Because it isn’t so much the action that people are stuck on, but the reaction and knowing what to do about it.

One way I teach teams to do retrospectives on a regular basis is to have 4 quadrants – Well, Less Well, Change and Expect. That last item is key. What did we expect to happen since the last time we reflected? If we put a change in place, did we expect something to happen because of that? Then, if the change was good, it can go in the Well column, and if it wasn’t good, it can go in the Less Well, allowing both to feed into new ideas we can try. We move from being a culture of inaction to one of micro-experimentation.

ExpectAs an example, I was working with a leadership team earlier this week that had gone through some reshuffling and was taking a look at the way they were currently running their program. One of the questions that came up was whether they needed all of the meetings they were currently having, and specifically if they could combine two meetings (with two different sets of participants) that happened on the same day. I asked two questions:

  1. What do we expect to happen by combining these?
  2. How long should we wait to see if we’re seeing the results?

This allowed them to say that we would expect to see an increased level of collaboration, decreased level of communication delays, and that we could reflect on it in 4 weeks to see if the desired impact was happening, and make a decision about what to try next then.

Small steps. Microexperimentation. Engaged participants. That’s a good step towards building – and discovering – a great organization.

{ 3 comments }

Retrospective – Hats and Soup

A couple of weeks ago, I wrote about a large scale retrospective I facilitated to get some rapid insights from a large team in just one hour. This week we were able to bring in a fuller set of the team, but were still under time constraints – just 3 hours. We needed to solve several issues at once:

1) Large scale. We were expecting up to 120 participants

2) Scalable – We knew 120 people wouldn’t be able to stay in one room, so we needed a way to split them into at least 4 subgroups before splitting into smaller groups

3) Rapid – we only had 3 hours, which needed to also include a review of the previous retrospective, as well as time from leadership to be able to ask questions about the insights generated from the game

4) Specific – the last retrospective generated only one item in the “What we did well” category – “Deflecting Issues”. We wanted to explicitly give them time to think about good things that have happened

5) Long-term – we were covering a 6-month period

6) Rapid Filtering – we needed the teams to be able to quickly self-identify issues under their control, and issues which were beyond their control so they could vote on things which could actually be changed

I ended up choosing a combination of 6 Thinking Hats as well as a modified version of Spheres of Influence called Circles and Soup which I found on Diana Larsen’s blog. We ran it the following way:

Purple Hat – Things You’ve Learned: Our goal here was to get people thinking about what new skills they’ve learned while a part of the program. Some people have been on the program for two years, and while there have been lots of challenges, they also have learned a lot of new ways of working. This isn’t actually in 6 Thinking Hats, but was critical to add.

White Hat – Facts: There are lots of conjectures and guesses about things, but we wanted to focus on facts. Some were great (), while some were concerning (“There are 7 Work Days in week”).

Yellow Hat – Good things: What we thought was going to be the hardest part of the retrospective was really insightful. They were only allowed to write good things that had happened over the past 6 months. The teams didn’t use the full 10 minutes, but still generated some great insights

Black Hat – Bad things: As we expected, the teams did use up the full 10 minutes on this, and then some. But the insights here were things that we could take action on as a leadership team, which is always a great thing. When people say, “I hate this” you can’t do a lot. But when they give specific things, you can fix or mitigate those, which is a great feeling.

Green Hat – Ideas for Improvement: The goal here was to generate actionable items. One concern we had was how to generate actionable items that, well, were actually actionable – meaning, things the organization could do something about. In the preparation, the leadership team was really concerned about how to filter these, and I’ll talk more about that below.

Red Hat – Emotive Statements: In 5 minutes, write two ‘emotive’ statements – things that just come to your mind. The example I gave was Steve Ballmer’s famous [Developers, Developers, Developers, Developers] video where he says, “I…..LOVE…..THIS…..COMPANY!”

As I mentioned above, we wanted to be able to let the teams vote and prioritize the things they thought were the biggest items. But we also wanted to filter things the team could actually control. My concern was that I didn’t want that to be a management action – the filtering needed to come from the teams. But given that we only had about 90 minutes to collect and analyze data, how could we do that?

I came up with the following visual chart. The four quadrants around the center were, clockwise from top left, New Skills, Facts, Bad and Good. In the center of the chart, I drew the Circles from Circles and Soup, with the inner circle representing the things the teams could directly control, the middle as the things the team could influence, and the outer circle being “the soup” that the team could only respond to when they found themselves in it.

With the first four hats, I had the teams consolidate the answers into the appropriate quadrant. Behind the scenes two of our coaches worked to consolidate duplicates – something the teams should have done with more time, but we were surprisingly low on space with the amount of items they were generating.

Once we got to the ideas for improvement, I introduced the circles. I told them to think about the circles as they wrote their ideas, and then post them to the appropriate circle. We did the same with the emotive statements – they put them into a circle which was closest to what they felt the statement fit into, or the control they felt over it.

I found this to be extremely powerful – it created a natural filter for showing the teams what they could control and handle. In addition, it appeared to focus their thinking into items they could do, and things they needed help with.

Once we had the Thinking Hats exercise finished, I had the teams dot vote the items they felt were most important. Each participant got two dots with a marker. In addition, if they thought something was really critical, they could grab a dot sticker and put it on the card to highlight it.

As all of this was happening, the key directors from the program were reviewing the board and watching what was coming up. So after the dot vote, I was able to turn the floor over to them to be able to talk directly about some of the things they saw, including questions and some answers. I stressed it important not to promise any actions directly during the Q&A until we had a chance to analyze the data.

In the end, we ended up with over 350 cards of information, and some really great insights into what could be improved across the program and organization. The leadership has already begun taking action on certain items from the retrospective, which is building more trust in the teams that, when it’s within their control, action will be taken. In addition, we achieved the goal of getting the right information from the teams by helping them naturally filter the things under their control so we could not only respond faster, but also help them to see that something we just have to figure out how to respond to when it happens.

Thanks Diana for the great exercise idea, and to Jared Richardson, Paul Mahoney and the other coaches who helped co-facilitate, collect information, and bounce ideas off of.

{ 1 comment }

How Agile Is Your Process?

Individuals and Interactions over Processes and Tools
Responding to Change over Following a Plan

When teams and organizations look towards better agility, they generally start with one of the known frameworks out there – most often Scrum but also SAFe or many of the other agile methods. But one of the key principles from the Agile Manifesto says:

At regular intervals, the team reflects on how to become more 
effective, then tunes and adjusts its behavior accordingly. 

What this says is that, over time, we should be getting better and better in how we work and deliver. But oftentimes this ends up running counter to the process we have in place, and it is difficult to know what to do in those cases.

Scrum by any other name

Team Grasshopper has been working with Scrum for a while. They’ve been very successful so far in delivering features to their customer. They all sit together in an open room with plenty of whiteboards, so conversation seems to flow freely throughout the day. At the end of Sprint 9, the team has a retrospective. Julia, the team’s ScrumMaster, is facilitating.

“OK team, one thing we wanted to do this retrospective is focus on our process itself. Let’s start with an open conversation and I’ll capture the data.” Julia moves to the whiteboard. Jackson, one of the developers, speaks first. “You know, I appreciate the idea of the daily standup. But it seems like we don’t have much to talk about there. After all, when we have a blocker, we put it on the board immediately, and between our Scrum board and the conversations throughout the day, we all know what we’re working on.”

Roberta jumps in. “That’s a great point, Jackson. Also, I noticed that our customers – especially Jessie – could benefit from more frequent demos so they can talk to the other vendors in advance of Sprint Planning. It seems like we should be checking in with them every week, but I know we can’t do planning any more frequently than every two weeks because of their schedule.”

Team Grasshopper is at a crossroads. If they stop doing daily standups, and move sprint demos to be weekly, but sprint planning still every two weeks, aren’t they violating the rules of Scrum?

Individuals and Interactions

Part of the confusion for teams such as Team Grasshopper, as I mention in Recreating Scrum Using Kanban, is that they don’t own all aspects of their process. Scrum is predicated on several implicit policies which come out of choosing your sprint length. So if you have a two week sprint, you do Sprint Planning every two weeks, Sprint Review every two weeks, and Retrospectives every two weeks – that is implied because of your sprint length.

As another example, in the Disciplined Agile Delivery framework it is implied that you will use iterations and demo at the end of an iteration. Or in SAFe, it is implied that if you are “Scaling Agile” you use a Team, Program, Portfolio approach.

To be clear – these aren’t necessarily bad things. For many teams and organizations, it provides a clear, proven starting point. But it isn’t clear to teams how to modify the process and still get the value – in other words, the “why” that backs the “how” of the processes. This is critical to move beyond selling the term “Agile” and moving towards true agility While many of the methodologies are backed by a set of principles, the idea goes beyond just principles. David Anderson refers to them as “properties” in his Kanban book, but perhaps the most familiar way of understanding these “things” is via Design Patterns.

Towards a Pattern Language

Let’s imagine a team that is having communication problems. They struggle to know what the other members are working on. So one force is that they need to find a way to communicate more frequently. However, another force is that you are dealing with multiple people, so you need a way of making it easy for them to remember when to do it. The third force is that if we are going to have frequent communications, we don’t want them to be overtly long – they should be self-limiting.

With that problem and those set of forces, we can look towards the pattern Daily Standup. The team will come together to coordinate their work, on a daily basis so there is a clear cadence, and stand up to help remind the team that this needs to be high-impact and no longer than it needs to be.

This same team needs a way to help their customer understand the work they are doing. The first force is that the customer can not sit with them all the time. The second is that their customer isn’t a software developer, so they can’t just see code. The third force is that we need the customer to be able to help make decisions of what else they want – recognizing that they won’t know what they don’t want until they see it. This leads to a fourth force – if they don’t know what they want until they see what they don’t, we need to get working software in front of them as quickly as possible.

This set of forces leads to the pattern of System Demo. Which, like Daily Standup we’ll want to set a cadence for. Talking with the customer and the teams, weekly seems about right to be able to demo working software in a way that gives the customer enough information to be able to influence the backlog or at least be thinking about what they want.

By looking at our practices in this manner, we begin to explicitly own the process we use by determining policies based on the patterns in our specific situation. Once we own the policies, we can make the decision of when to modify them, since we understand both the challenges, as well as the principles behind our goals.

Lean Thinking

The idea of explicit policies is core to Lean Thinking through the principle of Standard Work. Teams document their actual process as the standard way of working. They then inspect that process, allowing innovation and individuality to shine a light on it, and then as they modify it, they document that as the new standard. For example, in Kanban we start with where we are – meaning we document our value stream, and then document the explicit policies of work (see Recreating Scrum using Kanban and Explicit Policies). We then observe the flow of work, and modify our policies as appropriate.

…Over Processes and Tools

Back to Team Grasshopper. Their struggle is not with their process, but with the idea that they don’t know how to modify Scrum to fit into the process they need. This isn’t Scrum’s fault per se – one could easily modify many of the methodologies to include guidance on how to pay attention to the principles and modify as they see fit. But the Agile Manifesto is clear – Individuals and the Interactions come before Processes and Tools.

In the end, Team Grasshopper ended up making their policies explicit, which helped them understand how to track the principles behind the “Why” of the practices. They moved sprint demos to weekly, and kept Sprint Planning as every two weeks. They cancelled their daily standups, but added a retrospective board to their scrum wall to keep a close eye on the communication between team members to make sure that they did not see a drop off in communication.

Your team can do this as well. You own your process – not a consultant, not a website, not a training, not a book. To modify it, you need to understand the principles and patterns behind it – so it’s OK to start with a set of prescriptive practices at first to see what needs to change. But remember that it’s you and your team’s interactions that come before any process and tool. Modify your tool for your process – don’t modify your process for a tool.

{ 3 comments }

Putting Your Best Code Forward

I like sharing things I’m working on. When I’ve searched for a solution, and not found one, I hope that sharing what I did find will help some other poor schmuck like me in the future. In fact, more than once I’ve done a search for a problem, and found a solution – in one of my own blog posts from years back.

I’ve been working on a Rails Security talk, and needed a way to figure out just how many lines of code are present in a default Rails application. Meaning – not just the lines of code for controllers, views, etc, but also the number of lines of code for all of the default gems. So I put together the following code:

GFILE = "Gemfile.lock"
 
list = File.read(GFILE)
 
gems = []
 
list.each_line do |line|
 line = line.strip
 break if line.include?("PLATFORMS")
 next if line.include?("GEM")
 next if line.include?("remote:")
 next if line.include?("specs:")
 next if line.empty?
 gems.push(line.split(' ').first)
end
 
total = 0
gems.uniq!
gems.each do |gem|
 puts "Processing #{gem}"
 contents = `gem contents #{gem}`.split
 local = 0
 contents.each do |file|
  output = `wc -l #{file}`
  amount = output.strip.split(' ').first.to_i
  local += amount
 end
 puts " LOC: #{local}"
 total += local
end
 
puts "Total Lines: #{total}"

It did what I needed, and I could have just thrown it away. But I figured someone else might need something like this, so I posted in publically. The problem? Let’s be frank – that’s some awful code. `GFILE`? `local`? When we post code, we should put our best code forward – examples of how to do things right. I didn’t post it as a draft – I posted it as a solution that worked. My good friend [J.B. Rainsberger][2] pointed out in a comment that I could do better. And he’s right! So let’s clean this up:

require 'set'

GEM_FILE_TO_PROCESS = "Gemfile.lock"

The first thing was to change that horrible name to something understandable. I also included the set library, because I really wanted a `set`, not an `array` that I needed to call `uniq!` on. Next, I extracted the line checks to separate methods, based on what I interpreted them to do when I came across them:

def gem_list_finished?(line)
 line.include?("PLATFORMS")
end
 
def non_gem_line?(line)
 line.include?("GEM") ||
 line.include?("remote:") ||
 line.include?("specs:") ||
 line.empty?
end

I then extracted out the line counting to their own methods:

def gem_name_without_version(line)
 line.split(' ').first
end
 
def get_files_in_gem(gem)
 `gem contents #{gem}`.split
end
 
def line_count_for_file(file)
 output = `wc -l #{file}`
 output.strip.split(' ').first.to_i
end

This has the handy side effect of removing the system calls (code called in backticks) away from the main logic. I also pulled out the `puts` statements into a log function:

def log(message)
 puts message
end

Now comes the meat of it. We still read in the file, but also initialize a set to store the gems, and put our other critical variable all in one place:

gemfile_list = File.read(GEM_FILE_TO_PROCESS)
gems_to_process = Set.new
total_line_count = 0

Next we process the Gemfile. Note that it’s clearer now that we have conditions we stop processing, and conditions where we skip processing:

gemfile_list.each_line do |gem_line|
 gem_line = gem_line.strip
 break if gem_list_finished?(gem_line)
 next if non_gem_line?(gem_line)
 gems_to_process.add(gem_name_without_version(gem_line))
end

Finally, we walk the gems we found and get their contents. I could probably use inject here instead of initializing a variable, but I prefer it to be a little clearer:

gems_to_process.each do |gem|
 contents = get_files_in_gem(gem)
 gem_line_count = 0
 contents.each do |file|
  gem_line_count += line_count_for_file(file)
 end
 total_line_count += gem_line_count
end

All in all, it’s a much better representation of something I would want to share. Could it get better? Absolutely. I could create a model around the Gemfile, asking the lines questions instead of checking them explicitly. And I probably will – if I ever need to turn this into something more explicit. The full code is below, and at [the gist][1]:

require 'set'
 
GEM_FILE_TO_PROCESS = "Gemfile.lock"
 
def gem_list_finished?(line)
 line.include?("PLATFORMS")
end
 
def non_gem_line?(line)
 line.include?("GEM") ||
 line.include?("remote:") ||
 line.include?("specs:") ||
 line.empty?
end
 
def gem_name_without_version(line)
 line.split(' ').first
end
 
def get_files_in_gem(gem)
 #gem contents returns the files
 #as a line break delimited string
 `gem contents #{gem}`.split
end
 
def line_count_for_file(file)
 output = `wc -l #{file}`
 #line count is the first column from
 #the returned value
 output.strip.split(' ').first.to_i
end
 
def log(message)
 puts message
end
 
gemfile_list = File.read(GEM_FILE_TO_PROCESS)
gems_to_process = Set.new
total_line_count = 0
 
gemfile_list.each_line do |gem_line|
 gem_line = gem_line.strip
 break if gem_list_finished?(gem_line)
 next if non_gem_line?(gem_line)
 gems_to_process.add(gem_name_without_version(gem_line))
end
 
log "TOTAL GTP: #{gems_to_process.count}"
 
gems_to_process.each do |gem|
 log "Processing #{gem}"
 contents = get_files_in_gem(gem)
 gem_line_count = 0
 contents.each do |file|
   gem_line_count += line_count_for_file(file)
 end
 log " LOC: #{gem_line_count}"
 total_line_count += gem_line_count
end
 
log "Total Lines: #{total_line_count}"

So what are your thoughts? Could it be improved even more?

{ 2 comments }

A Retrospective of a Retrospective

Hand filling out a cardYesterday I ran a largish retrospective for about 60 Program Managers, Product Owners, ScrumMasters and Team Leads. Since a couple of people had asked me on Twitter about how I ran it, I wanted to go through a mini-retrospective of it.

Background

In this program, there are about 25 teams working together on a large-scale project. They are following aspects of the SAFe Framework, and yesterday was their PSI planning. Because of some pressures of the program, the teams had already moved the normal Inspect and Adapt session to nearly the end of the next PSI, but I wanted to still run a retrospective. So the challenge was – effectively running a retrospective to collect data and generate insights in one hour.

Framework

I tend to follow the pattern from the excellent Agile Retrospectives: Making Good Teams Great book. The steps are: Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Close the Retrospective. (I’ve blogged about it before)

Setting the Stage

The program had been through a lot of turmoil, and many people have not seen results out of the retrospectives they’ve done previously. So I gave a brief overview of the mindset of a retrospective – namely, focus on things we have control over and can potentially change. That ultimately we own the process that we follow, and it should work for us.

Gathering Data

With a group this size, any form of open data gathering would have been ineffective. In addition, there is a mix of personalities, ranging from extremely vocal to not speaking at all – even if there was a fire. I chose an activity called “Triple Nickels” – split everyone into groups of 5. Each person in the group gets a piece of paper, and has 5 minutes to write down 5 things – complaints, kudos, improvements, etc. They then pass it to the person on their right, who has 5 minutes to build off of whatever is in front of them. All told this took about 25 minutes, and we generated well over 200 pieces of information.

Generating Insights

With being over halfway through with the retrospective at this point, I knew we needed a high impact, rapid way of generating insights. So I put 5 categories on the wall – Things We Did Well, Things We Did Less Well, Things We Need To Change, Things That Are New Ideas, and Kudos. I asked each group to generate up to three cards to place into each category, and that they didn’t have to put a card in a category at all. This took about 15 minutes.

Once the cards were up there, we still needed to understand the impact. So I had a mass dot-voting session. Each person got two dots with a marker they could spend on any card they thought was important, and a star sticker they could put on a card they thought was the most important.

Deciding What To Do

Because this was a program-level retrospective, and we only had one hour, I worked with the leadership team to agree that we would take action – not just a plan, but actually take action – on the top items by the end of the following week. I communicated this to the teams participating, and stressed that it was my reputation on the line to make sure that happened.

Closing the Retrospective

To close the retrospective, I ran a session of ROTI – basically, a chart on the wall with the numbers 0 through 4, with 0 being it wasn’t worth the time invested, and 4 being more value was gotten than the time invested. There were no 0s or 4s, but most hovered in the 2 and 3 categories.

Closing Thoughts

Even though we only had 60 minutes to run the retrospective – and I don’t normally like doing that – the combination of exercises seemed to really work well at getting data. The teams stayed very engaged to their credit, and I had the help of two great coaches – Paul Mahoney and Jared Richardson – to help guide them as well.

The biggest feedback I got was around the Triple Nickels exercise, that it worked well for helping to get information from people that otherwise wouldn’t have spoken up. So I consider that a good win.

Our next steps are a larger Inspect and Adapt workshop with all of the team members – all told probably over 200 people – which will be held in March. I have ideas already for that as well, and will update once that happens!

{ 2 comments }

Influencing Change: The Butter Rule

Deep Fried Butter standOne of the unique things that consultants get is a view of the dysfunctions of lots of organizations. We know which dysfunctions are normal, and which are, well, special. It’s easy to pick out the challenges, because not only are you a fresh set of eyes on the problem, but you are also not integrated into the organization the same way as the employees are.

Amidst all of these wonderous dysfunctions, challenges and problems we uncover, we try to be helpful, and even productive. After all, not only have we seen many of it before, but we’ve helped them all get better (or at least, we hope we did). And, they are paying us lots of money to help them, right?

One of the most powerful statements I’ve read from a book was in Secrets of Consulting by the wonderful Jerry Weinberg. Paraphrasing, he says that, from the outside, you can’t tell the difference between an awful consultant and a great consultant. Both look like they aren’t doing anything, but in one of the cases, the organization is doing great things.

It’s the paradox of consulting – organizations hire you to help solve problems they think they should solve themselves. Weinberg’s Fourth Law of Consulting reminds us that consulting is the art of influencing people at their request. He further goes on to remind us that, if you propose a solution as a consultant, then the client has to admit they have a problem, and that’s a hard thing to do sometimes.

A much easier thing is to create an environment for the client to come to the solution themselves. The challenge is that you can’t just tell the client what problems they have, and then expect them to fix them. After all, they probably knew what many of their problems were ahead of time, and hadn’t fixed them by the time you came in.

Butter in a frying panInstead, use the Butter Rule. Have you ever made a grilled cheese sandwich, pancakes or eggs in a frying pan? I was taught growing up that the first thing you put into the pan is butter (as well as sugar in your tea, and gravy on everything). The butter serves two purposes – first, it tastes good. It adds flavoring to the food itself. But it serves another purpose – it helps the food not stick to where it is at. When the butter is just right, the food glides around the pan with ease. But if you use too much butter, things end up greasy, soggy, and just not good.

Similarly, when we want to get change happening, we have to find a way to prevent the people we want to change from staying stuck where they are. To do that, we look for positives about what they are doing, and use that to draw them towards the change we want.

So, tomorrow, as you walk around your teams, your organization, or your client’s teams, spend some time finding positives. These little nuggets can be footholds into adopting change by showing the team what they are doing well, and helping them build from that to address the issues you have also found. You might find that they don’t stay stuck as long – and that it’s even a bit tastier, too.

{ 2 comments }

Control of Error for Self-Organizing Teams

One of the holy grails of agile software development is the concept of “Self-Organizing teams.” This can be seen in the principles of the Agile Manifesto which says “The best architectures, requirements, and designs emerge from self-organizing teams.”

While much has been said about the misconceptions of self-organizing teams as well as the role of leaders, there is one principle in particular which is vital to the success of a self-organizing team.

To get there, we need to start by defining just what is meant by a self-organizing team. One of my favorite terms comes from the book Facilitating Organization Change: Lessons from Complexity Science. It says:

Self-organization is the tendency of an open system to generate new structures and patterns based on its own internal dynamics. Organization design is not imposed from above or outside; it emerges from the interactions of the agents in the system.

When we attempt to bring change to an organization, we often reach for certain patterns that have worked before. But every team is different, primarily because they are made up of people. Individuals interacting together form certain patterns, which influence the whole of the organization. Likewise, patterns that have emerged previously impact the interactions of individuals. It’s this system of behaviors which create the “culture” of a company.

Cockburn's Communication Effectiveness ChartHowever, as noted in Esther’s article above, you can’t just turn a group of people loose and hope for the best. There are three key factors which influence the placement, shape and power of the emergent organizational patterns:

  1. Container – Sets the bounds for the self-organizing system. It defines the “self” that organizes. However, it is important that the boundary of the container be semi-permeable – there should be some interactions outside of the container
  2. Significant Differences – This determines the value that will come from the created system. For example, if we put all of the developers on one team, and all of the testers on another, the organizational patterns that will emerge will evolve around those containers (see Conway’s Law). But if we include a mix of talents, genders, races, etc, the patterns will emerge differently.
  3. Transforming Exchanges – This is where the real power of self-organization comes into play. This simply refers to the contact the people have with each other. As you can see in Alistair Cockburn’s communication effectiveness diagram above (from his website and his book Agile Software Development: The Cooperative Game) face-to-face communication is going to produce much better patterns that emailing the team.

However, transforming exchanges aren’t just limited to interactions between two people in a team. In fact, it is possible to have a transforming exchange between a person and the very system they are a part of. This notion of the system providing actionable information is a key tenant of Lean Thinking, and one of the important principles of self-organizing teams.

But Lean Systems turn out not to be the only place that understands this. My daughters attend a Montessori school. The other night, we were at a parent education meeting, and one of the topics that came up was “Control of Error“. The idea behind Montessori education is that it is a self-directed learning environment. Therefore, the activities the children do must be designed in a way to provide them feedback about if they are succeeding – in short, it has to be able to show someone who is learning how to do something that they are doing it wrong – without teacher intervention.

Montessori materialsFor example, in the picture to the right, the teacher is demonstrating two “works” which provide this feedback, or control of error. The pink block tower gives feedback by showing that the next block in the stack should be smaller than the last. In the other work – the red rods – The smallest piece fits exactly at the end of the pieces above it, and the length of both pieces equals the next largest.

It’s such a simple concept, but vitally important in our thinking of building teams and organizations. As a manager or leader, you should ask yourself how people learn about how their actions affect the system, the people within it, or the organization. If I’m deciding whether to spend more time optimizing an algorithm, do I have the feedback from the system to know when I should stop (both from a necessary performance perspective, and a ‘You need to do other stuff’ perspective)? Does the team know how often they are getting stuck, or when others need help, without resorting to simply asking everyone all the time? Do the business leaders have the tools necessary to make business decsions based on feedback from the teams – and do the teams understand the impact of those decisions?

Too often we see organizations wanting agility, but maintaining the traditional management thinking. If the best designs truly come from self-organizing teams, then are we giving them the containers, the diversity and the feedback from the systems they need – without relying on the right people always being at the right meeting to hear the right thing?

If you are interested in reading more about these interactions, I’d highly recommend picking up the book Facilitating Organization Change: Lessons from Complexity Science. It goes into the science of Complex Adaptive Systems and how you can tailor your organization to facilitate self-organization – and achieve the culture of agility you strive for.

{ 0 comments }

Burndown chartIt’s Friday afternoon. Team Plaidpants is finishing up their sprint, but trying to understand why they struggled so much to complete their stories. “It really seemed like we had the stars aligned this time, ” said Yvonne, “but somehow those two bugs got in the way. And I have no idea why this story took so long to finish!” The team nodded their head in agreement.

Sarah, the team’s ScrumMaster, got an idea. “Hey team, I’ve read a lot on both Scrum and the principles of Lean. We’re good at story points, but bad at making our commitments. Maybe we can find a way to measure something else about the stories to see what our patterns are.”

The team agreed to spend the next three weeks measuring the Cycle Time of a story – when work started on it, until it was delivered. They also tracked how many times a story was delayed, and if it failed a test or otherwise have to have rework done on it. At the end of the third sprint, Sarah brought the team together.

“Thanks everyone for tracking these stories. I think there’s some interesting data in here that might just help us.” Sarah fired up her laptop and projector, and showed the following table on the wall:

Estimate Cycle Time Rework Count # Delays
0 1 day 0.3 0
1 4.1 days 0.5 2
2 1.7 days 3 0
3 2.6 days 1 1
5 3.4 days 0.4 3
8 4.7 days 5 4

Sarah explained the data. “This table shows the estimates of each of our stories, as well as an average of how long it took us to actually complete the story once we started work on it. It also shows the average number of times we had rework, and the average times a story was delayed.”

John, a lead developer on the team, was confused. “Sarah, you are saying that a one point story actually took longer than a 2, 3 or 5 point story? Are you sure that data is correct? And we had an average of 5 cases of rework for an 8 point story?” Sarah replied, “Yes, John, that’s right. And I think it highlights that while we can get better about getting our smaller stories to acceptance instead of waiting until the end of the sprint, we really need to be concerned about the 8 point stories, becuase it seems like we just don’t know enough about them going into the sprints, which cause more issues than it’s worth.”

The team agreed that for the next three sprints, they wouldn’t allow any 8 point stories into their sprints until they had been split, and that they would drive 1 point stories to completion as soon as they were ready, instead of batching them up at the end of the sprint. They suddenly found themselves hitting their commitments much more consistantly, and found less surprises during the sprint.

Too often, teams focus on the commitment aspect of story points – “Did we hit our number? Where is our velocity at?” instead of focusing on the flow of work itself. But as Team Plaidpants found, sometimes focusing on the flow can lead to better delivery – and a happer, plaid covered team.

{ 4 comments }

The Question Behind the Question

4 question marks in a boxEarly in my career, I worked at a startup where I learned a phrase that has helped drive me to understanding faster in more situations than I can count. The developer (I guess he would be considered a DevOps guy now) was named Dave and I came to him with a question one time. I don’t remember what the original question was, but I clearly remember his reply:

OK, but what’s the question \*behind\* the question?

This has stuck with me for over 10 years. One simple phrase that drives home two key points about communication:

  1. Listening requires paying attention not just to the words, but the intent behind them
  2. The fastest route is often the most direct one

It is similar to a chess game. When you watch two experienced chess players in a game, you will see one of them move. But behind that move is an entire web of actions and consequences they’ve mapped out – not only in their own moves, but in reaction to the moves of their opponent in reaction to their own moves.

But the goal of chess is to capture your opponent’s king. And, your opponent’s goal is to keep you from doing that. In our day to day conversations, we shouldn’t feel the need to hide behind a complex web of conversations to get to our key point. But we will if we don’t trust how the other person will respond to our question.

As an example, imagine if every time a team member brought up a problem he was having, his manager got riled up to want to go fix it. Soon, the team member learns not to directly engage with the manager, but to ask series of questions to find out what needs to happen, without actually triggering the “direct response”.

As coaches, our job is to be constantly scanning the landscape in front of us, paying close attention to the words, body language, and hidden meanings. We can be effective with that using techniques such as the 5 Whys, but sometimes we just need one phrase:

So, I hear what you are saying. But, what’s the question \*behind\* that question?

You might just track down what’s going on a whole lot quicker.

{ 0 comments }