Agility and Project Leadership

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!

This post from the Economist magazine mentioned by Scott Berkun's blog, underscores the importance of project management to the success of video game delivery:

Mr Mollick found that some 30% of differences in revenue between games could be attributed to the producer and the designer alone; and that the lion’s share of this variation was due to the producer. The boring project manager, in other words, meant more to the success or failure of the project than did the flashy designer... That means having a thoughtful producer on board, able to curb (or indulge) the designer’s wilder impulses and make sure that deadlines are met. Rather than being interchangeable, suggests the research, managers, and their talents, matter a great deal to the success or failure of their projects.

According to this article, the notion of "producer" is borrowed from the Hollywood model and is "akin to project managers in traditional software firms and are often resented by creative directors for the amount of control they exert".  One point I do find issue with in the article, is idea that project managers exert control which stakeholder resent.  Often times, the project manager has very little control yet is responsible for the success and delivery of the project and is why the profession is so hard!  This is especially the case if your a ScrumMaster running an Agile project since you'll have to engage in servant leadership.

But what I completely agree with is the notion that the management of projects by "boring", or I would much rather say, rational, calm, detailed oriented and seasoned project professionals is a large contributer to the succcess of projects.  I agree with Scott Berkun though, that to it is presumptuous to make the claim that the manager is more important then the designer or developer as all team members are important. 

The details of the Economist article can be found here, and while I have not read the academic article by Mollick yet, I'm glad there's research out there that backs up the what we as project managers all know, which is that our profession is not simply overhead but is vital to the success of critical projects.

I found this interesting post that outlines what the author belives makes the perfect ScrumMaster:

1. Servant Leader – Must be able to garner respect from his/her team and be willing to get their hands dirty to get the job done
2. Communicative and social – Must be able to communicate well with teams
3. Facilitative – Must be able to lead and demonstrate value-add principles to a team
4. Assertive – Must be able to ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
5. Situationally Aware – Must be the first to notice differences and issues as they arise and elevate them to management
6. Enthusiastic – Must be high-energy
7. Continual improvement - Must continually be growing ones craft learning new tools and techniques to manage oneself and a team
8. Conflict resolution - Must be able to facilitate discussion and facilitate alternatives or different approaches
9. Attitude of empowerment - Must be able to lead a team to self-organization
10. Attitude of transparency – Must desire to bring disclosure and transparency to the business about development and grow business trust

The one that caught my attention was the quality of being a servant leader.  The Greenleaf site which is inspired by the founder of the movement, Robert Greenleaf, introduces servent leadership by quoting Greenleaf who describes servant leadership as:

The servant-leader servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived?

Basically what this boils down to is having a ScrumMaster or project manager lead teams with a high emotional intelligence.  Instead managing through a command and control sytle, the ScrumMaster acts as a servant leader to the team. The ScrumMaster leads the team, but differently than the traditional project manager.

Servant leadership is about patient, respectful and selfless management of team members and encouragement of a more colloborative engagement.  A servant project leader will raise issues and remove impediments, without taking responsibility away from the team, yet stay in the background and supports team communication and team decisions with little intrusion.  It's about being a coach and mentor as well as manager and leader.

Though this notions fits the ScrumMaster role a bit better than the traditional project manager role, adopting a servant leadership style regardless of what type of project method or process you implement will make you a more effective leader in our modern, fast paced and networked world.