Agility and Project Leadership

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.

This very interesting and profund post by Douglas Rushkoff calls into question our current fixation of creating more jobs.  As he states:

"We're living in an economy where productivity is no longer the goal, employment is. That's because, on a very fundamental level, we have pretty much everything we need... Our problem is not that we don't have enough stuff -- it's that we don't have enough ways for people to work and prove that they deserve this stuff."

With Obama ready to get approval for the jobs package and America and most of the rest of the world in an economic and jobless slump, this is a very provacative statement to make in light of our current situation.  Nevertheless, the lingering economic slump and ability of corporations to maintain and in many cases, increase profits despite high unemployement does require us to call into question the current viability of our economic systems and the foundations of work, employment and careers.  Add to this the rapid technological and productivity changes of the past decade, and this only accelerates the need for self reflection and re-examination of our careers.

While I'm not completely sold on Rushkoff's proposal for a more colloborative and community based economic system that uses a form of barter and/or local currency to exchange intellectual goods while our basic needs get met, I do agree that the concept of having a "job" is becoming increasingly obsolete.

For readers of this site who are project managers, is our own profession becoming obsolete as well?  I would answer "it all depends".

I think if your a "true" project manager, which by that I mean a person who truly leads and manages a team, has breath and depth of knowledge to be able to make decisions on the direction of tasks and work, and can effectively communicate to teams and stakeholders, then you will always be valuable.  But if your just a project scheduler, status reporter or task tracker, then you will likely become obsolete by technology and business process productivity improvements.

Furthermore, you will really need to be "agile".  I'm not just talking about becoming a ScrumMaster and doing Scrum, but really have the ability to adapt, evolve and reinvent your skills and management methods to technological, economical and social change.  This is big stuff.  I really see project management skills as being key to future survival, as it is not out of the question to foresee a future where we're all free agents, who bid on projects and have to form teams, draw plans, and execute projects with high quality deliverables quickly, then disband and move on to the next project.  This is how movie studios have been delivering movies for quite some time, and it would be quite a social and economic change for everyone to be working this way.

I think we're at the starting point of a signficant change in how we work and deliver projects and you will either be thrilled by it or scared to death.  I'd chose the former.