Fear of Exposure in Scrum

Some developers just like to be left alone in a corner to focus on what they are working on (for better or worse) and can become quite defensive about perceived regular inspections of what they are working on. The problem for these ‘closed book’ developers is the fact that Scrum is all about regular inspections – not to spy of course but to identify waste and misguided ‘progress’.

Of course these inspection ceremonies such as the daily scrums, sprint reviews and retrospectives may also uncover those individuals (and I use that word on purpose) that genuinely don’t wish to do the right thing for the team. These few ‘bad eggs’ are often the ones who are most afraid of exposure as the rug that they have been using to cover up poor quality, lazy ‘work’ is dramatically pulled out from under them.

Feel Free to be Exposed in Scrum

Growing up in Australia we are taught very early on how dangerous sun exposure can be. Stay out too long and you will be nursing red, painful skin for several days. That being said, let’s not be too tough on our source of life as staying out for a short, disciplined period of time can lead to a nice, healthy glow and an important dose of vitamin D.

Scrum’s focus on regular inspection of both the product and the process is all about gaining the glow and avoiding the burn. It is much easier to take care of tanned skin as opposed to red raw, burnt skin. This is exactly the same as software. If we can detect issues early and often, there will be less painful surprises later on that require significant nursing and attention.

I find that when framed in that way, team members (who genuinely wish to do the right thing) will embrace these ceremonies even if they have a natural inclination to stay in a corner with headphones on.

Have you had to deal with a fear of exposure in your organization or team? How did you tackle it? Did you manage to overcome it? Let me know what happened and how you handled it by leaving a comment below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

Fear of Change in Scrum

This is a classic human phobia and when we decide to make the leap into Scrum from a more traditional approach we certainly throw up change ‘in spades’ don’t we? How about programmers doing testing, releasable software every sprint, cross-­functional and self-­organizing teams, not to mention no more project managers just to name a few – yikes!

So here’s the thing ‐ change is scary. It takes people out of their comfort zones, it disrupts the status quo and is often perceived as a threat to many who are comfortable with the present state. The sad reality is that there will always be those in any organization who will simply reject change irrespective of how effective you’ve been in promoting the benefits of Scrum and / or how unhealthy the present situation is.

It is important to understand and accept this organizational axiom or you’ll find yourself dwelling in a constant state of disappointment.

If you take Cohn’s approach from above, you will eventually generate a strong enough wave of positivity that will wash away any cynical attitudes.

Free to change

A real key to initiating change is in how the transition is framed and communicated. Not many folks are comfortable with forced or categorical change that completely adjusts the existing landscape. Instead, present the transition as an ongoing experiment. Communicate the fact that the change is under scrutiny rather than being fait accompli and if something isn’t working, the team will simply inspect and adapt together.

Understanding this failsafe option often allays the fears of those scared to change.

Have you had to deal with a fear of change in your organization or team? How did you tackle it? Did you manage to break free? Let me know what happened and how you handled it by leaving a comment below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

I remember when I was excitedly presenting ‘Scrum 101’ concepts to my first soon-to-be Scrum team. I was sure everyone was going to pick up on my contagious enthusiasm and indeed, on the whole I gleaned a bunch of decisive nods and smiles. However, when I looked more closely I started to also witness some noticeable fidgeting and darting eyes synonymous with discomfort and fear, especially coming from a few of the testers. To understand why this was, we need to look into the past and briefly explore what has happened to the QA function in recent times…

Waterfall friendship

Thanks in large to the earlier adoption of the Waterfall model of software development, a more profound appreciation for the testing function began to take hold. Within many organizations, a strong, independent testing team that stood on an equal footing with the programming team was becoming the norm. Testing standards were developed, professional development paths purely for testers were established and the testers ‘owned’ a whole phase of the cascading Waterfall process.

Then along comes Scrum (and its other agile cousins) and all of a sudden life changes. Testing in Scrum becomes the responsibility of everyone in the team; test-driven-development becomes a programmer-centric testing practice and even functional tests can now be automated by programmers. Suddenly the question starts creeping into worried minds – “How and where do the testers fit in?” Before going on, to avoid any undue panic for any reader at this stage, I will cut straight to the chase and state that in fact the tester has never been so important. Whilst others may still remain fearful of the new world order, some testers recognize this and are immediately relieved and excited and relieved by Scrum and its “everyone’s-in-it-together” approach.

Change is in the air

Change is scary. Crispin and Gregory offer some important insight into why the transition to agile development can be particularly worrisome for some testers.

As I will go on to explain, when working in a genuine Scrum environment, none of these fears are justified. Yes, there is an identity shift, however every tester ‘worth their weight’ that I have worked with has either immediately or eventually embraced their enhanced identity with open arms.

When change occurs, it is a natural instinct to romanticize the past, clinging to anything that was warm and fuzzy about it rather than remembering the darker, negative times. Testers shouldn’t forget that life certainly wasn’t a walk in the park in the old days (even if there were pretty waterfalls along the way). A constant that I have witnessed many times when working within this more traditional process is the frazzled, burnt-out tester.

New identities

So how do we help testers embrace their role in the new Scrum world where the ‘waterfalls’ have dried up?

Let’s first address the so-called ‘elephant in the room’ – the fear of being made functionally redundant. Fundamentally, the testers should feel safe because they are different. They possess a unique skill-set and way of thinking that is critical to the success of any software project and I like the following description to help illustrate this point.

In a nutshell, testers think in alternative problem solving patterns that are, generally speaking, mutually exclusive to the way that programmers think.

Now that we have got that big concern out of the way, let’s look at some of the exciting new sub-identities that a Scrum tester will assume, all of which are clear departures from the mind-numbing, repetitive manual testing that previously played such a disproportionately large part of the tester’s life.

The tester as a consultant

Testers are specialists at their craft and as such, they are in a unique position to help guide non-tester specialists to improve their testing game. With Scrum’s focus on delivering quality working software, this has never been so important. For starters, the tester in Scrum can (and should) act as a sounding board for the programmers as they start to get their heads around test-driven-development.

Also, whilst pair-programming is certainly a powerful XP technique (that is often utilized within Scrum teams), I feel that pair-testing is potentially even more powerful because there is even more scope to encourage skills-transfer. It also fosters further appreciation for one another’s skills and functions.

Consulting to the user-experience designers can also prove to be of significant benefit by helping to anticipate potential issues associated with the more complex workflows.

Finally, the product owner can certainly leverage the tester’s inherent understanding of the core acceptance criteria by assisting in various inter-sprint walk-throughs, helping with the final verification of the ‘done’ user stories as well as providing input into what should in fact comprise the initial ‘definition of done’.

The tester as a designer

I believe that the core skill of a tester is actually that of design. Irrespective of who actually runs or implements a test, a seasoned professional tester should always be able to design the most effective test cases compared to anyone else on the team.

Well designed tests not only form the foundations for the eventual testing process itself, but can also provide vital input into the actual design of the user experience. When a tester is involved in the actual design of the user story test cases prior to the sprint planning session, I can assure you that the session will be a great deal smoother, faster and with fewer contentious debates. For those concerned that this advice is slipping into the land of ‘Scrummerfall’ or ‘Waterfalling’ sprints, I will quote Cohn when he states that:

The tester as an explorer

Test automation is integral to the success of Scrum. However, even with extremely thorough test automation in place, there will always be the need for manual exploratory testing that no level of automation is able to replicate. This element of testing is without doubt more art than science and for those under the false impression that exploratory testing is just another name for gorilla or ad-hoc testing, the following commentary will give you a new appreciation for the subtlety of this function

With exploratory testing, each tester has a different approach to a problem, and has a unique style of working. However, there are certain attributes that make for a good exploratory tester.

A new beginning

In a Scrum team, everyone is responsible for testing. Quality is no longer an afterthought and testing should become an inherent part of every stage of the user story development even before a single line of functional code is written.

The transition to Scrum should feel like an exciting rebirth for the tester. Removing the manual testing shackles offers the Scrum tester an opportunity to focus on what they do best – design, consulting, and exploratory testing. They are finally given an opportunity to flex their unique skill-set in far more interesting ways.

So have you made the leap into Scrum as a tester? How did it go? Or are you about to take the leap? Let me know what you’re thinking and any concerns you might have by leaving a comment below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

What cures serious jet-lag after a month-long overseas working trip while being struck down with a head cold? Doing a presentation about Agile attitudes and abilities at a major conference in front of hundreds of people!

OK, so it’s not quite chicken soup followed by bedrest but it certainly took my mind off how I was feeling physically!

I was lucky enough to be asked to present at the Agile Australia 2012 conference in Melbourne with 850+ fellow local agilists. My topic was ‘Agile Attitudes and Abilities’ that make up a great ScrumMaster, Iteration Manager or any other type of Agile leader. In this presentation, I covered off a range of topics such as:

• What it means to be a servant-leader
• Why I feel that some in our industry ‘don’t get it’
• How to change the tune of those who are too focused on the functions of this role at the expense of getting the right attitudes and abilities in place
• What the right attitudes and abilities are
• Why there is a wide belief that the ScrumMaster is the same thing as a Scrum Project Manager
• What happens to the Project Manager in a Scrum implementation
• How someone can make the transition from a Project Manager to a ScrumMaster and why many fail

It went very well and the feedback I received was extremely positive. A big thanks to everyone who attended – you were a warm audience and you asked some great questions at the end of the presentation and in the hallways following. As a presenter, that’s all you can really ask for.

For those who missed it you can watch it in full with the accompanying slides above, or you can click here to be taken to the Youtube page.

If you have any comments or questions, you can pop them in the comments section below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

We prefer Attitude over Aptitude
That is, while there is value in aptitude, we value the right attitude more.

Don’t get me wrong – aptitude is certainly important however, if I had to choose between a proficient developer with a super attitude and a genius developer (who hacks the Unix kernel for fun) with a surly attitude, I would honestly choose the former over the latter.

There is a movement in IT recruiting circles to try and locate so-called ‘rock-star’ developers. I’ve always had an issue with this juxtaposition as I feel it sends a confused message to the market. Let’s think about this for a minute; what are the qualities that are synonymous with rock stars? I’m sure you’ll agree that they are typically perceived as charismatic, creative and individualistic – good things right? Flipping the coin now, let’s now take a look at some of the not so laudable (stereotypical) characteristics – think temperamental, attention-seeking and arrogant with a healthy dose of ‘my way or the highway’ attitude thrown in there. Does this sound like the type of person that would play nicely in a tight Scrum team? I think not.

So let’s now take a look at a studio musician. These musicians are happy to live out of the limelight and instead just support the lead singer to achieve their goal of producing a great album. For example, I bet that no one reading this blog knows the name of Michael Jackson’s keyboard player (without using Google) right?

Studio musicians are expected to be creative, be extremely versatile, and have a formidable skill set…The fact that you are working very closely with other players, engineers, producers, artists, label and agency people (and who knows who else) usually means that the easier you are to work with, the more likely you’ll get asked back.

I would say an important thing for me is to serve the song at all times. Try to keep an open mind, and if someone has an idea in the room, then always let that idea be heard. If it involves you trying something different in the part that you’re playing, you can’t get defensive about it.

There’s a way to do things in the studio, and it differs from playing live. A studio musician’s protocol exists, and you’ll be expected to abide by it. Suffice it to say that if you like being the center of attention, then studio work may not be for you.”

- by Bobby Owsinski and Paul Ill from The Studio Musician’s Handbook

My conclusion: I’d much rather have a team of ‘studio musicians’ rather than a team of ‘rock stars’.

Scrum values

So how should you go about selecting a team of ‘studio musicians’ to ensure that your Scrum team doesn’t collapse under the weight of immense ego and constant bickering? I think the best place to start is with Scrum’s core values that should be embraced by all team members, forming the basis of their professional personality. These values are:

• Courage
• Openness
• Honesty
• Respect
• Commitment

In addition to these, I am always seeking the following attitudinal attributes in my Scrum team members; energetic, pro-active, empathetic, inquisitive and friendly. Let’s explore what I mean by these in more detail.

Energetic

I’ve worked with some really smart, developers who are easy-going and friendly enough. Sounds like our type of candidate right? Well these same developers had other special powers akin to those of the soul-sucking ‘Dementors’ from Harry Potter. Using their zombie-like interactions, these developers were somehow able to completely sap all positive energy from a room, especially during the Daily Scrums where we want to set an energetic tone for the entire day.

You want team members with contagious energy rather than soul-sucking Dementors.

Empathetic

Working in a close team requires patience and understanding. You are reliant on others to help achieve the set goals and the reality is that being human, we are all prone to having ‘off’ days. This could be due to a range of factors including difficult personal circumstances or feeling unwell. When these situations inevitably arise, I expect teammates to not only be understanding but to also step up to the plate and temporarily help carry any additional load if necessary in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield.

Inquisitive

Scrum teams are cross-functional and we are aiming to develop team members into ‘generalizing-specialists’ who are able to do:

One kind of job very well and some other jobs adequately. With generalizing specialists your teams enjoy the benefits of high productivity, while lowering the risk of bottlenecks and retaining flexibility.”

- by Jurgen Appelo from Management 3.0: Leading Agile Developers, Developing Agile Leaders

This requires team members to not only be willing to extend their skill sets but to also be eager to do so, taking every opportunity to learn more about the functions that they are not particularly expert at.

Friendly

I remember working with a somewhat anti-social yet highly intelligent developer who I felt needed a talking to after a particularly brutal attack on a fresh, new product owner’s ideas. Our conversation went something like this:

Me: “Irrespective of what you thought, there are ways and means of communicating without resorting to verbal nuclear bombardment”
Him: “Well I’m not being paid to make friends – I’m here to do a job”
Me: “Well, yes and no pal. You’re correct in that you are here to do a job; however, you are also being paid to work in a highly collaborative team environment. The more friendly you are, the more effective you will be.”
Him: (Silence)

When selecting a team member, I’m not just looking for someone who is polite but I try and identify someone who is genuinely friendly. It is much easier to rally to a friend’s aid compared to a stranger (or worse, someone you dislike) and when push comes to shove, working with friends is also much more fun (and that can only be a good thing).

It doesn’t mean you have to be close friends with everyone. That’s not even possible. But simply knowing a little more about their life, their families, their home, and their hobbies (and them knowing some more about yours) would be a great start.”

- by Jurgen Appelo from Management 3.0: Leading Agile Developers, Developing Agile Leaders

Respectful

This is one of the core Scrum values mentioned above but I feel it is important to explain my interpretation of it in more detail as unlike the other Scrum values, I have found that its application can sometimes be ambiguous.

Let’s face it; people (even very smart ones) will occasionally come up with some less than stellar ideas. Perhaps they misinterpreted some fundamental input data or maybe they just got excited and blurted out what was on their mind without filtering it first. Unfortunately I’ve worked in several environments where brainstorming sessions ended up feeling like a cagey Olympic judo match with the participants cautiously waiting for each other to slip up so that they could throw their ‘opponent’ across the room with a less than healthy dose of criticism.

That is the last thing that you want in a creative zone and instead there should be a constant feeling of safety generated from the knowledge that teammates will be respectful even if they aren’t particularly enamoured with an idea or opinion.

Show respect for the other person’s opinions. Never say, “You’re wrong”.

- by Dale Carnegie from How to Win Friends and Influence People

For some people, if they hear the words, “You’re wrong” too many times, their ideas (including the good ones) will dry up pretty fast. There are far better ways of disagreeing without putting the car-wash on someone.

Time to make music

I believe that Scrum’s success is premised on the fact that you have a team with the same positive, collective attitude. A group of brilliant yet egotistical individuals will never work as well as a group of solid yet collaborative teammates.

So remember, Scrum is about the team and not individuals. That doesn’t mean that an individual isn’t recognized as unique and integral; however it does mean that their personal goals should be completely superseded by those of the team. In other words,

Everyone is there to play their part as perfectly as possible. When the red light is off, the personalities are as diverse as you would see anywhere, but when it’s time to make music, everyone’s focus is 100% locked on the music.”

- by Bobby Owsinski and Paul Ill from The Studio Musician’s Handbook

Give me studio musicians over rock stars any day thanks!

So, have you had to deal with rock stars and the baggage that usually comes along for the ride? Have you replaced them with studio musicians? Let me know in the comments below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

We each had a few minutes to create a new Agile game from scratch and my concept was lucky enough to be selected as the one to build upon. So what was the game about? I discuss the process of building the game as well as the final ‘product’ (rules, step by step process of running the game, expected outcomes etc) in a guest post at Kane Mar’s blog – Scrumology.com. Go check it out! I promise it’s worth it.

Have you invented an Agile game yourself? Or do you have your favourite go-to games to teach and show various Agile concepts? Feel free to drop me a comment below or on Kane’s blog.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

While this is a great situation, care must be taken to erect some strong ‘scaffolding’ to help direct this positive surge, or risk having all the hard work go to waste as inconsistencies start to become apparent and discipline is lost.

To ensure that these problems don’t arise, a new position complete with a fresh list of roles and responsibilities needs to be created to maintain standards and consistency. A Scrum PMO (or equivalent) would be ideal however setting up a PMO is no easy feat and as this blog is about identifying effective shortcuts, I will recommend a simpler alternative to start with the creation of the Chief ScrumMaster position.

When I first undertook this new role I was jokingly referred to as the Scrum Overlord which although as a name is more in line with the incumbent ScrumMaster vernacular, I think the title Chief ScrumMaster may sit a little better in the mainstream, but who knows…

Now I’m not necessarily saying that this role is a long term substitute for a Scrum PMO, however it is my opinion that it will certainly suffice to manage a group of up to about seven ScrumMasters.
 

ScrumMaster vs Chief ScrumMaster – how they differ

We have programmers and we have technical managers; we have testers and we have QA managers; the ScrumMaster / Chief ScrumMaster relationship is no different. Simply put, the Chief ScrumMaster is the functional manager for a group of ScrumMasters. If you prefer a looser structure, then you could also view the Chief ScrumMaster as the facilitator of the ‘ScrumMaster Community of Practice’.

Now that we have established the general relationship between these two roles, we can identify the roles and responsibilities of each and the delineation between them.

Let’s start with the new Chief ScrumMaster role.
 

Core functions of the Chief ScrumMaster

Mike Cohn’s book ‘Succeeding With Agile’ provides an excellent basis for the core functions of a Scrum based PMO and I’m going to start with a selection of these for our Chief ScrumMaster position description. I have put my own spin on these descriptions, so for the original descriptions please check out Mike’s book here.

(I’ll list the core functions below before going into greater detail. Clicking on the links below will take you directly to the relevant description.)

• Training and coaching
• Challenge existing behaviors
• Manage the inflow of new projects
• Provide and maintain tools
• Define and refine metrics
• Help establish CoPs
• Ensure consistency across the teams
• Coordinate teams

Training and Coaching

Novice ScrumMasters need to learn how to become good ScrumMasters and maturing ScrumMasters need to learn how to become great ScrumMasters. Programs need to be created to facilitate this education process.

Challenge existing behaviours

Mike Cohn talks about challenging the teams as they start to slip back into bad habits. This is very important, however I think that in the case of the Chief ScrumMaster, it is also critical to continually challenge the business (as a whole) as it inevitably slips back into its bad habits.

Manage the inflow of new projects

Whilst the product owner team should be coordinating strategic product dependencies as new projects are spun­‐up, the resource and logistical dependencies need to be understood and managed by the Chief ScrumMaster.

Provide and maintain tools

Whether the business decides to use high‐tech or low‐tech tools (or a combination of both), the various artifact templates need to be defined, adapted and version controlled.

Define and refine metrics

Metrics should be used carefully for good rather than evil purposes so the Chief ScrumMaster needs to ensure that relevant metrics have been formulated and are being utilised for the correct purpose.

Help establish CoPs

Function-specific communities of practice should ideally form organically from the ‘grass­-roots’ level however often they will need the initial kick-­start and occasional ‘shot-in-the-arm’ to keep them running effectively and it is it the Chief ScrumMaster’s responsibility to monitor and stimulate this if necessary.

Ensure consistency across the teams

This is possibly the most important function. It is extremely important that consistency and discipline is maintained especially when there are multiple teams and ScrumMasters. If certain teams need to apply varying approaches to the practices (for whatever reason) then these variations should be conducted in a systematic and controlled fashion with guidance from the Chief ScrumMaster.

Coordinate teams

With multiple inter-dependent teams working on the same product backlog, processes need to be defined and maintained to ensure coordination occurs as seamlessly as possible.
 

Additional functions of a Chief ScrumMaster

Below are some additional functions that I feel can be added to Mike’s list.

(I’ll list the additional functions below before going into greater detail. Clicking on the links below will take you directly to the relevant description.)

• Ongoing Scrum PR
• Process engineering the methodology
• Company level education and change management
• Defining the relevant definition(s) of done
• Continual process improvement via collective retrospectives
• Impediment escalation point
• HR for the ScrumMasters
• Creating a physical environment conducive to Scrum

Ongoing Scrum PR

Promoting Scrum should not only occur in the early stages of the adoption but also as the organisation evolves. New stakeholders will be constantly coming on board and anyone new will need to understand the incumbent Scrum environment.

Process engineering the methodology

Remember that Scrum is a framework and not a prescribed methodology. As such, the specific, fit-for-purpose methodology needs to be defined on a business-by-business basis to ensure consistency across teams.

Company level education and change management

As each new Scrum initiative or practice gets introduced for the first time, the business needs ongoing education to ensure that the proposed benefits are understood.

Defining the relevant definition(s) of done

Defining and maintaining a consistent definition of done across all teams is critical to ensure that expectations are aligned, especially during key integration periods.

Continual process improvement via collective retrospectives

Many useful suggestions will bubble up from within the various team sprint retrospectives and it is important that any golden ideas that ‘Team X’ comes up with (that other teams might also find helpful) are leveraged across all groups.

Impediment escalation point

Not all impediments that disrupt an individual team will be able to be resolved by the specific ScrumMaster, especially issues relating to organisational constraints such as the physical working environment. The Chief ScrumMaster should be the first escalation point for such impediments.

HR for the ScrumMasters

Just like everyone else in the organisation, ScrumMasters have HR requirements that need to be managed such as career planning, remuneration reviews, training and so on.

Creating a physical environment conducive to Scrum

To work successfully, Scrum needs to exist within a collaborative and comfortable team environment with minimal disruptions from the outside world. Ensuring a close working relationship with the Facilities department who can assist to modify the workplace where and when required is integral to Scrum’s success.
 

Core functions of the Scrum Master

When the ScrumMaster is a ‘lone wolf’ in a small organisation then the functions listed above will also need to be taken on by the ScrumMaster. However, when there is the luxury of a Chief ScrumMaster or Scrum PMO, the ScrumMaster is then free to focus primarily on the roles and responsibilities listed below:

(Again, I list the ScrumMaster roles and responsibilities below before going into greater detail. Clicking on the links below will take you directly to the relevant description.)

• Process improvement
• Impediment management
• Reporting
• Conflict resolution
• Diplomacy
• Coaching
• Managing change
• Maintaining the definition of done
• Maintaining effective communication
• Updating artifacts
• Facilitating workshops
• Facilitating Scrum ‘ceremonies’

Process improvement

Identifying key improvement points through quantitative data analysis (e.g. survey results, velocity tracking, quality metrics) as well as through the more qualitative sprint retrospectives.

Impediment management

Probably the most publicised of all ScrumMaster functions is the management of impediments through the monitoring, quantifying and removing (or escalating) of these project ‘speed humps’ or ‘brick walls’.

Reporting

Reporting key metrics and progress to senior stakeholders and other teams as well as the Chief ScrumMaster is part and parcel of daily operations especially within larger organisations.

Conflict resolution

A great ScrumMaster won’t even have to deal with conflict as they should be able to sense tension and diffuse any potential situation before it even occurs. Conflict mitigation and resolution applies not just at the individual team member level but also at the intra-team level.

Diplomacy

Especially in the early days, silos will likely exist between the various groups who are required to work together in the new Scrum environment. ‘Building bridges’ and bringing everyone together around the ‘campfire’ is one of the more subtle responsibilities of the ScrumMaster yet critical nonetheless.

Coaching

It is imperative that the ScrumMaster not only comprehensively understands the broader Scrum framework, but more specifically, they need to be highly proficient with the specific methodological approaches defined by the Chief ScrumMaster (see above). This includes being an expert at the various tools and templates being utilised to help manage the Scrum process.

Managing change

There will be constant changes to both general project scope as well as individual product backlog items. Controlling this change and guiding the various parties as to how the change should be managed is extremely important.

Maintaining the definition of done

Once the definition of done has been defined, the ScrumMaster needs to work hand-in-hand with the product owner to ensure that it is maintained at all levels i.e. task, product backlog item and release.

Maintaining effective communication

Scrum relies on positive human interaction and as such, the ScrumMaster needs to actively encourage a culture that allows this to occur.

Updating artifacts

The ScrumMaster needs to maintain up-to-date sprint artifacts either themselves (such as the burndown chart and sprint goals) or, they may need to do some chasing to ensure that team members are updating what they need to update (such as their tasks).

Facilitating workshops

Prior to a project kicking off, the ScrumMaster needs to facilitate the creation of the product backlog by conducting user story workshops as well as Planning Poker estimation sessions.

Facilitating Scrum ‘ceremonies’

Obviously there are a number of gatherings that occur throughout the sprint iteration and the ScrumMaster is responsible for the smooth running of these sessions. This includes the logistics and facilitation of the:

• Daily scrums
• Backlog grooming sessions
• Sprint planning
• Sprint reviews
• Sprint retrospectives
• A motivated ScrumMaster will also make efforts to constantly ‘spice’ these sessions up by introducing various formats and locations to keep life interesting.

I’ve posted various articles on this blog detailing the ins and outs of the sessions above. Feel free to browse around and let me know what you think.

A consistent ecosystem

Phew! When you read these lists of roles and responsibilities you begin to really appreciate the fact that maintaining a successful Scrum ecosystem is no trivial matter.

I believe that the key to maintaining success, especially as the broader Scrum rollout gains momentum, is consistency and continual education. A centralized Chief ScrumMaster supported by dedicated ScrumMasters will ensure that these critical success factors are achieved.

So, has your organisation taken the plunge into Chief ScrumMaster territory? Do you agree with the functions detailed above for both the Chief ScrumMaster and the ScrumMaster? Let me know in the comments below.

—————————————————————————————————————————————————
If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

I’ve created a ‘New Book!’ page which goes into greater depth about how the deal came about and how the book will differ from this blog. I’ve also included a table of contents so check it out and let me know what you think.

—————————————————————————————————————————————————

If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

For a technique that is so simple, I have to admit that explaining the underlying concept for the first time to the team (and other stakeholders) was actually the trickiest part. To tackle a complex and seemingly unresolvable issue such as software estimation you have to look outside the box and any solution that falls into this category is not always simple to convey. The purpose of this article is to help you to communicate what relative estimation is and why it is beneficial to adopt.

Quick Summary

Relative story point estimation is a type of delphi estimation method that is applied at the product backlog level. In a nutshell, this means that it relies on the simultaneous input of a cross-functional team to ‘triangulate’ in on a common estimate for a user story, or other product backlog item.

Unlike traditional estimation units such as ‘ideal days’, the measurement unit utilized during relative estimation is not time based but rather, size based. Size in this case does not have a direct relationship to a specific time duration but instead, it is a function of three factors: effort, complexity and risk.

These sizes are measured in units that we call ‘story points’ and typically, a slightly altered Fibonacci sequence is used as the point system:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞

The reason for using the Fibonacci sequence is to reflect the inherent uncertainty when estimating larger items.

Relative estimation applies the principle that ‘comparing’ is much quicker and more accurate than ‘breaking down’. What this means is that instead of trying to break down a user story into component tasks and determining the task durations to obtain an estimate, the team is simply comparing the size of a new user story to the size of a previously estimated user story to obtain an estimate. Simply put, it relies on relative comparisons with known quantities rather than arbitrary units of time that are guessed. The assigned point value that a user story receives is not a time unit but rather a relative ‘marker’ compared to other previously estimated stories.

The team ‘velocity’ metric is then used to determine how many points can be completed on average per sprint and this value is then applied to the product backlog to determine how long the entire backlog will take.

An example

You’ve been given the task of creating a very basic fruit salad en masse for a nice big picnic. You’ve never made one before and you’re interested in working out how long it will take. You have oranges, bananas, pineapples and bunches of grapes (20 of each)

Let’s say that you assign a value of five story points to a banana (to work out how this initial calibration can be set, check out this article about transitioning from time estimation to relative estimation). Next we will ‘estimate’ an orange relative to the banana. An orange is similar in physical size to the banana so the ‘effort’ to peel will be similar; it is more complex because we need some sort of cutting technique (algorithm) to peel it; and it is more risky because we need a sharper knife. Conclusion is that an orange is almost twice the ‘size’ so let’s give it a value of eight. Now let’s take the pineapple. Going by the same rationale it is definitely going to take more effort due to its larger physical size, it is more complex to cut and is even riskier with all of those pesky spikes everywhere. I would say that it is more than twice as big so how about we give it a 20. Finally how about grapes; well they are low risk, low complexity but require a bit of effort plucking them off the stem so let’s give grapes a 2.

Let’s now calculate the size of our complete ‘product backlog’.

20 x pineapple (20 points each) = 400 story points
20 x bunches of grapes (2 points each) = 40 story points
20 x oranges (8 points each) = 160 story points
20 x bananas (5 points each) = 100 story points

A quick calculation tells us that to release our ‘product’ we must complete 700 points (assuming we need to stick to scope of course).

Determining how long our mega fruit salad will take to make will require a velocity. To work this out, let’s assume we are running in mini-sprints with a duration of ten minutes each. So let’s get chopping and see what we can achieve in ten minutes. If you’re like me, you’re possibly not the handiest in the kitchen so in one of the sprints I might possibly get through one pineapple, one orange and two bananas. That would give me a velocity of 38.

So when will our product be delivered for delicious consumption? Well according to our backlog and our velocity it will take 700/38 = 18.4 sprints or roughly three hours to complete. This doesn’t take into account impediments along the way such as interruptions from the kids or having to sharpen a blunt knife however it certainly gives us a solid estimation without arduous analysis.

Over the bridge

To now demonstrate why I prefer story points to other units such as the common ‘ideal days’, I will use an example that is close to home.

For several years I was lucky enough to travel to work every day over one of the world’s most iconic bridges (The Sydney Harbour Bridge) offering me a daily Zen moment as I stared out over the sparkling harbour. I travelled by train however going over the bridge at the same time were also cars, bikes, pedestrians and below the bridge on the water cruised passenger ferries. Now let’s hypothetically say that once arriving at the other end of the bridge there was someone documenting the time that it took all travellers (irrespective of transport mode), to get across the harbour from one side of the bridge to the other. Obviously each response would vary depending on transport mode as well as impediments such as traffic, punctures, sore legs and so on.

The above situation is analogous to asking two different development teams how long a user story will take to complete in ‘ideal days’. Team A may suggest three days and Team B may suggest two days (perhaps due to their more senior makeup for example). Now, ideally the team that conducts the work should estimate the work but for very large projects, the estimation may occur before the teams are finalized; so whose ideal days should be used? This is a problem when using ‘ideal days’ but not so much if using relative story points and I’ll explain why.

Relating back to our bridge analogy, the reason that story points work is that the person at the other end of the bridge is now documenting a very different metric. Instead of capturing various data relating to how long it took to get from one side of the bridge to the other, they are now documenting what the actual distance travelled was. Obviously the distance in all cases will be exactly the same! In this case, the mode of transport is irrelevant as we are now talking about an independent relative distance. We can then apply whatever velocity we like (i.e. mode of transport) to determine duration. Translating back again to our software world, think of the distance as being equivalent to the relative story points for a story (independent and static) and think of the team make-up as equivalent to the mode of transport (dependent and variable).

Explaining the benefits

Many senior stakeholders aren’t necessarily interested in diving into the detail that I have explained above. They are simply interested in the business benefit of a particular method relative to other methods (pardon the pun). Below is a list of benefits that I find particularly effective when convincing senior stakeholders.

Relative story point estimation allows us to:

1. Rapidly estimate long-term product backlogs without requiring detailed specifications and complicated dependency charting
2. Provide broader insight from diverse functional experts (which offers checks and balances and less point sensitivity) to ensure that estimates aren’t being padded nor under-baked
3. Ensure that the entire ‘brains trust’ of the team is able to understand and assess the merits of the requirements, allowing for early detection of any potential issues as well as areas for improvement
4. Leverage the knowledge gained from completing legacy work
5. Actually have some fun whilst conducting a traditionally mundane and frustrating task. Planning poker sessions are interactive, lively and much faster than traditional estimation marathons
6. Sound pretty snazzy as talking about your ‘team velocity’ is way more exciting than mumbling something about your ‘team rate of progress’ – ok maybe leave that one out…

Finishing Up

Bottom line is that estimation is hard. Very hard. There are so many unknowns and we’re dealing with software that requires perfection to compile and work. As such, no method is going to be a silver bullet. However I truly believe that relative story point estimation is, at the very least just as accurate as any other methodology and yet is far more elegant and simple in comparison.

So how have you handled the explanation of relative estimation to your stakeholders? Was this fruit analogy helpful? Share your thoughts in the comments below.

—————————————————————————————————————————————————

If you liked this article you can:

Subscribe to the RSS feed

Or you can share it:

Just show the stakeholders what was completed over the last two-week sprint – sounds simple right? Well, based on my experience, a sprint review is rarely simple and in fact, I consider it be the most delicate session to facilitate.

The core issue is aligning the expectations of a disparate group of stakeholders outside of the team. These people are often more senior in the business relative to the team, they most certainly have less familiarity with the project compared to the team and without wishing to generalize, often have the attention span of a puppy with an attention-deficit-disorder!

During sprint planning

Preparation for the sprint review actually starts during the prior sprint planning. During the planning session the team must ensure that tasks are being allocated appropriately in readiness for the sprint review. These tasks include:

• Preparing some basic demo data

• Preparing a demo workflow script

• Demo dry run / rehearsal

You don’t want the team to spend too much time on these tasks as the sprint review shouldn’t be turned into a ‘dog and pony’ show, however these tasks certainly need to be acknowledged.

There are also a few important points to stress to the team during sprint planning. Firstly, the sprint review demo needs to be conducted on the staging environment rather than on the development server (and definitely not on an individual’s machine). This is not a ‘smoke and mirrors’ demonstration and the team needs to really prove that what has been developed is releasable.

Secondly, although the team should have fun during this session, it still needs to be taken seriously. During the sprint review, both the team’s and Scrum’s efficacy is on display to those who might not have had much exposure to either.

During the sprint

Once into the sprint, the ScrumMaster and product owner need to start running through their collective check-list in anticipation of the review. Items to cover off include:

Location
Confirm the location of the sprint review. Make sure that any relevant meeting rooms have been booked and that they are well equipped for the occasion. Double-check that there is a suitable data projector, ample seating, network connectivity and a whiteboard. I also recommend testing that the equipment actually works as expected; nothing is more embarrassing then so-called technology experts unable to get the projector to work before the session even begins.

Invitations
Ensure that invitations are sent out to the relevant stakeholders sooner rather than later. In fact, there should be a standing invite to the regular attendees so this point really only applies to any anomalous extras.

Painful attendees
You may have concerns about a particular stakeholder who has a habit of taking centre-stage and issuing unwarranted criticism or off-tangent comments. If you have one of these delightful characters to deal with, I recommend that the ScrumMaster and / or product owner visit them prior to the sprint review to give them a sneak peak and to get some early input. If they feel a little bit special they are less likely to be destructive during the review. We don’t want to ‘fix the results’ but we certainly want to avoid unnecessary morale-busting reviews.

Presenters
Near the end of the sprint when you are able to ascertain exactly which user stories will likely be demonstrated, ensure that the team has decided who will be demoing what. It might be just one individual or it could be a group effort – there is no hard and fast rule.

Expectations
Once the demonstrable stories have been determined, I recommend circulating an email to all attendees to give them a brief heads-up of what is going to be presented. The reason for this is that in the early sprint reviews of a project, the ‘user-ready’ features with snazzy UI are typically few and far between which can lead to some miffed, eyebrow-raising stakeholders. For example, by informing them that the upcoming sprint review will focus primarily on the less visual, technical ‘plumbing’ work, there is less likelihood of misaligning expectations.

This email also serves as a friendly reminder of when and where the session is with a gentle warning that any latecomers will have to supply coffee!

During the sprint review

Refreshments
Everyone loves snacks. Ensure that there is something to nibble on as well as drinks (hard whiskey if you’re really worried about how the review will go). I find it so amusing that often people’s positive or negative judgement of a conference or training session comes down to the catering so you might as well make sure this element is covered off well.

Scene setting
Once everyone has settled in and enjoyed some light banter over the refreshments, the product owner should briefly outline the sprint goal as well as reiterate what will be demonstrated. Also, for early sprints, it doesn’t hurt to explain the definition of done to the stakeholders.

Impediments
Following the scene setting, it can also be a really good idea to discuss any impediments that impacted the sprint, including why they occurred and how they were dealt with. This is an opportunity to lobby for greater assistance if there are any ongoing impediments. An example might be the physical environment; you may be having problems dealing with the Facilities department in your mission to get larger desks or more breakout space.
In addition, I recommend using this segment to briefly make a point of key process improvements that were implemented to help achieve the sprint goal. Don’t go into detail here as this session is about reviewing the product, however a quick mention won’t hurt and is a great opportunity to demonstrate to the stakeholders that the team is constantly improving.

Preview at the review
It is a fundamental tenet that during the sprint review, you should only demonstrate stories that are complete (have met the definition of done). This makes sense, however it can be very frustrating for the stakeholders. Even if the team came very close to finishing a couple of stories but just ran out of time to meet the definition of done, then really, these stories shouldn’t be shown at all. However, the reality is you will receive significant pressure from certain stakeholders to still show what has been worked on even if it is not quite finished…
In this situation, instead of being a stubborn mule, I recommend creating an additional agenda item labelled, ‘Coming Soon’. This way, much like a movie preview, we acknowledge that the work isn’t complete however the stakeholders will still get a sense of work that has been on the boil and ‘coming soon to a sprint review near you!’

Breaks and phones
If your session is longer than an hour, I suggest you have five-minute breaks every 45 minutes to maintain focus. However, be aware of the ‘attention-deficit-disordered puppies’ who will get easily side-tracked and ‘mugged’ in the corridors so don’t let them stray far.
Also, although tough to enforce, try requesting that everyone submit their Blackberrys (providing that RIM is still around when this is published) at the door. You may need to hire armed guards to pry those smartphones out of some of the stakeholders’ hands! At the very least you should request that, “For the safety of this sprint review we request that you turn off all electrical devices”. Good luck and at the very least, think up a creative punishment for those whose phones ring during the session…

Suggestions from the ‘peanut gallery’
There will no doubt be a range of questions and suggestions that surface throughout the session. I recommend that questions should be controlled and kept on topic – the team should answer any and all questions that surface regarding what is being demonstrated however questions that are tangential or completely off topic should go ‘offline’.
Acknowledge any suggestions made (however outlandish they might sound) by writing them in the standard user story format on the whiteboard. With any luck, after seeing their crazy suggestion written in black and white, the stakeholder will retract their pearls of wisdom. Reasonable suggestions should then be added to the product backlog by the product owner for further assessment.

Picnics or Battles

Sprint reviews can be akin to turning up for a summer picnic or alternatively, turning up for pitched battle. It really comes down to taking the necessary precautions and treating each session seriously whilst still having some fun. Don’t assume that every stakeholder has the same level of background as the team and ensure that all attendees are made to feel comfortable by always explaining what is happening and why it’s happening.

Aligning everyone’s expectations is the name of the game and achieving this objective is critical if you prefer picnics to battles!

Now it’s over to you. Have you ever had a room full of stakeholders staring at an empty screen while you rushed around trying to get a projector working? How do you deal with someone who issues unwarranted criticism or off-tangent comments? Feel free to share your thoughts and comments in the section below.

—————————————————————————————————————————————————

If you liked this article you can:

Subscribe to the RSS feed

Or you can share it: