Agility and Project Leadership

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. 

My recent post in the PMC discussion forum and the excellent replies about the utilization of Earned Value Management and Six Sigma's Statistical Process Control, got me thinking about how this differs from Scrum and its use of Empirical Process Control.  This article from Scrum Alliance seems to advocate that both techniques can co-exist, and my initial thought is that they could.  And since the focus on my blog is “bridge the gap between traditional and agile project management”, I thought I’d write about how they could.

But as I thought it through and reading the replies to the Scrum Alliance article, my feeling is that they should not co-exist.  In fact, the question could be “why would you want them to”?  This reply from a reader expresses the same sentiment:

(Six Sigma) is largely about reducing variation, which is one of the key control methods in (repetitive) production. Product creation, on the other hand, is very much about innovation and generation of understanding in a once-in-a-lifetime environment. I find these two fundamental approaches very much in opposition to each other.

At the core of Six Sigma is the need to reduce variation while simultaneously increasing quality for well defined projects and processes, whereas Scrum is used for ill defined projects or processes that have never been solved before or is heavily dependent on feedback to determine when the problem has been solved correctly 

Projects that require detailed and process oriented planning would be best served with Six Sigma statistical control.  This would especially be the case for projects with good historical artifacts, or projects with very similar scope and requirements, e.g., a project to build an extension to a data center with the requirements that it mirror the existing one.  In this example, I would be confident of being able to establish a firm baseline for scope, cost and schedule.  When the project gets executed, I could use EVM and Six Sigma statistics to reduce variation and increase quality.

But what if my project involves something like creating a new software system or product that will capture untapped market share for my company?  In this instance, you’ll most likely have vague, incomplete or too high level requirements that will have to be prototyped, tested and reworked in short iterative “sprints”.  From this perspective, variations could be a good thing as it could clarify and reveal requirements the customer was not aware of till revealed in demo session of the prototype.  

I was involved in just such a project for a new software application where at each two week demo, the customer would request new features which would be incorporated into the prototype until a fully functional application with all requirements were delivered.  This application was eventually deployed into production with very little changes.

Much as Six Sigma is executed with SPC, Scrum is executed with EPC which advocates obtaining information by means of observation, experience and experimentation.  This is done in a continuous cycle of inspecting the project deliverables with customer feedback to ensure correct operations and results are obtain and adapting and changing the process as needed.

Through Scrum is a light weight project management framework that has a strong Lean process bent to eliminate waste, some have taken that to mean it does not have a rigorous foundation.  EPC if utilized properly can be a very disciplined way to manage uncertainty and complexity for things like the development of new software systems.

In conclusion, given the different approaches and the problems they are trying to solve, I don’t think in this instance you should be integrating Scrum and Six Sigma.  If your project’s parameters and scope are well defined, then it would be a better approach to use Six Sigma to control variation and quality, but if your project is not well defined then use Scrum to control variation and quality with empirically validated feedback from your customers.
 

I've been an off and on reader and contributor to this excellent PM portal, and wish to now contribute more regularly by having this blog.  My goal, obviously, is to post on project management related topics, but as the title of this blog relates, I'm very interested in bridging the intersection between traditional, process oriented project management, with the agility and flexibility of Agile project management.

Topics to range from the theory and practice of traditional processes such as PMBOK, CMMI, SDLC, etc. to Agile frameworks such as SCRUM, Extreme Programming (XP), Lean, etc., but most importantly, to how the incorporation of these standards, frameworks and methodologies enhance project leadership.

Project leadership is to me, the most vital element of any project success whether and whatever method, framework, or philsophy of managing projects you happen to employ.  At the core, what really stirs my passion in these discussion is how  project leadership becomes realized.