#4 — Agility 101: Agile Values — Working Software and Creepy old times
By: Luiza Lima
Tags: Digital Transformation, Agility, Agile, Agile Transformation, Values

Quick catch up from last article: The first Agile value reinforces the importance of having the right people interacting the right way. This is such a big deal in agility that most frameworks have a specific role to ensure that: the agile professionals. This doesn’t mean process and tools are not important. It just means they are less important than having the correct people interacting the right way.

The second value of Agility is:

2. Working software over comprehensive documentation.

This value might be the most self-explanatory of them all. It basically means that you should not waste too much time with comprehensive documentation. At the end your measure of success is having something that works. And the best way to do it is to deploy what you have as soon as possible. The longer you wait to put anything into production, the further you will be able to measure your success.

A lot of people think that here is where the concept of MVP was born. It definitely is a foreshadowing of it, but the concept itself wasn’t born in the manifesto. It rose and became popular almost a decade later and is part of the Lean Startup movement. The minimum viable product was made famous by Eric Ries — a frustrated developer that after months of working in a digital product that was a complete failure, started the movement. Although MVP wasn’t born with the manifesto it certainly dips from this source and is already considered an adopted member of the family. Lean Startup is a great book and Erick Ries an excellent reference to follow! He’s also a famous blogger that has been writing since 2008! It’s quite fun to read his old texts. I will leave you the link: http://www.startuplessonslearned.com/

We will talk about MVPs later. Now let’s get back to Working Software value. I want to give you some context and take you back into really dark and bizarre times of software development.

I’ve been working with digital for over 10 years now and I can tell you that we used to stay months and months describing and documenting features. We had a deep belief that if we described clearly enough, explained detailed enough eventually this would go right. And the more software development went wrong the more we would obsess over documentation. There was no way a project would be launched without at least a dozen pages of extensive writing. It would take months and months of planning. It’s weird to think of that now, considering agile companies are currently doing weeklys or even daily deployments.

For me, it’s both funny and tragic. The funny part is that Project Managers and Business Owners actually believed that they could pass months discussing a project without adding developers and product designers to the process and think this would work. The tragic part is that I was one of them. I’m not proud to say that I have written over 100 pages of detailed documentation back then. =(

A great metaphor to that it would be trying to revamp a house without even considering bringing your architect and engineer to the discussion. Imagine you bought an old house and you feel that you could define the entire restoration on your own. You would stay months describing and detailing a documentation of what to change. What walls to bring down, Where to put your plugs, your house appliances with no notion whatsoever of power plants, hydraulic plants or even structured walls. How do you think this would end up? Crazy right? But this was exactly how we used to do with software development. No wonder it didn’t work out!

Wouldn’t just be easy to call your engineer and architect and just explain what you need and let them figure out the best way to do it? Well, this is what user stories are! More important than having comprehensive documentation is just telling the experts what’s your problem is.

Back then we though developers couldn’t understand us. The truth is the problem was within us. We were the ones that couldn’t understand the importance of adding them to the process. How could they understand us if we never talked. The first developer I’ve personally interacted with was when I started addopting agile.

Time box over here. See you soon…

Last Article: #3 — Agility 101: Agile Values — Individuals and Interactions

You can follow me on LinkedIn: but are the same artciles, though! https://www.linkedin.com/in/luizacunha/