Johann Savalle

@yasha.solutions

Product designer and full stack developper living in france
< Back to all articles

Agile Product Development

February 06, 2019

NB: Article still in progress

A jargon-free explanation of Agile for people who just want to work and build a product.

The basics

Agile is based on the recognition of a few facts:

  • We suck at time estimation
  • We suck at communication
  • It is easier to correct small mistakes than big ones

So taking this into consideration, the main idea is to break down a big projects into a loads of small ones. Very small ones. Like one or two weeks long projects, up to one month max.

Why? Because small projects means only small mistakes, easier to correct and stay on track.

In this short period of time, we try our best to produce something that look like the final product or part of it.

We test it, fix our assumptions for further planning : time, resources and what is the end result – and then we go at it again.

That’s it.

Really?

Yes.

Seriously. Don’t over complicate it.
We could. But we are not going to do that here.
What’s important is too understand the strenghts of Agile is to keep things simple.

Really simple.

Jargon

I promised a jargon-free article but we still need to get some words out of the way because you will see them very often.

Roadmap: The big blocks you want to achieve
Backlog: A huge list of stuff you have to do to make the roadmap happen
Sprint: The small block of time you need to deliver a version of the product.
Standup meeting: Not really standing up – but the concept is to keep so simple you could have these meeting over a watercooler. Have these often. Like everyday if you can. Maybe even twice a day.
Burndown Chart: How fast will you burn that pile of stuff you gotta do to get this product shipped? That’s question everyone want to know? Well, you don’t really know anything what you know is that it’s day 1 and you have 856 items to do to ship this project. If day 2 you have only 850 and day 3 you have 842 then you can start getting an idea of the speed you will go and how fast you “burndown” these fuckers.
Kanban board

Agile applied to web application

Research
User
Technnology

Design
Design Workshops
Design Sprint

Design deliverables
Moodboard
Design system

  • Components
  • Brand
    Mockups
    UX Wireframes

Engineering
Operations
Programming
Testing
CI/CD

Marketing & User feedback

Iterations and new features

The end?

Maybe you are asking why there are so many books, so many trainings about it if that’s so simple?

It is because simple is hard.

We – as humans – tend to like :

  • perfection
  • security
  • predictability

Agile provide none of that out of the box.

No perfection
Since you keep doing small parts of the project, you keep delivering a half-done product . You have to be ok to ship something that is not yet perfect. This is harder than it looks. But you gotta trust the process and just keep on delivery small parts that accumulate over time to the full picture.

No security / predictability
It is lie to promise anything more than “We will try our best to achieve this and that in a given amount of time”.
A lie we say all the time.
Security does not come from agile.
It comes from experience. If you have experience with the work and with team that will be working on it, you have can have good confidence that your estimation is close to the truth. Roughly. That’s also why doing a gantt chart at the begining of a project when you have never worked with these people you cannot say anything smarter than – “Let’s start to work and see how fast we are chopping down these trees”. Once you’ve cut trees for a couple of weeks you can start getting a better idea of an estimate.

So really it is just a realistic approach to risk management – meaning, since we are brutally honnest about our lack of guaranties regarding the results, let’s break it down into a very small chunk of manageable pieces of work where we have high confidence we can manage – and predict – but if not – then it is no big deal because we can also improve the week after.

That’s it.

The big secret is that even regular project management know time scheduling is a big illusion. Agile decided to make this official and not lie to ourselves.

Of course there are some ways to do time estimations in agile – which are actually pretty accurate. But that’s because the philosophy of the method is that we are pretty bad at time estimation and therefore it’s taking a radical approach to it.

< Back to all articles