BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Day I Became Unnecessary - Part 1

The Day I Became Unnecessary - Part 1

Let's start with a true story:

It is a hot summer Tuesday in 2011. I'm in a meeting room in an office building located at Avenida Paulista, São Paulo, Brazil.

The event, or rather, the ceremony is the review from sprint seven of a Scrum project for a financial institution. In the review the development team presents the result of the last sprint's work (time devoted to developing a defined portion of the system) to costumers. There were eleven people at the table, divided as follows:

Costumer:

  • A project manager (grey)
  • Two experts on legacy systems (grey)
  • Three end-users (who will use the product) (green)

Supplier (us):

  • The Scrum Master (in this case not one of the developers) (grey)
  • Me, Agile BA from the costumer point of view and PO from the technical team point of view (grey)
  • Three developers (the team had six, but as the review was on the costumer's site and we do not have a van, we did not bring the whole team). (red)

The seating was arranged as follows:

The first interesting fact was that the end users (green) and developers (red) sat facing each other without any encouragement from us.

Developers began their presentation, going through the screens that met the customer’s layout standards, performing operations that had been selected at the last planning, when suddenly costumers started asking questions, making comments and the conversation flowed freely. I was just watching.

I noticed that we, "the grays", which used to dominate these meetings, dictate pace and subject matter, were quiet and only opened our mouths when it was really helpful to the discussion.

I also noticed that the vocabulary used by developers was totally business-oriented, there was no need for translation.

Things got really interesting when one end user remembered important requests that were forgotten and therefore out of the scope of the last sprint and consequently out of the approaching release.

We know it happens. All the planning in the world can’t prevent change or new discoveries. The methodologies of project management deal with change in different ways. In the case of Scrum the release may be delayed when something important is discovered late. Of course nobody likes to delay a release so if it is done it should be for the least possible amount of time - a sprint.

The focus of my work as Agile BA / PO is to understand both the business and the system that is being built. Let's say that normally this means me getting my hands dirty with the costumer and end users to find a way to meet the needs in the cheapest way, such as making the most of existing services in the system. What did I do in this case? Very little.

The development team made use of their business knowledge and customers made use of their system knowledge and together they arrived at solutions in record time and very effectively.

We "grays" only gave useful hints here and there and I was in charge of updating the documentation (which seems less and less necessary in such an environment, being useful only for building the user manual and to support the – in this case - unavoidable external QA).

What is most interesting is that we are talking about our seventh sprint and our sprints have ten working days, we are talking about approximately 105 calendar days, a mere three months or so from the beginning of the project.

Leaving aside the fact that we delivered a considerable amount of functionality in less than five months with rigorous architecture and user interaction criteria – and in an outsourcing relationship! - our use of Scrum has delivered another impressive advantage:

In short time we had a team of six developers able to deliver both the technical solution and to understand and act on the problem domain.

I wish I could measure the financial value of this, because besides the golden eggs (running code), we developed the goose that lays the golden eggs (the team).

We arrived at this point based on three pillars. The first pillar is the fact that Scrum recognizes and empowers what I call “the team entity” as its core. The team is responsible for actually delivering the solution to stakeholders in a face to face interaction at the end of every sprint.

These ceremonies shorten distances, diminish prejudices and doubts, and create empathy. Developers and stakeholders start calling each other by their first names (at least here in Brazil) and one day start sitting next to each other at the conference table by pure affinity.

During college as a business administration undergraduate I studied different approaches to assess the performance of professionals and have not found anything as tangible and fair as Scrum. I realized that you don't need more than two sprints to know whether a professional is a “pig”, a “chicken”, or worse.

That leads us to the second pillar, the “team refinement”. As they say “Scrum does not solve problems for you, but it makes them clearly visible”. With daily meetings, division of tasks between the team and the use of work visualization tools like our sprint kanban (a canvas representing work progress and who’s doing what) it becomes very clear and tangible who’s doing a good job and who’s not.

All project teams had a deal with management: If someone was not performing and chatting was not working, he or she would be asked to leave the project. If the same person had problems in the new project he or she would be asked to leave the company.

To dismiss someone from the project did not feel as drastic as to fire someone from the company and a few team members were dismissed. Well, one was fired because he had been dismissed in the previous project. Once there was no tyranny or unilateral decisions the dismissals were justified and required little explanation, even for the dismissed member and tension was replaced by relief.

I had two fronts, the team had to feel free to communicate and even decide who should leave and the costumer had to understand that dismissals, even the ones that made the team smaller than contracted were for the good of the project.

I asked for a vote of confidence from both and practice made clear for us that it is better to be smaller and good than big and lousy.

The third pillar, which is more directly to do with the role of Agile BA / PO is the application of my deliver-value table:

Solution (deliver)

Problem (value)

Developer has the last word

BA has the last word

BA is advisory

Developer is advisory

Technical design

Goals

System

Business

End user

Stakeholders

Non-functional

Functional

How to do it and why do it this way

What to do and why do it

I present this table or variations on my courses and lectures. It serves to clarify that although there is an intermediary between the development team and the business (like a business analyst or product owner), one side should NEVER be alienated from the other.

From the development team point of view the business analyst or the PO is responsible for representing (after investigation) the problem domain; however, the team must always be kept aware and should always be consulted. The development team is responsible for the solution domain; however, the business analyst or PO must always be kept aware and always be consulted.

The magic of iterative work is that this interaction occurs all the time: during the Scrum ceremonies such as plannings, daily meetings and sprint reviews or even in the middle of the sprint.

This makes information about the domains to flow freely in a dynamic process allowing for better decisions. Iteration improves interaction.

I remember that one day in this same project I was at the costumer site when I received a call from a developer consulting me about a technical change in the way we were going to meet a requirement. The conversation lasted two minutes but it served to strengthen our ties, allowed me to learn a better way to solve a problem and generated a healthy consensus that lasted.

In short, we must reduce the barrier between those who think in terms of value and those who think in terms of delivery, even when the responsibilities are well defined.

I spoke about Scrum in this post but the real magic for me in this context (besides agile values) comes from lean software development concepts and in part two of the post I'll present, as a business administration academic, the reasons why those of you who are working as an Agile BA / PO should want to become unnecessary.

The question is: would you dare?

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.

Rate this Article

Adoption
Style

BT