Agile is all about the profit
While considering my teammate Amos’ recent blog post where he debates what Agile really is my mind was drawn to a statement our current client made during one of our early project kickoff meeting. While discussion why his clients have been successful following his plans he made the statement:
You will never go broke, making a profit
At the time this seemed like a good joke and litte more. However, the more I thought about it, the more it rang true. What does this have to do with Agile software development? While questioning what is or is-not Agile and what his definition of Agile might be missing, he says:
… The one thing that I didn’t mention above. … Delivering a useable project at any point in development. That is it. That is what I’m missing. This has got to be the hardest part of agile. …
I think the key here is the value of a shipped product is ALWAYS greater than that of one sitting on the shelf. Value is the key. To me, the agile mindshift is one of always producing value for the customer, for the team, or for yourself.
Produce value for the client:
- by adapting to their ever changing business needs with understanding, speed, and energy
- by aligning all user stories with tangible user value and goals
- by planning and documenting in inverse proportion to the item’s priority and deadline
- worry about what is in front of you first and put off decisions to the last responsible moment (stolen and probably butchered from a WWBBD: What Would Brian Button Do)
- by working on the highest bang-for-the-buck stories first, top down, and delivering working code as often as possible
Produce value for the team:
- by conducting frequent retrospectives where the team can think about how they are doing and how they can be better
- by realizing that many/most of a team’s problems are really “people” issues masquerading as technical ones
- by actively paying down technical debt
- by reducing knowledge silos and keeping the team only full of valuable members and all members valuable
Produce value for your self:
- by staying motivated and positive
- by keeping the thirst for knowledge alive and always learning from any experience
- by taking greater pride in the success of the team over the success of an individual ego
- by working to be a great communicator: to team members, to the client, to your code (Tests)
I didn’t mean for this post to turn into a list of things to do … but often our practices are the best way we can take abstract principles and make them tangible. So long as the practices don’t become to focal point, they are a useful way to monitor, enforce and discuss the important concepts.
Profit really is the key. Our client helped his clients by making sure they were profitable. Sure, maybe they could have been more profitable, if they had taken bigger risks and bet the farm for instance, but year after year a steady profit is inspiring.
Which brings me to the Underwear Gnomes of South Park. Their business plan was a simple one.
- Collect Underpants
By focussing on providing value (profit) at each point along the way, maybe step 2 wouldn’t be such a mystery. Granted, gnomes are pretty agile to begin with. Fast too.
Alex Miller presented a talk at his recent Strange Loop conference about Walter Mischell’s marshmallow experiments. Mischell studies children’s ability to defer gratification when they were put in a room with a marshmallow and told they would receive another one in ~20 minutes if they didn’t eat the first. The longer term study found that kids who were able to wait, scored much higher in “life metrics” later on (e.g. work success, school studies, etc).
Alex’s talk got me thinking about deferring gratification in software development …. which imediatley made me think about testing.
In college, there were no tests. Just me, alone, with lots of code. And, there were lots of headaches and confusion. Fast.
Now I write tests and consider the behavior of my system before I write a single line of code. Now every line of code was written with a pair. After every iteration the team gets together to discuss how we are doing and how we can do it better. There are some headaches but a lot less confusion. Now there is pride and quality.
Having the discipline of writing tests first, and developing software in thin vertical slices from the top down is hard. It is hard because we desire closure, and immediate feedback. But by focusing our energy on producing a long term quality product, we can achieve a higher level of satisfaction.
Being surrounded with that many passionate professionals makes you want to be better.
A huge thanks to Alex for putting on a great conference here in St. Louis. I can’t wait for next year.