Agile Forest

Scrum evolution over time: Part 4 – Artifacts

Renee Troughton

March 11, 2012

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and part 3 we looked at the ceremonies and how they have adapted, or not, over the years. It is now time to have a look at the key artifacts.

There are three artifacts in Scrum: Product Backlog, Sprint Backlog and the Burn Down Chart.

Product Backlog

The original June 2003 site did not differentiate between the Product and Sprint Backlog:

A prioritized list of all work to be completed prior to releasing a product :

Only one person maintains and prioritizes the backlog list.
Any interested party can request that backlog be put on the list.

Between sprints, all involved parties and the engineering team meet to determine which work can be completed in the next sprint, and what the executable will be.

In the 2007 pdf we have the Product Backlog defined as:

The requirements for the product being developed by the project(s) are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. The Product Backlog is never complete, and the Product Backlog in the project plan only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used emerge. The Product Backlog is dynamic, in that management constantly changes it to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, the Product Backlog also exists. An example of a Product Backlog maintained on the Scrum Product Management tool, based in a spreadsheet.

In both March 2007 and March 2009 the Product Backlog definition was:

At the beginning of the project, the product owner prepares a list of customer requirements prioritized by business value. This list is the Product Backlog, a single list of features prioritized by value delivered to the customer. The Scrum Team contributes to the product backlog by estimating the cost of developing features.

The Product Backlog should include all features visible to the customer, as well as the technical requirements needed to build the product. The highest priority items in the Product Backlog need to be broken down into small enough chunks to be estimable and testable. About ten developer-days of work is a good size for a Product Backlog item that can be ready for implementation in the next iteration. Features that will be implemented further out in time can be less detailed.

In September 2010:

The Product Backlog is a prioritized list of everything that might be needed in the product.

Within scrum.org the definition is now:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate.

The Product Backlog is often ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.

Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that any one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items is then employed.

Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

The ScrumAlliance definition of the moment is:

A prioritized list of desired project outcomes/features.

A product backlog is dynamic—Items may be deleted or added at any time during the project. It is prioritized—Items with the highest priority are completed first. It is progressively refined—Lower priority items are intentionally coarse-grained.

Product Backlog results and opinion

My biggest problem with Scrum (other than it’s odd names for things) is that it creates this belief that this backlog of requirements just pops into magical existence with no work. This is not an activity that a Product Owner can do in a few hours. Nor is it something they should do alone. The whole team should be part of this activity to create the backlog in the first place. This is an opportunity for the team to be given context as to why this project came into existence in the first part, the opportunity to say we need to have a team or 6 or a team of 3 to get through the work in time against expectations. There is no recognition in Scrum of marketplace realities – projects are almost always constrained by either scope, time or cost. Vendors do need to still give some form of estimate of the end to end work – yes with knowledge that change will without a doubt occur, but the financial reality of this world is that software development work is capitalised by accountants and consequently needs to have funding set aside for it in advance. To do this the whole team needs to have a somewhat good understanding about the features and about the market pressures. I used to call this activity “Iteration Business Planning” and it would precede the start of iterations. An outcome of it would be a business case for the work to be done.
Now before you start replying that this smells like waterfall I would say that it is a compromise. In waterfall such an activity would have taken months – what I am suggesting is that for a six month project this takes one week. It’s not big design upfront, it is the right amount of design and elaboration to ensure that you are building the right thing and that the right thing can be built to commercial expectations.
Thankfully over time the creator of the requirements was changed to not just be the customer or “Product owner” but that also the team could identify requirements. This hints at there being IT only features. The thing to be wary about IT only features is that they provide no value to the Product Owner, hence why are you doing them? If you can express in what way they provide value to the Product Owner (which you should) then they are really Product Owner features. Work such as “setup the database” is not a feature – you are doing that to realise some value in a real Product Owner feature.
All instances above take the line that prioritisation is only done by value. I would argue along with other Agile proponents (eg Alistair Cockburn and Jeff De Luca) that prioritisation should be done with respect to value and risk. This doesn’t mean that you do all the high risk features first. You do the high risk, high value features first. You do the high risk, low value features near the end (or never). It would be nice if Scrum was updated to provide further guidance on this.
The question of how often to Product Backlog groom (prioritise, estimate and discover) is an interesting one. Scrum.org says to do it as needed with this activity taking up to 10% of the Development team’s time in interruptions. I agree with the ‘do it as often as needed’ philosophy but be careful about how you implement this. It is important not to make the developers context switch too much and constant interruptions by the Product Owner of “hey, can you estimate this new feature for me?” is not the intent of this activity. Ensure that as a team you have worked out a strategy to minimize context switching but still enabling this to be an activity that doesn’t get skipped.
The fact that the Product Backlog will evolve over time is an important one. What I do get concerned about here is the commercial reality behind it. A certain amount of tolerance can probably be handled but how much are Product Backlogs changing out there? I really would love to see all of the Release Burn Charts across the industry to see where the scope was when the project started versus where it ended up being. Should we as a community not be gathering this information and asking questions about why it is shifting so much and whether there is a better way to predict such dramatic shifts in the future?
In the March 2007 data capture, the ideal size of a feature was defined as 10 days. Scrum.org has now clarified that it just needs to be doable inside of an iteration. Both of these definitions scare me a little. Probably because I think of a “feature” as the big thing that a customer wants eg “Manage my accounts”. Most people outside of Scrum these days are using a Feature -> Epic -> Story -> Task breakdown (or something similar). The Story (or User Story) should be no bigger than a Sprint. Ideally the Story should be around 2-3 days in length – why? So that demonstrable results are being showed very frequently, ie the feedback loop is tight. A feature could be made up of potentially dozens of Stories that cross multiple Sprints. A Feature Progress Chart (or Parking Lot diagram in FDD) provides a visual cue as to how well this feature’s delivery is progressing.
I do appreciate the approach that Features further (ie lower in priority) out need less elaboration or breaking down. In this respect all Features need a high level estimate on them but only as they get closer to being put in a sprint does the breakdown need to occur. The reason for this is that it is ultimately waste to break down work that is only possibly going to be done. Elaborate just enough, just in time.

Sprint Backlog

In the 2007 pdf we have the Sprint Backlog defined as:

The Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality. The Team compiles an initial list of these tasks in the second part of the Sprint Planning meeting. Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish. Tasks that are of longer estimated time are used as placeholders for tasks that haven’t been finely defined. Only the team can change the Sprint Backlog. The Sprint Backlog is a highly visible, real time picture of the work that the team plans to accomplish during the Sprint. The rows represent Sprint Backlog tasks. The columns represent the days in the month of the Sprint. Once a task is defined, the estimated number of hours remaining to complete the task is place in the intersection of the task and the Sprint day by the person working on the task.

In both March 2007 and March 2009 the Sprint Backlog definition was:

The Sprint Backlog is an artifact of the Sprint Planning Meeting. When the Scrum Team has selected and committed to deliver a set of top priority features from the Product Backlog, the Product Backlog’s features are broken down into a Sprint Backlog: a list of the specific development tasks required to implement a feature. These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work. When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint with a high probability of success.

In September 2010:

The Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product.

Within scrum.org the definition is now:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.

The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum. The Development Team tracks these sums daily and projects the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

The ScrumAlliance definition of the moment is:

Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks.

A sprint backlog is a negotiated set of items from the product backlog that a team commits to complete during the timebox of a sprint. Items in the sprint backlog are broken into detailed tasks for the team members to complete. The team works collaboratively to complete the items in the sprint backlog, meeting each day (during a daily scrum) to share struggles and progress and update the sprint backlog and burndown chart accordingly.

Sprint Backlog results and opinion

This wider community belief of breaking work down into Feature -> Epic -> Story -> Task is muddying the ‘task’ definition. For me a task is something more fine-grained then Scrum’s definition. It doesn’t add value and it is there more for the developer to be able to track the things that they have to do – eg “Create a new business object and update the Customer business object”. But to take Scrum’s definition as a clear rule for Scrumists then Feature will always be done inside of a single Sprint which makes the fact that there was ever a debate on which Sprint components get visualised a little strange. Regardless, the whole concept of pulling in a Sprints worth of work and progressively demonstrating delivery is truly magical.
Sprint goals. I have mixed feeling on this concept. The sprint goals for me should be “get through all the work that we pulled in at the start of the Sprint”, after all, it is about working software. To have a meta-goal I feel muddies the waters. Deliver to commitments. If the above references to sprint goal is purely to deliver the features that were committed then I have no problem with it – I just hear various interpretations of this around.
A Sprint is a sacred timebox. I am confused by Scrum.org’s recent definition. It seems to elude to the fact that scope can just be added and removed by the Development Team without concern. If it is talking about exceptional circumstances whereby the team finishes all the committed to features then that is fine, but change inside of the iteration should not be a norm. It is a timebox to deliberately reach commitments and to push out external factors (such as Product Owners that want change every day).

Burn Down Chart

In the 2007 pdf we have the Burn Down Chart defined as:

A burndown chart shows the amount of work remaining across time. The burndown chart is an excellent way of visualizing the correlation between the amount of work remaining at any point in time and the progress of the project team(s) in reducing this work. The intersection of a trend line for work remaining and the horizontal axis indicates the most probable completion of work at that point in time. The burndown chart helps me to “what if” the project by adding and removing functionality from the release to get a more acceptable date, or extending the date to include more functionality. The burndown chart is the collision of reality (work done and how fast it’s being done) with what is planned, or hoped for.

Incidentally the picture provided within the pdf is of a Release Burn Down not a Sprint.

In both March 2007 and March 2009 the Burn Down Chart definition was:

The Burndown Chart shows the cumulative work remaining in a Sprint, day-by-day.

At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work remaining to be completed is the cumulative backlog. When tasks are completed as the Sprint proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog decreases, or burns down over time. If the cumulative Sprint Backlog is zero at the end of the Sprint, the Sprint is successful.

The Product Backlog items brought into the Sprint are fixed for the duration of the Sprint. However, the Sprint Backlog may change for several reasons:

The development team gains a better understanding of work to be done as time progresses and may find that they need to add new tasks to the Sprint Backlog to complete the Product Backlog items selected.
Defects may be identified and logged as additional tasks. While these are viewed primarily as unfinished work on committed tasks, it may be necessary to keep track of them separately.
The Product Owner may work with the team during the Sprint to help refine team understanding of the Sprint goal. The ScrumMaster and Team may decide that minor adjustments that do not lengthen the Sprint are appropriate to optimize customer value.

The Burndown Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product.

In September 2010:

A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint.

Within scrum.org the definition is embedded within the Product Backlog definition:

Monitoring Progress Toward a Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

The ScrumAlliance definition of the moment is again sparse with:

Burndown chart: at-a-glance look at the work remaining (can have two charts: one for the sprint and one for the overall project).

Burn Down Chart results and opinion

Looking over the Burn Down Chart artifact you would be excused to be confused about what is happening with it. First it was just a Sprint Burn Down, then it was Sprint and Release Burn Down, then it was for scrum.org back to just a Sprint Burn down and Scrum Alliance have it as both. It explains why there is so much mixed information and approaches in the community.
Personally I have always disliked how both the Sprint Burn Down and the Release Burn Down have, for lack of a better term, burnt down. To easily differentiate the two I have always made the Release a ‘Burn Up’ chart. It also tends to work better burning up then down due to the way the scope line changes.
Scrum.org’s removal of the Release Burn Down (Up) is strange. It is explained in their recent FAQ but if I was going to choose between the two and which one was more important I would have put my money on the Release Burn Up. When you have a good wall with all of your cards on it, it is pretty easy to see at any point in time whether you are going to achieve your Sprint commitments. With a list of Product Backlog cards on the wall it isn’t as easy to see whether you are going to meet your Release commitments. Some would say that the Release is impossible to commit to. Try seeing how easy that is to say when you are a Vendor. What the Release Burn Up does is demonstrates whether you are on track or not based upon current achieved velocity and predictive velocity. You can have conversations earlier about the scope, about the time and about the cost of the project.

Anything else?

I feel a few crucial artifacts are missing. There is nothing about where Business Cases fit into this picture. There is nothing about the conversations that need to be made about what is more important for the Product Owner – scope, time, cost or quality (some would argue quality is non-negotiable). Admittedly this is something of an organisation’s governance process and could be seen to be irrelevant but for some crazy reason in most places where I see Scrum being applied at the enterprise level these basic governance artifacts are one of the first things thrown out the window because ‘Scrum says we don’t do that stuff’.

With one more blog to go in this series, we have seen how Scrum has evolved over the years, soon we will see how it hasn’t.

Scrum evolution over time: Part 3 – Ceremonies

Renee Troughton

9 comments

March 5, 2012

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and how they have adapted, or not, over the years. It is now time to have a look at the key activities and ceremonies.

There are three – five key activities or ceremonies in Scrum (depending on how you take content on the sites), but more often then not it is represented as only three: Sprint Planning Meeting, Daily Scrum Meetings and the Sprint Review Meeting. The additional two sometimes considered separate are the Sprint Retrospective and the Sprint itself.

Sprint Planning Meeting

The original June 2003 site did not have a reference to Sprint Planning.

In the 2007 pdf we have the Sprint Planning Meeting defined as:

Takes 8 hrs. First four are spent with the PO presenting the highest priority product backlog to the team. Allows questions, etc. Then team selects as much Product Backlog as it believes that it can turn into a completed increment. 2^nd four hours the team plan out the sprint, creates design.

In both March 2007 and March 2009 the Sprint Planning Meeting definition was:

The Scrum begins when enough of the Product Backlog is defined and prioritized to launch the first thirty-day sprint. A Sprint Planning Meeting is used to develop a detailed plan for the iteration. It begins with the Product Owner reviewing the vision, the roadmap, the release plan, and the Product Backlog with the Scrum team. The team reviews the estimates for features on the Product Backlog and confirms that they are as accurate as possible. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity. It is important that the team “pull” items from the top of the Product Backlog that they can commit to deliver in a thirty-day sprint. Pull systems have been shown to deliver significant productivity gains in lean product development.

When the Scrum team has selected and committed to deliver a set of top priority features from the Product Backlog, the Scrum Master leads the team in a planning session to break down Product Backlogs features into sprint tasks. These are the specific development activities required to implement a feature and form the Sprint Backlog. This phase of the Sprint Planning Meeting is time-boxed to a maximum of four hours.

Within scrum.org the definition is now:

The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team.

The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:

What will be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?

<< Some depth is then made on these two bullet points where the “Sprint Goal” term is introduced for the first time >>

The ScrumAlliance definition of the moment is again sparse with:

Sprint planning: the team meets with the product owner to choose a set of work to deliver during a sprint.

Sprint Planning Meeting results and opinion

Planning didn’t matter back in the turn of the millennium!
Thank goodness we don’t have 8 hr planning meetings anymore. Well, we probably still do but most of it is hidden these days. Lets say your Sprints are fortnightly. Each fortnight you are still likely to spend two hours of planning and backlog management. Then we spend a little time pulling in the right amount of work and talking about it. Hmm I could maybe stretch that out to three hours a fortnight.
Design; well I haven’t seen that done intensively in a meeting for quite a while. Normally that is done real time as the story is picked up by a developer. It isn’t really a meeting, not in the Feature Driven Design sense of doing some real design work collaboratively. Maybe this is more of a hangover from trying to culturally shift people’s thinking away from massive design efforts and giving them an olive branch to hold onto.
There is absolutely no detail regarding “how-to’s”. Nothing on how to estimate and nothing on how to get a feature backlog in the first place. The term “velocity” isn’t used to indicate the amount of “pull” of work into the iteration, but it is hinted at. This is somewhat understandable given that all the data captures were taken from overviews but even then scrounging around to find the detail is piecemeal.
Still hate the usage of “Features” and “Tasks” without any reference *anywhere* to user stories or even potentially epics.
There is no indication about what is a good size for these tasks or how to break work down.
Nothing mentioned about ensuring that work is not allocated to the team within this meeting.

Daily Scrum Meeting

The original June 2003 site has the Sprint Planning Meeting as:

A short daily meeting where the team shares status.

During the sprint, the team conducts daily scrum meetings.
The meetings are held in the same place at the same time every work day.
The meetings don’t last for more than 30 minutes.
A scrum master is appointed.
The scrum master is responsible for asking every team member the following three questions:
1. What have you done since the last scrum meeting?
2. What has impeded your work?
3. What do you plan on doing between now and the next scrum meeting?
Conversation is restricted to the team members answering the above questions.
Meetings can be established for immediately after the scrum meeting based on answers to the above questions.
The scrum master is responsible for making decisions immediately, if required to remove impediments to progress.
The scrum master is responsible for noting impediments that must be resolved external to the meeting and causing them to be removed.

In the 2007 pdf we have the Daily Scrum Meeting defined as:

Every day the team gets together for a fifteen minute meeting called a Daily Scrum. At the Daily Scrum, each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? And, what impediments are in the way of you meeting your commitments toward this Sprint and this project? The purpose of the meeting is to synchronize the work of all team members daily and to schedule any meetings that the Team needs to forward its progress. The team members are inspecting each others work in light of the team’s commitments, and making adaptations to optimize their chance of meeting those commitments.

In both March 2007 and March 2009 the Daily Scrum Meeting definition was:

Once planning is complete, the Sprint begins its thirty-day cycle. Each day the Scrum Master leads the team in the Daily Scrum Meeting. This is a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to get a global snapshot of the project, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day. Within scrum.org the definition is now:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:

What has been accomplished since the last meeting?
What will be done before the next meeting?
What obstacles are in the way?

The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum. The Daily Scrum is not a status meeting, and is for the people transforming the Product Backlog items into an Increment.

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting.

The ScrumAlliance definition of the moment is still sparse with:

Daily scrum: the team meets each day to share struggles and progress.

Daily Scrum Meeting results and opinion

I want to call out the usage of the word ‘Daily’ here. A Scrum Meeting doesn’t have to be daily. I have seen many highly functional teams performing fine with two or three scrum meetings a week. Do I generally recommend daily? Yes. But it depends on the size of the team and the amount of interaction that is actually needed. Some teams are naturally good at communicating all of the time. Sometimes (especially for non software development teams) the landscape doesn’t change so quickly that a daily discussion is required.
XP called then stand-ups as did Ritz hotels (doing them back in 1998). But it does seem that Scrum was the first to record the format and espouse it’s value. The term ‘scrum’ here frustrates me. It is a cutesy name that has been applied to something that commercially is more viable if you just call it a ‘stand-up’. The ‘stand-up’ name itself infers the quick nature of the meeting. By standing up members are encouraged to keep the meeting brief and to the point. The visual cue of boredom via fidgeting is heightened. The blue sky term ‘huddle’ equally frustrates me.
Maybe initial scrum meetings weren’t held standing up – after all 30 minutes is very long! These days I am happy if they go for 10 minutes and I start to fret when they hit 15 minutes. A 15 minute stand-up is a clear indication to me that a team that might not being doing the activity daily needs to do it more frequently.
Scrum Meetings are hard to get right. It takes a delicate balance of control and autonomy to grow the team’s capability in self sustaining these meetings. Discussions can hint at emergent conflict or team dysfunctions. There is more to running these sessions then just the brief list of objectives hinted above (and more value then hinted above as well). I recently did a decision tree for Scrum Masters when running the Scrum Meeting to help guide them of the sorts of questions and thoughts that they should be considering at the start of the Scrum Meeting, whilst each individual is talking and at the end. It ended up being a three page tree with over 25 nodes. That in itself surprised me. I would love to see more useful guidelines to Scrum Masters about how to facilitate effective Scrum Meetings.
I am frustrated by usage of language like the “Scrum Master is responsible for asking every team member…” This is a team meeting not a Scrum Master meeting and it sets an incorrect presumption that discourages an environment of autonomy that the Scrum Master is trying to establish. Each individual in the team is responsible for answering the three questions, the Scrum Master is accountable to ensure that they follow through on that responsibility.
I mentioned in the roles post that I differentiate between the core team and the extended team. It is the core team that is required to provide answers to the three questions. The extended team is invited to attend and may speak but they should not take over the show. I believe it is unfair that extended team members by the above definition are unable to even ask questions. Would you really stop the person who is potentially paying for your product development from asking a question regarding the scope boundary of a particular story?
There is no mention of a wall (physical or virtual) which is a missing key element of this ceremony overview. It is a smell when team’s talk about the work but never refer to it by touching their cards. Touching their cards ensures that everyone clearly knows which story they are talking about and can more effectively contextualize the conversation. Likewise I would always recommend that mid iteration the team additional walks the wall – talking through every card that is not done to ensure that the sprint goals are re-ignited in their minds. This is a key technique that the overviews are missing.

Sprint Review Meeting

In the 2007 pdf we have the Sprint Review Meeting defined as:

At the end of the Sprint, a Sprint Review meeting is held. This is a four-hour timeboxed meeting where the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders that wish to attend. This is an informal meeting, with the presentation of the functionality intended to foster collaboration about what to do next based on what the Team just completed. The Product Owner and stake holder inspect the Team’s work in light of project goals, and make adaptations to optimize their chance of reaching those goals.

In both March 2007 and March 2009 the Sprint Review Meeting definition was:

At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the sprint. The Product Owner leads this part of the meeting and invites all interested stakeholders to attend. The state of the business, the market, and the technology are reviewed. The Product Owner determines which items on the Product Backlog have been completed in the Sprint, and discusses with the Scrum team and stakeholders how best to reprioritize the Product Backlog for the next sprint. The goal for the next sprint is defined.

After the Scrum Review Meeting, the process begins again. Iterations proceed until enough features have been done to complete or release a product.

Within scrum.org the definition is now:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is a four-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. For example, two week Sprints have two-hour Sprint Reviews.

The Sprint Review includes the following elements:

The Product Owner identifies what has been “Done” and what has not been “Done”;
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

The ScrumAlliance definition of the moment is sparse with:

Sprint reviews: the team demonstrates to the product owner what it has completed during the sprint.

Sprint Review Meeting results and opinion

Not much has really changed for the Sprint Review Meeting over time and it probably didn’t need to that much. Personally I prefer having the backlog always prioritised correctly at all times and so a portion of this description is less applicable. That said some people would argue that the intent is the re-prioritise the work that didn’t get done. For me this is a smell and the overview of the process really shouldn’t be handling this exception. The goal is to deliver all of the stories. It should be a realistic goal and in that respect there should not be the need to re-prioritise the work that did not get completed.
Who is doing what is also less black and white then what is defined above. Why can’t the Product Owner demonstrate what is done? Why can’t the Product Owner and Scrum Master contribute to what went well?

Sprint Retrospective

In the 2007 pdf we have the Sprint Retrospective defined as:

After the Sprint Review and prior to the next Sprint Planning meeting, the ScrumMaster holds a Sprint Retrospective meeting with the Team. At this three hour, timeboxed meeting the ScrumMaster encourages the team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint.

In both March 2007 and March 2009 the Sprint Retrospective definition was:

The second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.

Within scrum.org the definition is now:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.

The purpose of the Sprint Retrospective is to:

 Inspect how the last Sprint went with regards to people, relationships, process, and tools;

 Identify and order the major items that went well and potential improvements; and,

 Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

The ScrumAlliance’s definition:

Sprint retrospectives: the team looks for ways to improve the product and the process.

Sprint Retrospective results and opinion

Early versions of Scrum don’t have Retrospectives as a key ceremony as it was taken from Norm Kerth’s Project Retrospectives and Alistair Cockburn’s Reflective Workshops. By the time it was incorporated into Scrum it was a norm for all of the other Agile frameworks.
Popular believe now is that Scrum is all about “inspect and adapt”. Most people immediately think that this pertains to the stories that are delivered but the reality is it is both the work that is being delivered and how it is being delivered.
Often the Sprint Review and Retrospective are lumped together and commonly this is why Scrum has kept to the “three ceremony” belief. But the reality is the purpose of the meeting is different from the review and it should be considered a separate ceremony.
Common failure modes in Retrospectives include a lack of follow up on the retrospective actions or too many actions chosen for resolution. The lack of details about how to conduct this activity would not mitigate these common failure modes. Personally I either make the actions (limited to no more than five) new stories or ensure that at the beginning of the next retrospective they have been completed.
Nothing about true root cause analysis is described. This would be another failure mode – fixing the wrong problem.
When the team is familiar with the format of the retrospective I would rotate the facilitation role to further encourage autonomy. It doesn’t always have to be the Scrum Master that facilitates this session.
If the Retrospective Quadrant technique is used there are very common quadrant patterns based upon the life of the project. Early in the project there is a lot of points around ‘puzzles’ and ‘what is not working/what to do differently’. As the project progresses the numbers shift from the right side to the left. A lack of a shift or a resurgence of puzzles is commonly indicative of a team dysfunction. Often I see a lack of clarity around roles and responsibilities in the ‘puzzles’ area. If a new team member is added it tends to come back again as the team goes through the forming, norming, storming and performing behaviours.

The Sprint itself

In June 2003 a Sprint was defined as:

A short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog.

A sprint lasts no more than 30 days.
A sprint is undertaken by a cross functional team consisting of no more than 9 members.
Every sprint has a specific goal.
An executable demonstrating the goal will be completed by the team during the sprint.
The sprint team has final say in estimating and determining what they can accomplish during the sprint.
Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect.
If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose.

In the 2007 pdf there was no separate section defining a Sprint other than it being one month.

In September 2010 the Sprint definition was:

The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.

Within scrum.org the definition is now:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

No changes are made that would affect the Sprint Goal;
Development Team composition remains constant;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

The ScrumAlliance has no separate definition for the Sprint.

Sprint results and opinion

I’ve talked about the 30 days before so I won’t go there again.
I don’t think enough people understand that the Sprint itself is a sacred timebox. Change is not meant to be put inside of the Sprint with the exception of potentially cancelling a Sprint. This is a weakness and a strength at the same time for Scrum. A strength because it forces the Product Owner to control themselves, a weakness because for some areas of software development waiting a Sprint to change is commercially too long. In these instances most Scrum Masters would then recommend a shorter Sprint length, but in some respect it is not addressing the root cause of the problem – it is providing a framework to somewhat mitigate it.
It is unrealistic to assume that development team composition will remain constant. In this day and age of rapid change the framework needs to handle and be able to solve this problem. Onboarding will happen. We all know it probably shouldn’t but this is a commercial reality.
I’m not sure about the wording on the scope being clarified bit. Yes a story is a promise for a conversation and in part of this conversation the scope will have clarification, but what if the developer realises that the story is now four times bigger then expected – the whole goal of the Sprint is in potential jeopardy. Scope should be known enough when the Sprint Planning has concluded so that the team will be able to deliver to it’s Sprint goals. Any changes to scope subsequent to this should be minor. Remember – the Sprint is a sacred timebox away from dramatic change.

Anything else?

I really dislike the terms ‘scrum’ and ‘sprint’. They were hard terms to sell to management in the mid-early 2000s, they are even harder terms to sell outside of software development where as a framework it is still really useful. Call them “iterations” everyone else does. No-one literally group hugs to form a ‘scrum’ (despite there being evidence to prove that this will result in more effective outcomes). Terminology complaints have been going for a long time now and still there is no change. A number of organisations have to call their implementations something else to get around these non commercially acceptable terms.
I really dislike the term ‘ceremony’. It is a meeting or even better a repeatable process activity. This is another example of a term being used to make Scrum sound ‘cute’ when really it needs to take itself more seriously.

Scrum evolution over time: Part 2 – Roles

Renee Troughton

8 comments

February 26, 2012

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In this post, part 2 of 5, we look at the roles and how they have adapted, or not, over the years.

There are three defined roles for Scrum – the Product Owner, the Scrum Master and the Team. The links from 2003 for roles were dead but I think we can safely assume there were three roles back then.

Product Owner

In the 2007 pdf we have the Product Owner defined as:

The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting product. The Product Owner achieves initial and on-going funding for the project by creating the project’s initial overall requirements, return on investment objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration. The Product Owner is responsible for the success of the product.

In both March 2007 and March 2009 the Product Owner definition was:

The Product Owner has the following responsibilities.

Define the features of the product;
Decide on release date and content;
Be responsible for the profitability of the product (ROI);
Prioritize features according to market value;
Adjust features and priority every 30 days, as needed; and
Accept or reject work results.

The product owner is responsible for the first of the three Scrum ceremonies: Scrum Planning.

Within scrum.org the definition is now:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Ensuring the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

The ScrumAlliance definition of the moment is sparse with:

Product owner: responsible for the business value of the project

Product Owner results and opinion

Aside from the ScrumAlliance’s less then detailed overview there can easily be seen a small transition of improvement of understanding of the role over time. Note how between the 2007 pdf and future content the Product Owner no longer became a person who has financial accountability. Basically the “Sponsor” part of the role was removed and the role then became a glorified Subject Matter Expert. No other role was created for the elusive person who had money, apparently they have no involvement in the project. I do like the concept of someone being accountable for the “product” but this is still a poor substitute for a real customer.
How does a Product Owner know that the features will result in market value? Is it an instinctual activity? Do they do market research? These are questions that I do not believe the Scrum method adequately covers. This is likely why other methods or techniques such as Lean Startup have grown in support.
Prioritisation evolved over time to be done as needed, which is a welcomed change.
I do like how the current scrum.org definition clarified accountability versus responsibility.
The scrum.org details on the Product Owner being a single, highly empowered person is also a welcomed clarification – but it does raise the point that this assumes teams work on one and only ever one product. The reality is that many maintenance, or Business As Usual teams support multiple products and whilst it is nice and warm and fuzzy to have a prioritized backlog from a Product Owner for each product being supported it still doesn’t help the team understand competing factors within the same organisation. Kanban does provide some explanations of how to handle this problem but it certainly isn’t a part of any introductory readings.
It is interesting to see that the “accept or reject the work results” responsibility was added mid evolution and is now removed again. Who is responsible for this if the Product Owner is no longer?
I do have a question for the ScrumAlliance agilists – who is responsible for the quality of the Product? If the Product Owner is responsible for the business value, shouldn’t they also be accountable for the quality – after all, almost always when teams get pushed to deliver by a particular date it is quality that the Product Owner chooses to downgrade (at the future cost of maintenance and technical debt).

Scrum Master

In the 2007 pdf we have the Scrum Master defined as:

The ScrumMaster is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.

In March 2007 the Scrum Master definition was:

The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meeting:

The ScrumMaster needs to know what tasks have been completed, what tasks have started, any new tasks that have been discovered, and any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster must also look carefully at the number of open tasks in progress. Work in progress needs to be minimized to achieve lean productivity gains.
The ScrumMaster needs to surface dependencies and blocks which are impediments to the Scrum. They need to be prioritized and tracked. A remediation plan needs to be implemented for impediments in priority order. Some can be resolved with the team, some can be resolved across teams, and others will need management involvement as they may be company issues that block all teams from achieving their production capacity. For example, a telecom company recently implemented Scrum and found eighteen items on their impediment list, only two of which were directly related to Scrum teams. The others were company issues that needed management attention.
Last but not least, the ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management or the Human Resources. Certified ScrumMaster James Coplien developed over 200 case studies of notable projects while working at ATT Bell Labs. He reports that over 50% of productivity losses were caused by personnel issues. The ScrumMaster must pay attention to them to ensure the team is fully functional and productive.

Additionally in 2009 the following was added onto the March 2007 version (preceding):

The ScrumMaster is a facilitative team leader working closing with the Product Owner. He must:

Ensure that the team is fully functional and productive;
Enable close cooperation across all roles and functions;
Remove barriers;
Shield the team from external interferences; and
Ensure that the process is followed, including issuing invitations to Daily Scrum, Sprint Review and Sprint Planning meetings.

In September 2010 it changed again:

The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices,and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called “removing impediments.” The Scrum Master’s role is one of a servant-leader for the Scrum Team.

Within scrum.org the definition is now:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

Finding techniques for effective Product Backlog management;
Clearly communicating vision, goals, and Product Backlog items to the Development Team;
Teaching the Scrum Team to create clear and concise Product Backlog items;
Understanding long-term product planning in an empirical environment;
Understanding and practicing agility; and,
Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

Coaching the Development Team in self-organization and cross-functionality;
Teaching and leading the Development Team to create high-value products;
Removing impediments to the Development Team’s progress;
Facilitating Scrum events as requested or needed; and,
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

Leading and coaching the organization in its Scrum adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact Scrum and empirical product development;
Causing change that increases the productivity of the Scrum Team; and,
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The ScrumAlliance definition of the moment is again sparse with:

ScrumMaster: ensures that the team is functional and productive

Scrum Master results and opinion

Phew… where to start on this one. I consider the SM role to be an art. There is this careful balancing act that needs to be at play in order to enable the team to deliver and creating a self autonomous environment versus advising and teaching. The SM role to me is ultimately about improving the teams whole capability at delivering. How does an SM do this? Through behavioural adjustments – people skills are key so March 2007’s third bullet point is incredibly important, but now lost again.
It should be the whole team not just the SM that removes roadblocks. What does an SM do if the roadblock is outside of their control though? Naturally they would help remove it but then this role is beginning to sound like a Project Manager to me… and Certified Scrum Master training says there is no such thing as Project Managers.
Shouldn’t the team work out which interactions are helpful or not? Isn’t that the point of the retrospective? The SM is there to question the team and to plant the idea that the interaction may not be ideal but ultimately it is the team’s choice. That is what makes a self-empowered environment.
Shouldn’t the SM be responsible for also ensuring the team is following first and foremost the Agile Manifesto and principles? I’ve seen plenty of teams that do the practices but then don’t treat each other with respect or have the courage to call out dysfunctions when they see them.
What is ‘Scrum theory’ exactly? I suspect it means reading a whole pile of books and blogs because the detail doesn’t exist anywhere else.
Facilitating sessions should be a temporary activity for the SM – ideally this would be rotated within the team as capability improves.
Ideally the SM role should not take more than 10% of a person’s time (assuming a 8 person team). How much time they actually need to supply depends on three factors – team size, team Scrum capability and the stage of development (ie first sprint or 10th sprint). A team that doesn’t know Scrum will take longer to depend less on their SM. A three person team will transition generally quicker to a position not requiring a dedicated SM faster than one with 10 people. A team that is in their first sprint are still going through Forming, Norming, Storming, Performing and so will depend on their SM more to resolve some of the personality issues. Most Scrumists say it is a full time job, I normally advocate a half bell curve over the life of the project. As the dependencies decrease the SM can then actually start helping delivery of stories (ie can contribute on a different level). Nothing in the descriptions above deal with the timing nor in the contribution levels of the SM.
The term ‘coaching’ is misleading. More often then not the SM is training and advising the team. True ‘coaching’, which I do believe is also needed, gets the team or individual to self reflect to reach answers to problems.
The recent scrum.org definition now combines the SM and Agile Coach role. These are different roles and shouldn’t be combined the way it has been explained. In a small organisation then without a doubt it would be combined but it really is a different ‘hat’ that is being put on. An Agile Coach grows the capability of Scrum Masters, provides an overall adapted framework for the culture of the organisation and works on changing the mindsets of senior executive managers. In the terms of Shu-ha-ri: the team is in Shu, the Scrum Master is normally in ha and the Agile Coach is normally in ri. Choosing an implementation model is no small feat either but as always comes down to its own implemention of Agile – ie create an implementation backlog, prioritise, estimate and work to deliver results frequently.

The Team

In the 2007 pdf we have the Team defined as:

The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. A Team is responsible for figuring out how to turn the Product Backlog into an increment of functionality within an iteration, and managing its own work to do so. The Team members are collectively responsible for the success of each iteration.

In both March 2007 and March 2009 the Team definition was:

The Team:

Is cross-functional, with seven (plus/minus two) members;
Selects the Sprint goal and specifies work results;
Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;
Organizes itself and its work; and
Demos work results to the Product Owner.

Within scrum.org the Team definition is now:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

The ScrumAlliance definition of the moment is:

Team: self-organizes to get the work done

The team results and opinion

Again scrum.org is coming up trumps in providing a really well thought out and detailed explanation including for the first time differentiating that the Development Team is subset of the Scrum Team.
The recent version of text from scrum.org also explains a lot further what ratio of time size is preferred and justifies this well. The 7 (+/- 2) model was too restrictive. People may often miss the fact that this is more a guideline then a rule.
I am frustrated with terms such as ‘Development Team’, ‘testing’ and ‘business analysis’ being used as eludes that Scrum can only be used for software development. Yes I understand that software development was it’s starting place but I would be more generic and say ‘Delivery team’ instead.
The use of the term ‘cross-functional’ is also a pet hate. Only the recent scrum.org definition covers the depths of what it means in adequate detail but even then a major point is missing – why is a cross-functional team recommended? Ultimately it is because you want to achieve the sprint goals without having to depend on external factors. As soon as you have dependencies on those outside of the team to deliver user stories within the sprint then you are introducing risk. Many people miss the fact that a cross-functional team means a team that is first and foremost focussed on achieving the sprint goals (and when I say sprint goals I mean more the product backlog items that have been pulled into the sprint backlog). All too often I see team that have coded and ‘delivered’ the software for the stories inside of the sprint, but the testing is incomplete at the end of the iteration AND the developers have chosen to start new stories rather than help achieve the sprint goal – ie they would rather develop then help out testing to get the sprint achieved. The second intent behind the cross-functional team is that these developers should be focussing on the goal rather then their specialised domain. Where this gets interesting for me is when this is a regular occurence – ie the team are often performing duties outside of their standard specialisation. This is a smell for me. When this happens often – does this mean that the sprint goals are achieved? Yes. But does it do it at the expense of the team’s engagement? Yes. I would argue that if you put a great developer on testing duty for 75% of the project they will be highly unmotivated and it is for this reason that I actually believe the term should be “cross-skilled” rather than “cross-functional”. Cross-skilled infers that you can help out when needed, but that it shouldn’t be the norm where cross-functional is a little more open ended. My adapting too much to issues through a cross-functional team you are likely avoiding a particular flow constraint issue.
Some of the wording in the earlier versions is suggestive that the team is the one that chooses priority – eg ‘selects the sprint goal and specifies the work results’. A clearer wording would be ‘determines how much can be achieved inside of the sprint and defines a way of working that will achieve this’.
‘Demos’ is probably not referring to a showcase and more a ‘hey, we think we have this story right – can you take a look?’
You can see how a single word has a lot of potentially inferred meaning behind it – it is for this reason that short descriptions of roles and responsiblities are fraught with danger.

Anything else?

I’m really getting a theme that the ScrumAlliance doesn’t want you to know anything more than a single sentence so that you have to go on training. A cynical person might think that it is a nice model to generate more revenue. For this I have to give scrum.org kudos of not shying away from giving something more meaningful to its readers.
So where is the Project Manager in all of this? Scrum says that no such role should exist, nor needs to exist in a self-autonomous team but then that eludes to a governance model that is not consistent in a lot of organisations. Often, organisations have a gating process before work starts and whilst delivering Sprints they require Steering Committee oversight – who should be part of this within the team? The Scrum Master? In an ideal world the Steering Committee would turn up to the showcase and see the output to be comfortable. In an ideal world system environments would be in control of developers and not require negotiations with an external team. But most Scrum teams don’t live in this ideal world. There are inevitably external factors that mean the team isn’t in full control of its complete destiny and this is where a project manager can be effective – in ensuring that the team is effective. They are externally, outbound focussed handling pressures outside of the team.
I have seen many projects that have software development components to deliver but at the same time have other components that have to be aligned – such as marketing/communications, training, business process re-development. Normally I treat them as all part of the one team as their stories will affect the success of the ‘product’. They have their own user stories which are prioritised against all the software development work, any dependencies are recognised. Because their work often only comprises < 5% of the end to end work I consider them part of the ‘extended team’. In this respect I have two ‘teams’ – one is the core team who delivers a majority of the stories. These are the people who are full time on the project. Anyone else is part of the extended team. This concept of two teams is not reflected in any Scrum content.

Scrum evolution over time: part 1

Renee Troughton

9 comments

February 19, 2012

A number of people have asked me to explain why I feel Scrum has stagnated and fails to continue to grow. I couldn’t simply provide a 140 character reply that would suffice for those that needed a deep and meaningful reply and so this is part 1 of a 5 part series on Scrum over time and an in depth analysis of how “agile” Scrum really has been over the years.

The 5 part series will be broken down into the following:

A look at Scrum at a high level
The key roles
The key activities/ceremonies
The key artifacts
What is missing

I really don’t want to have these five posts come over as Scrum bashing because I do truly believe there are some damn good elements in Scrum worthy of usage. In fact, I could just as easily do the same analysis for any other software methodology and come out with similar complaints – this is because we are sorely lacking a framework that is both incredibly flexible and is rapidly adaptable directly by the community. As I have said earlier the reason why I have focussed on Scrum is because people have asked me to address it.

So before we get into the detail just a quick overview of how the analysis was done – 5 cuts of data were taken from the internet. These cuts were from June 2003, March 2007, March 2009, September 2010 and a few weeks ago. These dates were chosen based upon major content changes on the websites analysed. Two key sites were analysed for core content – scrum.org and scrumalliance.org which split in late 2009 (capture begins in October). Without doubt these two sites would be the key ‘core go-to’ points for Scrum users.

What is Scrum?

In July 2003 Scrum’s overview was:

An iterative, incremental process for developing software in chaotic environments. Scrum consists of a series of 30 day sprints, each sprint producing an executable. Between sprints, all interested parties evaluate progress and reevaluate technical and business requirements. Work is reestablished and the team enters into another sprint.

The pulse of Scrum is the key to its success … management determines what should be done prior to every sprint, their determination influenced by prior deliverables and requirements. During the sprint, the team is left alone and produces the best software possible : let in chaos, keep out chaos, let in chaos, keep out chaos, let in chaos, keep out chaos … etc.

In March 2007 the pdf was much the same but had some really nice details about it being an empirical process control and what that meant.

In March 2009 the overview read as:

Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.

Scrum is made up of three roles, three ceremonies, and three artifacts.

Three roles: the Product Owner, who is responsible for the business value of the project; the Scrum Master, who ensures that the team is functional and productive; and the self-organized team.

Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.

Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burn down chart.

In September 2010 more detail was added into the overview:

The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them

while providing a framework within which complex products can be developed.

Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control.

The first leg is transparency

Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.

The second leg is inspection

The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the tolerance to inspection of the process. Fortunately, this doesn’t seem to be true of software development. The other factor is the skill and diligence of the people inspecting the work results.

The third leg is adaptation

If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling,and enjoyable.

Scrum employs time boxes to create regularity. Elements of Scrum that are time-boxed include the

Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.

Lastly as at now on Scrum.org:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is:

 Lightweight
 Simple to understand
 Extremely difficult to master

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

and ScrumAlliance.org:

Scrum Principles

The framework and terminology are simple in concept yet difficult to implement. Successful Scrum teams embrace the values upon which Scrum is based (paraphrased from the Agile Manifesto):

We value

Individuals and interactions over processes and tools
Completed functionality over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, the items on the left matter more.

True success with the Scrum framework comes from teams and organizations who understand these values and the principles that form the foundation of all agile processes.

We’ve introduced some new terms in describing the Scrum framework. Let’s look at them in more detail. Scrum is made up of three roles, four ceremonies, and three artifacts.

Results

So what changed in the general fundamentals of Scrum over the years given what we can see of the opening overviews:

Timebox has adapted from being a strict 30 days to one month or less
The three roles concept has never changed (covered in more detail in part 2)
The ceremonies increased from three to five and then back down to 4 (covered in more detail in part 3)
The three artifacts have never changed (although as you will see in detail in part 4 that isn’t the case under the covers)

Opinion

The “30 day” rule isn’t a huge deal. I do recall reading in 2004 that you could reduce it down and there was mention as to what the impact would be to the sizing of the other ceremonies but it was something that I had to drudge around to find. If you took it originally as a rule then one may have been disadvantaged but remember back then delivering something once a month was actually a big deal.
My biggest gripe is that most people now don’t do thirty day sprints. 57% of the community are using 2 week or less sized sprints. Given that only 14% of the community are using sprint lengths anywhere near one month why wouldn’t you just change this to fortnightly. I understand that part of what they are saying is that more than 30 days is unacceptable but to be honest, continuous improvement feedback loops where the sprints are one month are terrible. I have tried four week sprints, one week, two week and daily. I learnt through trial early in 2004 that two weeks was ideal. Most of the community knows this now, why can’t the overview reflect this and not lead new starters to Scrum to believe that 30 days is the right answer.
It was interesting to see that the ScrumAlliance re-wrote the 2nd manifesto statement – “working software” was changed to “completed functionality”. Part of me wishes they would have re-wrote it even further, but this was a curious change to me. Why not mention “value” anywhere? Software that we deliver should be working, completed, but most importantly should deliver value.
For my 2 cents the format of the March 2009 overview actually gives the best introduction to someone unfamiliar with Scrum as to what it is.
I wish most of these statements took out the ‘software development’ bit. Yes it was born for addressing software development process issues, but the reality is the framework applies really nicely for more than that and I would love to see the scope widened further to a broader community including those using it for other purposes.

Game storming book review

Renee Troughton

1 comment

February 8, 2012

Gamestorming, a playbook for innovators, rulebreakers and changemakers by Dave Gray, Sunni Brown and James Macanufo is a great composition of a number of games and techniques out there to reach collaborative and innovative outcomes; well worthy of a read for all Agile coaches.

The form, for the most part of the book, describes the game, the objective, number of players, duration of play, rules, the strategy for facilitating it and kudos to the originator of the game.

It wasn’t that every page for me was a gem, in fact there were probably only a handful of things that I felt I didn’t already know that I could take away and apply on a situational basis. But a handful of things – is a handful more than I had and for me that is still saying something. So lets take a look at the concepts and ideas that made me think:

Page 21: Every time I group a set of like themed post-it notes on a wall it actually has a term – ‘affinity mapping’, go figure.
Page 39: The airplane metaphor. This reminded me somewhat of the sailboat retrospective technique. The back of the plan is ‘where we come from’, the port holes ‘who do we deliver value to’, the propellers ‘what gives us the power’, the cockpit ‘how do we steer’ and the horizon or front of the plane is ‘where are we going’.
Page 65: Empathy map. I actually just appreciated being reminded about this fantastic idea from XPlane. Furthermore I had the fun opportunity to put it into action today which for the most part I felt worked well for the workshop I was in. Looking at the Anti-Problem (on page 80) made me wonder if these two techniques could be effectively applied to demonstrate a customer view/perspective that you want to avoid.
Page 113: Pie chart agendas. I hate writing agendas with a passion (the ultimate waste – documentation of a future waste event), but the option to demonstrate in a visual format how much time is being spent on particular activities is a creative approach that might have me doing them with a little more motivation. The full circle of the pie is the total time of the meeting, you basically slice it up into pie pieces of the time proportionately you will be taking for each topic.
Page 131: Trading card avatars. Used as an icebreaker this game has the added boon of also generating avatars for the story wall. Basically each person creates their own trading card with a hand drawn picture of themselves, their nickname and little known facts.
Page 165: The Elevator Pitch. Not a new concept to me but a nice format structure – “For (target customer), who has (customer need), (product name) is a (market category) that (one key benefit). Unlike (competition), the product (unique differentiator).”

If you are new to facilitating, Agile coaching or Scrum Master then I would definitely recommend taking a look at this book.

The Car Change Game

Renee Troughton

4 comments

February 3, 2012

Why is it so hard for software development groups to adopt a different approach or methodology? Why is it so hard for managers and leaders to transition out of the command and control mode?

Because we hate change.

This is a game that you can play at the beginning of a training session to allow people to open their minds that what they are about to learn isn’t easy. It is hard to change and they need to consciously go into the training that it isn’t just a matter of ‘change your way and you will succeed’.

To prepare this each participant needs the following (or have available on the table within reach):

two A4 pieces of paper
scissors
colour pens/crayons/pencils/whiteboard markers
voting cards (eg 1 to 10 or 1 to 5)

Show them a A4 piece of paper with the exercise template on it. An example of the template right here:

Exercise template

The exercise doesn’t have to be about a car, you can choose anything, but this is just an example.

Explain the following rules:

With your A4 piece of paper draw a car for yourself. It should fill up at least half of the page.
Your own car doesn’t have to look like the one above, you can be as creative as you like
But… the headlights need to be coloured in yellow and the car needs to be coloured red.
Once you have drawn and coloured in your car then use the scissors to cut it out.

Inform them that you will be timing how long it takes to do the car, but that it isn’t a race. When they are done put their hand up to signal end of time for them.

Let them start and start the timer. As each person signals write their time up on the board.

When the group has all finished their car do a quick demo of a few of the more interesting designs. Here is an example of my finished car:

Talk about the quality of the solutions, how closely the cuts are against the lines and the evenness of colouring in. Then ask the group to vote using their cards how comfortable they felt doing the exercise (for example 1 is extremely uncomfortable, 10 is extremely comfortable). Write up the comfort scores.

Now explain that the activity is going to be repeated again – but this time do not use the same hand that you used the first time. For example, if they are right-handed and used their right hand to draw and cut the first time this next time use their left hand.

This second car should be a duplicate of the one they created in the first instance. Explain that they will be timed again and start the exercise.

Write up the times again. Before walking through the results ask the group to use their voting cards and to rate how comfortable they felt doing the exercise this time. Write up the scores.

Now take a look at some of the designs and give a walk-through of the differences. For example, here is a comparison of my cars (the original is on the left):

Car Comparison

Using my own cars as an example here is what we can observe:

The sizing is vastly different. Scale and proportion are beyond what is probably tolerable.
The cut out is more jagged and nowhere near as close to the line.
The colouring in is less intense and has considerably more whitespace in it.

Then have a look at the time differences. The second car will likely be 50-100% longer to do despite having a template and no longer requiring innovation.

Then have a look at the comfort levels. They would have dropped but it is likely that there was still a lot of laughter in the room (until the scissors had to be used).

Get the group to consider what it would be like if you used the hand that you used for the second car every single day for the next three months and then attempted the exercise again. Ask them to re-vote what they think their comfort rating would be after the three months. Write this up.

Facilitate them through an introspection/reflection regarding what they have learnt about change. Common results will include the following:

Adopting a new change (be it methodology or leadership style) won’t be easy;
in fact it will feel very uncomfortable
but if we stick at it for a while then we will get better at it and consequently feel more comfortable.
It is highly likely that adopting this change will actually result in it taking longer to do things for a while
and that quality out output might also degrade
but bit by bit we will get faster and better until our results are comparable.
After that we might even start seeing some benefits of doing the change

Now that you have prepared the group with the frustrations they will receive by change it is a great opportunity to start asking the question “If it is so hard, then why should we change?”

Frequency Foundation and Agile

Renee Troughton

25 comments

January 23, 2012

Frequency Foundation had its debut launch with its first post back in April 2002 with almost weekly articles ranging from patches that stimulate energy in the weakest parts of your body to multivitamins, the risk of vaccination or of going to hospital, autism causes and even the reversal of aging.

A number of articles and blogs produced by Frequency Foundation refer to “frequencies” that can be used to solve a multitude of ailments ranging from influenza, measles, borne virus, mental illness and even the cancer “germ”. Mercury or fluoride can be eliminated, your hypothalamus can be stimulated or you could even affect bacteria in your stomach associated with the generation of fat.

Each time these ailments and risks are described visitors are also provided with the opportunity to purchase a frequency for $10US. Alternatively visitors can purchase a $110 subscription to the Frequency Foundation.

These purchased frequencies are provided in PDF which can be re-generated on specific machines. For a more detailed understanding of how the technical elements fit together to “improve the effectiveness of frequency transmission” the “New ABPA Summer Sale” from June 23 2007 goes into considerably more detail.

On March 28 2010 the site moved where similar styles of articles were often output. Frequencies were no longer available for individual purchase but subscribers still had access to changes. In addition the new website provides service of Photo Analysis and ABPA/SC1 Transmission for $200. More detail on what this sort of service is can be found at http://frequencyfoundation.com/forms/PhotoAnalysis.pdf.

Royal Rife and how it is linked to Frequency Foundation

Even in these early days Frequency Foundation was careful to ensure that they had themselves covered with disclaimers:

What you see here may or may not be useful, helpful, or harmful and much of it will not be approved by the FDA. This is a research site and any information is for other researchers to use at their own risk. Consult with your physician for medical advice.

The hint to why such a disclaimer exists is likely due to the association with the technology and theories being used to create/generate these frequencies. The Photo Analysis PDF goes into more detail of this:

Royal Rife identified frequencies for eliminating pathogens using a high powered microscope that could examine living organisms with higher resolution than most microscopes available today. He could directly see frequencies killing pathogens and noticed that exact frequencies were required to generate the effect.

Many people need help identifying pathogen frequencies since Rife’s technology for visualizing living organism is not readily available. Frequency Foundation helps identify these frequencies for a specific individual by analysis of high resolution digital photos.

The Frequency Foundation uses advanced technology originally developed by the Department of Defense for broadcasting the same frequencies remotely using ultra-low frequency bands similar to those used to communicate through the earth to submarines.

Looking at Royal Rife on Wikipedia reveals a different perspective on Royal Rife’s work:

Royal Raymond Rife (May 16, 1888 – August 5, 1971) was an American nventor and early exponent of high-magnification time-lapse cine-micrography. In the 1930s, he claimed that by using a specially designed optical microscope he could observe a number of microbes which were too small to visualize with previously existing technology.Rife also reported that a “beam ray” device of his invention could weaken or destroy the pathogens by energetically exciting destructive resonances in their constituent chemicals.

Rife’s claims could not be independently replicated, and were ultimately discredited by the medical profession in the 1950s. Rife blamed the scientific rejection of his claims on a conspiracy involving the American Medical Association, the Department of Public Health, and other elements of “organized medicine”, which had “brainwashed” potential supporters of his devices.

Wikipedia continues later:

Interest in Rife was revived in the 1980s by author Barry Lynes, who wrote a book about Rife entitled The Cancer Cure That Worked. The book claimed that Rife’s beam ray device could cure cancer, but that all mention of his discoveries was suppressed in the 1930s by a wide-ranging conspiracy headed by the American Medical Association. The American Cancer Society described Lynes’ claims as implausible, noting that the book was written “in a style typical of conspiratorial theorists” and defied any independent verification.

In response to this renewed interest, devices bearing Rife’s name began to be produced and marketed in the 1980s. Such “Rife devices” have figured prominently in a number of cases of health fraud in the U.S., typically centered around the uselessness of the devices and the grandiose claims with which they are marketed. In a 1996 case, the marketers of a “Rife device” claiming to cure numerous diseases including cancer and AIDS were convicted of felony health fraud.The sentencing judge described them as “target[ing] the most vulnerable people, including those suffering from terminal disease” and providing false hope.In 2002 John Bryon Krueger, who operated the “Royal Rife Research Society,” was sentenced to 12 years in prison for his role in a murder and also received a concurrent 30-month sentence for illegally selling Rife devices. In 2009 a U.S. court convicted James Folsom of 26 felony counts for sale of the Rife devices sold as “NatureTronics,” “AstroPulse,” “BioSolutions,” “Energy Wellness,” and “Global Wellness.”

Several deaths have resulted from the use of Rife machines in place of standard medical treatment. In one case, a U.S. court found that the marketer of a Rife device had violated the law and that, as a result of her actions, a cancer patient had ceased chemotherapy and died.In Australia, the use of Rife machines has been blamed for the deaths of cancer patients who might have been cured with conventional therapy.

In 1994, the American Cancer Society reported that Rife machines were being sold in a “pyramid-like, multilevel marketing scheme”. A key component in the marketing of Rife devices has been the claim, initially put forward by Rife himself, that the devices were being suppressed by an establishment conspiracy against cancer “cures”.Although “Rife devices” are not registered by the U.S Food and Drug Administration and have been linked to deaths among cancer sufferers, the Seattle Times reported that over 300 people attended the 2006 Rife International Health Conference in Seattle, where dozens of unregistered devices were sold.

The long winded linkage to Agile

All of the blog entries, both in the old and in the new site, of the Frequency Foundation are done by a single person. This person is an original signatory and co-creator of the Agile Manifesto; the co-founder of the Agile method with 75% of the market share – Scrum. This person is none other than Jeff Sutherland.

Confirming a direct association is not difficult with the Frequency Foundation organisation directly re-routing mail to the Scrum Training Institute at 32 Appleton Street, Somerville, MA. Whois domain registration confirms this again.

Consent forms, submarines and photos

Delving further into some of the information and forms reveals some interesting insights into the quality of such frequency services. The consent form has some particularly interesting statements including:

Because of the lack of FDA or other federal or state government approval of tests, procedures or information provided, I understand that results can only be accepted for their entertainment value.

and “I am here”…

not as a government employee or agent of any type on a mission of entrapment or investigation.

Furthermore, there are references to the technology being used being similar to what submarines used to communicate through the Earth. If you look further into submarine communication the method that is being eluded to is Extremely Low Frequency (ELF) Transmissions which has two bases connected together at a distance of 50 kilometers with their own power source. Due to the complexities of such sites only two actually existed in the world and with the US version now decommissioned the likelihood of such technology actually being used by Frequency Foundation is incredibly implausible (unless they are using the Russian one).

Most of the Frequency Foundation work seems to be based upon research done with microscopes and yet they ask for photo’s to be sent through to allow for remote analysis. Requirements for the photos are equally enlightening:

Take the photos with a tripod, as it doubles the resolution of the image.

Effectiveness is also directly related to the size of the file containing the photo. If you camera will generate a 2MB JPG file, that is 4 times as good as a 500k JPG.

A second digital photo of the whole body from head to toe is critical. If any of your body is out of the photo, pathogens will migrate to that area.

There is no denying, such use of a service can only be considered “entertainment” and at $200US that is a fairly costly form of entertainment.

The blog author’s personal opinion and unanswered questions

Personally I am confused as to why Jeff Sutherland has actually gone to some lengths to separate the two of these organisations. Even his linked in profile has no mention of Frequency Foundation. Is it a concern to him that his relationship with radionics and Royal Rife would impact on his reputation within the Agile community?

I have found only one single person (on multiple sites) who has extolled the virtues of Frequency Foundation. The organisation itself provides no direct references to substantiated scientifically confirmed results – even confirmed in writing if you look at the 6^th point on the consent form.

The organisation is still selling Photo Analysis and ABPA Transmissions.

This is not a post to extol or demerit the virtues of Scrum, but if it’s founder is caught up in an environment that denies scientific tests, that is concerned by agents investigating him and has limited technical depth in simplistic things such as photo resolutions then what does that mean for the Scrum community?

I do understand that science theories such as Evolution were discredited by the mainstream population and even officially by the US government for a portion of time but we are talking about a science community that has recently tested and debunked this theory. A theory that has reached the courts and lost several times.

The believer in this theory, Jeff Sutherland, is still trying to sell his $200US solution to anyone desperate for an answer.

Are we being led by a knowledge founder that doesn’t believe in metrics; a leader that doesn’t stop when faced with facts? Does this call into question why Scrum is so slow to adopt change and new concepts?

Are we being led by a knowledge founder that peddles $200US entertainment solutions. Where does “working software” (solutions) fit in here?

How does this fit against the Scrum community’s ethic of openness? How does this fit against “We would rather say, ‘no,’ then make false promises.”

Are there any relationships between Scrum’s method of training and Frequency Foundation?

Is there any link to the Frequency Foundation and the split of the Scrum Alliance and Scrum.org?

If you feel inclined please leave a response on your thoughts to these questions.

Author’s disclaimer

Opinions presented within this blog represent only the author and not the organisations that they currently or have ever worked for. The opinion of The Agile Revolution is represented within their podcast.

The author doesn’t mind if you represent the FDA, a government authority, an agent, if you are on a mission or if you found it entertaining (for free).

Stoosonians unite!

Renee Troughton

5 comments

January 15, 2012

The Smithsonian is the world’s largest museum and research complex with hundreds of affiliated museums.

The Stoosonian is much the same but switch up museum with people and thought leaders. It could be the collective noun for people focussed on building such a network focussed on leadership in the same guise that the Agile Alliance crowd marketed the Agile Manifesto.

If you haven’t heard of Stoos then you might have been on holidays and not reading or following the twitter streams in the Agile community. In just one week I heard about it from three separate sources so the community is certainly abuzz. And I hope rightly so.

So what is Stoos? Take a look at their opening statement at http://www.stoosnetwork.org

Reflecting on leadership in organizations today, we find ourselves in a bit of a mess. We see reliance on linear, mechanistic thinking, companies focusing more on stock price than delighting customers, and knowledge workers whose voices are ignored by the bosses who direct them. All these factors are reflected in the current economic crisis, increased inequity, bankruptcies and widespread disillusionment.

There has to be a better way.

In January 2012, a diverse group of twenty one people including senior executives, business strategists, managers, academics, and lean/agile development practitioners from four continents, met in Stoos, Switzerland. We believe that we uncovered some of the common characteristics of that better way.

From the stoos network page there is a myriad of information that can be found from the closed sessions that were held. A good portion of content has started being posted on LinkedIn and on a variety of blogs and other mediums including #stoos on twitter. In fact, the wide variety of mediums does mean you have the traverse around a bit to gleam everything that is being talked about but without a doubt the social stream is incredibly active.

I spent a few nights taking everything in and having a look around. The hype from colleagues lived up to my initial delve and then I began to test the waters on a few questions that I had. My first concern had been the target Stakeholder list. Now let me start that I am highly impressed that the group took the effort to do this list, debate it and then re-evaluate it. But two things jumped out on that list (and a third now that I have received some responses):

The C-section (eg CIOs, CEOs, etc) are rated so low (before and after),
First line management is non existent (but maybe that is due to deviations in definition of middle management)
Shareholders are rated at 0

The reason why I was concerned in particular about the C-section being so low is that every time I have done an Agile transformation within an organisation it absolutely had to have C-section level buy-in. This wasn’t an optional element. It was critical to success. Without C-section level buy-in teams were left to do Agile in stealth. Sure they worked better than before but there was a upper bound of roadblocks that endlessly re-0ccured and never got addressed because there was no organisational focus on being Agile. Culture of the team subtly changed but without C-section buy-in the culture of the organisation would never change.

This is critical to not miss. Agile, to get the benefit, requires cultural transformation. The Leadership problem is no different – in fact it is more often then not Leadership that drives culture. I’m not just talking about first line managers but also middle managers, CIOs and CEOs.

I then did a deep dive at the problem analysis done. Again I want to take a moment and congratulate the Stoos team on the job they did on generating this starting diagram. I would imagine they spent a few hours on this and as a starting map I think it covers most of the key points. To get it past 80/20 right it would have likely taken the whole two days.

If you take a look at the top two (not necessarily by priority) root causes you see shareholders and C-section management as the cause.

So my concern is that without doing something to address those two root causes that all this effort might be in vain.

Side note: would love to see the 5 whys applied to the root causes because they aren’t base root – eg Why are leadership skills missing in today’s managers?

Now I posed the question of C-section being non targeted in the twitter stream and was given a couple of nice links which is great information and a step in the right direction but again isn’t the root cause. The root cause as in the article is lack of education – and who do we need to educate? – the C-section, shareholders, and future to-be C-managers. Which is why I am happy that educators are high on the target audience. So there is hope, but maybe not in my lifetime.

What I love about the Stoos community thus far:

They are responsive, they are listening and they have some beautifully deep thinkers in there. A few of the questions that popped up in my mind today whilst I was a road-trip I was amazed to have found others ask and have had answers/responses to.
There is an appreciation that the command and control culture is thousands of years old – this is a very deeply embedded behavioural human trait. I am curious if it is neurologically driven somehow.
There is an appreciation that we actually have the answers on how to lead – it is just that for some reason it is not disseminating as expected. This is where I think some deep thinking root cause analysis needs to be directed towards.

As a test I asked a friend of mine who leads a team of ten about their leadership.

Do you think you are a leader or a manager?
A little of both. More detail then given.

How do you think your team perceives you – more as a leader or a manager?
Probably a manager.

Why did you go into management as a field?
For the money.

Not because you enjoy working with people?
No. I was smart, it was expected of me to progress that way.

How much time do you spend learning of new leadership and management techniques?
None. I have no time for that sort of stuff. I am too busy.

So if you weren’t so busy you would spend some time learning how to be a better leader/manager?
Probably not.

I could have continued going on to find the root cause but at that time my friend was starting to get the picture that I wasn’t playing nicely. Getting honest answers on this is going to be hard but we need to get some broad understanding (ie real metrics lean start-up style) to make sure we are going to make a dent in this massive global problem.

So lastly I want to say thank-you to the Stoos group for having the guts to tackle this and to make a great start on it. I am pleased that the group has such a diverse set of thinkers but would love to see a few other thoughtleaders included in the list – my pick would be someone who represents motivation (eg Dan Pink), someone for crowdscourcing (eg Dan Tapscott) and someone from the field of Neuroscience (to be honest Peter Burrows wouldn’t be so bad as he conceptually understands Agile and more importantly has some interesting team dynamic theories).

Keep it up and don’t take this blog as a big rant of criticism – the good certainly way outweighs the bad.

The New Age of Business

Renee Troughton

1 comment

December 20, 2011

Ideagoras. A beautiful word, but even more beautiful when you get to the substance of it. In Greece, 600BC an agora was an open place of assembly where trade occurred. In today’s world trade is big business and the growing trend of this business is shifting to the Internet at break-neck speeds. The agora was the political heart of Athens. We cannot wholeheartedly say the same of the Internet today but opinion is debated and freely open for anyone on the internet with a decent download speed.

Don Tapscott and Anthony D Williams first created the term ideagoras in Wikinomics to refer to the online idea marketplaces (amongst other terms such as Marketocracy and Prosumers) but don’t limit yourself to the internet on this and certainly don’t limit yourself to ideas. Think of it more in terms of crowd sourcing. When you consider Seth Godin’s work there are strong links.

Using ideagoras we can create better models of climate change or with the addition of gaming elements discover breakthroughs in genetics. But what does this mean for the world of Agile?

For me ideagoras and crowdsourcing goes so much wider than the tantalising treats that Don gives us. Tied to Agile it is a beautiful model for decision making, swarming and must make us re-evaluate how we motivate, listen to and lead people in the business world. Let us take a quick look at how ideagoras can revolutionise an organisation.

Decision Making

Large organisations don’t just have a few or a dozen projects on the go. Commonly they have hundreds of projects on the go. Many are undercover and hidden from upper levels of magic, pet projects of their creators with little return on investment when you look under the covers. Lean Startups have sparked a resurgence in the importance of working on the right work not just doing the work right. They promote the concept of taking the idea and then testing the market with a mockup or prototype solution to first confirm that you are on the right track to get the most bang for your buck (my words not theirs). Using ideagoras we can take this to the next plateau. Rather than go out to the market with a mock-up or prototype first get the idea list filtered out through crowdscourcing. The idea in the first place should come through this mechanism. Have a feature on your website to be able to have your own customers add requests for improvements on the systems that you provide to them. Enable them to vote up (“like” or “+1”) the ideas that they would want to see implemented. Let your employees do the same using the same website. In this respect employee innovation can be recognised and encouraged by your own customers.

Now there are obviously down sides to this approach. Firstly, like most things in life it can be ‘gamed’ and there would need to be care taken to limit this, but there are a number of technological solutions to reduce this risk. Secondly, and probably most importantly these brilliant ideas are now exposed to your competition. The fastest implementor will be the one that wins the business. But this is not a bad thing – it is a great encouragement to ensure that we do follow through using Lean Startup principles to make sure we are on the right path and then Agile to rapidly develop the solution. A truly nimble and versatile organisation that focusses on rapid delivery, feedback and excellent customer relationships will be the winner in this future business war.

Think of the Fortune 500 companies – how many of them would stand up to the agility required to pull this off? Ten percent? Bureaucracy and red tape will drag them down and the small and medium businesses that can move quicker will continue to draw in the dissatisfied consumers.

Swarming and Motivation

If you have taken the first step to including your customer in your decision and idea generation process then you need to make sure you have the right team to follow through on the job. This is where swarming comes in. Most organisations throw their ‘resources’ about from project to project with little thought as to whether the person is actually interested and passionate about that type or project. Additionally they do it with little thought of true speed and its relationship to return of investment.

In the future of speed to deliver innovation is going to the be determining winner for customers then swarming will become a natural reaction. You need to make that baby in one month. Governance processes will need to dramatically change to allow for this to occur. Estimation processes as well. We will need to be able to trust gut instincts on how hard it would be to fully deliver the idea and accept some failures of poor estimations. We will need have governance processes that kick off projects solely based upon votes received and the gut estimate. A safe to fail culture is critical here.

To resource the work we need passionate people who will focus on this idea like it truly is their newborn baby. To do this we can leverage ideagoras again. Employees interested in being part of this work should be able to sign up for it and be able to be immediately released to follow through on it. Potentially they could also be ‘socially approved’ as suitable for this role by their peers within the organisation. Again gaming of this would need to be careful.

Swarm the motivated people quickly onto the project to realise the benefit into the marketplace sooner.

Leadership and Customer Satisfaction Rating

What if the business world we lived in was like Survivor and you were able to vote someone off the island? 360 degree reviews and anonymous employee satisfaction surveys are a very poor form of this. The better solution is to use ideagoras again to rate leaders. Let anyone rank or ‘rate’ anyone else in the organisation (again watch out for gaming the system). Do you think this would change Leader’s behaviour? Hell yes. Do you think they would be scared by this? Hell yes. There would be nowhere to hide. It would force many to leave. But think about it. Would the sort of person that you want to retain be threatened by this? No. Would the sort of person that won’t make it in this new age world be threatened by this? Yes. This is an amazing filtering system for getting the right culture.

Think of the scenario to yourself right now – think of all the bosses you have had over the years. If you pretended for a moment to be a CEO and have their resume’s on your desk how many of them would you hire? Which ones wouldn’t you hire?

No one knows better than the employees underneath a manager as to whether they are a good leader or not. Why not ask them to rate your leadership team?

Take it further. Take it to your customers. eBay has for an incredibly long time had the concept of rating the seller. A transparent feedback mechanism of trust from the consumer to the supplier. Sound familiar? Organisations that feel that they want to be leaders in customer service need to be able to demonstrate in a transparent, easy to access way their customer’s feedback. Social networking is improving this but organisations can help this along even further by enabling transparent feedback and visualising the comments (the good, the bad and the nasty) to everyone. Nothing will drive customer service better than knowing every single customer is freely given the right to publicly chastise or support you on your own website. I would love to see a feature added to Facebook that allowed you to rate an organisation’s service, ultimately providing a repository of this information outside of the organisation itself (for all those not courageous enough to do it themselves).

Conclusion

This is a wake up call. Large bureaucratic organisations I am talking to you. Without Agile, Lean, Lean Startups, Crowd Sourcing and other emerging frameworks you will fail. Now is the time to invest in yourself for the future. Inspect and Adapt. Listen to your customers and your employees not just your shareholders. Trust, respect and respond to your customers and your employees first and foremost. Your shareholders will as a consequence be happy because your organisation will be succeeding in a world when many are not.

Motivation and performance

Renee Troughton

3 comments

November 25, 2011

All my blogs are highly self-opinionated. This one is going to be even further out there.

We have all hopefully had a good look at Daniel Pink’s amazing work on motivation. But despite this knowledge how do most organisations still currently manage motivation and performance?

They almost always still have yearly bonuses. Maybe this is because CEOs are motivated to get their yearly bonus and hence they think everyone else will be equally motivated for theirs. If all of our bonuses were several million dollars I am sure we would all be willing to conduct deplorable activities such as offshoring half of our work to third world nations… oh wait… no I have morals (well enough not to do this), that and I know it actually won’t work.

Most organisations still do the whole ‘you aren’t cutting it so I need to have a serious talk to you’ discussion.

Have you ever worked in an organisation where you haven’t felt motivated? Did you enter that organisation with such a low level of motivation? Of course not. People don’t enter organisations unmotivated – organisations make them unmotivated. Who do the organisations blame for this? The person of course!

I think there is something seriously wrong in this world if it is a CEO’s attitude that unmotivated people should quit, as if they are dead weight that the organisation cannot learn anything from. They performance manage these people in the hope of making them even further uncomfortable that they will leave. I say this as if it is an intentional plan, because it is in some organisations. To be honest it sickens me.

I have had the privilege to speak to some people who this has happened to. They haven’t explained their lack of motivational issues to the HR bodies of the organisation because they feel strongly that the HR bodies do not care or refuse to do anything about it. Their common causes of motivational derailment:

Bullying
Sexual harassment
Doing endlessly monotonous work
Not having the opportunity to do what they do best
Not being listened to (talking to the wind)
A long-term physiological or psychological illness (manifesting into stress of lack of performance)

In all these instances these people were labelled as being ‘at fault’ by their management and forced into a performance review process. Does the above items really seem like the employee’s fault? And yet when they leave senior management have the attitude “Well done! We got rid of that highly unengaged person.”

What have they done ? They have basically not fixed a really bad problem and instead will introduce someone else into the loop of misery, all the while leaving a permanent dent on someone’s mental health. I am so incredibly angry about this.

What needs to be done:

Stop having the attitude that “we need to get rid of the poor or unengaged performers” and replace it with “we need to listen and start changing the culture around here”
Start asking who your HR group is meant to be supporting – the managers or the people? Let me give you a hint, if is just the managers then you are wrong.
Stop telling poor performers that they suck, start listening to them. Start asking questions like “When you joined this organisation what sort of environment were you hoping for?”, “How can we change the work that you do or the way that you do it so it can be more fun?” and “How can we make you more in control of what you do on a day-to-day basis?”
Don’t jump to the conclusion that a poor organisational score on managing performance means you have to get rid of people. Find out why people rated the organisation that way and rather than manage them out work with them to improve their motivation and performance.
Be aware that people are smart. If you tell someone ‘stop doing x’ they will game it, they will do it, but the underlying discontent and unhappiness will remain; it will likely manifest elsewhere or result in other actions. It is better to get a positive outcome for the employee and the organisation then just the organisation.