Off the Rails…
It was all going so very well. By the start of the 3rd week I was beginning to get the hang of the process. I wasn’t a shining model of productivity, but I was certainly making improvements. I was learning a lot about how I worked and what I needed to do to become more productive. I had started making notes about all the experiments I wanted to run in the coming weeks. I was keeping my PK Journal up to date. The only issue was that I hadn’t tried it with real work yet because I was also still on staycation. (I travel a lot for work, so when it comes to vacation, I’m totally happy to just spend the time at home becoming fully present with what a bad decision it was for someone who is horribly allergic to cats to adopt three of them.) Being at home for the first part of this experiment had allowed me to establish the physical habits of personal kanban and my hope was that this would keep me rooted in the practice once I was on the road again.
So naturally, the obvious next step was to completely screw that all up.
I had planned to be away on a retreat for a few days during the 3rd week. While I was there I picked up a slight cold that immediately turned me into a walker for about 8 days. Both of these events meant that for a period of almost 2 weeks, I was completely unable to do work on anything on my board.
So… time for a Failure Bow
If you are accustomed to working within the context of a traditional approach to managing projects you are probably familiar with the idea of doing a post mortem, or review at the end of a project. The objective of this meeting (or set of meetings) is to examine what has taken place and find a way to generate lessons learned which could be used to improve future efforts. In theory, this sounds like a great idea. In practice, however, there are two problems with this approach. First, they are rarely done with the regularity, or rigor required for them to truly add value. More often than not, team members are reassigned and send off to work on new projects before the project review can be conducted. Second, when project reviews are conducted, it is typically to focus only on the things that went wrong. Unfortunately, this often turns into a finger pointing session that does little to recognize the things that went right, and often is more centered around hanging blame on individuals than on determining the practices or processes that allowed the trouble to start in the first place. There are, to be sure, exceptions to the above, but in a traditional model skipping this critical step is far too common.
Repeatedly taking the time to examine how things are going is something that is baked right into an Agile approach. Scrum, for example, is defined as being built on “three legs”: transparency, inspection, and adaptation. If you are practicing Scrum, each Sprint includes the Sprint Retrospective, a “ceremony” where the team meets privately to inspect how they are working and to determine what steps they need to take in order to improve during the next Sprint. While a disciplined traditional approach may include a review at the end of each project (or ideally, the end of each phase), in Scrum, this happens every 2-4 weeks. It is the last official thing a team does during each Sprint.
The Scrum framework offers a more lightweight approach than you’ll have under a more traditional methodology like the one defined in PMI’s Guide to the Project Management Body of Knowledge (PMBOK). Because Scrum has removed so much of the process overhead, one of the things that teams come to depend on is the cadence of Scrum. We begin each Sprint with our Sprint Planning meeting; we hold a Daily Standup (or Scrum) meeting each day (at the same time in the same place); we hold a Demo (or Review) meeting with the stakeholders at the end of the Sprint and we follow that up with the Sprint Retrospective. Each of these practices provides opportunities to inspect and adapt, but it is the Retrospective meeting where the team comes together privately to exhale at the end of the Sprint and work out how they, as a unit, can become more effective.
Another interesting aspect of the Sprint Retrospective is the way the meeting is conducted. Teams will often start by focusing the positives and identifying what went right during the Sprint. Even if the Sprint did not go well, there is always something positive that can be gleaned from it. When the team talks about what could have gone better, the goal is to offer constructive criticism geared towards enabling them to function better as a unit. The subtle shift in from focus on “you” to “we” is a very important cultural change for those of us making the switch from a traditional approach. Before the Sprint Retrospective ends, the team will come up with an action plan for the next Sprint so that they can do more of the good things they’ve identified and take steps to correct some of the things that did not go as well as they could have.
If you are new to Agile, it may seem unnecessary to hold reviews with the frequency called for by Scrum - especially if things appear to be going well. Many rely on the old adage, “if it ain’t broke, don’t fix it”. The problem with that approach is that it becomes far to easy to overlook things until a time when they are so clearly broken, that there is no way back. If we are always inspecting and adapting, we are far more likely to catch things while we still have the ability to make any necessary adjustments.
If you are interested in learning more about Retrospectives, there is a great book by Esther Derby and Diana Larsen called Agile Retrospectives: Making Good Teams Great.
Since I posted my comments on the change to the Scrum Guide, I have had the chance to teach two Certified Scrum Master classes. Despite my issues with the change, my desire to be transparent about things won out. I am still teaching commitment and explaining why, IMHO, it is so critical to the Team. However, I am also explaining the change in the most recent Scrum Guide and the argument for use of the word “forecast”. In both cases this has generated some healthy discussion within the class and my hope is that the participants will leave the class well enough informed to make up their own minds about it.
Talking through the commitment vs. forecast question in the class offered a great example of one of the truly awesome things about Agile. Regardless of which flavor(s) of Agile you are working with you can expect that the standard will continue to evolve and change – and that is baked right into the different frameworks. So, as the workscape continues to grow and transform, expectations for productivity continue to increase and as knowledge workers continue evolving how they approach the overwhelming volume of information they have to deal with on a daily basis, it is safe to say that the techniques we apply in Agile will continue to evolve as well. This may not sound significant on the surface, but I would like to offer two points to illustrate why I believe the organic nature of Agile is so critical.
1. Knowing that you are working with a methodology or framework that is going to continue to evolve and change places a different sort of demand on the practitioner. When working with a standard that is more, or less, locked down, many people reach a point where they believe they have finished learning it. Hopefully this is more the exception than the rule, but the problem is that they are able to get to this point in the first place. With a standard that is not locked down, that continues to keep pace with the changing workscape, the only way for the worker to remain viable is to continually grow their own knowledge and experience in step with the practice. This forces Agile practitioners to approach their work as a learning experience, which requires a level of awareness and attentiveness that is not called for by someone who has already “learnt” it.
2. For the practices themselves, once they are locked down, the change control process can become such a burden that the framework, or methodology becomes static. As soon as this happens, it begins to lose its’ ability to provide value in a continuously evolving workscape. If Critical Chain really was the last new tool added to the PMBOK, than that means that the process most of us have come up with reached a static point during a time when:
· Most of us used Windows 98 or NT
· Most of us probably got online using AOL and a 14.4 Baud dial up modem
· The iPod did not exist
· We had never heard of Monica Lewinsky
· We had never seen the Matrix
· We were probably still watching George Clooney on E.R.
· We were still two years away from hearing the phrase “Hit Me Baby One More Time.”
It is clear that our world of work has changed significantly since 1997. The way we deal with our work has also changed significantly since then. Why then, wouldn’t we require that of our process as well?