Agilidade: Como vemos

Hi,

today's post is a little bit different from the conventional. Still talking about Agile, I tried to summarize the vision that we (people working with Scrum) have about agile development. In advance, I already say that I don't have only one answer, but I came with several opinions that may clarify our agility's concept.

But how? Well, for two days I took between 5 and 10 minutes to an informal chat with friends of GPE. I prepared a question guide to supporting me in this conversation about agility, while I tried to capture the overview of each one.

So, let's go!

When I questioned what would agility means, I heard opinions about the team's ability to self-organize; quick response to changes; not wasting time on rework; and continuous delivery.

The self-organizing team defends the absence of the manager defining what to do and how to do, relying these decisions to the whole.

The other concepts are closely linked, since the continuous delivery with short releases allows the customer to see the product evolution and what needs to be fixed. Thus, the team will be quickly responding to the changes and avoiding rework.

Among the main benefits in agility, stands out the customer proximity; the planning at the beginning of each iteration; and the transparency.

The first benefit is associated to the customer satisfaction. Is possible to the customer to monitor the progress of the software on each iteration. The second one demonstrates that the development team feels comfortable to do their job while having well-defined items to be developed by the end of the Sprint. And the third benefit emphasizes the significant aspects of the process should be visible to everyone.

None of the friends would like to return to work without any agility or agile practice. Likewise, they don't want a project manager, with the exception of a single answer that miss the role of a team leader. A leader has different characteristics and responsibilities than a manager, but this is a subject for other post! Follow us and soon you'll see this topic returning! 🙂

During the conversation I also tried to identify points that can be improved. One point that came up was the documentation. This point can be seen by different ways, because it depends the characteristics of the project. For a small project, a small documentation or nonexistent may be sufficient. But for other projects there are complex business rules that require such documentation. I believe this point can be solved by including some documentation tasks in the definition of prepared item backlog.

I noticed another point that can be improved: the high amount of meetings at each iteration: Review, Planning 1, Retrospective, Planning 2. These meetings, presents in Scrum, has its purpose and can be adapted according to each project, afterall Scrum is a constant adaptation! In the project I currently work, there was a time our Planning 2 was being very unproductive. We decided to change, taking more time to Planning 1, and to write the descriptions of the backlog items much more detailed. This change improved the planning of our items and made our Planning 2 shorter.

Well, we reached the end of the post. Finally, I summarize the points that stood out in the following image.