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

A short story about co-location

The post I created yesterday reminded me of this story:

A team I was working on was asked to sit together in a rather cramped area. Five of us (two developers, one application architect, one tester, one business analyst) were asked to share a very small area about the size of a typical office. The business analyst had desk space equivalent to the size of a typical end table; there were monitors perched precariously above us on small shelves; we shared one phone; and the limited wall space we had was covered with our visible boards and stickies. Fun!

As we reflected on our space at the end of the project, this comment was made from one of the developers: "On the bright side, I don't think I looked at the requirements document once. I just turned to the business analyst beside me and asked her what needed to be done!" Co-location for the win.

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" - Agile Manifesto

Strategizing to solve a communication problem

My wife spent part of this past weekend on a leadership retreat. Her team was asked to participate in the following game to help them develop their team strategy and communication skills:

Setup:

• One person acts as a builder.
• One person acts as the architect.
• Two people are observers.
• The builder and architect sit back to back in chairs. The two of them are not allowed to look at each other, but they are allowed to talk.
• The two observers stand on either side and watch and are not allowed to talk or interfere in any way.
• The builder is handed a blank piece of paper and some shapes that have been cut out.
• The architect is handed a drawing where the shapes are already put in place - the blueprint.

Playing the game:

• Round 1
• The architect's job is to have the builder re-create the drawing by putting the shapes in the correct placements on the blank piece of paper. The architect is not allowed to turn around, but is allowed to talk.
• The observers are instructed to watch - no talking or gesturing.
• The builder is also not allowed to turn around but is allowed to talk.
• Time how long it takes for the team to correctly finish replicating the drawing.
• Rounds 2-n
• A rule change: For this and any subsequent rounds the observers are allowed to 'tap in' during the round. That is, when they tap the architect's shoulder they can trade places with the architect who then becomes an observer. You can 'tap in' as many times as you want during the round.
• Before starting the round the team is asked to strategize together on ways that they could improve their communication and their results.
• Once again the team times how long it takes for them to correctly finish replicating the drawing.

The teams enjoyed the challenge of working together to improve their communication strategies. The best solution that any team found was to have the observer 'tap in' whenever the builder put one piece in the correct spot. This strategy enabled the builder to easily understand when they had done something right (improving communication) and helped the team to improve their time. Hurray for the team!

This was a great exercise to promote team building, continuous improvement, strategizing, and to encourage the team to actively work on their communication skills. It reminds of some of the ways I have seen and used to help teams improve communication between roles. Does the developer have a hard time understanding the requirements document? Let's work on our documentation skills to make our writing clearer. Does the team struggle to meet it's project deadlines? Let's increase the project management rigour and status reporting. Are bugs found during user acceptance testing? Let's write a better test plan.

Or... have the architect (customer/business analyst/tester/project manager) turn around and talk to the builder (developer) directly. Break the rules (and your cubicle walls). Shorten the distance.

The role of a business analyst in agile

I ran into Kevin Brennan tonight at #agile2011. I was glad for the chance to talk to him because I've received quite a few questions from BAs in Winnipeg about how their role will change when they work on agile projects and Kevin has been doing a lot of work with the agile extension to IIBA's BABOK.

Here are is a summary of our conversation:

• How many BAs can articulate the goals and objectives of their company, team, or project? Start here if you cannot.
• Even if you are able to articulate the goals and objectives - can your team? Without understanding the project goals and objectives the team doesn't have enough information to help them make decisions about scope and priorities and often makes decisions based on 'Is this helping somebody?' which can increase the scope of the project.
• BAs can help facilitate the alignment of priorities and goals - enabling the business to speak to the development team with one voice.
• Facilitate requirements and a common understanding of the proposed system through inclusive modeling techniques (eg. user story maps, silent brainstorming, product box - see more here)
• Facilitate the acceptance of change (rather than the restriction of it).
• BAs don't do any less analysis, but they will end up doing less documentation. This reminds me of this tweet:
  

  “Documents we write communicate our good thinking. You can write one without thinking. You can communicate good ideas without a document.” – Jeff Patton (Jan. 19, 2011 - twitter)

• As a BA, if you need to create a document, it will more likely be after the story is complete rather than before creating the story. Some additional guidelines for documentation on agile projects can be found here.

Plus, here are a few more that I thought of after our conversation:

• Collaborate with testers who share many of the same concerns about priorities, goals, scope, and requirements.
• One thing that doesn't change is the need to work with the business as any software produced by the team may change the business processes. Even with iterative delivery, there will be adjustments to be made.

If you have others to add or even disagree with some above - please comment or find Kevin or myself during the conference and we'll chat.

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.