[Lessons Learned] Applying Agile Principles to Life

Random Observation/Comment #447: Don’t try to find a one-size fits all solution. It doesn’t exist.

After taking a full week of training courses and becoming SCRUM certified, I learned quite a few remarkable characteristics about agile that I could apply to my own life.

For those who don’t know, agile is a methodology around iterative development, continuous improvement, and complete transparency. In my opinion, agile solves many of the problems faced in heavy waterfall companies by holding the resources and time constant while varying the scope – thereby giving the deliverable prioritization and decision making back to the customer. This keeps the customer engaged and produces a very lean and motivated team.

These main principles of agile have been appropriately ported over to my own life:

Kaizen!

• Continuous Learning. Kaizen philosophy revolves around continuously improving oneself. If you improve 1% every 2 weeks, you will be 25% better after a year. This is more than about being smarter every day – it’s about pacing your improvement. Realize that it’s impossible to do a 180 and expect it to stick – it’s much more manageable to adjust your habits one smaller segment at a time (30 day challenges!).
• Invest in your team. In agile, the team is most important because it’s the one that delivers. Make sure you grow this team by broadening their knowledge base where needed and addressing their needs. In your personal life, know which friends are helping you and help them back. Give back to the community and look to improve other people. Once you invest in that bigger community, you’ll find you’ll improve with it as well. When you invest in the team long term, you will grow a group that trusts each other and delivers efficiently.
• Remove single points of failure. For an individual, this means working on your weaknesses, but as a team I think this means sharing your knowledge and growing the team’s capability. Any silos of knowledge and silos of skills will bite you in the butt later on. Trust one another to learn and grow.
• Adding a resource will hinder team development. Remember that changing aspects of the team will almost definitely reduce productivity. This is sometimes unavoidable when there’s unexpected turnover, but be sure not to manage in a way that thinks throwing more resources at a problem could reduce the amount of time it will take.  In life, make sure your personal board of executives that help you with life decisions stays constant. Build that trust with them and rely on them.
• Hold Retrospectives. These are lessons learned meetings that aim specifically for actionable changes that can be applied to the next sprint (work session). I personally always set up end of month retrospectives just to update my list of triumph moments of the month as well as regular progress towards my 30 under 30 goals.

Limit Works in Progress

• Fewer and more manageable user stories. In agile and kanban, we only give the dev team a smaller number of prioritized user stories at a time. We do not over burden them with the whole list of features expected because it becomes demotivating when facing a giant wall. Instead, management only puts what can be completed in 2-3 days and continues adding to the list once most of the user stories are complete. In our personal life, we should do the same with our tasks. Prune your to-do list to more manageable short term tasks and you will be able to complete them.
• Don’t multi-task. Along the same lines of giving too much work, try to instill finishing one thing in a stretch of time instead of switching between tasks.  It’s far easier to start a project than to finish one, so just start fewer projects. Do your top 3 first and ignore the rest until those 3 are done.  Remember: Starting a project means nothing. It just distracts you from your other existing projects. I would rather finish 2 things than start 10.
• Groom your backlog. Half way through every sprint, there is a session to review your to-do list and reprioritize based on current progress. This exercise is extremely important because it also motivates the team to see the bigger picture. In my own life, I set up time specifically to look at to-do list items and reprioritize them.  I usually save the lessons learned for the month-end retrospectives.

Definition of Done

• An incomplete project does not get credit. In agile, user stories represent full front-to-back integration. It’s about concept to cash and not just fluffy tasks that build layers.  It’s a workflow that business can derive value from.  In many cases, you may not finish a full user story in the given sprint time (2 weeks). If this is the case, there is no partial credit for an incomplete user story.  This concept encourages developers to complete meaningful contributions before jumping around to other ones. It creates focus and also supports measurable end points. In my life, I try not to post accomplishments until they’re actually accomplished. Talking about Works in Progress gives an elation of praise and recognition for starting a project. I think the real challenge is completing it.
• Write thorough acceptance criteria. A project is deemed ‘complete’ by fulfilling multiple acceptance criteria set by the team and Product owner before the project starts. In life, if this is a personal goal that’s vaguely immeasurable, you are usually creating these end points by yourself. When you do this, make sure you discipline your goal to know when it’s actually completed.

Know Why

• People are driven by why. If you’re in a team, keep the goals transparent to the business value. Set the bigger picture and work backwards from there.  In most cases, you’ll find that the team will come up with a better solution than just one person, so if you don’t share the full reason behind it, you will stiffle team creativity.  In your own life, ask yourself “why am I doing this?”  If it’s very clearly to make money to support an expensive alcoholic and consumer life style, then fine. If you’re also doing it because you love the job and the people you work with, then all the better.
• Green statuses are bad.  Along the same levels of why, it’s important to have challenges and friction. In relationships and personal life, we shouldn’t just be making easy decisions. If all decisions were easy, then we’d have no real choice and fate would determine everything for us.  In the same light, you may not want life to always be a green status.  This doesn’t always mean to add entropy to mess up something good, but it does mean that you should always stretch yourself to complete more and continuously grow.
• Servant leadership. In agile, management and decision makers do not make promises until the team agrees. This is because the team is the one that’s doing all the work. In the same way, I feel like management should be leaders from the bottom up. We want them to protect us from BS, but also step out of our way when we’re doing great.  We want to be inspired by them and not just do what they say because we have to.  Money should not drive the team. Team should drive the money. This is the independent self-regulation our life needs.

The biggest take away for me is to treat your life as a product. If you invest in it, then it will succeed – you will produce new ideas and contribute to your community.  Make sure your product is healthy by focusing on a handful of major projects at a time and learning from every experience.

~See Lemons Agile