This past week I had the pleasure of meeting Lucas Boyce, current executive with the Orlando Magic and former White House staffer, at a local economic development event here in Gainesville. I highly recommend Boyce’s story of moving from foster care to the White House, but I was really struck by two points from his speech.
Even though he focused mostly on changing your own life to impact your community, his words really resonated with me as a teammate, especially here at 352. Let’s talk about the “Four Ps for Success” and “Building Each Other.”
The Four Ps for Success: Agile Development Application
We all have heard cliches like, “No pain, no gain,” “hard work pays off at the end”, “you reap what you sow.” The “Four P’s” by Mr. Boyce give some of these tired sayings a renewed flavor which I was able to instantly relate with some of the success my team has been experiencing lately.
Pain is something most of us actively avoid, but the Agile philosophy is a great proponent of feeling pain as early as possible. If you are going to have pain, discover it early and deal with it. That doesn’t mean that you’re creating an early feedback loop; it’s about building a healthy development cycle (that may include some painful activities).
For example, if you cut some corners to deliver something faster, you’ll feel the pain incurred by the technical debt you are accumulating. As soon as you feel that pain, stop and work to fix it. Non-trivial deployment steps are always a constant source of pain. Automating will be a time investment up front but you will soon feel the recurring pain of deployment. As soon as you feel it, automate.
Patience is required to endure pain and to fix the pain points exemplified. No one likes to feel pain, but you have to work through it if you want to succeed. Automation often entails highly tedious trial-and-error, along with repetitive programming and configuration. But remember, no pain no gain!
Plan is more or less gospel truth in Agile, and software development in general. We do Sprint Planning to provide a roadmap and to provide a compass for a direction once we’ve started down the path. And of course, patience is necessary to both construct and execute the plan (if you’re starting to sense that the 4 Ps are very inter-connected, good).
Prize is what we’ve been striving for. It is the promise, the religion, the superstition, the law of the universe of being rewarded for hard work. Just to throw one more cliché at you: Good things come to those who wait. A prize is given to those who endure pain and have the patience to follow through a plan.
Recently, my team has experienced tremendous success that directly correlates to the four Ps. When we succeed as a team, the results are obvious to our customers: we always deliver results as a team, and those results speak for themselves. This success has been more internal.
We worked only on well-defined user stories. Instead of strictly enforcing time limits and cutting corners during the sprint planning meeting, we stayed the course and insisted in correctly breaking down stories into well-defined, independently deliverable chunks instead of having epic stories in the sprint.
The resulting estimates were more correct, allowing us to trust the velocity speedometer more. Our stories were fully tested, QA was integrated into the team without a dividing wall, stories were incrementally demoed to the customer, and code was launched at the end of the sprint with nothing pending to be done.
We were done, done, done. I think it all started with feeling necessary pain, having the patience to follow a plan and finally receiving the inevitable prize.
Build Each Other (spoiler alert!)
The final part came as an inspiration for our next set of awesome changes and improvement. When talking about his achievements, Boyce mentioned one crucial ingredient as being how his family was a big part of his success. Specifically how the family members build each other.
At 352, we believe teamwork elevates our talents, which gets us halfway to Boyce’s vision of success. We are friends at work, we have fun and we support and elevate each other. That elevation stems from my skills combining with my team members’ and elevating me to a status I could not reach on my own. I take Boyce’s “build” to actually mean building an individual.
I’d like to ask Mr. Boyce how his family built each other, but I think it’s important to ask questions of our own team families as well.
- How do we currently build each other in our teams?
- If we don’t, should we be doing it?
- What are some of the ways we could start building each other?
Ask and answer your own questions in the comments!
Image credit: Greg Westfall