Sea Star Wars: A lesson in organizational change

Sometimes in order to make a change happen, all you need to do is change the environment.

This summer I witnessed a great example of this in a small but fantastic aquarium in Ucluelet, BC. When you see a sea star in the ocean or at the aquarium, you rarely or if ever see them move. However, the staff at the aquarium instigated a sea star race by changing the environment. They put the feared Morning Sun Star in the same tank with other sea stars including the very large Sunflower Sea Star. Once the other sea stars detected the presence of the Morning Sun Star they all started to move away from it as fast as they could. The sudden reactions and speed of those sea stars was a sight to see – a turtle would have been proud!

If you have analysts, developers, testers and users who don’t communicate very well you can help encourage better communication by changing the environment. Create a co-located space and then have them all work in that space together. The environmental change forces them to acknowledge each other’s presence and begin working together. Instead of “Hey, there’s a dangerous Morning Sun Star in here and I have to run away before it eats me”, you should get reactions like “Hey – there’s a user in here, I guess I’ll show them the changes I’m making to this screen to get some feedback”.


Subscribe to Winnipeg Agilist by Email

Making the undesirable desirable - a lesson from Tom Sawyer

Today's Google home page celebrates the birthday of Mark Twain with images that tell the story of Tom Sawyer convincing his friends to whitewash his fence for him. It is an example of making the undesirable desirable. You can read more about the story on wikipedia and here are some pictures of the story courtesy of google:

Tomorrow an article I wrote on Agile Adoption will be published by InfoQ. One of the strategies and patterns for change in that article is to "make the undesirable desirable". Here is an excerpt from the article:

"A colleague of mine recently experienced some resistance from his team when he asked them to try pair programming. Instead of forcing them to do it, he simply asked ”What would it take to get you to try it?” When they joked that they would gladly try it if they had a big screen TV to use for paired programming, he quickly obliged and the rest was history. The new behaviour became fun – it became desirable."

Although Tom used this strategy for selfish gain, this strategy can also be used to affect positive change in your organization. You can find more strategies and examples useful for your agile adoption in the InfoQ article.

Are we agile yet? Applying fuzzy logic to the manifesto

Some background on logic from my brother who is a math professor:

In Greek logic (the logic of Plato and Aristotle) there are only two truth values. Any statement is either true, or false, but not both. Truth is absolute. This works nicely except for when we say things like:

"This sentence is false" 

If this statement is true, then it is also false, and if it is false, then it is also true, and if it is true, then it is also false - a 'fun' logical circle which causes trouble for Greek logic. This liar's paradox was ignored for about 2500 years. Since sentences are either true or false, then the sentence above obviously isn't a sentence. Case closed.

In the last century, mathematicians started to realize that things were not so simple. A quote from my brother:

"There are contradictions in the laws of physics – We have Einstein’s relativity that explains planetary motion, gravity, all these big things. And we have quantum mechanics that explains subatomic energy and matter, all those tiny things. Unfortunately, they contradict each other in the middle. Because the one requires physical reality to be absolutely smooth and continuous, while the other requires quantum bumps, which are profoundly non-smooth and discontinuous. Right now the laws of physics are both true and false (and by false, I mean true.)"

More common examples of statements that can be both true and false include: "I am young", "I am tall", and of course, "We are agile". Truth becomes fuzzy. The truth of those statements can lie somewhere in between absolutely false and absolutely true depending on who is saying them.

"A newborn is young" = truth value of 100%.
"A 20 year old is young" = truth value of 80%

Thus, fuzzy logic was born. Statements can have a truth value in between true and false.

Now let's apply this to the question "Are we agile yet?" by looking at the four tenants of the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Many of us have read articles or have been in discussion groups where these statements are discussed at length and usually someone tries to apply Greek logic by making statements such as: "Agile has no documentation" and "Agile means no planning". However, the word "over" in the middle implies that fuzzy logic is at work. The manifesto authors are saying that for agile teams truth should be closer to the left than the right. We should focus more of our time on working software and less of our time creating documentation. Planning is still important but responding to change is more important so our plans need to be more flexible. For each statement, we want the left side to be more true than the right - the truth value should be above 50%. Additionally, having a truth value of 100% for any of the statements above can be a dangerous thing. We should stay fuzzy.

So when answering the original question for your team or organization - "Are we agile yet?" - don't expect a checklist of practices to give you the answer. Instead, ask your team this question: "Given the statements above, which direction are we moving?" If you are moving to the left and have committed to staying on the left side of each equation, then you've joined the club - you are agile. Agile is a direction, and that is absolutely true.

My brother Tim's bio: http://www.cmu.ca/facultystaff/trogalsky.html

Agile Adoption - 6 Influence Strategies

The vital behaviours for successful software projects (agile or not) are simply these: a) improve communication by co-locating, b) get access to the customer and c) have short delivery cycles. (Read part 1 of this post here). This is so simple, and yet agile adoption continues to be a big question mark for many people and a track is dedicated to the question at Agile2011. So how can we influence these three behaviours?

The second half of the book “Influencer: The Power to Change Anything” (Patterson, Grenny, Maxfield, McMillan, Switzler) is devoted to the six types of influence strategies you can use to make sure the vital behaviours occur. But first, let’s look at some quotes from the book that describe strategies that we often find ourselves using, but that have been proven to be ineffective:

“When it comes to resistant problems, verbal persuasion rarely works” (No kidding eh?)

“People bet on single-source influence strategies all the time (and fail)”

Understanding that I am a beginner influencer, here is a brief summary of the six influence strategies found in the book with concrete examples of how you can execute these strategies in order to bring about the vital behaviours that will improve the results of your software projects.

1) Make the Undesirable Desirable (Personal Motivation)

If people find the behaviour undesirable then they are not likely to exhibit that behaviour unless you can convince them it is fun. One way to make the behaviour intrinsically satisfying is to turn it into a game. Keeping track of things like velocity and the number of passing tests in a visible area can be a fun way to keep score. As the team has early successes, find fun ways to recognize them for their accomplishments such as completed stories, iterations with decreasing defects and happier customers. One of our teams rings a cow bell when a story is completed and employees cheer when they hear the bell. The team also gives a syphilis stuffed toy to anyone that breaks the build (they can redeem themselves by buying donuts). These are simple ways to make new behaviours fun and desirable.

2) Surpass Your Limits (Personal Ability)

People need to be convinced that they have the ability to make the required changes. Send your team to a hands-on agile training so that they can experience what it is like to work on a project that exhibits these vital behaviours. Make sure that the training is hands-on rather than lecture based. Once the project has started, help your team to gain confidence by starting with short delivery cycles where they are producing working, high quality code (even if only in very small batches). Once the team sees early results they will gain confidence that they can change their approach.

3) Harness Peer Pressures (Social Motivation)

Use peer pressure to your advantage by creating a co-located area. According to one of the studies in the book, “one variable more than any other affected how people behaved: the presences of one more person”. Putting people in a common space with expectations set for the 3 vital behaviours will improve your team’s chances of changing their behaviours. Also, find the opinion leader on your team (the one that has the most respect and influence) and spend a lot of time with that person addressing their concerns. If there are included in the process they will begin to share your ideas with the team and the vital behaviours will occur.

4) Find Strength in Numbers (Social Ability)

We are more likely to be successful when we have a little help from our friends. Create a dedicated team that is responsible for the results and hold the team accountable rather than an individual. Teams that work together are more likely to come up with a plan that will succeed.

5) Design Rewards and Demand Accountability (Structural Motivation)

Any system of rewards can be dangerous. The book is very careful to describe that if the other influence strategies are properly used, rewards need only to be small in order to influence change. A simple strategy would be to create a visual project management board where individuals can move post-its from one column to another as they progress through the steps required to complete each story. Moving a post-it is can symbolize a very small reward that happens during your daily stand-up meetings. Rewards such as the cow bell used above for completed stories can also be simple and effective.

6) Change the Environment (Structural Ability)

Make use of the physical environment to influence the desired change. Create your co-located space so that it encourages people to work together by removing the cubicle walls, office doors, etc. Increase the “propinquity” of your teams and your customers by having them work in the same space. “The best predictor of whether two people will work together is the distance between them.” Additionally, make sure your visual project management board is in a central place and displays some of the common metrics such as velocity, wip limits, and burn down charts. This helps make the invisible visible.

To recap, the Influencer book has some great ideas and strategies on how to influence change. If you are considering how to influence your team to improve their software project results, promote the three key behaviours identified above by using all six influence strategies to make the change inevitable. If your teams are struggling to exhibit the behaviours, consider changing your influence strategies rather than giving up or targeting other behaviours.

Agile Adoption - 3 Vital Behaviours

One of the books on my reading list this year was “Influencer: The Power to Change Anything” (Patterson, Grenny, Maxfield, McMillan, Switzler). As I read it, I was struck by how the ideas in the book can be helpful for guiding an agile adoption.

The book is split into two parts. The first section outlines how any change can be made inevitable by looking for the vital behaviours that will bring about the change. The second section outlines six different types of influence strategies that you must use in order to make those vital behaviours happen. In this post, I’ll just be talking about the first section on vital behaviours.

According to the authors, any change can be made inevitable if you can find the correct set of vital behaviours. For many common problems, these vital behaviours have already been discovered by various research teams. For example, the vital behaviours for losing weight and keeping it off were identified by a U.S. government research project: a) weigh yourself every day, b) eat breakfast every day, and c) exercise with home equipment. A strong marriage can be determined by looking for the following vital behaviours during arguments:  a) statements that communicate shared respect and purpose, and b) taking timeouts when required to halt emotional escalation. The best teachers a) reward positive actions often and b) alternate frequently between teaching and testing.

So what are the vital behaviours for agile adoption? First, let me suggest that agile adoption isn’t the goal at all – rather the goal that we are looking for is to have successful projects. Agile adoption may or may not be required to meet that goal. If then our goal is to have successful projects, has anyone done the research to find the vital behaviours that are part of all successful software projects? Indeed – Alistair Cockburn did significant research into this topic and found three common behaviours amongst all successful teams. He described his findings in a 2006 Agile Toolkit podcast where he said: (starting at about 3:25) “Those that were collocating face to face, short delivery cycles, access to customers were delivering. Those that were following some process very carefully were not delivering.” In an article where he describes his research methods and results he writes that a) they improved their communication by co-locating, b) had access to their customer and c) had short delivery cycles. He also commented in his article that “I ran the seemingly odd hypothesis that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken." Reflecting on my own project history, I find that I agree with his hypothesis. You can read more about his research here. Notice by the way, that all 3 of these behaviours are about shortening the feedback loops.

If you look at Alistair’s work and writing on Crystal Clear, you’ll notice something interesting. These three behaviours are all in included in the 7 properties of Crystal Clear. However, of the 7, only 3 are listed as mandatory and one of the above was not included in the mandatory list. “Easy Access to Expert Users” was excluded (still on the list, but not mandatory) and replaced by “Reflective Improvement” despite his findings and hypothesis. I’ve asked Alistair about this and look forward to his answer – I’ll keep you posted.

Another interesting observation about “Easy Access to Expert Users” is that for external products with external customers, it would be difficult or impossible to have access to those users. It makes sense then that the Lean Startup movement is heavily focused on tools and techniques to find and measure feedback from your external users.

While these 3 vital behaviours may be the ‘key’ behaviours that will help your team be successful, they will also spawn other behaviours to improve your results. For example, in order to have short delivery cycles, you will need to deliver small increments of value which could lead your team towards the practice of user stories. In order to have short delivery cycles and not spend an inordinate amount of time doing manual regression testing for each delivery, your team will likely move towards automated testing. In order to have short delivery cycles and not spend an inordinate amount of time creating deployment packages, your team will likely move towards a continuous deployment practice.

In conclusion, if you are a manager, executive or coach wondering how you can make your teams more successful but have struggled with or without agile techniques, try encouraging and supporting these three vital behaviours as a starting point and then examine the results. Then, use something like reflection workshops to examine the results and start adding, deleting, or modifying practices over time to improve your results. Based on what we know about organizational change management, this iterative approach to process improvement has an increased chance of being successful. If the Influencer book is correct, (and there are lots of examples in the book to indicate it is) then these three behaviours should make a significant impact on your projects.

Read part II of this post to find six possible influence strategies to make these behaviours inevitable.

Some thoughts from day 1 of Agile2010

I started the day with Mary Poppendieck's talk "Leader's Workshop: Making Change Happen and Making it Stick" which was based on the following book: Switch: How to Change things when change is hard. The talk was split into 3 parts. First you need to Motivate the Elephant, then you need to Direct the Rider, and finally you need to Shape the Path.

Mary suggested that in order to Motivate people, you need to treat them like volunteers. You need to treat them like they could leave at any time. A quote from Peter Drucker: "They need, above all, challenge. They need to know the organization's mission; believe in it, they need to see the results". As our table discussed this concept, we were able to easily relate to our own stories of leading youth at church or in boyscouts. I think this would be a great way to be treated and I can see how it would translate into energized and passionate employees. A volunteer team has to be engaged or they will disappear.

The purpose of Directing the Rider is to provide clear direction. One of the ways to do this when change is difficult is to find the bright spot. When you are having trouble implementing a change, look for some small success and then duplicate it. She gave a great example about post-it notes. When 3M first made the post-it notes, they could not sell them. They test marketed them in several locations and they only sold them in one ("the bright spot"). It turns out that the sales rep in Richmond Virginia decided to give them away and once he did everyone wanted one. 3M then followed this model in other locations and now post-it notes are a household item (and a valuable agile tool!). So, to direct the rider in difficult situations, find instances of success and clone it. A book that she references is: Positive Deviance: Influence: The Power to Change Anything"

Finally, she suggests Shaping the Path by looking at the long term and allowing local decision making. You also need to find ways to make the desired change the path of least resistance. "Change will only stick when the path of least resistance is the path of change." IBM's move towards agile was used as an example. Instead of forcing agile, they allowed it to succeed in smaller teams and then sold and promoted those successes. Soon, everyone wanted to do it.

In summary, to encourage change in a team when it is difficult a) treat your team as volunteers b) find the bright spot and clone it and finally c) make the desired change the path of least resistance.

In the afternoon I went to Hacker Chick and Dawn Cannan's hands on presentation "Better Story Testing through Programmer-Tester Pairing". We had fun doing developer/tester pairing of acceptance tests in FitNesse and Java. I learned a few new FitNesse tricks and also that I haven't lost all my dev skills. I played the dev role and our team was the first to complete the assigned task, beating some notable names in the room <cough>Brian Marick</cough>. The session also re-inforced ATDD and gave me some ideas I'd like to incorporate into a future presentation.

Also, I missed Janet Gregory's talk this morning on the Dance of QA in agile, but I managed to talk to her this evening at the mixer. She gave a quick summary of her talk and how she related it to dance. Agile team members need to be like contestants on "So You Think You Can Dance". On the show, hip-hop dancers learn other dance styles like ballet and vice versa. Similarly, agile team members (including QA) need to improve their skills in all of the disciplines in a project team. An interesting thought.

Thanks to everyone - a great first day.

In other news, Bob Payne is now following me. #Stalker.