"Clean Agile" with Bob Martin (uncle Bob)

I listened to an O'Reilly Live Event with Bob Martin

Bob was one of the original signatories of the Agile Manifesto, a software legend and no holds barred educator.

key takeaways

Agile does not make you go faster, it produces data to understand where the project is at

We do Agile to get data such as velocity and burndown, "to see how screwed we are"
We want the bad news as early as possible, cold hard data
So we can react and adjust our definition for: fast, cheap, good, done (for the feature/project)
Agile is about managing a successful outcome given all your constraints

Agile software development at 30k foot level is dividing project up into small time increments, measuring how much you get done, multiplying out to get a date and making adjustments as necessary given your constraints e.g. we want to launch X

my notes

Agile is a set of disciplines

Product Owner is chief specificer, has the problem, specifies the features of the system

Project Mgr handles schedules, cost. Not defining features

How do you manage a software project?

Mismanagement leads to: producing wrong product, inferior quality, being late, 80 hours a week

Pick any 3 of good, fast, cheap and done. You can't get all 4 simultaneously.

So you have to quantify "how good?", "how fast?", "how cheap?" (schedule, scope, quality, staff)
Product Manager/Owner are supposed to manage the project to the best possible outcome by managing these factors
To do this you need data

teams velocity is useful data
how much work (story points) remain is useful data
note: there are going to be changes, estimates will change, more tasks added/removed

Agile does not make you go faster, it produces data to understand where the project is at
We want the bad news as early as possible, cold hard data

In software the dates are often frozen but the specs are not. Agile is about managing a successful outcome

Agile:

Exploration and Coding happen at the same time (tho more analysis & design @ start than end)
You split the timeline into timeframes e.g. weeks (or 2 week sprints)
You build out slices, verticals, which includes UI, middleware and BE
Goal: don't half do a feature, do complete features even if only half
After a couple of sprints you have enough data to understand if the project is doable or not in expected timeframe

Health to the Web