Multi-Track Agile with TTA

Building digital products are hard. There are many important and difficult disciplines that need to be cover in order to have a proper product. First of all, you need to have a product that people love(YC definition) and not only get the PMF(Product-Market-FIT) but also have proper engineering behind it. Digital products are very fresh and new compared with traditional software and projects. Since digital products are software, there is a push for delivery. Always was and always will be, which is fine don't get me wrong, however we often get half or even 1/10 of the picture. It's not only about software delivery but making sure we are building the right product and above all make sure we have customer impact with the right outcomes.

Why Multi-Track Agile?

Single Track Agile(Scrum) does not work anymore. We need more. As you put completely different things like(Delivery and Discovery) on the same sprint, bad things happen. Most of the companies have engineering running with agile and product running with something else. Even if you add these 2 concerns together, often delivery eats all the things. Naturally, we prioritize delivery since is what people think is what pays everybody salary. However, delivery is one element, there are others. Lean stands for thinking about the whole system. Often we see the tree and fail to see the forest.

As a native Brazillian, I like football. In a football team, there is the defense, midfielders, and offense, there is the goalkeeper, the coach, there are a structure and functions. At the end of the day players and the coach is what matter most but there is a HUGE supporting staff behind it. Why in Tech we think we don't need a support staff? So High-performance sports teams like football and basketball have awesome support staff but hold on for tech we should just have developers?

Single-Track agile it's about the team. We need a bigger team, more specialization and different roles like UX, BA, Architects. Agiles does not mention anything about these roles and it should not mention because agile is about principles and values not about process.  However, we need to have a better way to deal with Discovery

The Discovery Track

What should we do on the discovery Track?

1. Make sure we are building the right product
2. Make sure we are tackling the right personas
3. Make sure we will add VALUE and have an IMPACT on customers
4. Make sure we have a WOW customer experience
5. Run Experiments to DISCARD(Ideas and Features).
6. Run continuously, not only 2 weeks before the "project" begins.

The big issue here is that people still are too much into the *project mindset* and just focused on Output(Get X Features by Y Date in Z cost). Projects fail all the time. However, people still don't important about experiments. Several other approaches and movements like Lean Startup, Lean UX, DTA, Modern Agile are all about experiments. There is no innovation without failure. There is no discovery without failure. You need to be able to DISCARD feature(User Stories) otherwise we are just building a feature for sake of building features. Dropping features is part of the prioritization and learning process to build a successful digital product.

Why do we need Architects here? First of all, architecture is all about requirements and the discovery track is a good place to get the requirements on the source and also to make sure we are doing proper due diligence on feasibility, which means: could we build this? do we have all the software components in place? if not we can discard it or get head on the infrastructure side for instance.

When TTA was born? 

I created TTA. Basically, I was working a lot in Silicon Valley from 2015 to 2018. I basically mixed 2 silicon valley movements with previous values I already had in sense of (Agile, Lean, DevOps, SOA).  The first part is the DTA(Dual Track Agile), created by the silicon valley product group in 2012. The second if the silicon valley engineering organizations/culture. When you have scale the problems are different. So companies like Amazon, Netflix, Uber, Lyft, Facebook, LinkedIn had to build the infrastructures, tools, and services in order to scale and make their product engineers more focused and productive.

Engineering organization is a great pattern, however, no everybody has problems and money to have a huge organization with VP and the same size as a product organization. Not everyone was silicon valley problems. However everybody needs to be productive, and even on a smaller scale, there is a need for platforms for deployments, observability, stress test, and chaos engineering, A/B Testing, rinning databases, tools for developers to be more focused on the business. Having said that, that's where I glue the 2 things together: DTA + Engineering Orgs == TTA(Three Track Agile).

TTA has no PO! PO is composed by (BA + UX + Architect) these 3 people working together make a single PO. We also learn from experiments instead of having a HIPPO calling all the shots.

A goto Philosophy not a descriptive process

TTA has 3 tracks. Foundation, Discovery, and Delivery. Foundation is all about architecture, engineering for self-service services, tools, and platforms. Discovery is all about the product, innovation, and experiments. Finally, delivery is all about building things the right way with tests, proper software design, proper database automation, code review, design review and so on and on.

TTA is not a descriptive process, it's more like a goto philosophy. You can do TTA alongside with Agile, Lean, Kanban, DevOps, SOA. TTA requires discipline and attention to the execution. TTA is not a waterfall process. Why TTA is not waterfall?

1. I don't assume You need to finish all foundation and discovery in order to have stuff in production.
2. There is a retrofit between foundation, discovery, and delivery.
3. I don't assume once you finish discovery you can do the delivery, discovery is never done, as long as you have a product you will have changes and you will have foundation, discovery, and delivery.
4. Tracks are like threads, they run in parallel.
5.  Architects are close to the business and discover problems early and often avoid bad surprises for the delivery track.

NoEstimates, Variation, and NoProjects 

Digital Products require #NoEstimate and #NoProjects since having long term detail planing does not make things become real. Projects are incompatible with products because products never end and projects have an end. Variation is something every manager and a non-tech person needs to understand. It's an old lean concept which basically says that there are things we don't control and this thing will affect our output.

I can know a road very well, drive there every single day and still have zero control and chance to predict when it will have a car crash and the whole road might be blocked for hours. People have wrong expectations about delivery speed thinking they are linear and in fact, they are not linear. Why? Because of the variation.

When TTA Do not Work?

TTA some issues like:

1. IF you don't have discipline - TTA won't work for you.
2. TTA requirest a medium / Large size engagement it's not something a 3 month APP work.
3. If you are not willing, to be honest, and change your mindsets/values and strategy TTA is not for you. But now I have other bad news for you: Agile, Lean, OKRs also won't work :-)

The Hard thing about hard things: Antibodies & Silos

At the end of the day, TTA requires people. Several people believe enterprise companies will never innovate because they cannot change the culture because of Silos and management culture.  Management has power structures, what are your goals? Build an empire and have 300 people under you or build kick-ass digital products? What's the more important structure or innovation?

As time pass, a company creates several anti-bodies (often managers) which does not let the change happen because they protect and keep the current status quo.  What worked before won't work anymore. Everybody is looking for digital transformation but we need a bigger transformation actually. Are we leading the right way? Or do we still have old mindsets and old values that don't work anymore? Let it go is hard but is the only way.

Cheers,
Diego Pacheco

Popular posts from this blog

Java Agents

Manage Work not People

HMAC in Java