Modifying and Extending the ScrumBOK
| 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.
Today's announcement marks a new era in Scrum's evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework."
This again is similar to PMI's encouragement to extend the PMBOK as I mentioned in a discussion forum post back around the same time. Through the Agile community typically shuns formal frameworks and processes, the popularity of Agile and Scrum seems to have compelled a need to establish a formal body of knowledge and process for those who wish to contribute to future modifications as well as extending the ScrumBOK to suit their industry and domain of specialty. The latter is promising for those who wish to extend Scrum beyond the software industry to which it is mostly applied.
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.
Today's announcement marks a new era in Scrum's evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework.
|
Agile Analogies Gone Wild
| 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:
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. |
Obsolete Jobs and Accelerated Agility
|
"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. |
Being Reflective and Conducting Retrospectives
| 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.
For Agile/Scrum, it is even more important in my opinion, to conduct an assessment of your iterations/Sprints at the close of each one. In the Agile community this is often referred to as the "retrospective". This is a meeting where a team looks back on a past period of work so that they can learn from their experience and apply this learning to future projects. This should be conducted at the end of each iteration/Sprint and will involve the team, management and the Product Owner and facilitated by the ScrumMaster.
An important ingredient to these retrospectives is the ability to reflect deeply about the deliverable or product. Did the product meet the backlog of requirements from the Product Owner? What did the team actually accomplish? What impediment did they face and was the ScrumMaster able to remove them? What worked well and what did not work well in each iteration/Sprint?
What you don't want is Retrospectives to regress down to finger pointing, blame games and bitch fests. This is the duty of the ScrumMaster or Agile PM to ensure that retrospectives get conducted smoothly, fairly and productively. These also need to be documented and archived for a lessons learned for future projects.
|
Energy and Self-Organizing Teams
| 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. |







This very interesting and profund