Agile value delivery with Outcomes

Agile value delivery with Outcomes

Admin aaWednesday, March 18, 2020

Agile is +20 years old. Most of the companies did not get it. I'm glad to see the several new UX movements are getting it and are producing some amazing books, not limited to UX but in the helm of digital products and discovery like: Sense & Respond, Outcomes Over Output, The Hard Things about Hard Things and Traction. I read all these books and really recommend you read it too. So the big fight that agile started and Digital Products / Discovery carry on is, stop focusing in Features make sure you understand your customer and deliver real value. Deliver value is not easy and still something everybody talks but feel know how to do it. The difference between a successful startup and a failed one is the ability to execute well knowing their customer and making products they love. I made some previous posts in regards to other forms of value I recommend you check it out here and here. In order to deliver the value, we need to focus on outcomes and stop focusing on output(features). There is a good relationship between OKRs and Outcomes. Output has a strong relation with project culture and Management 1.0 which does not make sense in the digital world any longer.

What Matters?

Tasks dont matter. Users don't care about tasks. However, management still plans and thinks just in sense of outputs(tasks).  At the end of the day, there are few things that matter but we could consider for the business that what matter most is: 

1. Increase in Revenue

2. Decrease Cost

3. Increase new Businesses 

4. Increase Market Share

5. Increase Revenue from the existing customer base

Easily you could see like 2 things. Increase revenue and reduce costs. Focus only on reducing costs could easily create the wrong culture and deliver poor results. So ideally we should focus on increasing revenue with means Impact. Outcomes lead to impact. So the business impact is what matters most.  

Outcome and why they matter? 

Outcomes matter because it unlocks ways to RE-INVENT the business and deliver better and more innovative results. Even if you team is agile, most organizations are not agile and are super hierarchical. So it's super important that things start the right way.

So what are Outcomes? Outcome is a change in human behavior(final user or employee) that drives business results. Outcomes are things that people do that are observable and measurable. Why focus on outcomes now? Like I said before agile is saying a similar message for +20 years, building features does not work anymore. Look Lean Startup movement. Let's see a sample:

Impact: Reduce Costs

Outcome: Reduce the number of support calls

Output: Improve user usability on complicated features.

Using this Outcome formula we can do much better discovery planning sessions and roadmaps. Using outcomes make us focus and think on ideas and experiments to improve user experience. So Outcomes have a perfect marriage with Lean UX and Product Discovery discipline.

Relationship with OKRs

When working with OKR you want your objective to be Inspirational. However, a great practice is to use Outcomes as Key Results in OKRs. You can achieve better key results by asking the question: "What user behavior has this initiative created that drives business results?". This question is so so important because it moves us away from features(output) and makes us close to value delivery questions and experimentation.

One of the biggest OKR issues is that you can cheat! Easily you could shape your OLD KPI goals and tasks in an OKR language and format. OKR is not only about comunication dont be fooled by OKR nice communication what matters is drive business initiatives that create impact.

OKR's main goal is to make you THINK about your goals and have goals in an agile fashion. If you are not thinking hard about your goals and think in a set of experiments to improve things be careful OKRs might not drive the results you want.

Outcomes enhance OKRs and help OKRs happens in the right way. How that happens? Consider OKRs Key results and Outcomes, in other words, what user behavior change or employee behavior change that needs to happens to drive business results.

Outcome-based Roadmaps

Finally, when doing discovery we need to get away from features and tasks. We need to avoid the Management 1.0 trap.  One way to do it so is focusing on Outcome-based roadmaps instead of feature-based roadmaps. Feature-based roadmaps result in fixed price/scope projects, waste, low tech solutions, and poor user experience. In other words, Fiction, guess, Lies and other incidents.

It's important to plan a roadmap based on user journey using methods like *impact-mapping* or *outcomes-mapping*. Planning based on outputs limits team agility. In order to-do, outcome-based roadmaps you need to have a list of questions, possible will become discovery experiments, themes, and outcomes instead of a feature list. Outcome-based thinking is one of the keys to true digital transformation. You need to think that everything is an experiment and your colleagues and customers are outcomes as well.

Cheers,
Diego Pacheco

Multi-Track Agile with TTA

Multi-Track Agile with TTA

Admin aaSaturday, February 22, 2020

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

Modern Digital Products & #NoProjects

Modern Digital Products & #NoProjects

Admin aaTuesday, February 11, 2020

#NoProjects is an interesting movement driven by Allan Kelly. I follow Allan since 2015, I really like books. As humans, we tend just to add things up and we forget to remove, re-visit, re-cycle and re-think our values and mindsets. Effective Learning is also about unlearning. Project Myopia is a very interesting book on the matter. Projects are in the center of our universe, however, our universe should be customer-centric, product first and innovation-driven. It took me some time to realize how projects can be incompatible with digital products. Software is hard, products are even harder. Agile is all about Value, however, the IT Industry and digital product companies often have issues to define, measure and understand the value. Understanding and Seeking for value is really key to deliver better products and avoid waste(Lean).

Dead or Alive Products

One of the very first things that Allan points out in his book(Project Myopia) is that there is a correlation between downloads and changes. Downloads are less critical than organic growth and customer satisfaction; however, there is an exciting connection. Dead software often has no downloads. Dead software means what? This usually means ZERO maintainers or ZERO changes. As an Architect, the first thing I look at an open-source library to use in any language like (Java, Scala, Go, or Rust) is to check is the library/framework is ALIVE. All these ideas bring us to two central questions, whats DEAD product means, what ALIVE product means?

DEAD SOFTWARE

* Done: Project is delivered, and no future projects are going on.
* No More Updates: Software stop changing, so no improvements, no new features.
* No More Maintainers: People stop working on the software since there is no project.
* No More PRs: Since people dont use it, no one wants to contribute.
* No More Investment: Since there are no users, there is no money to invest.
* No More Changes: ZERO changes, is the DEATH of the product.
* No More Downloads: No Download means no new users.
* No More Users: No more users means losing users until complete DEATH.

ALIVE SOFTWARE

* Never Done: Always changing. No End.
* Always has updated: Never DONE.
* Has several maintainers / several companies/people involved: Since the product is alive, people want to be part of it.
* Has several PRs per week/month
* Has the constant investment
* Has changes in production every day
* Has Downloads everyday
* Has new users and retains user base

I think you get the picture. DEAD means-end othe line, no want wants DEAD. People won't relate to LIVE things. So products need to ALIVE and chaching all the time.  So, in other words, even if you use PROJECTS, you dont want to projects END; you want one project that leads to another project and so on and on... This is so true, and it's completely wrong on the project mindset because projects have an END, and we dont want and END. Estimations have a relation on this matter, I recommend you read my latest post on #NoEstimates.

Project Lies and other incidents

It could be a Guns 'n Roses Album :D

So Projects need to have an END. Projects also require setup, project setup is super expensive, we need to do the following activities(not limited by and a super simple view):

* Marketing - Make sure people know your brand and what work with you. Product Branding and Engineering branding are completely different things.
* Hiring: Hiring is not cheap and not easy. You need to evaluate candidates in the sense of Cultural FIT, Attitudes, Skills, Apply Tech test, Review Tech knowledge, and is at least a 2-week long process per person.
* Train the team: not only in Agile, Lean, Devops principles but also in tech like Cloud, Languages, Frameworks, Databases, etc...
* Tune your team up: Make your teamwork well and deliver value constantly

When you managed to get all these parts done and working well, what you do? Well, you kill this project and start over. This makes sense for you? Projects also consider a success when you deliver on SCOPE, TIME, and BUDGET. First of all, this is very old, bridge-based, PMI concepts that dont apply to our current world anymore. I recommend you also read this post. Multiple projects also limit our pursuit of value. Because we are limited to think we need to finish one project before starting another, and if we consider the backlog flat, we could actually get all high priority items and work on the first and if we fail but do not use all money? Did we fail, or did we succeed? We fail considering traditional project definitions. Due to modern product discovery concepts, we actually succeed because we avoid wasting way more money on software that would not work for the customers.

Projects do not accept FAILURE. Projects assume you will deliver all the backlog you had. This definition is completed flawed within our modern product culture since Lean Startup said and done well - we dont know the product, the market, and the customer, and we need to DISCOVER. IF we need accept we dont know, how can we FIX the backlog? How can we tell we need these 10 exact features or user stories?

Debt as a Liability

Another killer insight Allan introduces on hos book is the issue with *Tech Debt* Term. I personally never liked the term tech debt; since we are building digital products, I prefer the term *Debt* since we can have product debt, UX debt, BA debt, etc...

However, Allan points out a much better concept. Liability. No one wants to have liability, thats non-negotiable. I wish this was the term, and every manager and product professional know this. Debt is often seen and a good thing in the business space, since every company has debt. However, liability is the view as no desired thing at all.

Liability VS DEBT is not only a different word. What matters most is change your mindset. I really recommend you read this post. Changing the mindset means, dont think only about feature and Output. Acknowledge that digital building products are hard, and we can't just pile up liabilities.

Inflate Expectations

This is another big issue most companies face today. Projects create false expectations. On paper, you might say a project cost U$ 500K year but, in reality, might cost 1M. Creating Gant charts and long projects and estimates only make us feel better but do not guarantee user adoption or drive better value. I believe it is the other way around, actually drives the worst performance and less value since we are focused and constrained about the things that do not matter.

Estimations are worst them expectations. Estimations are a kind of expectation. Once you set it up, it will be hard to change. Working with no expectations is hard. I deeply believe we need to Think BIG and have BOLD and audacious Dreams. However, I believe we need to Execute SMALL and very carefully.

Agile won't work for you if you dont change your expectations. Agile does not work if you don't ant accept true and hard things. Agile is like a mirror, you might not like what you will see. Expectations need to be managed and focused on making REAL customer impact not make a scheduled impact on a giant chart or 3-5 year roadmap.

Value Pursuit

Value Pursuit is what matters most. Know whats value is hard and tricky. Customer obsession, UX hard work are the only way we can get there. Experiment culture means: Allow failure to happen; with no failure, there is no innovation; with no innovation, there is no impressive customer impact. We need to acknowledge that building products is HARD and won't happen just because we build it.

If you dont DISCARD any user story making a discovery, it means that you are not making the discovery. Discovery means to play with ideas and experiment with what's the best and right impact on the customers. It's our view on the customer DEAD or ALIVE? Like I said before, software needs to be alive in order for us to have a great product. So how can the product be alive if our view on the customer is STATIC(dead)?

IF We know all the answers, why do we need UX? Could we just build and they will come? Well, the product industry and lean startup already showed us things do not work this way. Persuing value means accepting we dont know all the answers, and we will experiment and discover it. Following deadlines, blindly does not leave much space for discovery.

Continuous Improvement VS Crystalized Values

Continuous Improvement means:

* Listen to the customer(User - not only your business team)
* Listen to your engineering team
* Run regular Process/Team retrospectives
* Have 101 Sessions with everybody in your team
* Do RCAs(Root cause Analysis) and improve what is not working well
* Understand why bugs happen and avoid the happen for the same reason
* Understand the Variation and dependencies and try to manage it
* Do not kill all variation, or you will kill innovation
* Learn to see and eliminate waste(Lean)
* Improve and manage your flow, have limits (Kanban)
* Give visibility of all the improvements you are working all

All that does not work if you do not change your mindset. If you still are waiting for X features in the Y date given Z cost, no improvement will work for you. Because you are not focused on the value, you are focused on OUTPUT. Value cannot be crystallized, it needs to be ALIVE. So it's is in constant change.

Culture: The Elefant in the Room

Why it is so hard. Because your company is BIG and has lots of people who think in the same way. They reinforce themselves. So you are not facing one individual, you are facing something much stronger: Culture.

As an XP practitioner, I always believe in R2 Loops. The ide is old and comes older than XP actually in the 70s to be more precise. But Companies do not learn. R2 Loops means to change your strategy by changing your mental models and values. Otherwise, you are not really changing. Saying "I'm Agile" or "I',m Lean" do not make you Agile or Lean. Using practices without changing your thought process and beyond anything else, you "Expectations" means nothing.

This is the Way | A way Forward...

Like Yoda once said:

The only way is taught education. Education takes time, and it's not only done via training but via day by day hard work. Are your changing agents(agile Coachs, Managers, Leaders) promoting change day by day?

Are we measure the things that matter? Agile is all about the retrospective, but how many *Product Retrospectives* did you performed? How many product discussions you had after production? How many times did you talk with customer support? A product retrospective is different than a Team retrospective. We need to involve Customer Support, Sales, Product People(Discovery) and see numbers on USAGE and understand what is working and what is not working.  Otherwise, we are just pilling features and hope our user base grows. Like Google SRE folks like to say: "Hope is not a Strategy".

Cheers,
Diego Pacheco

Breaking the Debt cycle

Breaking the Debt cycle

Admin aaThursday, January 9, 2020

Organizations need Lean more than ever. IT became a huge waste factory. Software scale works backward, the more money you throw in, the bigger the project the bigger your risk and bigger the waste you have. The technology work backward because If you think about Milk, the bigger the scale the cheap is the price. I was wondering how did we get into the position we are. Tech debt does not describe debt anymore, we are dealing with a totally bigger order of magnitude scale of debt. Tech debt can be big but I'm talking something beyond big. Maybe at the scale that some governments have debts with the IMF. Why did we go south without noticing? I have some theories. Technology is like a time bomb, companies might start breaking because of it at some point. The debt become so high that multiple 3-5 years of investments might not be able to pay then off and business might start failing because of the bad technology practices. You might think I'm crazy. Because of business operates with products and customers. However, we need to keep in mind today most of the products mean == Technology. Therefore even if you have an amazing user base and the working product you might get stuck in a very dangerous cycle.

Success Definition

PMI says that a project definition of success means to deliver on time, on budget and with the expected scope. The PMI definition of success is hardcoded in the brains of most business organizations.

This success definition requires Estimates. Estimates are guessed, they never work but we still use then as they were something reliable(which they are not, therefore we cannot trust then). Estimates are often done by managers who do not understand how modern software developers, product discovery works and often that happens 1 year before the project start targeting 3-5 years duration. Why? Because finantial / sourcing departments believe that buying more software is cheaper - they are wrong, it's not, It's the opposite. As a software engineer, you will be PUSHED to deliver somebody else guess. This practice is being around for decades(2-3) and companies are being around for decades, companies buy companies that operate with the same principles so debt piles up like crazy.  It's would be much better to have another definition of success, being more agile and product-oriented rather than being project-oriented.

This is my proposal for a better success definition. First of all, we don't care about OUTPUT, only about OUTCOMES. So it does not matter if we get or guesses right(nobody does). What matters most is deliver value(Agile says that for +20 years and companies still did not get it.) Value can be perceived as different things like user impact such as improving user organic growth or reducing churn.  Predictability is value as well, however, in order to have it, you need several things in place. I will talk about predictability latter on.

Acquire New Skills and Culture are value as well. Several times companies fail to perceive the impact New Skills and Better Culture can have on results in the long term. These factors often are not taken into account to judge initiatives. This really does not make sense because people do software, so if your product will be defined by your people, if you do not worry about what skills they have and culture you really are neglecting results and creating debt.

Reduce Debt side by side with Reduce Waste are more important than ever. Technology becomes about waste, inefficiency, slowness, lack of delivery. Money comes in debt comes out. Debt needs to be managed and tackle with much more serious discipline. Successful product companies know that. In theory, everybody knows that in practice companies prefer to prioritize best which kills their speed to product value in a long rung.

Better user experience, it might sound funny but the industry still does not prioritize UX. UX is not only about to look and feel but about the whole experience from the tone, the interactions, how it works, how to fix the user pains and problems to how reliable, fast and great the product(system) is. More features do not means more. Users care about fixing their problems, not about number of features.

Predictability Iceberg

Every single company out there wants predictability. That's the only thing they see. However thats only the tip of the iceberg. I would not have enough time and space to draw and the universe that exists under the predictability iceberg. For most of the industry, this iceberg is very shallow and could mean simple and linear things like estimates, writing specs, having and architecture. Unfortunately, thing are more complex.

Predictability depends on a stable system, Dr. Deming said that ages about, companies still did not get it. I share very interesting Deming experiments on one of my previous posts. The stable system requires talented people working on the right roles with the right practices. Today is almost impossible to be productive without a proper cloud platform in order todo Deploys, Observability, Tests, A/B Testing and much more.

SOA plays a very important whole in this picture. having contracts and proper ISOLATION allows you not only to contain blast radius in case of failures but also to contain debt. Hiding databases are one of the most powerful architecture techniques we have. The main issue is 20 years ago have a central monolith database was the way to go and since the industry never much attention on this "debt thing" you what happed.

Proper Discovery might be one of the most important things you need todo. Discovery disciple allow you to answer the most important questions for your business continuity:
* Are we building the right product?
* Are we fixing the right problems?
* Are we targeting the right users? Do we know our users?
* Are we doing the right strategy? It's our MVP too big?
* What should I modernize what should I re-create?
* What are the right priorities?

Proper Kamban is the bread and butter of continuous improvements. If you are not doing continuous improvements you are creating debt. Continuous improvement is a nice and beautiful world to say but in practice, few know who to do it. Why? Because in order to tune the system you need to understand it very well. Improvements are done in several fronts by?
* Running RCAs(Root Cause Analysis) and preventing bugs to happen again
* Using WIP limits and control utilization and see bottlenecks and act on them(Test/Code, Acceptance).
* Having flow / regular cadence by having more queues and always improving explicit queue policies like the minimum number of tests, documentation, and review your own code before submitting to the Code Review Queue.
* Training your team and teaching then how to be more effective and productivity
* Having retrospectives in challenge your tools, process, and practices.
* Having regular DEMOS to collect customer feedback and improve the product
* Re-thinking your architecture in order to reduce complexity and boilerplate
* Creating generic solutions which reduce developer workload
* Having platform services to allow engineerings to be focused on the business.
* The list goes on and on...

Automation, Observability, Automated Tests, Templates, Guides. I will stop because this list is much bigger than the one I add on the iceberg picture.

Too Much Debt: Vicious Cycle

In the beginning, teams tend to be super fast. As time pass, people leave the company and the business change the code became more and more complex as a consequence the ability to quickly iterate and release software becomes slower and slower due to the debts.

The picture above show how LED time deteriorates overtime and entropy takes over at some point. Adding more people actually makes it worse because we are only adding more VENON into the system so it might speed up this death spiral. IF I dont have a stable system with 2 people adding 20 won't make my life easier, actually will make worst as debt will be produced faster and the need to coordination will be a higher price. In order to add more people properly without suffering you need:
* Great SOA Architecture in place with proper ISOLATION
* Great Talent Density
* Stable System

Without these requirements we are only making the bad vicious cycle spin.

As you produce Features DEBT is created(Did you know?) DEBT increases complexity, complexity slow down you productivity and you produce fewer features. This cycle tends to repeat ever and ever and companies dont understand why they cannot meet the deadline. One interesting factor is that as you have more teams you have more dependencies and if this dependencies are binary(share same tables, code bad, open tickets) you slow you progress and debt even more. Your dependencies show be services which are deployed and reduce the debt, therefore, speed your progress.

So what do you want to do is reduce the investment and maximize the impact and also produce little debt.

Higher benefits, lower debt, and lower investment should be your top priorities. But what happens if my initiative takes 5 years or more. Well, work with 3-month budgets which will help you to reduce the waste and maximize the benefit.

Unfortunately what happens is the other way around, where companies invest a lot and the benefit is not that big and the debt is actually bigger than the $$$ investment. Companies often not prioritize refactorings, re-architectures, and prefer to "integrate" on what they already have, this only pushes the problem to be bigger.  The issue is that the product might not see the benefit in playing the debt system not "perceived" feature/capability will be added to the final user however this need to be taken into account otherwise the long-tern ability to add benefit might be compromised forever.

Breaking Free

First and foremost education is key. Do you know how much DEBT do you have? Could you DEBT be paid by your investments? If you dont know your debt and/or is not measuring it effectively, you will be in trouble or maybe you already are.

Making hard calls like refactoring / re-architecture / re-design instead of integration and migration as-is or lift-and-shift are very necessary, even if they dont have ZERO new features. The feature is not the only thing that matters, seeing just features create huge hazard to the business.

MVPs are great tools. The main issues people don't know how to run proper MVPs. in order to run a proper MVP, you need to focus on a "small" movement possible, doing discovery we do MVPs without code and this are the best MVPs. MVPs mean validating assumptions which can be done by talking with your REAL USERS or running UX Research or A/B testing in production. You can do a software MVP but you need to reduce features and inside features, you also can do less.

Fixed Scope projects should be avoided at all costs. Cheap and "obey-only" vendors also need to be avoided at all costs because they create debt bigger than the benefit. Total Tercerization also does not work because a software company might have part of the puzzle and the business org might have the other part so PARTNERSHIP is the only way.

Small Budget allocations like (3 in 3 months) help to ease the financial pressure and also produce less debt and waste, movements like OKRs, NoEstimates, Byond Budget, Continuous Digital enforce this culture

Ultimately breaking free is not easy because require to convince a lot of people but I deeply believe we need to evangelize for change otherwise software might kill itself and take the business with it.

Cheers,
Diego Pacheco

Modern Discovery: Breaking new silos

Modern Discovery: Breaking new silos

Admin aaSunday, September 15, 2019

First of all, I want to explain why I added a puzzle as an image for this post. This is a metaphor I'm using with several people I work. People sometimes get lost and cannot keep with modern software initiatives. Well, agile is saying that for ages and people still don't get it. There is a huge difference between Simple and Complex systems. More and more making a digital product is from far to be a simple task. However, we still want answers that we cannot get. Sometimes this creates anxiety and we need to learn how to deal with failures, chaos, bad feedback and even that our solution my suck. Ouch thats very dark, right? No, not really, this is the reality, the REAL WORLD is a cruel place and ADULTS need to call tough decisions every day. So what's the deal with simple linear systems? well they imply that quickly you can understand what you are doing and make predictions about the outcomes. Well, digital products are not like that, we cant make predictions on simple linear thinking like A -> B -> C. It does not work like that.

The right Vision for Digital Products

Digital products are not like your uncle old software projects. Why not? well because the world has changed and startup competitors can beat you and from day to night you might lose it all. What's wrong with the project thinking or project midset?

• Focus on the wrong things: Dates, Scope, and Cost.
• Does not take the customer obsession into account.
• Does not use discovery and th way to learn tought experiments. 
• Does not pay technical debts and use technology as a bag of magic tricks.
• It's full of waste: Feature no boddy use, people don't even know it(lack observability).
• It's full of waste: Takes so long to release that people don't care or need to work differently. 
• IF for some reason you got all right, you end up killing your team and need to go to over again.

Why we keep doing this? simple because we don't educate our selves and keep repeating old management dogmas because is that the only thing we know how to do. There are better and honest ways to approach the problem but before we talk about Dates, could we talk about benefit? how we make sure we are adding value to the customer?

As soon as you realize there are at least a million things preventing you to get the date right, such as Technology has changed and you don't know how to do it. The user's changes and you know now them very well, the ways of developing software have changed and you don't master these new ways. User interfaces have changed from desktop to web to text, to voice to XR. Operations have changed to DevOps|SRE. Management has changed and now it does not make sense anymore, no one needs command and control anymore, we need coachs and mentors. The business has changed and we don't need People throwing requirements via word specs into developers. Sales have changed, software distribution has changed, the world has changed. Engineering has changed, are you still talking about relational DBS and governance?

OK if you acknowledge that which is huge, I have some very bad news to give you. Here are 2 super bad news. First could you chance? Are you used to continuous change? If not this will hurt. Even if you make it through here comes the second bad news. All of this things I mentioned before(which are super important) are pointless if we can't generate value. In order to generate value we need to understand the users, have the right technology/architecture and make sure we get the business right these tasks are not easy. In order to get this right, you need discovery it. So it's like a puzzle it will only make sense ater sometime, you cant understand up to the front(and don't need to) and it's not linear you can predict with sticks and carrots.

The Discovery Process

I'm not a Scrum guy. Actually, I believe a good part of the damage was created by scrum. Let's start talking about the role of Product Owner(also known as PO): Let me give some bad news for you. There is not the PO. Yes, the PO does not exist. It cannot exist. Why we cant have the PO role? PO implies you have a simple individual how knows the business, UX and Architecture this might be throught if you are Jeff Bezos or Steve Jobs, not I'm not 100% sure if they got this 3 skills.

The discovery process, needs to happen with triads of people. An architect, a BA and a UX person. Only with these 3 disciplines, we can make good calls about how the product should behave.

The architecture alone is non-sense, I think I don't need to explain that to anyone. However the other 2 alone people think is ok but actually is not ok at all.

BA alone more of times means some bad practices like not doing proper UX and also just getting orders from the business and sending down to the developers, a modern BA is not an Order taker but a leader. The modern BA has no issues with failure, it embraces the failure, a modern BA embrace experiments and is in constant learning about the business, the technology, and everything. A modern BA does not think about UI only, it thinks about other interfaces specially APIs.

Most companies think have the UX alone is a good idea. Thats a terrible idea. UX alone means you will have waterfall projects, so the UX will define all uis and you just need to execute it, ideally in a fixed price, fixed scope project, this is what most companies are doing and is comple waste. So Ux is bullshit? No, not at ALL. I love UX, Ux is super important but it needs to be binding with architecture and BA(who should know about the business).

The discovery process does not write Specs or user stories on the stone. They discovery things and the discovery process sometimes results in a user story other times results in just not asking the engineering thing to code. Yes, and thats one of the greatest results you can have from the discovery team, killing a user story is a good thing, you are saving tones of money doing that.

Why the hell do we need to kill user stories and throw them into the garage? Isn't this waste? Are we throwing money away? Well if you engineer some feature and the users don't like or don't use it well then you are for sure throwing money away because the engineer is the most expensive thing you can have after cloud costs. So you know be sure before throwing anything there.

But I'm 100% sure? Awesome so this means you are not doing innovation. Because there is no sure with innovation, is all about risk, its all about failure and learning from it. Thats why you need experiments and you don't know what will happen.

Breaking Silos

Breaking silos is something beautiful to say however companies are not ready to do it. Why not? because leaders are not ready to do it. Because often means less power and doing the right things are not for the week, only a strong leader can do such changes.

Let's consider 3 classical silos on IT | Product departments. Architecture / Technology is one silo. Ux is nother silo and BA(Business Analyst) is another silo.

Why these 3 silos are bad? Because they introduce delays and create the false illusion that they can work isolated and they simply cannot work in isolation, not in an efficient way. Why not? because no silo has the complete picture, so this silos just make things more difficult. Silos also create the wrong ownership feeling, An architecture my say is not my job to know about UX or Ba might say I don't need to worry about Technology, all wrong;

So we need to tear down silos and have flexible borders where the architect will still be the responsible about technology however will understand the business and know the user so all solutions this team creates are rounded and they don't have loose ends.

BAs often just know about the business needs or strategy, this does not mean is feasible to execute(architecture) or if is nice for the user(UX). Lean Startup and LeanUX do UX is a very agile way, most companies do UX in a super waterfall way. The discovery process make sure developers don't get surprises like? what we should code? are we ready to code this? or is the user really need this and does this UI make sense? The discovery process can and should also kill user stories as the experiments fail and they learn what works and what does not work.

Why you can't get Dates right with Estimates

Every sale, financial and market team need dates. However, get dates right via estimates is almost impossible and become more impossible every year. However we still rely on something that is not reliable at all(estimates). The need for estimates is real. So if we can get them right, could we replace them with something else? I believe thats the right approach. Instead of just saying there is no date we can replicate dates with:

• Business Visibility: Via Kanban boards, Demos and Retrospectives.
• Small 8h user stories: Small stories are easy to manage and predict outcomes. 
• Constant business progress: via talks, experiments, user story mapping, and releases.
• Using OKRs and focusing in quarters rather than anual process helps a lot. 

Even doing all that, people will still want some kind of commitment and dates at the end of the day, which I think are fine and fare if we:

• Have the right architecture and infrastructure in place that allows us to release software fast.
• Have business availability and discuss scopes(MVPs) in order to have smaller releases.
• Run discover the process and produce ~8h user stories(fight variation).

Doing so we can focus on cadence instead of trying to guess several requirements, super up-to-front without UX and Architecture involved. The chance to get this estimates right is lower than getting the first prize in the lotto.

So instead of guessing 400 items in a poor structure, poor defined, poor discovered backlog, lets run the discovery process and use the kanban cadence formula.

Let's say cadence us K. We just need to know how many user stories we need to deliver(discovery process) will be able to get that for us. We also need to make sure storys are no longer than 8h.

Them we get how many weeks we have to the desired date. We just divide the number of stories per the number of weeks and we have the throughput we need per week. This throughput could be called cadence(K).

When we have the cadence we can know how many devs we need just dividing the cadence per 5. Why 5? A single developer works 5 days and delivers 5 (8h stories) per week.

You can also observe our engineering team and tweak things to make sure you can deliver a story per day, You might need some time to tweet your discovery team to produce 8h stories as well but this is much better because you can predict better when you will finish. At the end of the day if a developer doesn't finish a story we are delayed so this is easy to manage.

From Estimates to Cadence 

When you have cadence, you dont need estimates anymore. Actually, you dont want use estimates you want to cadence because if your backlog is breaked properly and you deliver it it will be much better to manage it and have dates in short tern for the business. Dates in long-tern dont work and its impossible to have it. Dates in short tern following this method are perfectly feasible.

There are 3 key elements here: A) discovery process that produces 8h stories, B) Engineering team being able to deliver software with constant cadence. C) Management/business changing a bit how the demand software and break into more continuous deliveries rather than yearly waterfall releases.

TTA (Three Track Agile)

TTA is inspired by Dual Track agile, I just added a third track called foundation. Why do I have a foundation there? Foundation is hilly inspired in Engineering Organizations from Silicon Valley. You can think as a Poor Man solution(in the case you dont have an engineering Organization like in SV). So the foundation focus on Architecture and Technology to speed up the Delivery team like What Observability tools are we using it? Corporate architecture principles like SOA/APIs, Cloud-native, REST, Proper Software Design and much more. This is important to make sure discovery has fewer surprises and can focus on the business. This does not make all technical changed are removed from delivery. But if something could take 4 months to get it, it's not a good idea to discover it in the delivery where you expect to release software every day.  So the TTA it's my personal adaptation between DTA and EO from SVs.  In DTA there is retro-fit for all tracks in TTA is the same deal we just have one more track-focused in the foundation. This foundation could mean different things depending on the size of the product or company, could as simple as a list of technologies and templates and could get as complex and self-service platform solutions like stress testing platforms.  The cool thing is that you can put all these tracks together in a single kanban and have great visibility and the main benefits are:

• Reduce Risk
• Reduce surprises at Development
• Deal with bottlenecks before(increasing the change to get dates right).
• Enabling the delivery team to focus on business value  via constant software delivery
• Reduce waste
• Reduce re-work
• Increase visibility 

I hope you guys liked, I will make more post on this themes soon.

cheers,
Diego Pacheco

Modern Product Culture

Modern Product Culture

Admin aa

Product culture and mindset is one of the most important shifts enterprise companies need to go through. Project mindset has several flaws and yet we still follow it and thats need to change.  Project culture makes us focus on the wrong outcome like Dates, Escope, Feature, Cost instead of value and User Obsession. Since 2014 I follow Allan kelly work and read his books and saw several of his videos. I also exchange some emails with him back on the days. I was amazed how makes sense to back into 2014. Even almost 5 years passed and companies still don't get it. There are other movements that push to the same direction as NoEstimates, Beyond Budget, OKRs, Modern Agile, LeanStartUp. All these movements / Books have great synergy and they basically make you thing software development in a completely different way.


Discovery The Missing Discipline

Build a product requires discovery, we need to feature wat the user want if we can make that a business. Discovery is super hard and PMF(product-market-fit) is something 80% of the founders fail todo. If you might think, this is impossible, well for sure it's not easy. However, we don't have many options besides inherit a monopoly, finding oil in our backyard, winning on the loto. Projects create an extreme simplification of the problem. Just build software and users will come, you will be successful. We know thats not true however we still blindly build a feature like there is no tomorrow without evidence of real value on the business investment. Skipping discovery is not the solution.

Why discovery is so hard? Well because build products that don't suck its super hard. Involves business knowledge, Ux, Technology great execution. It's like winning a football world cup, where you invest the game and convince people to go to the stadium that doesn't exist, not an easy task at all. The right mindset is assuming that we don't have the answers and we need to discover it.

Customer Obsession & Experiments

Customer Obsession(the amazon way) it's the only way. It's impossible to build great products without understanding the problem(the problem that your product solves) with perfect match to the user. Sometimes companies know the users very well but they don't know how to turn that into a business. Saying the word "business" does not make you capable of creating the business, that is another super hard thing which requires specific domain knowledge and extremely hard work. Since customer obsession is not enought we need to introduce new practices called Experiments. Experiments are not new at all, they are in the heart of Agile, Lean and Lean Startup.

An experiment is an MVP. The reason why I don't like to use the word MVP it's because MVP got attached to the wrong ideas. Experiment means, let's test some assumptions and see what happens, we might need several other experiments, sounds like science right? Well, it should be because of thats the only way.

Hold on, If my awesome BA or UX tell me they have the answer? Or even better if we adopt SAFE or any other extreme complicated scaled agile solution? Well looks like, in that case, you will have lots of waste and little benefit, also you will be focusing on the wrong thing like PROCESS and therefore you should be focusing on understanding the user and the market.  That sounds very scary, but this is the REALITY, there is no easy answer.

Dual Track Agile

Dual-track agile it's not a silver bullet. However, it promotes some good practices like making sure discovery happens. I worked with engineers so long with so many companies that I can tell you 100% for sure when you have discovery and delivery on the same *Sprint* you end up not doing proper discovery because delivery eats discovery for breakfast.

Doing discovery does not mean you will succeed. However, putting a stop in other bad practices like being 100% spec driven, just worried about dates, not paying technical debts and HOPE everything is gonna be ok. Like Google said in SRE books several times: "Hope is not a Strategy". Discovery does not make you an expert in your user from the day to the might, discovery doesn't allow you to understand modern architecture from day to night, discovery doesn't make you obsessed with the user from day to night, however if done properly the discovery track enforce some good mindsets on you and as outcome you tend to have less waste and more benefit.

In a nutshell, discovery is a learning process where you discard bad things before you throw to developers and where you double down on great outcomes and focus on faster delivery for your users.

The New Mindsets

In order to work with companies, we need to learn new skills and totally new mindsets. The underrated mindsets that you must learn are:

• Anti-Fragility: Famous DevOps Concept - mistakes are fine: In an agile word(Fail Fast). 
• Learn Effectively: In lean world(avoid waste and maximize ownership).
• Learn how to deal with Complexity: Stop thinking about simple linear systems.
• Leadership, not Requirements: Modern PO|BA|BO|PM need to lead not throw specs. 

The Deck

Here is a deck with more on this subject.

Modern Agile and Product Culture from Diego Pacheco

cheers,
Diego Pacheco