Agility and Project Leadership

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. 

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.