Retrospective
Now that I’m at the end of this set of articles, a retrospective is in order.
I’m very pleased with the final shelves. They’ve been doing everything I need a shelf to do for months now, with no maintenance required. You have to love a feature that doesn’t require any support after go-live.
When I started writing these articles, I was curious what would come of it. I made a few key mistakes that prompted me to explore the project from an agile context, but I wasn’t sure what I would uncover.
Along the way I realized that “agile” is at risk of becoming a meaningless term. People are throwing “agile” in front of everything (including articles on home improvement projects).
The nice thing about agile is that it is a set of principles; a philosophy. And like any philosophy it has its strict adherents and its loose followers. It has those espousing the “right” way to practice agile and those that are bit more loose in their interpretation.
This can lead to ambiguity or confusion, but it also provides an opportunity for each of us to identify what we mean when we use the word “agile”.
This set of articles forced me to articulate what agile means to me.
If I reduce it to its basest essence, being agile to me is about assuming that you are wrong.
This is the conclusion. Other parts are here: Introduction, Part 1, Part 2, Part 3, Part 4, Part 5, Conclusion, Epilogue
You’re Wrong, You Just Don’t Know It Yet
Throughout the project, I assumed I might be wrong. I shied away from any decisions that would lock me into a particular direction. The one time I assumed I was right and pre-built a bunch of vertical supports, I turned out to have the wrong measurements and I cost myself additional time and effort undoing my premature optimization.
With each decision I made, I asked, “What if I’m wrong?” When I needed to buy the nuts, bolts and screws I was tempted to order them online but asked, “what if I’m wrong?” Then I decided to buy them locally.
When I needed to determine the length of the vertical supports, I had my measurements but asked, “what if I’m wrong?” I decided to pursue a design that didn’t require me to be right at the beginning in order for my project to succeed.
At every step of the process, I was open to the idea that I was wrong. This is why agile principles appeal to me…they acknowledge that you don’t know everything, and the decisions you make today won’t be perfect.
Maybe you didn’t pick the feature the customer most wanted. Maybe the design direction you chose wasn’t the best one. Maybe you get it all implemented only to find out that your architecture group has decided to use a different technology. Maybe you thought you could get all the work done in 2 weeks and it takes longer.
Being agile means you are working within a process and with people that expect that you won’t always be correct in your planning, estimates or decisions.
Thinking of a scrum process, every day you update your team on what you completed, what you will complete and what you need help with. This daily discussion allows for small course corrections.
Every sprint you demo your work and get feedback, giving another opportunity to course correct as needed.
Agile does not tie your success to your ability to make every single decision correctly from the start to the end of the project. It welcomes change with the understanding that we will know more about what we’re doing in a week than we do now and that’s ok.
If You Aren’t Learning, You’re Doing It Wrong
Agile is simply a series of small experiments made within a framework that supports evaluating results and using those results to make different decisions in the future. It can be thought of as a miniature version of the scientific method being carried out every day.
Agile Scientific Method
- Ask a question – “How do I make it possible for a user to do something?”
- Do background research – Research spike/user interviews/etc.
- Construct a hypothesis – “I think if we build this feature it will satisfy the user’s needs”
- Test with an experiment – Demo/Usability Study
- Analyze data and draw conclusions – Evaluate if the feature meets the need
- Use conclusions to modify this experiment or create a new experiment
Rinse and repeat.
Each story, each standup, each sprint is an opportunity to learn and improve. That is what agile means to me: learning and improving.
And that is just the process. The process is a learning process. The byproduct is well written, easily maintained software that makes customers happy. Agile is just the recipe making it all work.
A Final Thought
I hope you’ve enjoyed these articles. I may be correct in my conclusions. I may be wrong. In the spirit of agile, I’m ok with being wrong as long as I have a chance to get feedback and improve the next time.
As always, thank you for reading.