ProjectsatWork has published a study called DistributedAgile Teams: Achieving the Benefits. The report was put together by Elizabeth Harrin (@PM4Girls), who is the author of the website A Girls Guide to Project Management. The results of the research cover a lot of ground with respect to what makes distributed Agile projects work and what can contribute to their failure. The report is very insightful and definitely worth the time it takes to read. While some of the findings may seem like common sense, knowledge workers in the IT space (myself definitely included) seem to possess a remarkable capacity for periodic loss of grip to that tether.
My favorite part comes at the very end during the summary of recommendations. Number One on the list is:
This is one of the most simple things that so many of us forget when we are working at a distance. I believe this applies whether you are working down the hall from someone, or across the globe… there is a price that has to be paid when you are not sitting in the same room. With the transparency that Agile offers, this tax becomes far more obvious. There is no doubt that distributed teams provide a number of benefits, but those benefits come at a cost. The reason (IMHO) so many people struggle so much with distributed is that they keep thinking that the ride is free ... which it theoretically could be… unless you actually want it to work.
When I am teaching CSM classes one of the commonly asked questions usually doesn’t show up until almost the very end. When it does, it comes disguised in various explanations and wrapped in deeply detailed back story. In the end, it always boils down to the same question… “How much of this do I actually have to do?”
What strikes me as ironic is it always seems to come at the end of a 2 or 3 day class where we have spent the time discussing an approach to work that is more lightweight than has been used in the past. So, we’ve removed all the extraneous process, lots of the burdensome paperwork and a kitchen sink’s worth of other stuff but the question is still centered around on defining the bare minimum (of the less burdensome process) that must be done.
If the person asking the question is specifically concerned about reaching a state of Agile Nirvana-ness, or works for a company that awards gold stars for Agility, my recommendation would be apply no less than the amount of <methodology or framework of choice> as is required to deliver working product. This is one of the primary way we measure success in Agile. But most organizations do not give out a prize for being “TOTALLY AGILE”. And at the end of the day, the job is to deliver something that works, which can improve the company’s financial position in one way or another. In order to reach that goal, one must apply no less than the amount of <methodology or framework of choice> as is takes to reach that state.
But for many of us, especially those trained in traditional project management, we need a line in the sand. We want something helps us know when we are fighting for the Empire or the Rebel Alliance. (One more reason we should all be issued orange jump suits when we take CSM training.)
There are specific elements in the Scrum framework that (IMHO) when left out result in the practice of something which is possibly Agile, but no longer Scrum. However, my list is based on my own personal understanding of what SCRUM. This begins with what is defined in the Scrum Guide (and related documentation) and is then filtered through my own empirical approach and experiences. I’m quite sure solid arguments can be made to dispute each item I would include (or not include) on that list of what is required to do Scrum.
In my own personal practice of Scrum, there are two parts to the answer. The first part of the answer is that each person involved needs to apply no less than the amount required to complete work that can drive revenue. The second part if that in order to truly see the benefits that Scrum (or any Agile practice can provide), I have learned that it is best to start as close to a pure version or the practice as the individual’s organization can tolerate. Each iteration offers an opportunity to plan-do-check-act over and over again. Each time we go through those steps we should making adjustments until an optimal practice of Scrum emerges. Once this optimal practice does emerge, they must never stop finding ways to break it and make it better.
What I am more curious about is what drives the desire to find the bare minimum of the newer, more lightweight process. My expectation is that it stems from a perception that Scrum would be difficult to implement within the context of whatever waterfall-esque process is currently in place. This could easily lead to the question of how much can we leave out and still technically call it Scrum. But again, at the end of the day, bonuses are rarely awarded based on Scrum purity. And there are, unfortunately, far too many organizations, teams and individuals out there who have jettisoned all but the vocabulary and still feel comfortable calling it Scrum.
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?