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.

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.

​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.