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.

User stories and sandbag dikes

This year on the Canadian prairies we experienced a lot of flooding and residents banded together to support each other - building sandbag dikes to help keep the water out. During this ordeal, I had a small aha moment in comparing user stories to sandbag dikes. User stories and sandbag dikes are similar because:

1. They are both boundary objects. Well constructed dikes keep water out and contain a dry area. Well crafted user stories contain scope and keep additional scope out.

2.  There is no value to the user unless all layers are complete. To build a dike, you need to pile the sandbags on top of each other in layers and also weave in the plastic. Leave a layer out or forget the plastic and the dike is useless to the homeowner. To complete a user story, you need to build all layers or tiers of the system. A new database table doesn't provide any value to the user.

3. Size is important. If you want to protect a home from flooding, the dike only needs to surround the home, not the whole property. In fact, if you build it too big (for example, to protect the house, the shed, and the swing set), there are more potential points of failure, it takes longer to build which increases the risk of the dike not being completed on time, and you could have spent more time building dikes to protect other homes. If your stories are too big (for example, to implement logging in for a site, you build the login w/ password, forgot password, password reset, max login attempts, etc before building other stories), there are more potential points of failure, it takes longer to build which increases the risk of the story not being completed on time, and you could have spent more time completing other stories to increase the value of your project.

4. Priority is important. If you build dikes around the homes that are less likely to be affected by the flood, then when you run out of time it is likely that more homes will be flooded. If you complete lower priority user stories first, then when you run out of money you may not have accomplished the goals of your project.

I don't know, but you probably do.

Sometimes, the best answer to a question is "I don't know, but you probably do". Let me explain...

I occasionally have the opportunity to speak at user groups or to groups of employees to introduce them to agile - what it is, why it is important, how to start, etc. The presentations vary depending on the audience but always end in an open question period to answer any and all questions about agile. I can usually provide an answer to most of the questions, but I try to use various strategies to draw answers from the audience instead of answering each one on my own. Many times, their answers are better or more convincing than my own. If I'm not sure of the answer, I *usually* tell them I don't know but point them to some resources that might help. However... sometimes I forget.

At a recent speaking engagement I was asked a question about how to apply agile principles to address specific operations and maintenance issues. I answered the question, but I'm pretty sure my answer was too vague and largely unhelpful - some useful comment about reducing wip I think ;). So, here is my attempt at answering the question again using both the principles and the knowledge of the group to solve the problem. Of course, that group isn't here, but hopefully this will help anyways (I'll be e-mailing this to them).

"Thanks for the excellent question! I don't know the answer, but you probably do. Yes, it is true that reducing wip will likely help improve your situation, but since I don't at the moment understand the specifics of your problem, let me give you a few ideas to try. You probably have or can start tracking some metrics of how long it takes maintenance and operational issues to be solved. Using this as a baseline, try a few experiments and measure their results. To determine what experiments to try, have regular meetings with your team and ask them a) what has worked well in the past, b) what hasn't worked well and c) what would they recommend. Based on those recommendations, pick one or two experiments to try and then measure the results. Over time, I'd bet that your team will be successful in solving this problem together."

Colour and its relationship to usability

This June I had the priviledge of doing some travelling in Saskatchewan - speaking at both PrairieDevCon and MosoConf. At PrarieDevCon, I was fortunate to have the time to attend a UX session by David Alpert (who will also be presenting at SDEC11 in Winnipeg this fall). I haven't spent a lot of time doing UX research, but his presentation opened my eyes to a few things. One of these is the targetted use of colour to direct the user to what is most important to you (and maybe to them). In the presentation David demonstrated this concept with several examples from live sites where the use of two colours is used to direct the user to certain actions.

As I returned to work the following week, I noticed that a change was made to our internal dashboard at Protegra. A reminders and announcements section was added and highlighted in yellow/green while the rest of the site remained in blue. Everytime I looked at this site and my eyes were drawn to the words highlighted by the use of colour I thought of David's presentation.

 
Here are few other examples that David showed to us to demonstrate how the use of colour could be used to influence user behaviour effectively:

1. Twitter
What are they trying to get you to do?

Sign-Up is highlighted in yellow to attract new users while Search and Sign-in are blue like the rest of the site. Twitter is assuming that if you are already signed up then you are committed to finding the Sign In button on your own.

2. JetBlue
What is important to them?

Fly Now and Find Flights are highlighted in orange and they are using other more subtle UX strategies so that you will know the first bag is free and that they now offer vacation packages.

3. Facebook
What are they trying to influence you to do?

Sign-Up is highlighted in Green for new users, while Log In is smaller and in blue - just like twitter, facebook is assuming if you are already signed up you are committed to finding the Log In button on your own.

David's presentation has peaked my interest and I'll be looking to find other ways to use colour like this on projects (external facing or not) to guide the user to the actions we would like them to take and discourage them from unwanted actions or workflows. Also, as the Dashboard example shows, it isn't just about highlighting buttons - it can also be about highlighting sections of the site.

Thanks David.

You can find more positive and negative examples and other UX strategies in his presentation found on his site - or join us at SDEC11 to hear him present.

Assessing your process - 6 great questions

Recently, I was asked to work with a client to help them improve their process. In some of my other readings I found a list of 6 questions used by Alistair Cockburn in his research to search for the most successful properties of software methodologies. We used his questions to interview the team and found the results to be fascinating and useful. The interviewees took on average 3 hours to answer these 6 questions:

1. Please give me a brief history of the project: timeframes, changes in project size, problem domain, technology used, key events in the life of the project, the general approach.

2. What would you say are the things that worked in the project?

3. What would you say are the things that did not work well?

4. If you were going to start another project, or give advice to someone starting a similar project, what things would you be sure to put in place (recommend)? What are your priorities for those?

5. If you were going to start another project, or give advice to someone starting a similar project, what would you work (recommend) to avoid, or keep from happening?

6. What else?

Pretty simple list - I hope you find these useful as well.