Riccardo Viviani - 20 March, 2019 - 7 ’ read

Agile software development: the retrospective.

Agile LeSS, Agile Software Development, R&D

You know, Agile is for brave people.

You can tell by one of its core, foundational principles: challenge the status quo.

If you want your development team to use Agile successfully, you must always be true to this principle, even when it means making radical changes to a working system that has been in place for years, as happened to the Imagicle R&D team.

I’m telling you this because, as Scrum became mainstream, many teams adopted the Agile system without the principles, thus turning it into a rigid framework which – instead of simplifying the software development process – makes it complex and dispersive.

In this post, I’m going to share my experience as Imagicle Scrum Master, showing you how to leverage your strengths to maximize productivity and turn software development into an efficient, enriching (and fun!) process.

Agile Retrospective: inspect, correct, adapt.

First things first. Let’s start from the most crucial stage in the entire development process: the retrospective.

Back in 2014, when we introduced Agicle – our interpretation of Agile framework inspired to Scrum – the Imagicle development team consisted of less than ten developers, distributed into Viareggio, Treviso, and Magenta’s branches.

We’ve been working as independent teams for about 80 sprints, until, in the last two years and for more than 40 sprints, we started working as a single cross-site team.

(By the way, for those of you unfamiliar with the subject, a sprint or iteration is the basic unit of development in Scrum – a short time-boxed period when a scrum team works to complete a set amount of work; most commonly has a duration of two weeks).

Agile software development: the retrospective.

Now, as anticipated, one of the events that define the Scrum framework is the retrospective, a meeting held at the end of every iteration to identify what is working and not working in your process. During this phase, the team meets to reflect on how the sprint went: it’s an opportunity to identify problems in the process and determine how to address them, but, above all, to establish what worked out fine and should be incorporated in the process.

After 5 years of Agicle, it’s time for a general retrospective on the working method.

This time it’s not going to be the usual end-of-sprint meeting, but an in-depth retrospective with the aim of revising our development methodology and improve it to keep up with the growth of the development team and the new challenges.

Many good things have been done, others need adjustment; some must be removed.

MAD, SAD, GLAD is one of the possible models for driving the retrospective: each team member contributes to the discussion indicating what, in his opinion, was good and should be maintained, what needs to be improved and what went wrong and should be avoided.

The issues raised are then grouped into common themes, and the team considers possible actions to meaningfully investing in continuous improvement.

GLAD.

I like to start on the positive side (and I suggest you do the same; as they say, well begun is half done!).

In 5 years of Agicle, the good things have been many, starting from the adoption of the Test Driven Development practice (TDD).

We will further discuss the benefits of TDD in terms of code quality, class design, level of abstraction and modularity in another post on Agile; for now, suffice it to say that the adoption of the TDD allowed us to follow the Agile principle according to which you must be able to rapidly iterate and get fast feedback from the code. Moreover, the widespread and regular practice of TDD allowed us to increase the quality of our products not only in terms of external quality (ie that perceived by users, which translates into a drastic reduction in the number of bugs) but, most importantly, the internal one, which takes the form of greater maintainability of the code, simplicity in adding new features and less hesitation in modifying a code that “already works”.

We began by writing isolated unit tests for individual classes and individual components; then we learned how to write integration tests and finally E2E tests.

Today, we can count on over 100,000 tests performed at each change of the code base to guarantee the quality of the product.

The integration process, which could take up to a month to complete, is now automated thanks to our continuous integration system, which produces a new software release every time the source is changed, after passing all the tests.

Consequently, every two weeks, at the end of each sprint, we have a new version of the software that represents an improvement compared to the previous one, and, once the review is over, it is “potentially shippable“.

This allows us to stick to another important implication of the Agile method: deliver working software frequently. Your tasks need to be completely production ready by the time they are checked in, and, potentially, you must be prepared to release the product at any moment.

Finally, here is one more thing you need to implement if you want to fully exploit and optimize the potential of the development team: pair programming.

Pair programming has also enabled us to spread knowledge about product segments that were previously “treated” by individual “specialists”, going towards a model of collective ownership of the code that actually allows us to play as a team, rather than as individuals.

SAD.

Of course, there are things that have to be improved: some Scrum events have been interpreted too lightly, while others have been given too much weight.

In particular, we have given too much space to refinement sessions, decomposing each story or each bug into individual tasks, sometimes even analyzing the source code. As the team grew, this process became increasingly long and complex, ending up taking time away from activities. Also, his overzealousness sometimes would prevent us from having enough analyzed and estimated items to make sprint planning useful.

In fact, we used to put the ready items into work, but often it happened that during the sprint the operation ended, so the following ones were fished from the backlog basing on their business value, but without any actual planning.

This made it difficult and unclear for stakeholders to understand what the development team was working on, thus affecting the transparency of the process.

Besides, we’d definitely overloaded the review phase: for each item we’d check the entire set of acceptance criteria with the Product Owner (PO), which, in addition to making the event long and tedious, left out all non-technical stakeholders, ie the most interested in knowing the new features rather than verifying their correct functioning.

MAD.

Now read carefully, guys.

I’m going to share with you a couple of things you must really avoid if you want to optimize your Agile team and not wasting your energy (we’ve learned them from experience, but perhaps, by reading this, you can take the shortest route!).

The Product Owner is a single human being. Get over it.

The PO’s job is to articulate and convey the product vision and mission, relative priorities, and the customer’s voice.

In our experience, in order to allow the teams to “focus on development”, the product owner has been overburden with responsibilities. He not only had the task of gathering the needs of the stakeholders and prioritizing them in the backlog, but also of describing the user stories and the acceptance criteria. This, combined the high level of accuracy in analyzing the stories, contributed to having few items ready for processing and overloaded the PO work.

Collective ownership.

In many cases, sub-teams happened to form to focus on a single class of the application.

Over time, we realized that this was not only ineffective, but also risky (what if that person leaves?).

Plus, the presence of additional teams requiring synchronization among the activities would make the task prioritization difficult.

In fact, the more complexity you introduce, the more stressful and time-consuming it will be to push changes effectively and coordinate efforts. Remember, Dr. Agile prescribes simplicity.

Take action.

The Ninth Agile principle outlined in the Agile Manifesto states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.

Well, at the end of this great retrospective, we drew our conclusions to adjusts our behavior.

So, what worked out fine was the widespread practices of TDD and pair programming, which allow us to endorse collective ownership, quality, reliability, speed, and streamlined processes.

While what didn’t work was primarily:

exceedingly time-consuming refinement and review phases (also due to the fast growth of the team, which, in 5 years, has more than doubled);
an unreasonable workload for the Product Owner.

So, here comes the most important question: what actions can we take to improve our process going forward?

Of course, everyone can give a different answer depending on the issues raised and the structure of his team.

For us, the answer was, in a nutshell, do more with LeSS.

In the next post, we’ll tell you more about the Large Scale Scrum (LeSS), a framework for Scrum scaling, lean and agile development to big product groups.

And before saying goodbye, a little advice based on the Imagicle experience.

If you see that some Agile practices start to be…”not very agile”, don’t get rid of them. Put them into question. Change, adapt, do Empirical Process Control. Remember that a well-done retrospective is not only a goal; it can also be a great starting point.

Above all, always try to keep the principles in mind.

They don’t have to be dogmatic, but they can be truly inspiring.

So what are you waiting for?

Take action!

(And if you need any advice, drop us a line below!)

#stayimagicle