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.

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."