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.
"In preparing for battle I have always found that plans are useless, but planning is indispensable" - Dwight D. Eisenhower
There is always a fear when embracing Agile that things will fall into chaos and that planning and strategy go out the window. I have been on projects that have run into these types of issues and a big part of that stemmed from the team losing sight of the big picture goals and direction for the project. One thing that has been very helpful in preventing chaos and keeping things on track has been: release planning.
It is commonly agreed that collaboration for Agile teams is best when it is face to face. However, in an increasingly global world and with companies and workers focusing more on saving on costs by looking abroad, face to face collaboration is not always practical or even possible. Thankfully, there are many applications these days that have made it possible to work effectively with distributed teams regardless of where they are located and make it feel as if you are almost in the same room. Below is a list of five of my favorite tools for working effectively with distributed agile teams.
A team member once came to me and said that they're team was currently using Kanban, but that they wanted to switch to Scrum. When I asked why, their response was: "we need the two week time-box, because in Kanban everything goes into the in-progress column and just stays there". There are clearly many issues that would need to be addressed in this statement, but one that is very important that seems to be ignored on a regular basis is: WIP Limits.