Speaker: Dave Thomas @pragdave

For more see the table of contents

---

Notes

• Started with a vote between this talk and a programming language one. This talk (barely) won

“Agile”

• Wish people would stop using word “agile”
• “Agile” is now an industry
• “Agile” co-opted
• Was supposed to be on what values need to apply, not the practices
• Can’t sell or package values
• Can’t be agile if handed a process

“Agile is Dead”

• Agile is dead. Agile with a capital A is what you pay for. Lowercase agile is the original set of values.
• Devs are unhappy with Agile – too many meetings and processsed
• Read great quotes from Death of Agile quotes all of which value agile principles

Agile noun vs adjective

• Agile has become a proper noun; something people can package/sell/make you follow.
• agile should not be a noun. A noun is something you can point to
• agile should be used as an adjective
• It was made a noun to sell it; you can buy a pound of green
• Agile is lost to us; how do we reclaim it?

History

• How do we reclaim it?
• 1995 – 31% failed, 53% partial success (overbudget or late or didn’t deliver all functionality)
• 2020 – 11% failed, 47% partial success
• Can’t go back
• Too few people started programming when everything was specified up front and the problems to remember why it was bad.
• Requirements change

agility

• Take back control
• Ignore the branding
• Make it work for us individually and as a team
• Create a living, evolving local set of values and practices
• There are things you can’t do that would like to do. That’s live. Still much you can do at a local/team level
• Can’t change everything – business promises things, have the initiate carefully and measured
• Better off than are today by improving locally

First page of manifesto from snowbird:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Value

• Values are an internal filter through which you make decisions
• Make decisions based on the four values in the manifesto
• It’s difficult to do this. But the code is hard to write too

Skills need

• Empathy – see things as someone else sees. Cognitive (thinking) and affective (feeling). Also need empathy for things so understand how will react/stress under.
• Storytelling – everything we do is an abstraction; using stories/metaphors allow people to understand.
• Feedback – Classic feedback loop. input -> process -> result -> compare to expectations -> input. In software, we apply the feedback to the process (or expectations) instead like in unit testing. Could also be the process used to create the code in the first place. Aka error when coding, bad assumptions, or systemic error. The third is most valuable, but done the least.
• Change driven – spent most time changing things vs building new things. Development is a nested set of change cycles. Software is the most malleable building component. Think or work as a series of steps instead of an outcome.
• Value focused – Goal is help people and add value. Working software is a means to an end. Earlier delivery is more valuable so cadence is a trade off against accumulated value.
• Courage – being an agent of change means making mistakes. Don’t hide behind the process or make excuses. It has to be ok to make mistakes. If we are taking control or handling something, we are accepting responsibility for it. If we communciate effectively and honestly and are ignored, they are responsible. Don’t let an imposed constraint be a stressful responsibility unless you’ve accepted it.

What can I do

• no-one knows
• nobody can know what you individually should do
• except possibly you
• you are the only person who understands the constraints living under and your personal values.
• What to do – Find out where you are now, take a small step towards your goal, adjust your understanding based on what you learned, repeat. That’s agility!
• How to do it – When faced with 2+ choices that deliver roughly the same value, take the path that makes future changes easier

Example

• Unproductive meetings – Goal is to feel more productive.
• Non agile way is to say nobody can speak for more than 3 minutes and pass around the teddy bear.
• Agile way – start with why have them – know what’s going on, identify frustration, planning, serendipitous discovery, etc. Identity downtime. In classic Scrum 17% of time is in meetings.
• Small step #1: stop having meetings. Then adjust based on what happened. Will world end if abandon meetings for 2 weeks? Will company collapse? [seems like a big step]
• Found delivery went up but two cases of duplicated effort and lost too much communication.
• Small step #2: senior dev spends an hour a day chatting with individuals. Find common problems, patterns, and opportunities. Helps with small problems and brings people togehter for larger one. Found unnecessary activity and local expert
• Small step #3: change to 45 minutes a day
• Be prepared that will change over time
• Called “Developer without a portfolio”. 6/45 independently evolved to doing this. Most had a full time facilitator/ambassador. None wanted to go back.

Another example:

• Problem: when we refactor, we spend too much time fixing up the existing tests
• Side story: Tests were brittle and a lot of failures on new machine. Deleted all internal tests and reintroduced as needed.
• Why have tests: validate functionality, protected against regressions, inform design
• Cost: Time to fix when fail
• Small step #1: disabled on API tests after code written. Rely on caller to find issues. Make sure tracking error rate metrics before and after change
• Months later no observable change and refactorings faster. Found unintended coupling
• Small step #2: addd test to detect coupling and investigate cause

Closing

• agility – bring back the fun

Q&A

• How was it rewriting pragmatic programmer 20th edition? Threw out or rewrote a lot 30% of tips. Changes references in many others or described better. Ideas themselves didn’t change. Common sense. Things people know. Seeing it written down validates. Gave names to concepts that didn’t have.
• Example of storytelling of what we do? Use point of view of customer using product
• How change more? Get others to make small changes too

My take

Awesome keynote. It was so nice to meet Dave in person. It was great seeing his perspective. The material is helpful in impacting positive change. The info and examples are great. Missed a little of the end of Q&A to setup for my session