October Certified Scrum Meetup - sprint carry over, water-scrum-fall...

On Tuesday I facilitated our second 'Certified Scrum Meetup' event in our Wellington office. The purpose was to bring together people who have attended Certified ScrumMaster, Certified Scrum Product Owner and Advanced Certified ScrumMaster training to share ideas and learning on applying Scrum and Agile and overcoming challenges.

Thanks to those who attended the meetup; there were once again some interesting subjects to discuss.

1) How do you prevent carry over to the next sprint – or does it even matter?

10 people voted to talk about this issue so it's obviously something a few teams are experiencing. One suggestion was to understand the current velocity and to make sure we don't take stories beyond that. But there is often pressure to commit to more than we can actually do. It's tough as a Scrum Master to impose the 'rules' but it is part of our role. A suggestion was to ensure that we have a backup list of items that we go to if we commit to less and find that we have completed the shorter sprint backlog before the end of sprint.

2) How to prevent waterfall hidden as agile?

8 votes. Sometimes teams are 'doing agile' in a waterfall environment. Often it is referred to as Water-Scrum-Fall. In other words, there is a waterfall approach up front followed by a team doing Agile in the middle but finishing off with a waterfall approach to deployment and support. The feeling in the room was that when the environment is like this it's important to understand the goals of the organisation as they adopt Agile. Additionally, that it can be useful to have a coach. Teams can refine their process all they like but there's a limit to what they can achieve when the broader organisation isn't buying in to the change.

3) How do you decompose a story to an achievable size?

6 Votes. One approach is to use one of the many story splitting techniques that are out there. It can be particularly difficult if a story is a component and not a complete feature. Also try and involve all necessary parties when the story is being formed / groomed so that they are of the right granularity. It was pointed out though that we should really strive to ensure that they still add value. If we have to split the story down to such a granular level that it no longer adds value just to fit in the sprint then it's probably a sign that there are bigger issues that we should be looking at in our organisations.

4) How detailed does a story need to be for 'ready' state.

5 Votes. This issue was that the story was turning into more like a traditional requirements specification rather than a story. It is worth remembering that the point of a story is an artefact to have a conversation around. The team can then decide to what extent any further documentation is valuable. Agile is trying to move away from the more traditional approaches to documentation and the drive to document every decision. It's one of the key points of the manifesto:

Working software over comprehensive documentation

Remembering though that the point wasn't that there is no documentation, but just enough. The specific conversation was that a tester was producing a long list of documentation. One suggestion was to look at blending specification style documentation with an automated approach. Google Specification by Example (SBE). Another point was to encourage the tester to discuss the story with the team at the outset of work on it and develop a test plan from there rather than relying on lengthy documentation up front.

5) Rolls Royce vs. Toyota

4 Votes. This question here is how do we help our businesses move away from a perceived need for a full and comprehensive system with all of the functionality we may ever need, compared to an incremental approach to release a version of the software that has some functionality that proves early value.

In traditional approaches the business had to include all the requirements up front because of the funding models. We had one go to get it right and no chance of revisiting the scope and incrementally adding more features later based upon feedback. There is a major tipping point in organisations when they have made the changes required to enable an Agile approach to product development. These changes need to include many dimensions, such as cultural, structural and financial aspects of the organisation.

One approach that was suggested was to point out the early value that can be made by releasing early versions of the product that add value, compared to the big bang approach after many months of development without a release.

6) Has anyone tried implementing Scrum in a support environment?

4 Votes. This question was raised around a team providing infrastructure support. Scrum was designed around an efficient and effective way to organise software development teams. However, it has been used successfully in a variety of industries and approaches. One of the strengths of Scrum is to get whole teams working on completing tasks (or Stories) together. So if one of the goals in your team is to cross skill and create T-shaped people, then Scrum is a great approach. If however if our teams work on individual tasks and use more a of a ticket based system then Kanban may be a better approach.