Agility and Project Leadership

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.

In traditional project management, it is typically recommended that you conduct a project handover (and/or ceremony) and close the project.  This is typically done with a project closure document.  And though much of the emphasis is on planning your project thoroughly, mitigating the risk and issues and executing the project to its successful outcome, the closing aspect of the project is not mentioned enough in the industry, nor is it done well or at all.

Much is discussed about facilitating self-organizing teams in Agile/Scrum.  In my article on the Japanese origins of Scrum, Takeuchi and Nonaka who originated and inspired the Scrum movement, discussed the aspects of self-organization that leads teams to create their own unique rhythm, as they are forced to synchronize their work and pace in order to reach project timelines. 

But the question as to how to maintain peak performance of these teams is not addressed by the framework.  This is not surprising since Scrum is a light weight framework that leaves it up to the implementor to implement.  Fortunately, there has been a movement by Tony Schwartz called The Energy Project, which addresses identifying and managing our natural bio-rythms and fluctuating energy levels to achieve peak performance.

According to the site, based on a 2008 Towers Perrin Global Workforce Study of 90,000 employees across 18 countries, only 20 percent of them – 1 out of every five – feel fully engaged at work. Forty percent are actively disengaged.  Demand is exceeding our capacity to match supply.  The ethic of "more, bigger, faster" exacts a series of silent but pernicious costs at work, undermining our energy, focus, creativity, and passion.  Nearly 75 percent of employees around the world feel disengaged at work every day, according to the Energy Project initiative.

This issue should be of no surprise to many of the project managers and ScrumMasters out there trying to manage and motivate burned out teams, within a corporate environment of slashed budgets, relentless pace of work and a looming fear of unemployment.

The idea is that by integrating multidisciplinary findings from the science of high performance, we can identify and manage the neglected four core needs that energize great performance: sustainability (physical); security (emotional); self-expression (mental); and significance (spiritual).  Rather than running like computers at high speeds for long periods, we're at our best when we pulse rhythmically between expending and regularly renewing energy across each of our four needs. 

At the individual level, it explains how we can build specific rituals into our daily schedules to balance intense effort with regular renewal.  To offset emotionally draining experiences with practices that fuel endurance and move between a narrow focus on urgent demands towards more strategic and creative thinking.  Ultimately, it seeks to balance a short-term focus on immediate results with a values-based commitment that deliver real business value and organizational harmony. 

The site kind of overhypes the idea, but the main ideas behind identifying, managing and facilitating your teams ability to self-organize according to core energy levels at the physical, emotional, mental and spirititual levels is a powerful idea that should be explored more.

Having been involved with large infrastructure projects, both in IT and construction, it is almost always the goal to get vendors to settle on a fixed priced contracts.  The advantage of using this type of contract is the reduced level of work required by the buyer to manage the contract. The buyer will know the price being charged and the incentive lies with the seller to control costs. 

The two things to closely monitor is to ensure the work outlined in the SOW is actually being completed per the contract and the other is control change requests, which are typically negotiated away by the vendor to secure the contract but used to get back the profits lost due to it.  I have personally been involved with projects that had out of control change requests that resulted in projects being way over budget and delayed.  Though I don't have the statistics on hand, I'm certain many of the major project failures were due to the inability to manage changes in fixed price contracts, especially in the government sector.

Agile/Scrum does not have much literature on integrating procurement management with Agile/Scrum since most of these kinds of projects are done with co-located, in-house teams, though I did find this post from Jeff Sutherland that outlines a "money for nothing" approach, which is a hybrid fix price contract that includes time and materials for changes.  Here's a summary:

• Insert Money for Nothing clause in fixed price contract.
  • Only operational if customer follows Scrum rules
  • Mutually agreed estimates for all work items
  • Otherwise contract reverts to time and materials
• Customer determines ROI cutoff where implementation of the next feature costs more than the value of the feature
• Supplier allows termination of contract at any time for 20% of remaining contract value
• Supplier assumes risk of late delivery of mutually agreed deliverables

I've only previewed the presentation by Jeff Sutherland and plan to review it in depth, but some issues that come to mind for me immediately is to ensure the stakeholders understand that this is fixed in price, but not in price and scope and that changes can be added giving them flexibility, but to do so requires the removal of other features.  Another is the involvement of the Product Owner, since he/she is the one who works with the customer to obtain requirements that will add business value for the customer.  That person will have to buy off and fully understand the impacts of this approach to make it successful.

Have any of you out there adopted a similar approach?  I'd be very interested to know!