If you did not read part one I suggest you do so prior to reading this post. Part one is based on cases with tangible results and eye witnesses. Part two is based on my experience, informal research, and opinions. My experience is the main source of credibility.
I'll take a guess: If you work or want to work in an agile development environment I bet that when you first heard about it something touched your heart, something seemed “the logical thing to do” and you felt the need to see it happening in practice.
Well, it was like that for me. When I finally realized what agile was I did everything to make it happen in my context.
It is interesting how there are things we know only in theory that speak to our hearts and minds. We sense that they are good, desirable and possible, almost like some kind of instinct. Most of the things that fall into this group now in my professional life have to do with lean software development.
I've been flirting with the concepts of "lean" since 1994 when I was sixteen years old and studied mechanical and architectural design at a school for industrial training, but I have to confess: I forgot about it when it came to software development and ended up starting my career in IT bringing old habits from archaic industrial models to the lives of my poor colleagues.
I woke up when I recently started reading the Poppendiecks, who mapped the concepts to software development, and when I started keeping up with what Brazilian professionals like Luiz Claudio Parzianello / @ lcparzianello (Agile Business Analysis) and Rodrigo Yoshima / @ rodrigoy (product management with Kanban) are doing. I'm very inclined to put all of this into practice - after all, the feeling that there is a lot of wasted effort in our work is strong.
But what does lean have to do with an Agile Business Analyst struggling to become unnecessary? Let’s see.
One of the main subjects of lean production is to eliminate waste. Waste manifests in business processes in many ways. The most common are “inventory” and “handovers”. For our present goal let’s focus on handovers.
The handover occurs when there are intermediaries in the process. Whenever an intermediary intervenes, there is a direct expense and an associated risk.
The expense is the time taken by the communication and to the task itself. The risk resides in the probability of this communication going wrong. Problems in communication can be amplified through the process just like a snow ball, leading to devastating effects.
In the image above, each handover has a cost in time and a risk of bad communication, so, how to know when is it good to have an intermediary? Well, thinking about costs, it doesn't get any worse than when communication is two ways, as in the traditional development process below:
Every little doubt that arises in the development phase has to pay an expensive toll in both time and risk of communication problems.
So... “fire all the intermediaries” should be the name of this post? I don't think so. They (we) exist for a reason. We exist (or should exist) when our aggregate value exceeds our inherent cost in time and risk. It is an ROI calculation.
To illustrate: I remember that once we set up a partitioned activity diagram illustrating a huge chunk of a company’s process covering everything from lead discovery to product installation. The process went through no less than fifteen partitions; after analysis, although many improvements were identified, it was clear that each of the fifteen partitions brought more value than cost or risk, and they were therefore kept.
A frequent misconception in discussions about project methodologies is the fact that we see the world as static. Someone asks "what are the optimal roles in a project like that?" And someone (me included until recently) says, "this this and that."
It happens that the importance of the roles changes as the water goes under the bridge while we work on our products and we should take this into account.
Life is movement. The world is not static.
Are business analysts, who are intermediaries, important in IT projects? The answer is yes, of course, and is conditioned by a "when”.
In my experience, the peak of value of the business analyst in an iterative and incremental project is at the beginning and will decrease as a good team, like the one from the part one is formed.
As seen above, according to Lean, the work at the "B moment" occurs much more efficiently than at the "A moment", but without the business analyst you hardly reach B.
Here’s an analysis of the importance of the business analyst at the “A moment”:
BA's in-box |
BA's outbox |
Blurred enterprise strategy Organizational structure Value chain Business model Thousands of stakeholders Ambiguity Diverging opinions Cultural shocks Conflicting interests Little assertiveness Cynicism and sarcasm A development team |
Product vision Consensus among stakeholders Synthesis Common vocabulary No ambiguity Acceptance criteria Assertiveness Good humor and empathy A great development team |
The table above represents the result of an informal survey I took with developers I have worked with. The question was simple: "Do you think I contribute to the project? In what way?" Think about yourself as a product. It comes in handy to get to know where and when you are important.
This chart is meant to remind us that there are always two products being developed. The first is our solution, what people will use – we hope – to solve some sort of problem. The second is the team and the environment in which this team is working.
As Business Analysts we are expected to have a broader view of what matters for the business. Our goal is not limited to solve the problem at hand, it includes increasing the overall businesses ability to solve problems and the development team, even outsourced, is part of this ability.
Inside Scrum I hear all the time that the Scrum Master has a great deal on building a good team and I think it is true, he or she is one of them, he or she bears the same challenges.
At the beginning of a project in a new environment the Scrum Master is highly demanded. Technical matters such as repositories, environments, integration, deploying, pairing and even code indentation must be defined and put to work in a matter of days. The Scrum Master’s orientation and behavior are fundamental.
Even knowing that those decisions will evolve as the work is done and new options come to the team’s awareness, once working correctly, those issues become relatively less critical than the issues related to the product.
After the first review the matters about “what to do and why we are doing it” become focus because the customer gets involved and this is when the Agile BA assumes his role with the team because it would be unfair to put everything on the Scrum Master’s shoulders.
The same broader view of what’s important for the business will allow the Business Analyst to understand that most of the times it will be better if his involvement fades over time.
It is important to notice that what is fading over time is the business analyst, not business analysis. It keeps happening but at the hands of those close to the problems and at the hands of those close to solutions and now, thanks to the business analyst, close to each other.
About the Author
Claudio Brancher Kerber (@oclaudiobr) is a Brazilian self-entitled Business Analysis enthusiast and has been working with problem domain for software and hardware creation since 1997 focusing on leadership and team empowering.
In 1998 he created with friends the first real state website of Brazil, Aluguel On-line - a success among users who could easily find places to buy, sell or rent - and a financial failure for lack of a simple business model. From there he quit civil engineering and studied business and marketing to understand his failure and is using this and other experiences to help organizations to fill the gaps between their business models and the IT meant to support them.
Claudio is currently working as Agile Business Analyst in the Internet initiatives of Grupo RBS, a major TV, radio and Newspapers player in Brazil. He also speaks in conferences and rides his bicycle in the streets of São Paulo. His website is here.