Agility and Project Leadership

While I’ve been a big advocate of using Scrum for time critical projects involving new product and software development, I’ve not been convinced this project method works for very large scale, multi-located or globally dispersed project teams.  Scrum has had the most success in software development and when coupled with Extreme Programming (XP).  The reason for this is that XP advocates pair-programming and co-located teams which is conducive to Scrum’s facilitation of self-organizing and cross functional teams.  There are other aspects to XP such as unit testing and continuous and integrated builds which is also conducive to Scrum’s iterations of sprints.  But it is the close proximity of teams and communication which allow Scrum and XP to work so well.

But can this scale to large, globally dispersed and multi-located teams?

Some in the Agile community say it can and some have called it managing a “Scrum of Scrums”.  Mike Cohn was one of the first to advocate this.  But his focus is mainly on how to run stand up meetings with multiple Scrum teams.  While I think this is important, it doesn’t quite cover the huge gamut of processes that would have to take place to effectively run a Scrum of Scrums.  This post by Vin D’Amico of BrainsLink.com is a good summary of the gaps you must address for doing a Scrum of Scrums:

• A lot of daily meetings. Granted, worst case is that someone at the top of the hierarchy must attend all three types of meetings. To lesson the burden, it may be better to reduce the frequency of the Scrum-of-Scrum meetings. Two or three times per week may be sufficient.
• The big picture may be lost. Each Scrum team has a ScrumMaster and a Product Owner who are experts in their areas. Who is the expert on the entire system? Who will ensure that the components developed by the teams will fit together and operate cohesively?
• Coordination is missing. The Scrum teams cannot go merrily along developing their pieces of the solution in isolation. There must be significant coordination among the teams. How does that happen? How does everyone stay busy without wild swings in workload?
• Vertical slicing becomes very difficult. Scrum teams are encouraged to implement features not components thus biting off vertical slices of the system. Doing so across multiple Scrum teams creates major configuration management problems. It can be done and it will be difficult.
• Testing becomes an even bigger problem. Features and components may work properly but the complete system may not. Who tests the entire system? How are the testing efforts coordinated?

I don’t think Agile/Scrum adequately address this.  Glen Alleman of the popular Herding Cats blog agrees and states that what the Scrum proponents are advocating with a Scrum of Scrums is a notion from the System Engineering field established before Scrum which is the idea of managing a System of Systems.  As he states, “all this tells us is that simply having multiple Scrums working on multiple threads in the project may be necessary but is far from sufficient for success. Much more is needed to control, coordinate, and define the processes between and among these parallel work elements.”

I found the picture below which gives a good graphical diagram of what a Scrum of Scrums could look like:

As can be evidenced even in this simple diagram, there’s a complex flow of communication, coordination, processes and work that would have to be managed using a rigorous system oriented approach to ensure the self-organizing, “emergent” deliverables from the Scrum of Scrums get completed on time, within budget and to scope/requirements.

If any readers out there have managed, attempted to manage or thought about managing a Scrum of Scrums, please let me know!

One of the better books I read recently that gives a broad, yet practical overview of Agile project management is the book by Jim Highsmith titled “Agile Project Management: Creating Innovative Products, Second Edition” published in 2009.
 

Though I do find the book to be a bit overzealous at times in it’s advocating of the superiority of Agile methods over traditional project management, it can act as a good guide for those from the traditional, process oriented side to get a broad overview of Agile.  He outlines an “Agile Project Management” (APM) delivery framework that incorporates five phases of Envision, Speculate, Explore, Adapt, and Close, which closely maps PMI’s five process groups of Initiating, Planning, Executing, Monitor/Control, and Close.

What I’d like to talk about is one section from Chapter 2 titled “Simplicity” and especially with regard to the section about “Delivery vs. Compliance”.  Agile practices have a strong emphasis on delivery, since the deliverables of the project are what really bring business value.  I will agree with his assertion that too many process oriented organizations get too pre-occupied with compliance items such as status reports, schedule, and project documentation and mistake these as being the true deliverables of the project, when in fact at the completion of the project, very little and in some cases, none of the business values were realized.

My problem though, is that some Agile advocates have taken this to mean that ALL compliance activities and artifacts should be discarded and use this to site why process oriented project management fails.  The reality is that in many, if not all cases with projects that have a fiduciary obligation to be meet with stakeholders, there will be a need for the Project Manager or Scrum Master to provide status and documentation and if your working in a highly regulated environment like finance or healthcare, there are compliance duties you must adhere to for regulatory compliance and approval that if not met, can be catastrophic for the company involved.

I think this is where a highly competent and experienced Project Manager or Scrum Master would have to employ his/her skills to know what is needed for compliance and minimize or eliminate if possible, these activities from his/her team members so they can work to deliver the project deliverables in a timely manner and with the highest quality.  It will be a constant balancing act to manage and balance the tensions between ensuring compliance and delivering business value.

Contrary to the image of a Scrum Master who steps back and just lets their team self-organize or the traditional Project Manager who micro-manages their team’s task to each line item on the WBS and checks these off for a status report, there are lots of leadership and management skills both subtle and multi-faceted that a great Project Manager or Scrum Master will know how to employ, which will ensure these roles will be in demand for some time to come.

What do you think about balancing business value verses compliance for your projects?

Love it or hate it, the defacto project management software tool is still Microsoft Project.  The latest version is 2010 and was featured on the Project Management 2.0 blog by Dave Garrett on this site.

The improvements I like are the easier integration with SharePoint and other Office tools, especially Excel.  The biggest change was the ribbon menu that was introduced in Office 2007 products and is now part of Project 2010.  The most interesting development to come for this new Ribbon interface, was a solution starter kit from the MSDN development team to enable you to do Scrum in Microsoft Project!  It adds a new ribbon tab when you pick a Scrum template from the “New Scrum Project” list.

This add on is focused on the desktop client and managing individual Scrum projects by a ScrumMaster to track and manage sprints by:
 

• Collecting and tracking status
• Managing the product backlog
• Managing the sprint backlog (and initial iteration planning)
• Viewing a burn down chart
• Easily exporting Scrum data to email/other apps

The add on does not have features for Project Server 2010 integration, PPM/EPM views or “higher level scenarios like integrating Scrum with EPM, or using Project to manage Scrums of Scrums (or Scrums of Scrums of Scrums…)”

Rather than provide screenshots which are already provided in the downloadable guide on the site, here’s a great overview video on how to use the add-on:
 

I know many Agile/Scrum purist would scoff at using such traditional Gantt based desktop PM tool like MS Project, but for many project managers making the transition to Agile/Scrum or existing ScrumMasters who are in an organization already using MS Project 2010, this is a great and cost effective way to do Scrum in an existing tool you are already familiar with.

Furthermore, if like me you are interested in modifying and/or extending the features of this ribbon, you can also download the source code from the site.  It is provided as a Visual Studio project file and was developed in C# using the Visual Studio Tools for Office (VSTO) module.  When it comes to Office automation, I’m a traditional VBA guy, but have been wanting to look into VSTO but not enough time or interest to do so.  This add-on’s source code has provided motivation to do so now (Please make sure to read the license agreement for the source code to understand what you can or cannot do with the source code and add-on).

I be sure to post updates on this add-on as I experiment with it more.

I found this excellent post by Mike Griffiths, that shows a Venn diagram of how PMI's new ACP cerfification maps to all the various bodies of knowledge from PMI and Agile:

I'm still skeptical of the adoption of this certification by the project management community, especially those from the Agile camp.  Futhermore, the other certifications from PMI for risk, scheduling and program management do not seem to have come close to the popularity and adoption of the PMP, which may be indicative of how this certification pans out.

Only time will tell...

1. Choosing Leaders. For each piece of music Orpheus performs, a committee of musicians chosen by orchestra members selects a concertmaster, the first-chair violinist. The orchestra's members also select a leadership team of five to seven players, called the core. In Orpheus, the concertmaster anchors the core, leads performances, and works closely with all the musicians to develop a unified vision for the music. Each instrumental section (cello, oboe, and so on) selects individuals to represent it within the core.
2. Developing Strategies. Before a piece of music is taken to the full orchestra, the core meets to decide how it will be played. The goal: developing an overall interpretive approach to the music. The core accomplishes this goal through rehearsals where many different approaches can be tried in a streamlined fashion.
3. Developing the Product. After the core is satisfied with its chosen approach to the piece, it is taken to the full orchestra to be rehearsed and refined even further. Musicians from throughout the orchestra make suggestions to improve the piece and critique the playing of their colleagues. When disagreements arise, as they do in any organization, the orchestra members work to reach consensus. If consensus cannot be reached within a reasonable period of time, then a vote is taken and the issue is settled.
4. Perfecting the Product. Immediately before every concert, one or two members of the orchestra are selected to go out into the hall and listen to the group as the audience will hear it. These musicians report back to the entire group and suggest final adjustments and refinements based on the actual sound of the full orchestra.
5. Delivering the Product. The final step is performance, the ultimate result of the Orpheus Process. The Orpheus Process does not end here, however. After every concert, participants informally discuss their impressions of the performance and make suggestions for further adjustments and refinements -- all with an eye to improving subsequent performances of the piece.

It struck me quite suddenly how this resembled the transition from traditional, process oriented project management to the more flexible and adaptable agile one for many organizations.  In particular, the notion of collaborative leadership is in line with Scrum's principle of more team leadership and collaboration through cross functional teams.  

The core tenant of the Orpheus Process is that individual musicians spontaneously take on ad hoc leadership responsibilities in response to the specific demands of each piece of music, ensuring that they sustain a unique multi-leadered orchestra that fully engages and flexibly deploys the creative abilities and energies of each musician.

Though not explicitly outlined in the Orpheus Process, this rotation of leadership and improvisational adjustments to the music is allowed to facilitate the self-organization of the team, which is a one to one correspondence to the main tenets of Scrum.

How does this apply for the ScrumMaster who is charged with leading the project?

It seems to apply quite well.  According to Scrum's philosophy, the ScrumMaster's function is to remove impediments and facilitate the environment surrounding a team so that it can organize itself.  He/she has to challenge and assist the team in establishing the deliverables of a Scrum project while simultaneously supporting the members of the team as they organize themselves.  He/she facilitates the open collaboration needed for actual self control and works together with the Product Owner to insure the directions of the visions and goals are clear.

This kind of leadership is harder than the kind expected in a traditonal project manager, since the ScrumMaster has to balance the ability to distinguish between what is important and what is not important and between what needs to be done right away and what can be done later, while still allowing the team to self-organize and collaborate.  The ScrumMaster will still have to address and solve conflicts, but give neutral feedback, pointing out potential improvements, but suggest corrections to incorrect behavior patterns to ensure the project get's delivered on time, within scope, under budget and with high quality.

I think the subtleties, complexities and multi-faceted roles a ScrumMaster must engage in is underestimated.  It is more than just removing impediments, as it requires leading without being a leader or conducting an orchestra without the authority or role of conductor.