Agility and Project Leadership

In a previous post, I wrote a brief book review of "The Software Project Manager's Bridge to Agility" by Michelle Slinger and Stacia Broderick, which I felt was an excellent guide for the traditional software PM who needs to get up to speed with Agile/Scrum.  Another book I am getting acquainted with is the book by Robert K. Wysocki titled "Adaptive Project Framework: Managing Complexity in the Face of Uncertainty", that is another excellent book that can be used to bridge traditional process oriented PM practices with Agile ones.

In this book, Wysocki uses an analogy that differentiates between the cook, whose skill lies in following a recipe accurately and consistently, with a chef, who has the experience and skills to create new recipes for each dish and to improvise within existing recipes based on the circumstances at hand.  This is to distinguish a traditional PM who follows a PMO driven process and obtain success if the project is well defined and the solution understood.  Adaptive PMs, according to Wysocki, would thrive in situations where the project goals are partially or not specified and typically evolve as the project progresses and where the solution is speculative.

I'll take the analogy further and assert that APF as outlined and described in the book is really for chief chefs, such as PMO directors/leads and or Agile coaches to adopt, customize and implement the framework for their department or organization.  This is especially for organizations who have a traditional waterfall like methodology in place, but have found a need to incorporate more Agile practices.

Wysocki has written some in depth articles on Gantthead to describe the APF framework before the book was published, which has not changed much since the publication of the book and I recommend checking them out.

Though Wysocki's book is dense and academic, it does provide a sound theoretical framework for those who are in charge of managing and leading a company's traditional, prescriptive PM process and/or methodology to integrate Agile practices into them.

In summary, for those whom this book and "The Software Project Manager's Bridge to Agility" by Slinger and Broderick are targeted, namely those who wish to adopt and integrate Agile practices into their traditional process oriented one, these two books will work as book ends:  The APF by Wysocki is for those who are tasked with implementing Agile in a top down, across the PMO fashion, whereas the Slinger and Broderick book is for the PM who desires to integrate Agile into their traditional process bottom up on an actual project they are managing.

I highly recommend these books!

I've come accross some items recently, that seem to indicate an adoption or recognition of Scrum beyond software development and to general business management practices.  Below is a webcast for a Scrum conference with Jeff Sutherland speaking about how he discovered Scrum:

He mentions the discovery though a paper written by Hirotaka Takeuchi and Ikujiro Nonaka that I wrote an article for on this site.  But more interestingly is the initiative he mentions by Harvard Business School to include a cirriculum to teach Scrum to MBA students.

This is not surprising given the ridiculously fast pace of the information technology industry for which Scrum is applied and had its origins in.  But given the heavy reliance on these technological innovations (think of recent trends such as mobile, social media, cloud computing, etc.) by organizations all over the globe, their pace of acquiring and losing marketshare, churing out new products and keeping up with customer expectations has been just as brisk.

So it is no surprise that I also found this Forbes article by a well know business author Steve Denning, who writes about his discovery of Scrum when asking the question of how to combine rapid innovation with disciplined execution:

At the time, I was working on a book focused on resolving an old management conundrum: how do you combine rapid innovation with disciplined execution? I was proceeding by asking people if they knew about any such workplaces where this was already happening.

I surprised to find that an unusually high proportion of the workplaces that I heard about were in software development. Initially I didn’t pay it any attention. After all, these were geeks, and they talked in a strange, barely comprehensible vocabulary. What could I possibly learn about management from people who had, I imagined, gone into computing because they preferred machines to people?

A colleague, Hans Samios, a manager at Intergraph Corporation in Alabama, contacted me and suggested that I check out what was happening in software development firms, under the names of Agile and in particular, the practices known as Scrum. I had never heard of Scrum, but I decided to check it out.

He gives a brief overview and talks about the well known failures of Scrum (which is typically due to not having a deep understanding of the organizational culture change needed and the very human oriented nature of this process) and mentions the turnaround and 41% sustained growth by SalesForce.com after adopting and implementing Scrum.

These developments are interesting and show that the techniques and best practices within IT project management are starting to get recognition with the wider business audience that it deserves.

The official Scrum guide has been updated this month, and as site's page states,  " represents the official Scrum Body Of Knowledge, (that) was written by Ken Schwaber and Jeff Sutherland, co-creators of Scrum".  In other words, this is Scrum's equivalent of the PMBOK of the PMI.

At 17 pages, it is 30 times smaller than the PMBOK, but no less richer in it's method of project delivery.  Here's some of the major changes to the guide as outlined the co-founders Jeff Sutherland and Ken Schwaber:

• The team working on an increment is the Development Team (All team members will be known as Developers regardless of their roles)
• The Development Team does not commit to completing the work planned during a Sprint planning meeting
• Scrum does not mandate a burndown chart to monitor progress, but these two progress metrics should be updated
  • Remaining work for a Sprint that is summed and updated on a daily basis
  • Trending toward completing the work of the Sprint is maintained throughout the Sprint
• Release planning is not a requirement of Scrum
• The Sprint Backlog is the Product Backlog items selected for a Sprint.
• The Product Backlog is "ordered", instead of "prioritized"

The core of Scrum did not seem to change at all, but rather some finer points were clarified.  But much like the PMBOK, it is a body of knowledge or best practices that is left up to the practitioner to implement.  For those doing Scrum it's a must to review in detail.

In a previous blog, I wrote about the new plug-in for Visual Studio 2010 for Scrum that fully integrates the Scrum method with VS develoment using Team Foundation Server (TFS).  This blog from Brian Harry, a Product Unit Manager for Team Foundation Server in Microsoft, provides a glimpse into the next Scrum addition for the upcoming Visual Studio system called V.Next and TFS.  Unlike the previous version that you downloaded separately and plugged into VS 2010, this next version seems like it will be integrated right out of the box.  

The Microsoft team did an internal company survey and found that 84% of teams they interviewed were using the Scrum method:

Though this survey was informal and done with Microsoft customers, I think it does underscore the general adoption of Agile and Scrum in particular, for the software development industry.  It has “crossed the chasm” to use a term by Geoffrey Moore, and is now pretty much entrenched in the mainstream.

One particular tool I’m excited about is the web based story/Kanban board where you can drag and drop story tasks within the board for a full visualization of Scrum sprints:

This would be a great way to do daily stand ups where your team can visually see sprint tasks updated in real time.  For distributed Scrum teams, these can be done through a virtual conference meeting.

Interestingly, the co-founder of Scrum Ken Schwaber, criticises the proposed implementation of Scrum in V.Next and TFS  since “the right process produces the right result (from Lean). Similarly, the right implementation of the right process produces the right result.  Only build tools for things in which you have expertise, not just the experience”.

While I can understand his concern, I think this is typical of a technology, process or methodology that crosses the chasm of early adopters and becomes mainstream.  The bottom line as usual, is the team and ScrumMaster’s ability to use the method and the tool effectively to deliver projects to customer satisfaction.

I'm finally got around to reading "The Software Project Manager's Bridge to Agility" by Michelle Slinger and Stacia Broderick, which as the title suggests, is a guide for the tradtional software PM to get up to speed with Agile/Scrum.

This book is particular suited for those PMP's looking to leverage their knowledge of the PMBOK and how Agile/Scrum can map to it.  Both authors are PMPs and Certifed Scrum Trainers.  The first third of the book provides a good overview of Agile for those who are not familiar with the method and the jargon used within Agile methods. 

The second third of the book is where the meat of the book is, as Slinger and Broderick break down each of the 9 Knowledge Areas and ITTO (Input, Tools & Techniques, Output) and show how Agile can be utilized.  The strongest chapters are where the authors show how scope, time and human resource management could be substituted with Agile methods: e.g., How a traditional WBS could be broken down into a feature based product backlog, traditional planning schedules with Agile lifecycles (Sprints), and how to incorporate cross functional teams with traditional project resourcing that will allow team members to adapt and learn new skills.  The mapping with procurement management was weak, but then Agile movement has never really addressed this.

The latter third of the book covers the bigger picture topics for the traditional PM looking to migrate to Agile, such as the changes to the roles and responsibility of the traditional PM vs. the Agile/ScrumMaster and some sound strategies on how to overcome this.  There are also chapters on creating an Agile PMO, selling Agile and mistakes to avoid.

Though the book provides a good overview of Agile as well as strategies on how to adopt this for the larger enterprise, the book is really for the traditonal project manager who is well versed in the PMBOK and looking for a way to deploy Agile/Scrum on a particular project.  It is a bottom up approach to bridging the gap between agile and traditional project management.

The authors provide a detailed side by side comparison of each of the ITTOs within each of the nine knowledge areas and how to migrate to a Agile method/process and do so within a vocabulary and framework a typical PMP certified project manager would understand.

Conversely, this book would work for the Agile PM/ScrumMaster looking to see how his/her knowledge areas map to the traditional PMBOK based practices.  I highly recommend this book!