It isn’t too surprising when you see that there are so many different ways to do a retrospective, after all, if there are that many options then surely you are meant to switch it up at the end of every Sprint?

So when should you move onto a new retrospective format? Well naturally if the format you are using isn’t working then consider using a format (more on this moment), but to help here is my decision tree on the matter:

Okay, so maybe there was a simpler way to say this…

If you haven’t used the original technique for more than six times in a row then don’t try something new.

Why six times? It is enough to get a pattern, to feel comfortable with the process so that you can maximise the focus on the intent behind the practice.

If your team has been doing it the same way for longer than that and don’t want to change it, then as a Scrum Master DON’T CHANGE IT. It is their decision not yours to switch it up in this instance.

I’m not going to go into the menagerie of options that you can use for a retrospective, but I would recommend that when you start keep it really simple. Ask two to four questions, no more than that. I still use the original ones:

• What worked well
• What to do differently next time
• What puzzles us
• Lessons learnt.

What I find is a lot of retrospectives fail, not because of the process per se, but because of the little additional “gotchas” that seem to be hard to find as guidelines/rules on the topic. Here are my top tips:

1. Start you retrospective by reviewing your previous retrospective actions. If they aren’t done then focus the retrospective on why the actions themselves aren’t getting done.
2. Don’t commit to more than five actions. You just won’t do more than five.
3. Fix the root cause not the surface issue. To do this, you need to make sure that you actually discover the root cause within your retrospective.
4. Treat the retrospective as a law of thirds – one third define (brainstorm), one third discovery (share) and one third determine (next actions). Teams often make the mistake of not managing time effectively that result in not enough time for actions.

Source: David Hussman on the Uncertainity Movement

Source: Bas Vodde and Craig Larman on Large Scale Scrum

Source: Adam Weisbart on Improv, Magic and Fun on Agile Teams

1) Do you think that “user story” is just a fancy name for SRS?

2) How do you compare a “user story” to “SRS”?

3) Do you think that “user stories” replace “SRS”?

4) Which of the two do you prefer working with?

So let me open with a clear positioning stance:

User Stories are not a fancy name for an SRS, they are not the same thing, they should replace an SRS when working in an Agile environment and I prefer working with User Stories.

The following comments are focused on how I believe they are different and are naturally based on subjective opinion.

Origination

A SRS is usually created part way through a project, once the Business Requirement Specification (BRS) has been crafted and signed off. An SRS is crafted by a Business Analyst, often with minimal collaboration to other team members and the business throughout its development. As part of its development the BRS is cross referenced to ensure traceability. Once produced the SRS undergoes a review and approval process that does generally have an extensive audience. Often this review and approval process can take several versions until the document is deemed correct.

A User Story can be created at the start of the project or throughout the life of the project. Through a collaborative workshop(s) called “Inception”, features are defined. Often these features are broken down into User Stories using the Story Mapping technique. As everyone who needs to deliver the project is in the room there is no handoff of documents and no extended review and approval process.

The key differences in the origination process is that User Stories are not dependent on the existence of a BRS to be created, that everyone is engaged to identify and define the requirements, and that there is no formalized approval process (because it is not needed if we are one team, all responsible for the outcomes that we agree to).

A simple analogy is that Inception is requirements gathering on steroids.

Content

SRS content is often lengthy, comprehensive but lacking depth to implement against. Normally, an additional deliverable is produced in between the SRS being delivered and software starting coding (normally referred to as a Detailed Design Document, or DDD for short). Field rules, expectations of behaviour under error or abnormal conditions are also specified within (sometimes as an appendix, or separated out into an additional deliverable). There are often multiple SRSs to a single BRS, but rarely would this number exceed a magnitude of 10. How a SRS is tested comes down to separate test deliverables.

A User Story is a promise for a conversation. It is often a single sentence written as a narrative of “As a <persona>, I want <requirement not solution>, so that <value obtained>”. In addition to this single sentence the conditions under which the User Story will be tested are included as Acceptance Criteria. Well-formed User Stories, like system requirements, cross cut components or architectural tiers of the system(s).

Critically there is an expectation that the documentation of the User Story itself is unlikely to be sufficient or comprehensive. The conversation placeholder is the opportunity to discover these elements of the requirements and to clarify needs in person with a business representative. This conversation has representatives from all specialists. This conversation may also extend to a group of developers in order to determine the best architecture or design to deliver the User Story. In this respect a DDD is not normally produced, but photos of whiteboard outcomes are kept in a repository for prosperity. Field rules are often discussed as part of this conversation.

Expectations of behaviour or abnormal conditions are often split out from the story – ie a new User Story is created per condition or behaviour to handle expectations. In this respect a single business need, described within Inception as a Feature, may result in potentially several dozen User Stories. This is especially true when good User Story splitting principles begins to focus on one Acceptance Test per User Story and the team moves towards an estimationless environment of reduced User Story size variability.

Change

As part of the SRS development, as the BRS may undergo several change requests. As part of the DDD development, test deliverable development, actual development & testing the SRS may also undergo several change requests. Over the life of a Project this could result in hundreds of change requests to approved deliverables – this is to ensure that what is delivered is of value to the end user, otherwise the system is unlikely to meet their needs. Each one of these change requests takes the team away from delivering to estimate the impact of the change.

As User Stories never undergo an approval process they can be changed at anytime prior to a developer picking it up to deliver. The cost of change at this point in time is negligible with conversations often being the only highlight. Once development has begun there an team internal change policy often guides what happens next. As a rule of thumb, if the change would take the team less than 30 minutes to do then it should be absorbed, otherwise the change should be raised as a new User Story. That User Story then gets prioritised by the Product Owner and may or may not be done based upon that priority. As a rule of thumb, unless the original User Story was completely off base, then it would still be delivered as it stands, otherwise it would be pulled from development.

Realising value

A SRS does not have it’s value ever realised or assessed. The BRS is tied to benefits and it consequently gets assessed for benefits realisation. Only through traceability of requirements is there confidence that the SRS realises value. From a delivery standpoint, only once all the SRS(s) and BRS has been delivered does the software often go into production. The outcome, is often a delivery near the realm of a year or more. The benefits realisation activity is consequently months, if not years after the production delivery.

Both the Features and the User Stories realise value within their originating narrative of “so that…”. As developers deliver User Stories they can go into production once they have been tested against their acceptance criteria. For iteration based team this often means fortnightly deployments to production and consequently a fortnightly realisation of value. Sometimes teams may not release to production at the end of these iterations because a minimal viable product is still not achieved. Some teams, especially those that have focussed on technical excellence through continuous integration and continous delivery, can realise value several times a day through regular deployments to production.

When Agile teams take on Lean Startup practices a User Story does not get deemed completed or done until analytics have been gathered in production to prove or disprove the value realisation.

A good analogy of Lean Startup as it applies to User Stories is “continuous micro benefits realisation”. In this respect, Agile teams have a higher confidence that they are reducing the #1 waste in software development – building the wrong thing, because they are constantly checking with real customers if they are on the right path (not the proxy customer who may be the Product Owner or Business Stakeholder). The other key difference when Lean Startup applies to User Stories is that the narrative alters to no longer be a requirement and instead is a hypothesis that critically should be proven.

Estimation

When a BRS is completed the service delivery team does a detailed estimate to deliver not only the SRS, but all artefacts and actual software delivery outcomes. The change request process is often the only means to recover further money. Critically, this estimate is done when the largest amount of unknowns are still unknown. Re-estimation after the SRS is completed is not normally done, especially in fixed price bidding environments. Estimates are commonly done by Project Managers and Architects and have next to no input from the people who actually do the work. There is no relationship to SRS and actual delivery rates (with the exception of the rare teams that still do Function Point Counting).

In Agile teams estimation is done throughout. Both Features and User Stories are often estimated, but critically not in hours or days. Instead Agile teams used comparative based estimation techniques where one User Story’s complexity is compared to other already existing estimated User Stories to best gauge its approximate size. As teams begin to deliver User Stories they track throughput rates, either by cycle time or amount of work done within an Iteration. This information is then used to forward project confidence of delivery. All team members are actively engaged and encourage to estimate the User Stories as a single unit.

Conclusion

It is hard for me to write all the above content and not continue to think “Why do we still do waterfall?” especially in the commercially fast paced world that we live in these days. An SRS is not the same thing as a User Story. The outcomes that each achieves are quite different because of how they are utilised, not because of the description of the need that is within them.

The presentation was video taped so when that is released I will update and provide a link.

Because it was a presentation on Visual Management I felt that it was quite important that visually it looked slick. I spent almost two hours a night, most nights for almost two months to get the 70-odd slides in the presentation. Some slides were cut due to the time constraints of keeping to 35 mins. Also due to time constraints we didn’t get the opportunity to cover items in more depth, in essence it was a slidefest of ideas and concepts, enough to say “hey, that’s a good idea, I could use that” but armed with the information to be able to seek out more.

To this extent I wanted to add to the slide deck some bullet points of thoughts that we didn’t have time to cover or extend further on. For those who were unable to attend I also wanted to iterate some key elements of the slides.

• Firstly, I would like to thank a few people who made this slide deck happen. Four pictures were taken from @craigstrong and one from @caza_no7 (Ian Carroll’s) work. The Usability section of these slides was worked on with Usability expert, Matthew Hodgson @magia3e of ZenExMachima fame. Some photos were taken from the Dandelion and Driftwood cafe in Brisbane with the approval of Penny and Peter Wolff. Lastly, a number of pictures have been taken from where I am currently working at Superchoice, I am thankful to Ian Gibson for his permission to use them.
• Slide 14, which discusses Value trees is an extension of Luke Hohmann’s Product Tree work. I have been using Value trees for a little while now to represent backlogs and am finding them more useful then a standard backlog, especially for identifying critical paths. Compared to a normal backlog they allow for recognition of the existence of dependencies and parallel processing. I am currently working on a whitepaper for these and with Luke Hohmann’s help should have it released fairly soon. The whitepaper will go into a lot more detail about what they are and how they work, so stay tuned!
• Slide 16, the Timeline Board is sometimes considered an anti-pattern in Agile circles. It is an advanced form of a Gantt chart, but unlike a Gantt chart it is quite adaptable to real time change and exists for the whole team to have transparency and ownership of the work. I don’t use this type of board often but I do tend to use it for complex move sequences and have done so a few times. The x-axis and headers represent time. Usually this is done as a two way exponential timeline. The key milestone sits roughly 2/3 of the way across the x-axis. From that date it logarithmically goes forward in time. It also reverses logarithmicaly in time as well. For example, the headers could be 3.5 months, 2 months, 1 month, 2 weeks, 1 week, milestone -4 days, milestone – 2 days, milestone -1 day, milestone, milestone + 1 day, milestone + 2 days, milestone + 4 days, etc. Once the wall is constructed items generally don’t move. Cards do have a tendency to be added. The main thing that moves is the current time point. Anything behind it should be crossed off done, anything on it is in focus for the standup and anything in front is visibility of what is coming up.
• Visual management isn’t just about software development. I have spent a good amount of time in my career applying it to other knowledge work areas.
• Visual management’s audience isn’t just the team. It is about re-enforcing everything visually – for both the team, managers and customers.
• Visual management isn’t just about a flow zone, it also incorporates many facets of other information.
• There is a direct relationship between the level of complexity of the type of work that you are doing and the manner in which it is visually managed – generally the visual management is one degree of complexity less than the work itself. This is a new concept that has not been previously explored.
• The application of software usability rules and how they apply to Visual Management is also a new concept that has not had a considerable depth of exploration. I am sure we will hear more from Matthew on this in the future (he felt it could have easily taken up the full 35 mins and I would tend to agree).
• There is a misconception about the purpose of the readability of cards on the flow zone. Most think that the information needs to be retained. The key purpose of usability relating to cards is to be able to find it quickly and to be able to read it easily, not retain it. You want to be able to find it with little thought in stand ups. You want to be able to find the right card quickly when talking to the Product Owner. This is where usability and Visual Management becomes highly important. We don’t spend enough time being consistent and writing clearly when writing cards. As Lynne Cazaly beautifully mentioned in her presentation, if you don’t take the time to write neatly what someone else has told you then you are not showing respect for their thoughts that they have given you.
• Achievements – I have mentioned them a few times on this blog. As part of this exercise of getting a slide up I somewhat simplified the generation of the tokens and the Agile Achievements playbook. If you are interested just send me a tweet and I can DM you a direct link to the content if you want to re-use it.

Lastly I want to thank Craig Smith for his help and support in doing the presentation.  I may be the Penny to his Brains (check Craig’s uploaded slide deck for the in-joke), but he is really the Will MacAvoy to my Mackenzie Mchale.

I was an early breaker of the “must be four week Sprints” rule, trying three, two and one weekly Sprints. I eventually settled on two weekly Sprints for large (ten person) teams and weekly for smaller teams.

In smaller teams of 2-3 people I experimented with part time Product Owners – people who co-located with the team for a few hours, but were otherwise contactable at any point in time by phone.

I played with having taskcards, removing Sprint Burndowns and replacing it with stronger visual observation as a marker for Sprint goal failure risk.

Release Burn Downs became Release Burn Ups. The relative worth of a Scrum Master full time versus part time was played with.

I did all this because in those early adoption days guidelines, blogs and books were very limited. I did this because the manifesto said “Individuals and interactions over processes and tools”. I saw Scrum as a process but it did not govern or supercede the manifesto and so I played with the rules hoping to test under what conditions ‘Individuals and interactions’ was better realised and what size of Sprint lengths allowed more effective delivery of working software.

If Lean Startup had been around in those days, not only me, but many of us would have been seen to be setting hypotheses, building, measuring the effectiveness of the change in process because we certainly needed to learn what worked and what didn’t.

I believe, to an extent, that Shu-Ha-Ri is applicable, but there is no clear point to me, nor do I think there should ever be a point when experimentation is not allowed. What early adopters have learnt are the conditions and root causes why certain elements should and should not be done. I only think it appropriate that Ri experimenters delve into the unknown with their eyes wide open to the risks that the previous experimenters have found. This is where the learning can be daunting because this is where the rulebook changes into guidelines and there is a lot of information out there to sift through.

I have seen a team successfully deliver a project with no product owner using a combination of Scrum and Lean Startup. By a strict classification this would be considered Scrumbut, however it was a very successful project (probably more than many others I know because we could prove benefits realisation rapidly and the customer was ever present in the data).

I have seen successful teams have a board of Product Owners. In fact, I am a member of such a board right now. It isn’t detrimental. Prior to the beginning of each Daily Scrum, as a board of Product Owners we collectively decide on priority. The card colour denotes the Product Owner and if the team has queries they know easily who to go to for immediate feedback. Problems with process are only problems if you let them be.

I see teams follow Scrum by the letter and fail – the wrong person was the product owner, cards weren’t broken down enough, the list could be quite exhaustive.

There is always risk in experimenting, but in saying “shu” learners should only go by the rulebook, without encouraging any critical thinking, is only further encouraging the lack of movement into “ha”. When we (as trainers) teach “shu” I believe we should have a responsibility to seed “ha”. It isn’t just about “do x, y, z”, it is “x works best when …”, “x is hard to do when …”, “you may want to consider to also do w when you do x”, in essence, it is the:

• what (approach)
• why (purpose/intent)
• who (is involved and to what extent, RACI is a good model for this)
• when (how often, how does the time impact other elements) and
• how (does it feel when it is working right versus working poorly)

We need to teach people how to think, learn and critically assess, not just give solutions. We need to stop telling them off for experimenting. If that had happened in the early days of Scrum we may have never learned of the value of shorter Sprints and of the hundreds of useful tips, techniques and tricks that we apply each day.

Scrumbut is and has always been a terrible name for deviating from the standard definition. You might argue that what I do is Scrumbut. I would say I do Agile -

For my team and my organisation, I endeavor to improve the cost-effective delivery of value to customers through the establishment of a collaborative, safe, supportive and ever positively evolving environment.

Shouldn’t that be the intent of Scrum too?

Note: This blog is a reply to the great conversation and blog by Bernd Schiffer. This is by no means a statement that I agree or disagree with Bernd, I just wanted to offer my perspective.