Thursday, May 14, 2015

Does one size fit all?

My understanding of what an Agile process should be has always embraced the goal of creating value through software development as early as possible, while giving customers/POs an absolute freedom to change their minds (i.e., requirements) in the certainty that the Agile teams will promptly and appropriately respond to the changes with the occassion of the upcoming sprint planning session.

From the willing to fulfill both principles, it follows that in each sprint an Agile team should invest the maximum effort to deliver end-user,  functional stories; and the minimum effort to make progress in preparing future functional stories by means of technical stories.

However, some technical stories are an inevitable factor in the equation of a software development process, no matter what kind of framework it may be based on. As an example, technical architecture designs, third party software developments, QA techniques, etc. must always find their place in the PI and sprint plans.

But my case today is about those technical stories that come up as a result of the "traditional" mechanisms that usually make up the corporate operation structures; mechanisms such as non-automated procedures to promote the software through the testing environments, with an overall duration that exceeds a sprint time frame.

According to the Agile principles mentioned above, a Scrum team should ideally be able to produce all the software layers involved in any functional story in the course of just one sprint. Still, reality is stubborn, and the team may have to break down that functional story into several technical stories for the inner layers (those transparent for the end-user: back-end, services...) plus a final functional story (the one involving the diverse front-ends), and to plan all those stories in succesive sprints. Obviously, all those constraints limit the capability of the team to optimize their generation of value for their Product Owner.

With this picture in mind, I would tend to believe that the Scrum methodology only fits small organizations, but also hope that SAFe will help us to deal with these restrictions. All in all, probably it's just a matter of eating the elephant a bite at a time! ;)

Friday, May 8, 2015

Your first release? Be prepared!

The Agile Release Train has past for the first time in our organization and we have succeeded in getting aboard on time (so yes!, if you are a BBVA client in Spain, our fantastic new tool to help you keep in touch with your financial advisor will be available on your PC and smartphone very soon, just after a short pilot phase).

Therefore, I can say we were pretty well prepared for all the tasks involved in the release process: we had been able to plan in advance most of those activities, even though we were not very conscious of the detailed degree of coordination required between us and the cross teams (release managers, channel managers, devops, quality engineers...) by the end of the PI. And fortunately such tasks could be carried out by the team during the last sprints of our PI in a wise combination with the incremental addition of new functional features.

In contrast, now we have suddenly found ourselves facing an uncertain future: we can expect (and maybe estimate, but only to some extent) a certain amount of (re)work to be done during this second PI as a result of potential defects; besides, we can also expect some improvements that might come up from the feedback of the early users. But all in all, we cannot either predict or mitigate the final impact of these risks in the final delivery of our current PI.

That's said, I tend to agree that Agile provides you with the most reasonable solution: since the throughput of your team is finite, just add the new stories to the backlog and reprioritize it keeping in mind the value return of each item.

Then, why do I feel less comfortable, less confident than I did at the beginning of the former PI?!!!