Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience.

At my workplace we always invite the entire company and often have more than 30 people in the room. As they claim to be happy and to enjoy the fortnightly experience I thought it might be useful to share our template and some guidelines for what is working for us.

Our cheat sheet

General guidelines

• The point is not to show that your software works but that it is useful and valuable
• Provide context and scenarios so that people can relate to features (role plays work great!)
• Don’t forget there is an element of show and entertainment. If people give up time every 2 weeks to come to your demo make it a good experience for them.
• No smoke and mirrors and never ever show anything that is not 100% done (see definition of done)

Our sprint review agenda

This is our usual flow through the review:

1. The Scrum Master opens the review and reiterates the purpose

• Show what the team has built during the last sprint
• Engage with the audience
• Collect feedback

2. The Product Owner presents what he wanted to get out of the sprint

• Describe the sprint goal and why you chose it
• Explain why it is important for the project and for the company as a whole
• Give people context about where we’re at in the greater scale of things

3. The Scrum Master presents the sprint

• Tell the story of the sprint: How did it go? Did you have level 3 support incidents? (We handle those in a support work time box) Was anyone sick? New team members? Anything else important?
• Give a status of the sprint and an overview of which stories were finished and which ones weren't

Green check means “done”, red cross means not 100% done and therefore won’t be demoed.

4. For each story:

• The demoing team member shows the story description and describes the boundaries (explain the acceptance criteria without reading them out)

The story we are about to demonstrate

• Demonstrate the feature on a real system, in this case generate the report and show the result.
• Take questions and listen to feedback while you demonstrate. Remember to collect ideas for new features and user stories to include on the product backlog.

• Repeat step 4 for all user stories the team finished during the sprint.

On some teams we alternate who is doing the practical demonstrations for each user story, on some we alternate for or each sprint review and on others we always utilise the same team member’s talent for telling stories and guiding people through an entertaining demo. We do whatever works best for each team and audience.

5. Scrum Master closes the demo

• Wrap up and thank people for their attendance and participation
• Communicate the time and date for the next end-of-sprint review.

Some general Tips

Here are some things we have learned during the process of continuously improving our sprint reviews:

• Audience participation and interaction works really well: If possible we ask audience members to play roles in our scenarios such as e.g. a customer who has lost his Snapper card.
• It is really important to prepare. We found out the hard way that it is a good idea to trial the demo before giving it to a larger audience to make sure it flows and that all the accounts, logins and data are set up.
• It is good practice to have the agenda visible on a wall or whiteboard at all times. This serves as a map of the territory we have covered last sprint. It is especially useful if some people come and go during the demonstration (our customer facing folks often do)

In summary, the most important thing to make sure everyone enjoys the sprint review is to focus on demonstrating the value and usefulness of the features we have built and to make sure people can relate to the software by providing context and scenarios.

Where to from here?

As more and more teams within Snapper are using various Agile or Lean approaches and would like to show what they have done since their last demo we are planning to hold bi-monthly combined show and tells.

The plan is that the product development team will demonstrate all features they have finished during the last two weeks and then the marketing team, our latest Scrum addition, will present what they have achieved during their sprint. Ideally, the marketing deliverables will match the product development team’s features.

We will then round up with the operations team who have chosen Kanban as their preferred approach. The ops team will show any major deliverables and will present key metrics such as cycle time, lead time, throughput etc.

The challenge will be to keep the show and tell under an hour and I hope we can keep people engaged, informed and entertained.

Tags: scrum, scrum master, sprint review, show & tell

After my last post on the role of the Scrum Master I have been asked if I could write a similar role description for the Scrum Product Owner.

Here’s my view of the role:

The Product Owner

The product owner is a visionary who can envision the final product and communicate the vision.

The product owner is also the person who sees the vision through to completion. This includes describing features, collaborating and communicating with the delivery team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress.

The Product Owner points the team at the right target, the Scrum Master helps the team get to the target as efficiently as possible. In other words: The product owner is the what-person, the Scrum team are the how-people.
 

In general the Product Owner ...

• is responsible for that the team builds the right product
• manages ROI and makes sure to deliver business benefits
• is responsible for that budget constraints are met
• is responsible for that what the team is asked to build is aligned with what the sponsor, stakeholders and users want
• provides boundaries to describe the realities within which the vision must be realised (e.g. time frames, external quality)
• makes sure management, stakeholders, sponsors are informed and the vision is aligned with their wishes

As a Product Owner you do ...

Some activities I would expect from an experienced Product Owner:

• Provide a vision for the product
• Communicate the project vision to the team
• Motivate the team to subscribe to the product vision
• Communicate the business benefits of the entire product and each individual feature
• Create and maintain the product backlog
• (the product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible that the work is being done and is being done properly)
• Continuously groom the product backlog
• Prioritise the product backlog
• Define releases
• Define release and sprint goals
• Continuously answer questions to add detail to requirements
• Accept/reject developed user stories at the end of the sprint (or during the sprint)
• Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting, sponsor liaison )

Here are some great resources I can highly recommend:

• Jeff Patton’s “The Product Owner and the Product Shaped Hole”
• Jeff Patton’s “How you Slice it - Agile Product Design”
• Bill Gaienne’s “3 Ingredients for a Great Product Owner” (10 min training video)

Tags: scrum, product owner, product manager, agile roles, agile

“An adequate Scrum Master can handle two or three teams at the time; a great one can only handle one”. (Michael James - An Example Scrum Master’s checklist)

I found that organisations, teams and new Scrum Masters (even freshly certified ones) often aren’t sure what the Scrum Master role entails and what value it provides.

Here is my attempt to summarize what a good Scrum Master does:

The Scrum Master role

"A Scrum Master is like a conductor coordinating the efforts of musicians, helping them to play together. Some teams are like jazz bands, so they need a leader who encourages improvisation. Some teams are like symphony orchestras, so they need a leader who keeps everyone on the same sheet of music. Conductors have to be deeply familiar with each instrument and with the music, yet they don't play in the band or tell the musicians what to do. They let the music provide detailed guidance; their job is to bring out the best in the musicians, both individually and as a group." (Mike Cohn - Succeeding with Agile)

 In general the Scrum Master ...

• makes sure the team is running (good) Agile development
• assists team members in adopting and improving Agile Development
• helps the team maximise throughput and to work in the best possible way
• protects the team from disturbance and external threats
• is a “servant leader” with no formal authority - all authority is granted by the team
• has no direct authority over Agile development team members but does have authority over the process

As a Scrum Master you do ...

Some activities I would expect from an experienced Scrum Master:

• Remove impediments
• Facilitate meetings (sprint planning, retrospective, review, daily stand-up)
• Coach the team on the Agile development process and make sure the team improves over time (note the caveat “experienced”)
• Re-enforce good practises
• Challenge bad practises and habits and work towards their removal
• Make sure people do what they have agreed to do
• Make sure that the team follow the team ground rules they have defined
• Make sure that quality is a team effort and commitment to the “done” statement is taken seriously
• Provide transparency via the product and sprint backlogs, daily stand-ups, demos and a visible workspace
• Assist in reaching the sprint goal (help with story creation, testing, making coffee, etc if necessary - loads of ad-hoc stuff)
• Ensure that a collaborative culture exists within the team
• Support the Product Owner
• Improve the team’s engineering practices and tools
• Communicate, communicate, communicate
• Smile lots, make people laugh, and make the team feel that you are one of them not an outsider

… as a Scrum Master you are not expected to do all of this yourself but you are responsible for that it happens.

Also, check out Kane Mar’s excellent mind maps of the Scrum Master role here.

Tags: scrum, scrum master, agile roles, agile

Last week I presented at WebDU in Sydney. The conference was excellently organised by Geoff and the Daemon guys and I met lots of interesting people. And I love Sydney! In short I had a blast.

Apart from a workshop on user stories I presented on 10 ways to fail with Agile. Judging by the Twitter stream my presentation about the most common mistakes and pitfalls during Agile adoption and how to avoid them has been well received (okay, they also tweeted I looked like Starbuck in Battlestar Galactica Season 1 ;-)

As promised here is a version of my slides which more than just pretty pictures ...

10 ways to fail with Agile on Prezi

Tags: organisations, agile, failure, inspect & adapt, adoption, transition, scrum

The other night I attended Rashina Hoda’s totally awesome presentation “Agile Undercover: When Customers don’t collaborate” at the Wellington Agile Professionals Network.

Rashina presented the research she had conducted on the basis of interviewing 30 people across 16 organisations in New Zealand and India. Having delivered a steady supply of Agile teams and individuals over the years I was excited to see the results of Rashina’s research.

Her chosen method of research was grounded theory which basically means that instead of testing a pre-conceived theory the researcher gathers data and generates a theory based on the data collected. A bit like Google Flu Trends ...

Not too surprisingly, one of Rashina’s main findings was that the greatest problem teams were facing was too little involvement from the Product Owner or customer.

What I found most interesting were the coping mechanisms teams employed to work around this lack of customer involvement. While certainly not ideal the following seven patterns emerged as coping mechanisms used in the “real” world.

Coping Mechanisms

1. Changing Priority
When teams didn’t have enough information on a user story they changed the priority and pushed stories that were awaiting customer clarification further down the product backlog until they received the required customer response.

An Indian team used a “definition of ready”: Very much like a Product Owner won’t accept anything that doesn’t fulfill the “definition of done” the team wouldn’t accept a story into the sprint that didn’t fulfill the “definition of ready”.

By “ready” the team meant that the business goals and expected outcome associated with the user story plus implementation details necessary to estimate the story had to be clear.

2. Risk Assessment Upfront
A New Zealand coach used an Agile risk assessment questionnaire to gauge the level of customer availability on the project upfront. The questionnaire included questions such as “What is the commitment of the customer rep in terms of time?”

Answers such as “Assigned to the project” or “Available as a first priority” were the best case scenario while the worst was “Just as time allows”.

The risk assessment before the beginning of the project allowed the team to discover potential problems upfront and to think about possible strategies to improve the situation or, if this wasn’t possible, to discuss strategies to work around the problem.

Sometimes the team could manage to negotiate with the customer to to free up the customer rep’s time to allow them to become a project team member for the duration of the project by providing funding from the project.

3.Story Owners
The practise of assigning story owners was an adaptation to the Scrum practice of allocating a Product Owner. Story owners were responsible for particular stories, instead of all the stories in the product backlog. Every story had to have an owner to get into prioritisation.

The strategy allowed the customer’s organisation to split the workload and time investment across several people and allowed the team to discuss stories in synchronization with the corresponding story-owner’s availability.

4. Customer Proxy
Some Agile teams used a customer proxy - a member of the development team co-ordinating with the customers - to secure requirements and timely feedback.

Most often the team member acting as the customer proxy was a Business Analyst, due to (most) BAs’ proven ability to communicate ideas.

5. Just Demos
Despite their reluctance or inability to attend other meetings, almost all customers were interested enough to attend product demos (show & tells). Often the part where the team showed new functionality would take 15 minutes but then the team and customer would use the full hour to discuss features and feedback.

6. e-Collaboration
Both in New Zealand and India the main cause of lacking customer involvement was physical distance - not only for teams and customers in different countries but also in different cities or even within the same city. Teams overcame this by using Skype, IM, wikis, Google docs and other collaboration tools.

7. Extreme Undercover
To avoid extreme consequences of lack of customer involvement such as business loss, Agile teams chose to follow Agile practices internally at the team level while keeping the customer unaware. Some teams confessed to having a “Don’t mention the ‘A’-word policy”.

I was happy to learn that Rashina had observed a clear decrease in the use of the “Extreme Undercover”-pattern over the span of her research, probably due to the increasing popularity of Agile among customers (yay!).



In an ideal world we wouldn’t have to use any of those coping strategies but having exhausted all other possibilities to convince the customer we sometimes have to use strategies to cope with a less than ideal situation.

Do those strategies make us less Agile? Probably so. But being Agile is not a binary value; it comes in varying degrees and in all forms.

I have used some of the above coping strategies myself, sometimes with greater and other times with lesser success. I found it very helpful to learn from Rashina’s research that other teams often face that same challenges and I have learned some new strategies I can try if all else fails.


Thanks
I’d like to say thank you to Rashina for giving me permission to blog about her research paper and, on behalf of the APN, for presenting. From a practitioner’s perspective I am grateful for her research as it allows us to gain insights into what we Agile practitioners actually do rather than what we should do or say that we do.

On a final note, I really recommend reading the full research paper which will be available on Rashina’s uni site soon (it’s only 14 pages).

Tags: agile, adoption, product owner, scrum

For anyone new to Scrum this presentation might be a good introduction:

Scrum101

Tags: agile, scrum

People keep asking me whether I’d run all projects using an agile framework such as Scrum.

When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “

Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum.

It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers:

I’d NOT run agile if ...

• People on the team are not fully allocated and committed to the project
• You can’t stack a great team and only get the people that everybody else wants to get rid of (Give me some of the company “stars” even if it’s just to show commitment and get me agile personalities!)
• You don’t have the courage to let the team make decisions, to allow them to learn by making mistakes and to trust them to get the job done - you’re stuck in command control
• You don’t have a business person who has the time, courage and authority to work with the team and to make quick decisions
• You expect instant success and need a silver bullet (Sorry to be the one to bring it to you but if your project is impossible or if you don’t have good people no methodology or framework is going to help you ;-)

There are of course numerous other things that are important for agile teams to succeed but usually there are work-arounds for non-ideal situations.

If I don’t meet any of the above obstacles I’ll go for Agile any time!

What’s your list of show stoppers or essential requirements for running an agile project?

Tags: organisations, governance, obstacles , change, agile, scrum

When I started with agile (Scrum) software development five years ago one of the main challenges I faced was combining an agile development approach with user-experience driven website design.

Especially, as we were working on a global, consumer-oriented web site with a strong focus on product branding we needed to make sure that we could benefit from the agile development approach without losing focus on a consistent user experience (UX) and information architecture (IA) across the site.

Agile frameworks such as SCRUM and XP say absolutely nothing about the IA and user interaction design processes, which meant that we had to learn mainly by trial and error.

Most of the problems we faced originated from a clash of two fundamentally different world views:

• UX people are driven by a holistic approach (big picture)
• Dev teams focus on iterative and incremental development

To deliver a successful site none of the groups could be allowed to dominate and to find a balance we tried several approaches.

Our experiments:

• Attempt 1: Concurrent IA, design and development
• Attempt 2: Upfront IA and graphic design
• Attempt 3: Post skinning

Attempt 1: Concurrent IA, design and development resulted in “piece meal” design and user interaction. We lost track of the big picture and lacked overall IA/design consistency across site. Also, our product owners found it difficult to keep an overview of the project.

Attempt 2: Upfront IA and graphic design caused problems with unused and out-of-date designs and feature specifications. Sometimes we finished an iteration or release with partially implemented features - very non-agile! We also found it difficult to adapt to feedback after the IA/design phase was completed.

Attempt 3: Post skinning (applying design after functionality has been developed) caused our implementation to drift from the design and user interaction intent and we often faced excessive and unnecessary re-coding and re-factoring work. The product owners and end users found it difficult to give feedback as non-shippable increments were demonstrated.

After three failed attempts we still wanted to utilize the advantages of an agile approach that would allow for continuous inspection and adaption and could help us to keep the focus on the most important parts of the site. Basically, we wanted to keep the agile advantages without sacrificing the overall user experience.

Attempt 4: Design-chunking - success!
(This term was originally coined by Lynn Miller)

With this approach we defined initial concepts upfront and subsequently broke the IA and user experience design apart into smaller pieces that could be delivered incrementally.

Design-chunking process:


The most important break-through came from two changes:

• We introduced an iteration (sprint) 0
• We de-coupled IA/user experience/graphic design from development

Iteration 0:

• done before development begins
• short (2-3 week) IA/user experience/graphic design only iteration to lay the groundwork
• defines “big picture” on which subsequent designs and not yet fully defined areas of the site will be based
• outcome 1: overall strategy for IA (site-wide elements such as page grid, navigation, rough placement of modules)
• outcome 2: overall design concept including site-wide design guidelines
• exact content balance between IA and design will be based on whether an IA or design led approach is used
• signed off by client (partial IA and design sign-off) and discussed with developer to assess technical complexity
• iteration 0 only covers fundamentals and potentially the details of the most important page. Details for other pages and areas of the site are still to be refined incrementally

Decoupling of IA/design and development:

• after iteration 0 decoupling IA/design and software development into two independent tracks
• tracks iterate separately but simultaneously and provide frequent feedback to each other
• the IA/design track feeds a refined design of the most important features/page(s) to the development track at the end of each design iteration
• the output from the IA/design track at the end of an iteration is used as input to the subsequent development iteration
• for the IA/design track to feed the development track the IA/design track needs to be ahead in time - ideally this would be one iteration ahead with minor refinements still possible during the development iteration (e.g. change an image)
• focus on potentially shippable increments of functionality to provide feedback opportunities for the client/users

This approach worked very well for us, we delivered nine releases to a happy client and in terms of process we felt we got the best of both worlds.

I would be very interested to hear your thoughts on this approach and particularly any experiences you may have had with similar issues in your projects - especially large and/or global web-based projects.

Also, an absolutely excellent description of this approach was done by Lynn Miller in her paper on Adapting Usability Investigations for Agile User-Centered Design. Much of my article is based on and inspired by her work. I only wish I had know about it before we started our extensive period of trial and error.

Tags: user-experience, agile, scrum, web