Agility and Project Leadership

In the software engineering field, especially with regard to object oriented design and programming, there has been a drive within the past decade and a half to identify recurring patterns in OO design and code that will enable more re-usability and “abstractions”, which are very general descriptions or templates for how to solve a problem that can be used in multiple situations.

This article by Mike Cohn on the Scrum Alliance site, discusses the perception that some people have that Scrum can be a "burden".  This is an often heard complaint I've experienced throughout my PM career whether it pertained to Agile or traditional methods.  Implicit in this argument is the notion of project management in whatever form, method or process as being "overhead" for getting things done.

Now that the profession has matured quite a bit and is established in many industries and organizations, you will hear less of this than in the past, but the perception still holds for some people.  Even in one of the most lightweight PM methods around, namely Scrum, the perception will hold as Cohn states, "these comments have surprised me—Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead."  While I can agree with this, I can still see why the perception holds and it typically has to do with several core factors.

First, it has to do with the maturity level, or lack thereof in a particular organization.  Scrum and Agile has their roots in software companies, and especially for software start-up companies where the core application or system was developed on the fly by founders loaded up on sugar and caffeine laden sodas and pizzas and all night coding sessions are the norm, even adding a routine of daily meetings and short planned Sprints can seem like overhead.  But at some point, they will need to hire developers and ship a useable product and this is where some planning and process needs to be in place.  Even for more mature or established organizations, there could be a lack of established planning, development and deployment practices where introducing project managment practices can be perceived as overhead.

Directly related to the above is upper managements lack of support for project managment.  And I'm not talking about where an organization experiences chronic delays and overbudget projects and decides to make project management a directive for the organization or department.  As Cohn states, " there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum 'too much overhead' may be a team's way of expressing displeasure at having any decision pushed down onto them from above."  What I'm talking about is where upper management needs to view project management as a strategic objective of the organization and takes the time to carefully plan, advocate and carry through with implementing project management practices that match their orgainizational's needs and strategic objectives.

Finally, if the project manager or ScrumMaster is not adequately doing his or her job of tracking and managing project details, removing impediments, communication, etc., then their role and the project management role in their organization in general, will be seen as overhead.  But if the project manager or ScrumMaster does an outstanding job, there is no better way in my opinion to sell project management to an organization than when a project manager or ScrumMaster proves this in the flesh.  Though you cannot always control factors such as the maturity of your company or upper management's decisions, you can control how you manage your projects and the manner in which you do so can have dramatic impacts to whether it is perceived as overhead or strategic necessity.

With this month’s Gantthead emphasis on global project management, it’s fitting to discuss using Scrum in an increasingly flat, global work environment.  With the trend staring in manufacturing in the 80’s and 90’s, coupled with the rapid advances in communication technologies, the imperative to to deliver application development in shorter timeframes, with better quality, lower cost and with globally dispersed teams is now the “new” normal.

Back in July, I wrote about the creation of the official Scrum guide or ScrumBOK that is to represent "the official Scrum Body Of Knowledge, (that) was written by Ken Schwaber and Jeff Sutherland, co-creators of Scrum"  A new announcement has just come out where the implementors of Scrum are encouraged to read, modify and extend the ScrumBOK.  As they accounce:

""Scrum was first developed 15+ years ago, and it has been evolving and adapting ever since. Informed by their experiences and those of the Scrum community, Jeff and Ken have carefully codified the framework in the Scrum Guide, which documents the basic rules, artifacts, and events of Scrum.

One of the more interesting aspects of Scrum is the colorful and offbeat use of terms, analogies and metaphors.  Well known blogger Jeff Atwood, of the site “Coding Horrow”, thinks just the use of the word “Scrum” is too weird:

1. It's two additional characters away from a term for male genitalia.
2. The term is derived from rugby, an extraordinarily violent sport. During my first year at college, a guy on our hall participated in Rugby. His ongoing injuries, both small and large, became a running joke in the dorm. Eventually even he started to re-evaluate the merits of the sport. As Steve pointed out, Wikipedia defines scrum as ".. the most dangerous phase in rugby, since a collapse or inproper engage can lead to a front row player damaging or even breaking his neck." My indirect experience with rugby leads me to agree. The most dangerous phase of a violent sport is not exactly the sort of thing you want to add to your project.
3. When you tell customers your software developers use the Scrum process, they have absolutely no idea what you're talking about.

There’s also been the rise and creation of other vernacular oddities and particularities within the Scrum movement such as “FlaccidScrum”, “ScumBut..”, etc. to name a few.  But one that I find particularly interesting is the metaphor of the “chicken and the pig” to describe stakeholder roles in Scrum.

 

 

This is supposedly based on a joke mentioned in the book “Agile Software Development with Scrum” published by Schwaber and Beedle in 2001 that started the movement.

The pigs are the people who “sacrifice” themselves and put it all on the line for the project to succeed, whereas the chickens are the necessary overhead that only needs to be involved with the project on a need-to-know basis that do not have to be directly involved with a Scrum.  They do not need to be involved in the daily meetings since they are not accountable or committed to the project and will get their say when they view a working demo at the end of a Sprint to influence the next one.

Some people, such as blogger Jeff Atwood mentioned above, think using such derogatory and sarcastic terms will make it harder for organizations to adopt Scrum, though the evidence seems to state the contrary with ever growing adoption of Scrum/Agile.

 

From my understanding, the concept of the pig and chicken is just Scrum’s metaphor for what is otherwise known in project management field as the “direct” and “indirect” stakeholders of the project cycle.

This short and memorable story allows the point to hit home without the use of management jargon.  The whole chicken and pig division idea is about giving greater decision making power and responsibility during a project stage to the people who are directly involved and committed to the final delivery (pigs), while limiting interference coming from sometimes powerful external players (chickens).

Sprints are aimed at delivering a fully functional working demo from spec to ready-to-use product, instead of some sort of interim deliverable.  Since the team provides a lot of input into deciding what goes into Sprint, this implies a collectively agreed upon commitment to delivering the change. That creates a contract between the team and outside world.

Changing the roles during the Sprint can endanger this contract and is why chickens are forbidden to be involved directly in a Sprint.  If a pig becomes a chicken he or she is no longer responsible for seeing the Sprint to completion putting the burden of dealing with any shortcomings in their work onto the shoulders of remaining team members.  

If a chicken becomes a pig during a Sprint they cannot realistically commit themselves to something that has been agreed before they came on board.  Hence it’s best when the roles stay unchanged for the duration of a Sprint. Seen in this light, this is an relevant metaphor for the important segmentation of roles for direct and indirect stakeholders of a Scrum Sprint.