In this very special video episode of the podcast, I’m joined by Jesse Fewell, whose new book Untapped Agility is full of insights, tips, and tactics that you can use to help gain support for your adoption of Agile. Jesse and I go way back. We worked together a lot during the initial phases of getting The Project Management Institute and the Scrum Alliance to talk back in 2009-2010. It was great to catch up with him and I highly recommend his new book.
This is part 2 of my interview with Tony Johnson from Crosswind PM. In this part of the interview Tony and talk through his recent experience attending a Disciplined Agile Training event held by PMI. We also share our thoughts and opinions on why PMI acquired Disciplined Agile and Flex and how we are expecting that to impact the Project Management community.
In the first part of the interview, which you can find here, Tony and I discussed some of the upcoming changes to the Project Management Institute's Guide to the Project Management Body of Knowledge (PMBOK), how that will impact the PMP Exam, and the impact you can expect it have on your work in PM.
If you’d like to reach out to Tony with follow up questions:
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.
Failure Bow
So… time for a Failure Bow
(If you aren't familiar with the Failure Bow, I'd like to recommend watching the Matt Smith TED talk below.)
While it would be easy to rip myself up for losing step, I knew that was going to happen at some point. What I was more interested in was what it would take for me to recover when it did happen.
Since I’d been keeping detailed notes on what was and was not working I turned to those to try and see what issues were causing the biggest trouble.
“Hi, My name is Dave… and I’m a Things-aholic.”
I was still using Things every day. I was recording tasks on my board and working them, but there were additional items in Things that I worked on and they never made it to the Kanban board. Most of them were personal items, but it did seem kinda of pointless to me to be working with two tools at once. It just divided my focus and make getting anything done that much more complicated.
I decided that I was going to start capturing everything I do on the board. I took everything listed in Things and created a post it for each item. I sorted and grouped the whole thing on my Kanban board. My plan was to try and go one week without using Things. During that time I would rely 100% on the Kanban board.
I made some modifications to the layout of my board as well. I added blocked boxes for some of the swimlanes and also made adjustments to my WIP limits.
I decided that I would start each day with (re)prioritization
I had learned that travel can have a very negative impact on working this way. I had a number of jobs coming up that would require travel. So, I decided to start researching electronic tools so I could test one out during my next trip.
One of the things I have found to be invaluable in this whole process is having the physical board to return to when things break down. There have been a number of events and situations that resulted in me needing to reset my approach. I’ll be posting about them in the coming weeks. For anyone who is going to try personal kanban, my first advice would be to start out with a physical board and develop good habits with your practice. These will be an important touchstone for you as you work through the changes this approach will have on your work.
The final thing that came out of my retrospective for iterations 3 and 4, was a new question… what should I do about recurring tasks? Was it really going to be worth creating post-its for recurring each item so that there was a card for each one on each day of the week? That seemed ridiculous. I had no answer, but sometimes, just having the question is a good start.
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.
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?
This is part 2 of my interview with Tony Johnson from Crosswind PM. In this part of the interview Tony and talk through his recent experience attending a Disciplined Agile Training event held by PMI. We also share our thoughts and opinions on why PMI acquired Disciplined Agile and Flex and how we are expecting that to impact the Project Management community. 
So naturally, the obvious next step was to completely screw that all up.
I was still using Things every day. I was recording tasks on my board and working them, but there were additional items in Things that I worked on and they never made it to the Kanban board. Most of them were personal items, but it did seem kinda of pointless to me to be working with two tools at once. It just divided my focus and make getting anything done that much more complicated.
One of the things I have found to be invaluable in this whole process is having the physical board to return to when things break down. There have been a number of events and situations that resulted in me needing to reset my approach. I’ll be posting about them in the coming weeks. For anyone who is going to try personal kanban, my first advice would be to start out with a physical board and develop good habits with your practice. These will be an important touchstone for you as you work through the changes this approach will have on your work.
