"Agile won't work for us" is something I've heard many times throughout my career. It is typically from companies that have tried and had a bad experience or people who have assumptions about what it means to try Agile. In this article I will share 4 common Agile myths in the hopes that teams that have been hesitant to try it out, might take another look.
When you're faced with a difficult problem it's easy to be overwhelmed with anxiety. This can lead to paralysis which prevents any chance of moving towards a potential solution. In his book How to Stop Worrying and Start Living, Dale Carnegie outlines a simple (not to be mistaken with easy) 4 step process that you can try the next time you feel stuck (some of this will feel obvious, but its surprising how often we forget these things when stress takes over).
If you haven't heard yet, Ted Lasso is one of the best shows to come out in the last couple of years from any streaming platform. The story revolves around a friendly, college football coach who is brought to England to coach a struggling soccer club. Everyone thinks this is a crazy decision by the team's owner and that he will fail, but with Ted's positive attitude and focus on developing people he can't be counted out. The show is very funny and full of heart, but what surprised me the most was how much I learned from Coach Lasso with regards to leadership and team building. In this article I will be sharing 5 leadership lessons that stood out to me while watching Ted Lasso (Spoilers for season 1).
As part of my team's workflow, every two weeks we take some time to have a retrospective session (we are currently using Scrum). Although the format can vary, we normally keep things pretty simple and talk through what went well and what could have been improved during the sprint, and then we come up with a few action items to work on the next one. I have helped facilitate many of these retros and one thing that I started to notice fairly regularly was how easy it was to quickly jump into where teams wanted to improve and only briefly touch upon (or completely skip) what had been working well. With the focus that agile frameworks place on continuous improvement, it is understandable for teams to want to find ways to fix things they feel aren't working, but I have found that focusing on what has been working can be just as important in ensuring the team continues to succeed.
MVP, which stands for Minimum Viable Product, is a concept that became widespread as many companies began to adopt Lean Startup principles and practices. Much like other popular movements (Agile for example) Lean Startup introduced ideas, such as the Minimum Viable Product, that can be very powerful and helpful for organizations, but that can also cause a great deal of friction if not understood and used correctly. In some of the companies I have worked with, the term MVP had actually begun to develop a negative connotation and caused the companies to avoid using it when it could have helped the most. In this article I want to revisit the idea of an MVP and talk about what it is and why it is an important practice.
When you are juggling a bunch of work, whether it be in your personal or professional life, it can feel like everything is equally important and that there is never enough time to do everything. If you are working on a team this can get even worse as people will have different ideas on what is higher priority and which items deserve more time and effort. This can lead to many long and frustrating discussions and everyone might eventually start to feel stuck. One tool that I have found to be very useful in reducing the emotion around prioritizing work and helping teams move forward is a simple metaphor involving rocks, pebbles, sand, and a jar.
A common concern for many development teams when they are planning a project is avoiding rework. There is the idea that if they can think through every scenario at the beginning of each stage of the project, they can avoid having to redo designs, documentation, or code in the future. On the surface this is understandable, as having to redo tasks unnecessarily can definitely be wasteful. However, anyone who has worked on a project, especially an Agile project, knows that once a design or feature has been released to end users, there will always be unexpected feedback that will necessitate rework.
Find all hidden work to see why your time is disappearing. One of my passions / favorite things is finding ways to bring Agile into my everyday life to make things more effective and allow myself more time and freedom to do the things I want / to make the most of my days. I have recently started reading the Life Changing Magic of Tidying Up. I have been enjoying the book immensely and one of the things that has really stood out to me is how much crossover there is between many of Marie Kondo's strategies and philosophies and those of Lean and Agile. One of the first parts of the books talks about why she tidies items by category and not by location and it reminded me a lot of what Lean and Agile try to accomplish by making work visual. According to Kondo, you need to organize by category (clothes, books, etc) instead of by room so that you can see exactly how much of each category you have. If you organize by room, you may not identify all of the clothes and you will always need to reorganize. The same goes for work within a team,
There are many great books that talk about Agile theory and principles and these are important to building a theoretical foundation for any new Scrum Master (or any new Agile leader for that matter). However, in order to be an effective Scrum Master and Servant Leader, it is essential to learn how to provide coaching and build up high performing, self organizing teams. This is always listed as skills that Scrum Masters can provide, but most training courses and Agile books focus more on tactics and don't often provide guidance to new Scrum Masters on how to develop the more nuanced skills that the position will require for success. Below is a list of the books that I have found most helpful in improving these skills and that I wish I would have read before I started building out my first Agile teams.
If you work in any sort of management position or in a team environment, it is very likely you have heard the term "self-organizing" team. This is something that has become a key ingredient in high performing and motivated teams and when I first learned about it it made total sense. However, it is such a high-level concept that I had no idea how to actually go about coaching and encouraging teams to effectively self-organize. After a great deal of research, experimentation, and failure, here is a list of tips that I wish I would have had when I was first getting started.