When we will get rid of Agile!

A short break within the Product Owners team posts thread.

It’s December 2012. Finally!

It has been since the beginning of the year that dozens of TV channels and magazines are filling up shows and pages with THE expected event this month.

Yes, exactly: next week December 21^st will mark the completion of the Great Mayan Cycle and the beginning of a New World Age.

I’ve been told by some people recently: “We’re not going to hear about Agile any more in 3 years from now!”

I tend to agree with this. We’re definitely not gonna use the scientific approach anymore and then will not be Agile any more.

The question is: When?

Once a New World Age will come. 

At that time major and maybe catastrophic events will have happened and the following 3 things will have changed profoundly:

1. The nature of SW development
2. The nature of human beings
3. The nature of organizations

1. SW development will not be a dynamic complex system anymore. Software will not be an intangible artifact and developing SW will not be a collaborative activity anymore, because only one person will be able to solve tough problems fast. Finally SW development will not be heuristic, because we will repeat solving the same problems over and over and build same programs the same way.
2. Human beings will change and our brain will become a simple linear processor. People will stop being driven by feelings, thoughts, emotions and beliefs and become perfectly predictable and rational beings.
3. Organizations will stop working as living systems and being complex dynamic networks of brains. BTW, brains will be flat and simple by that time and managers will be able to model their organizations like simple machines, where everything goes exactly as planned and no change in business or environment can ever happen.

This dreaming new era will definitely carry sheltered days, where all complexities are removed and future can be forecast.

I do not have a prophecy about when this will happen exactly, but until then I’m afraid we have no chance.

Complexity calls for complexity: we all would like things to be easier and schedulable. Meanwhile an empirical process control is the only way I know to handle creative work and dominate the chaos coming from a continuously changing environment.

Sorry!

Let’s see what happens with Mayan Prophecy in the meantime.

And if we will still be here, have a restful Christmas holiday and a great New Year!

How to build a big product in a collaborative way – 2

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.