Following last week’s interview with a newly-minted Scrum Master this week I have had a conversation with developer Mateusz Udowski. We talked about how SilverStripe’s adoption of Agile and Scrum have affected him and why he thinks SilverStripe is now more intelligent as a whole than it was before.

Mateusz, what was the most interesting thing that happened during the change? What was the most surprising?
I was expecting we would have problems with completing less exciting tasks such as testing, but that didn’t happen. Shifting the responsibility from individuals to the group gave space for everyone to work efficiently.

Also, we needed some structure and after we started working as a team we began to collaborate and everything seemed to fall into place. I think the main reason for our success was that the team members regarded each other as peers.

What's different now?
The biggest change is that there is no penalty for helping each other out anymore. The budget is relevant on the team level, but not on individual level, which means we can share problems and solutions.

One can clearly see what to work on now, and what needs to be worked on next. Tasks and impediments are clearly visible and are not being swept under the carpet.

Reducing the size of the team from 40 (whole company interacting semi-randomly) to 7 (Scrum team) makes it easier to work together, mainly because we get the chance to learn about and respect each others’ strengths, weaknesses and habits.

What is your day like now versus before?
Less stressful. It's possible to get more work done because we can focus on tasks and clearly see at any moment where we are in the sprint and in the project.

Folk wisdom has it that when you force a person's brain to focus on many things in parallel, their IQ falls considerably, and that's how it feels now - less chaotic, more intelligent.

What are you more more confident about now?
It's easier now to apply creative solutions and "refactor fearlessly". We have shifted from delivering at all costs to delivering high quality products up to capacity. Peer reviews, test coverages and testing by many people all contribute here.

It is possible to enhance how the team works both technically and from a process perspective. We can now build on top of what we have achieved in previous iterations because there is a "we" - a stable team.

What did you have to learn? What was the hardest to learn?
Not to tell people what to do and how to do it. It never worked well anyway. The other important ability is to be able to discern when is the time to say "no" to factors that would break the Scrum process.

How do you think you benefitted from working with a coach?
I've seen many of these Agile elements previously in different combinations and contexts, but never all put together.

A good coach will give you the confidence to apply all these principles now, immediately, and to achieve good result. Otherwise we would probably be stuck in the step-by-step approach which would stop halfway through and ultimately fail.

Pointing out the future possibilities is also helpful, showing that it's not the end of the road.

What's been in it for you?
There is more room for error and to try things out, hence more is possible. Short feedback loops and peer reviews provide a platform for learning and a cushion for failure.

Would you recommend Scrum and Agile to others?
Yep, without hesitation.


Conversations like these remind me why I love being an Agile coach. Whether the context or flavour is Agile, Lean, Systems Thinking, Scrum or Kanban (all very good things) - what it really boils down to is to make people’s working lives more enjoyable and purposeful and to create an environment where people are trusted to make decisions and have the freedom to succeed.

Mental note to self: Re-read this interview when I get frustrated with process, command and control and factory thinking.

Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.

Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe's blog (Sam Minnée, Aleksandra Brewer), below are selected highlights from the interviews.

It has been interesting for me as a coach to learn how people experienced the changes including the biggest surprises, differences, and how they found the changes working out for them.

Today’s conversation is with Scrum Master Aleksandra Brewer. Alex works with one of the Agile teams at Silverstripe and has likened working with me to a visit to the dentist.

Alex, what was the most surprising thing that happened during the transition?

Some of the surprising (although maybe obvious) things were that (1) it's possible for more than one person to work on the same user story, (2) work goes faster when people collaborate, (3) sprint planning that results in greater understanding of stories and tasks necessary to complete them really speeds up the work during the sprint - everyone knows what needs to be done and can pick up a simple task and complete it.

What's different now?

I love being able to see the day to day progress of the team - it's so visible on the board, plus the work seems to be going faster, with several people going through small tasks all the time. With the acceptance criteria being defined and discussed before the start of a sprint, and with the Product Owner being available to answer any additional questions and provide feedback throughout the sprint, there is virtually no possibility for any team member to go off on a tangent.

What are you more confident about now?

Talking to clients is easier now, as they are much more involved and ultimately responsible for making decisions about priorities. We (the team) make recommendations, share our knowledge and inform the client about pros, cons and consequences of the different options, but in the end it's up to them to make a final decision.

All along the course of a project clients know exactly where we're at, what's being built, etc., which they love. The transparency of Scrum, although scary at the beginning, is really beneficial for both the team and clients.

What did you have to learn? What was the hardest to learn?

The hardest thing to learn was to give up the control over what the individual team members were doing from day to day.

How do you think you benefitted from working with a coach?

Working with you has been a bit like going to the dentist - painful at times, but all along I knew it was good for me, and I'm in better shape now than I was before. It's been good to have you keep us on track, and point out things that now seem obvious, and yet were not at first.

Would you recommend Scrum and Agile to others?

Definitely. I couldn't imagine going back to the old ways, negotiating "resourcing" among Project Managers, developers being on several different projects at the same time, and not knowing when a project would end because of the uncertainty of developer availability.





Conversations like these help me put my work into perspective: They show me where I can improve as a coach and help me be a bit less perfectionist and appreciate that, even though we are not perfect, we have come a long way and I have helped make some people's working days a bit more fun and satisfying.

Next week I will talk to Mateusz Udowski., a developer at Silverstripe.

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