Agile Business Analyst – An Oxymoron?

This post is inspired by an article by Ellen Gottensteiner. Is an “Agile Business Analyst” an oxymoron. Before we answer this question, we first need to understand what “Agile” and “Business Analyst” mean.

“What is Agile?”

Anyone involved in Agile will know that no two people have the same understanding of Agile. Some feel it is defined by the Agile Manifesto. Others feel the Agile Manifesto was simply a “Call to Arms”. Some feel Agile should be solely focused on software development. Others feel it’s principles and practices extend beyond software into business, the home and even apply to law. You can read the manifesto at www.agilemanifesto.com. My personal view is that the first line is the manifesto. “We continue to learn how to do software by DOING it, and helping others do it”. It goes on to give a status report… So far, we have come to value the items on the left more than those on the right. The principle that seems to indicate “The Agile Business Analyst is an Oxymoron” is the “Working Software over Extensive Documentation”. After all, writing extensive documentation is all that a business analyst does. Right?

“What is a business analyst?”

The IIBA defines a business analyst as someone who practices business analysis techniques. The business analyst may have the job title “Project Manager”, “Developer”, “Tea Boy” or even “Business Analyst”. So what are the skills of a business analyst? I’ve interviewed about two hundred business analysts over the past few years. At the start of each interview I tell the candidate my view on the role of a business analyst… “Someone who knows the business well enough to argue with them. Someone who understands technology well enough to know what the developers need, and finally someone will need to be skilled in the business analysis tools to take the ‘vague and fluffy’ statements of the business, and turn them into the precision needed by the developer.” This is not a simple role. You need to be an SME, have a strong knowledge of technology, and have business analysis skills. Some business domains are less demanding and it is possible to learn the domain “on the job”. Other domains demand you know your business knowledge before you start.
When I think of business analysis tools, I mean business modelling (Entity Relationship Modelling, Object Modelling), Use Cases, Storyboards (Screen and Report Mock Ups), and State Transition Diagrams… And the rest.

The value of a Business Analyst.

Originally I was going to write “A good business analyst…”. But that is wrong. Its confusing the job title with the skill set. Its like saying a “good John Smith” or a “bad John Smith”. A business analyst is someone who uses business analysis tools. So, second attempt. A good business analyst adds value in a number of ways.
• Ensure that the project is developing those items of most value to the business.
• Asks the business detailed questions so that they have time to find an answer. These questions will naturally occur during the development. However, waiting for the answer can block development or result in incorrect assumptions. This will allow development “Flow”.
• Help the development team articulate a business case for paying down technical debt.

“What is an Agile Business Analyst – Whence The Business Coach?”

Agile changed the rules. In 2003, Andy Pols (a developer and many other things) and I (a business analyst and a couple of other things) re-evaluated the business analyst role in light of Agile. We started from the assumption that we did not need a business analyst. From there we identified the value they added that we needed to put back into the project. After many cups of coffee, and a few pints of beer, we came up with the “Business Coach” role.
We identified the following significant differences in Agile compared to traditional approaches.
• People no longer operate in silos with clearly defined responsibilities. The project took collective responsibility rather than individuals. The business analyst needed to extract knowledge from the whole project rather than be the “Truth” or an SME.
• Traditional analysis tools like UML produce models which are of little value to the Agile developers. Agile developers wanted to work with tests/examples rather than models.
• Agile developers want to work more closely with the business. It became obvious that the business analyst could no longer act as a gate keeper to the business. The developers needed to speak directly to the business, and to do that they needed detailed business knowledge. The business needed a better understanding on how to work with the development team.
• Knowledge needs to be in the heads of project members rather than in documents. (If you think it’s painful to read thirty nine versions of a forty page functional specification, how painful do you think it is for the person writing it? Ditching extensive documentation to focus on more valuable activities is one of the most liberating experiences in my career as a business analyst.)
In order to address these issues, the Agile Business Analyst needs skills to facilitate collaboration (Collaborative Requirements by Ellen Gottensteiner). They need to know how to generate examples rather than models (Feature Injection by Chris Matts <- Me ). They need knowledge transfer skills so that they can help the business and developers learn the skills they require. (Accelerated Learning by David Meier, Situated Learning by Lave & Wenger, David A. Kolb’s Circle of Learning, Visual-Audio-Kinestetics, Neuro Linguistic Programming).
Given the shift to a more facilitative role focused on team learning, we decided to name the role “Business Coach”.

The Agile Business Analyst is an Oxymoron!

If your view of the Agile Business Analyst is an “order taker”. Someone who simply writes down what the business sponsor/user wants. If you see the business analyst as someone who creates extensive documentation, then an “Agile Business Analyst” is an oxymoron. After all, Agile values “working software over extensive documentation”.

The Agile Business Analyst is NOT an Oxymoron!

I believe the Agile Manifesto is out of date. Many people agree with me. I believe in the principle “Delivering business value OVER Working Software OVER Extensive Documentation”. The Agile Business Analysts can add value so it is not an oxymoron.
The Agile Business Analyst role is evolving. It is responding to the challenges of Agile. Pioneers in Agile Business Analysis like Kent McDonald, Greg Goodman, Ellen Gottensteiner, Joe Little and Ryan Shriver have been developing practices for many years. Agile Business Analysts are adding value on many projects. David Morris is currently leading an initiative to write an Agile extension to the IIBA Business Analysis Body of Knowledge. If you have experience as an Agile Business Analyst, please add your story to the Body of Knowledge.

In the end, it’s all about our definitions. As we cannot agree on a definition of Agile, it’s hard to determine whether the business analyst has a place in it or not. That said, many projects find business analysts to be very valuable. Perhaps practice shows us the theory is flawed?

Sadly there are those involved in the Agile movement whose view of the business analyst has not moved on. They are selling a view that is many years old. They talk about “Bad Business Analysts” not realising that a “Bad Business Analyst” IS an Oxymoron.

Every few years I revisit the Agile Manifesto. These visits allways lead to a deeper respect for the people who wrote it.

This week Pollyanna Pixton said that she finally got that “Agile is Learning”. Personally I think Agile WAS a “Love of Learning.”. Now it appears to be a “Love of selling”. We need to get back to the learning but that is a subject for another post.

The first line of the manifesto is…

“We are uncovering better ways of developing software by doing it and helping others do it.”

It is a manifesto to create a software learning community. In fact, its more than the first line of the Agile Manifesto. IT IS THE AGILE MANIFESTO. A personal commitment to continually strive for better ways to do software development. But not theory, stuff that works on the ground. Stuff that works out in the wild rather than ivory towers or theoretical landscapes.

The rest of the Agile Manifesto is actually a status report…

Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

Pragmatists and experiential learners would never assume perfection or a complete solution that would never evolve. The implicit and missing words are “so far”

So far,through this work we have come to value…

As Alistair Cockburn said to me “The Manifesto is a historical document that should remain unchanged”. And I agree.

However, we can issue new status reports without rewriting the manifesto.

I have one small tweak I would make to the original manifesto. “We are uncovering better ways of developing software by doing it and then helping others do it.” After all, it would be nice if the people who taught this stuff could actually do it.

Chris Matts (Easter 2010)

This post is respectfully dedicated to Luke Hohmann’s friend Martha.

As stated in the “community of thinkers” we believe individuals should never become the bottleneck to learning. To enable others to learn from you even when you are not around it is essential to share the path you have walked.

And when following the path of others, think for yourself and create your own opinion. With all that knowledge and your opinion comes a responsibility. A responsibility to enable others to do what you have done:
Share the shoulders you stand upon!

We are creating a series of posts on who influenced us along the way in many areas. We encourage you to do the same.

Episode 1: Kanban / Lean (published)
Episode 2: Finance / Economics (next week)
Episode 3: Other agile
Episode 4: Motivational / Inspirational
Episode 5: Great people / great conversations
Episode 6: Weird stuff

Dave Snowden has released an excellent video on complexity and children’s parties ( See it here on Andy Pols’s Blog. Dave’s video inspired this piece which is a compliment to Dave and the video. )

I have two small children who live in a party rich area where the preference is to have a party at a venue rather than risk having your house trashed. This means I have had the opportunity to observe parties run by people who do so on a very regular basis.

Rather than a chaotic, ordered or complex system, the parties I’ve observed are a managed mixture of all three.

There is a four part pattern to most parties.

1. Constrained Chaos.
2. Ordered System.
3. Ordered food and ritual.
4. “Unconstrained” Chaos.

Constrained Chaos

Most parties start with constrained chaos. The children are allowed to play chaotically in a constrained environment. Behaviour like hurting others are reactively managed but the environment tends to provide the limits. In the early days this will be a soft play area and in later years an enclosed field for football or a swimming pool. The key to these constrained areas are easily controlled access points as the perceived risk to the system is unauthorised persons gaining access to the children. Within the constraints, the children can play as they chose, it is constrained chaos. This allows the children to arrive at staggered times without affecting play and also expend as much amount of energy as they chose. There are no rules. Attractors (footballs, water pistol) cause flocking (complex) behaviour.

These would be the boundaries that Dave mentions except that they are hard boundaries.

Ordered System

After a period of time a play coordinator will engage the group of children in a structured activity. This activity will generally take the children from a high energy state to a calm state. This could be “pass the parcel”, “pin the tail on the banker”, “stroke a farm animal”, “play with a parachute”, “painting” or “creative making”. What is common to these activities is that they are coordinated requiring all participants to act collaboratively (parachute) or in sequence (“Pass the parcel”, “Pin the tail”, “Stroke the animal”) or in a fixed place (“painting”, “creative making”). The system of children is effectively ordered during this stage.

Ordered Food and Ritual

The play coordinator leads to the children to an eating space where the children eat a party meal. The children are fairly calm at this point following the activity. After the meal, there is the ritual of the birthday cake and the party bags. By now most parents have started to turn up to collect their children.

Constrained/Unconstrained Chaos

At this point, the play coordinators release the children into the constrained soft play area or to run around a space. After the children have eaten food, it is in interest of the parent to arrive on time to prevent the child running around too much so that they do not up-chuck on the back seat of the new Chelsea Tractor. This means most parents turn up just before the end of the party and make sure energy levels do not rise too high.

I think the parties I observed are different to the Parties Dave mentions in the video.  I think Dave is referring to house parties that a parent organises themselves rather than a Party venue. The difference between the two is that Party Venues have a lot of (Tacit) knowledge about how to structure parties whereas a parent runs a few one-shot experiments. The first few Party Venue parties run were probably experimental, but it is likely the owner studied other venues first. After a while, a pattern for successful parties emerges. Party venues start by creating complex systems using constraints and attractors. They then create ordered systems using strict rules and rituals. Finally, they train parents to turn up on time. Parties are ordered chaos or chaordic systems.

Limits, Boundaries and Constraints

I am unfamiliar with the precise definition of the technical term Boundaries that Dave uses. His use indicates to me that soft boundaries are what I call limits and hard boundaries are what I call constraints.

After Agile 2009 I was lucky enough to spend a morning with Mike Sutton and Lasse Koskela on a Segway Tour of Chicago. The first few minutes of the tour involve training which included for me finding out the limits of the system. I got to feel what the limits felt like and how the Segway behaved if I pushed past the limits. The behaviour of the system changed but in a predictable way. The behaviour on both sides of the limits was different. Not only that, there was a gradual change. As another example, consider a speed limit. Stay below the limit and you’ll never see much of the speed limit system. Go above the limit and the system sends you fines (if you are caught). However the you are not prevented from going above the limit which may be necessary in certain situations.

I went to visit Ola Ellnestam in Stockholm. My bank balance had dropped below my limit and LloydsTSB refused to allow me access to any cash. It was a constraint rather than a limit. There was a hard transition between the two states.

Limits are things we can chose to ignore although the behaviour of the system changes. Constraints are imposed upon us and we have no choice.

Party venues use a mixture of limits (soft boundaries) and constraints (hard boundaries).

I tend to think of limits as rules which may be abided by and constraints as imposed regardless. I am aware that my thinking is not too clear in this space.

An interesting area of thought is the affect of time on limits and constraints. Not just time, but also learning which is what we really mean by time.

Happy Noo Yar

Chris

This blog is Uncopyrighted. We the authors, Olav Maassen and Chris Matts, believe information should be free and have therefor released all claims on copyright and have put all the content of this blog into the public domain.

No permission is needed to copy, distribute, or modify the content of this site.

Terms and Conditions for Copying, Distribution and Modification

0. Do whatever you like.

Credit and payment

While you are under no obligation to do so, we would appreciate it if you give us credit for any work of us that you use, and ideally, link back to the original. If you feel like spreading a copy of this content you may do so without payment.

Inspired by Leo Babauta of zenhabits.

This is the start of the real options blog by Chris Matts and Olav Maassen. This is where we will post anything we think relevant to the field of real options.

We’ll start with three comics Chris drew on the tube to explain several complicated aspects of real options.

Short intro to Real Options

Financial Options (This one is big)

Last Responsible Moments