Agility and Project Leadership

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.

I previously wrote about the Microsoft Project 2010 Scrum add-on and how it lets you manage a Scrum project using the most ubiquitous project management software tool on the market.  Given that the majority of Scrum projects are for software development projects, it is no surprise that Microsoft’s latest software development IDE, Visual Studio 2010 has a process template add-on to do Scrum.  It requires Visual Studio professional and above as well as Team Foundation Server (TFS) to be running and configured to connect by VS 2010, but I found you can setup TFS locally running Windows 7 to test it out.

If your a ScrumMaster or technical lead managing a software project building Microsoft based systems with VS 2010, this is definitely something to look into.  One of the first things you are prompted to do is define the length of your sprints, then itemize those into a Product Backlog which are Scrum’s way of defining and creating requirements:

As can be seen from the screenshot, the default VS 2010 project template is built around making it easier for the developer to follow and track the Scrum method.  The process template is built around the notion of a work item that is a database record that you create in TFS to record the definition, assignment, priority, and state of work.

The process template for Visual Studio Scrum 1.0 adopts and manages these Scrum items:

• Product backlog item
• Bug
• Task
• Sprint
• Impediment
• Test case
• Shared step

More important for the ScrumMaster is the ability to automate, monitor and report the status of your project using visual reports.

Here’s a sample Release Burndown report:

Here’s a sample Sprint Burndown report:

Additional Scrum based reports include the following:

• Velocity (Scrum)
• Build Success Over Time Report
• Build Summary Report
• Test Case Readiness Report
• Test Plan Progress Report

The fact that Microsoft has provided robust and freely available add-ons to project management and software development tools for Scrum, illustrate how much the Agile method has caught on in the industry.

Project management maturity is often measured by the three pillars of success: people, process and tools.  And though tools in my opinion is the least important of these, once you get the right people and process in place, using the right tool can significantly enhance and streamline the management of projects and is why such tools as the above are worth looking into.

I’ll write about other solutions in future posts that enhance the management and leadership of Agile based projects.  In the meantime, let me know what solutions you are using.

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?