Events

The role of Agile analysis in Continuous Delivery – Jenny Wong and Danilo Sato

Bridge the gap between analysis and delivery—discover how agile analysts embed with teams, validate assumptions early, and ensure you're building the right thing fast

What is entrega continua(Continuous Delivery – CD)?

That’s how the presentation began!

Following the conversation between the <a title=“Jenny Wong

  • Twitter” href=“http://twitter.com/jenny_wong" target=”_blank">Jenny and the <a title=“Danilo Sato

  • Blog” href=“http://www.dtsato.com/blog/" target=”_blank">Danilo, we saw what would follow, principles of analysis and engineering involved, definitions, and finally principles and activities that can be used and tested to really advance in this practice, advancing our deliveries continuously throughout their days and sprints.

Continuous delivery is a software development strategy that optimizes its delivery process to obtain high-quality software, delivered as quickly as possible.

But, incredibly enough, just like most strategies we’ve read about, we tend to dive deeper and prioritize practices and steps rather than why.

For Danilo, it’s noticeable that the manuals and blogs that talk about CD focus on engineering approaches with technical tips and step-by-step instructions, leaving aside analysis, product, and mainly the value related to delivery.   Firstly, because we need CD, secondly according to Danilo, despite having broken common thinking by working collaboration between analysts and designs, faster iterations, continuous feedback, and other agile aspects, there’s still a lot of work to be done until we really deliver something in production, which makes us take too long to get there.

That’s when CD comes in and accumulates technical aspects; you automate everything, and are you done?

Are we delivering the right thing faster?

It doesn’t matter if we deliver it faster if we’re not working on rapid value growth.

Then CD is not just about delivery; it’s not the goal and should be to deliver the correct thing faster, reduce risks, and really conclude what was started.

Based on this, some principles were presented that need to be considered in the path to Continuous Delivery.

Principles: #1 – Thinking beyond functional software, we have that thinking about the objective, who is the target audience for the software, what are the qualitative criteria that will be considered along the CD process? #2 – Small and incremental steps. #3 – Ongoing product management; we cannot view our work as complete when delivering the product, there are many other processes that advance beyond engineering and product development boundaries.

We need to continue collecting data in subsequent phases like sales numbers from the commercial team and others to know when the product is really concluding. #4 – Planning for functionality retirement in your system; we need to continue analyzing and removing unnecessary functions, it doesn’t make sense to deliver, monitor, and then go back on what’s not desired. #5 – Delivering VALUE is not equal to having something complete, like a feature; evolving can be very precious value for your audience.

How do we make this practical?

Firstly, we were told that we should think in terms of LESS is More, so we need to deliver the smallest subset to deliver smaller blocks (Slicing and Dicing your stories – Danilo and métricas de vaidade).

Secondarily, we need to get out of our buildings and start facing our customers with simple and existing tools to discover what’s desired before really doing it.

This is a way to get feedback and avoid delivering unwanted things.

Thirdly, we need to maintain our backlogs; what’s the essence of each assumption that existed behind each item there?

Manage it and see if something’s being left out might signal something?

Finally, we need to “Prune, not sweep your backlog”.

Fourthly, add a feedback expectation for each functionality, and add it as one, which will prove the functionality is more efficient.

They should not be generic tools like métricas de vaidade, but visible, validable, and representative periods for action and reaction.

Last but not least, a new approach was suggested with less work being done in large packages(BDUF) with epic assumptions without validation, user research, guerrilla testing, testing analysis, and much collaboration.

This way, we’ll have the delivery of a more relevant product that makes sense to what delivering products rapidly should be about – success in continuously delivering what’s desired!

Or learning and getting there as soon as possible!

See the presentation below:

Role of Agile analysis in continuous delivery from Jenny Wong
Note that some placeholders are not replaced with actual English text, but kept exactly as written in the original Portuguese text.