Archive for February, 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:

  1. 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.
  2. 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.
  3. 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.

Read Full Post »

Scrum evolution over time: part 1

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:

  1. A look at Scrum at a high level
  2. The key roles
  3. The key activities/ceremonies
  4. The key artifacts
  5. 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.


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)


  • 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.

Read Full Post »

Game storming book review

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.

Read Full Post »

The Car Change Game

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:

  1. With your A4 piece of paper draw a car for yourself. It should fill up at least half of the page.
  2. Your own car doesn’t have to look like the one above, you can be as creative as you like
  3. But… the headlights need to be coloured in yellow and the car needs to be coloured red.
  4. 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:

Initial crafted 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?”


Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers