I am finding this session to be too basic for someone like me – better for programmers, I would guess. Decided to bail out and go to Al Shalloway Session.
Moved to Al Shalloway session – Jim Highsmith appeared making me feel validated, a bit, but he ran out. I am guessing to Jeff Sutherland session. I am not going to that because, well, I have attended amazing Jeff Sutherland sessions.
Al is talking about Lean-Agile – focused on value.
Thirty minutes in:
Compares jamming in features like a car wedging it’s way into traffic jam on the highway. Not throughput.
101 steps to not overloading your team
Does self-organizing mean do what you want? (no) spoke about Demming in Japan. You have to figure out how to create the right environment That allows people to figure out how to do good work.
When women went out of the work force when the guys came back from the military in the 40s US quality went down because women were practicing Demming principles; men didn’t want to do that. They wanted to control and micro-manage.
What to do? Make value flow. Business Value – management (micro management is out BUT haven’t coders passed along poor code to testing because they could get away with it?)
Getting the right people to work on the right thing at the right time is more important than doing the steps faster.
He thinks Scrum leaves out steps.
How much of what we do leaves out valuable rework? A tenant of Lean “Eliminate Waste” is poorly understood. You might miss waste because you don’t have the big picture.
Showed a slide with waterfall step bubbles – requirements being one of them. Used example of rework on requirements and included building unneeded features, working from old requirements, “fixing bugs” – and what “fixing” bugs mean. Half the time it is *finding* bugs.
“Finding bugs” is waste – we wrote the bug in, right?
“Integration” errors. Overbuilding frameworks. Essentially duplicating frameworks.
So he says speeding up left does not undo issues on right. (ref to diagram.)
Read Emergent Design.
Long feedback cycles increase amount of work to be done. Shorter feedback cycles de radar the amount of work to be done. What organizational structure should we use to decrease feedback times. ( notice he is saying “feedback” NOT “release” time.)
Better for people to be armed with an understanding of the work they are doing. Confusion – Micro and macro prediction. (Vegas – predict whether green or red on table versus more money left on table during the day.)
Focus on time over the entire value stream.
If every team is working on the team level if you have team metrics, you will have integration problems. MMF: “minimum marketable feature.”
(he is going through case studies)
Second case study: coordinating multiple businesses and multiple teams (went fast might be kinda wrong).
Agile at scale: 1. define business capabilities – make a role of product managers to talk to stakeholders. 2. Create mmfs; 3. Prioritize mmfs, 4. Create high level stories, 5. Assign to team back logs (teams don’t get to choose- can prioritize not choose what set of stuff they are working on.). Do this based on business dependencies.
Teams then can make backlogs.
Amount of work went down because people aren’t running around prioritizing.
That is respect for people. (was buzzed because was talk about Lean not being about respect for people – strongly disagrees)
Holistic approach
Deliver quickly
Discover iteratively
Attend to structure
Optimize the whole
The most important driver to developers is adding value to the customers. 98 % driven by this.
Work Different 
Leave a Reply