Good practices for Agile Scrum (additions)

Summary

We know what scrum really is now. And we found out that it’s not about only stick to the rules. It’s about bending the rules to fit to the team. In the last years we learned that the scrum rules don’t work when you just apply them without considering the meaning of them. You have to get a grip on them and learn how to use them in a good way.

This document contains the procedures how the Defenders (current team I'm working on) evolved from the scrum methodology. It’s not said that this is the best approach, because teams differ from each other a lot, but the main thing is we have evolved through experimenting and you should too! It’s not only fun, but it’s leading you to your best practices and it’s making you strong!

Don’t get me wrong. You need to work strict on the rules of scrum for a while before you make any additions or changes to it. The goal is to find out what scrum means and what the rules are for.

Scrum encloses force.

Let me explain what I mean with ‘scrum encloses force’. If you are obligated to fulfill the goal of the sprint (and I’m talking about finishing what you’ve estimated), because of scrum, you are forced to cooperate in such a way that you eventually can comply to that goal. We all know that the first sprint isn’t going well and estimates are far off. In other words, you have to get used to the fact that you’re planning and estimating.

Standup

Legacy

We started out with the common stand-up, but it didn’t work out for us. I’m talking about the three questions stand-up: what did I do yesterday, what am I going to do today and am I expecting impediments or difficulties? So everyone summed up there thing like: ‘I was working on MTN-345, I’m working on it again today and I’m not experiencing any problems.’ It didn’t help us to get things done the right way. Most of the time, all of the user stories were in progress, because we didn’t collaborate well enough.

What we’ve learned.

Let’s make one thing clear. The product owner did order the sprint for a reason (, hopefully together with the team). So the first item needs to be finished first. The second secondly etcetera. All looks very obvious, but how are you able to do that? That’s when a good stand-up is coming in. Therefore the questions at the stand-up should be: how are we going to finish the first user story? Who is going to collaborate with whom? And what progress can we make today? What is the best approach to finish this user story the best way?

So you go, user story by user story and find out what you have to do to finish it nice and smooth and have an estimation on the progress. It’s like a small (daily) planning.

Refinement

Legacy

For a long time we tried to do refinement the normal way. We were letting the product owner show what the customer needs and we were trying to comprehend what that might look like in Twinfield. There were not many questions, because it was a one way direction more or less. So the implementation led to a lot of misconceptions and bugs. The tester found things the developer didn’t think about and the developer touched code he thought wasn’t worth to mention to the tester. So bugs sprout out from production.

I think the reason was because we didn’t talk about the feature enough. Most of all, we didn’t talk about it at all, because in our own heads it seemed clear enough.

What we did is let the product owner create the user stories and the acceptance criteria. He was spending a lot of time on that and at the end, the team changed a lot about them during the sprint.

What we’ve learned

Now we are creating user stories together with the product owner and help him out on that. That’s purely because as developers we know the domain and the code best and we know more and are smarter as a team than the product owner is by himself.

To understand the user story correctly, you have to go through three phases. And if you don’t want to have the tester falling behind a lot, you need to make sure your user stories are very small. And that ladies and gentlemen, may be the best part of being part of a development team. Try to puzzle your way out to have the best minimal viable product and implement it the smartest way. That is the cherry on the cake, especially for a developer.

For this three phases we created a Trello board for the user stories which we need to refine. Every user story has a checklist for all of the three phases, like: ‘The title of the user story reflects the actual fix’, or ‘The team has figured out and talked about different scenario paths’. The full list will be at the bottom of this document.

Also, you need to have everyone to talk about the subject a lot! If you think you got a silly question, don’t hesitate to ask. Speak your mind and you will see that stupid questions can lead to different thoughts and perspectives and might even lead to better solutions. At least, the one who asked a stupid question, knows more about the user story now. Keep asking questions!

One thing worth mentioning: you don’t need to talk about the solution at this point. There is no need for that. It will come in the sprint itself. (In practice, you’ll find out that each one of you is secretly thinking about a solution, so don’t worry about that)

Phase 1: Use cases.

Try to figure out the original goal of the feature. You could ask yourself a few simple questions. Like aren’t we dealing with a solution or a question? Aren’t we making a workaround for a deep underlying problem? Maybe the customer thinks he/she wants the feature, but is going to use it the wrong way. So the most important question here is: what does the customer needs the feature for? As a .., I want to …, in order to …

Phase 2: Scenarios.

The team gets to know the behavior best when scenarios are made for the feature. Given …, when …, then ... It looks kind of silly, but you’ll see that this is the best way to get familiar with the feature. Try to smell the feature. Try to taste it.

You might come to the conclusion that the feature can be splitted, or is hooked into other functionalities. You come up with additions and deviations. Finally you end up with perfect acceptance criteria, because you got the most important scenarios. And the most important thing is that you’re all on the same page! There are no misconceptions at all. Everybody knows what to expect and everybody knows what the impact is of the features functionally.

Phase 3: Consequences and Risks.

Up till now, you cannot estimate, because you don’t know the current situation of the code. What does the code look like? Is it rigid or fragile? Is it rotten or deteriorating? Are there unit, integration or end-to-end tests. In short: how is the current condition of the code and what is the technical debt to overcome?

Estimating

Now you got a good picture of what your situation is and the team can estimate. It knows quite exactly what they are up against.

But keep in mind that you are still not actively looking for a solution for the feature or problem. That’s a thing you need to do within the sprint. You also don’t need to fully understand the ins and outs of the user stories, it’s only to get really familiar with them.

The trick at estimating is to create yourselves a reference. You should define a reference point on a common and well known feature, for example a feature toggle. This is a real easy feature and you have a good feeling about what needs to be done and what not. You can mark this down as 1 story point. From that perspective you can value other features and estimate based on the feature toggle. You will become good and accurate on that in time. You come to a point and ask the team, how is this feature more or less difficult than the previous one.

Planning

During the refinement you have estimated a lot. And if you have done enough estimation sessions, you have enough user stories to fill the planning. So the planning will be a formality. A session in which you seek for transparency between the product owner and the development team and have a confirmation of what you agree to do.

As Defenders we create ourselves an image of how the sprint may look like up front and place user stories in it which we think we can do. During all the refinements we tweak that image. (In Jira, you can create a new sprint and fill it with a bunch of user stories from the top of the backlog)

Retrospective

Legacy

We started off with the questions who are available in Jira about preparation, added value, sprint product, self-organization and teamwork.

That became boring and eventually nothing interesting came out of it to improve ourself. It was the same old song, over and over again.

What we’ve learned

We tried out a lot of different retrospectives. That contributes on having a fresh mind and seeing things from many different perspectives. The most important thing is: improving. There are a lot of different retrospectives you can do like: the 4L’s, the 5 whys, speed boat, 6 thinking hats (mostly used for problem solving), and lots more of them.

Retro suggestion number 1

1. If you look at the work you did, try to sum up the facts.
2. Where was the collaboration?
3. What was impeding you?

How would you redo the implementation if you could do it all over again? Where are the tweaks in your process?

I know it’s difficult, but with the right questions, you will come far.

Retro suggestion number 2

Let the team realize that everybody is thinking in an other way.

Let everyone draw a picture of a castle with clouds and landscape. You will see that everybody has a different view.

Try to have a developer draw one picture together with a tester by drawing one line at the time swapping between the both of them. So first the tester draws one line and then the developer one in addition to the previous one. You will see that the line the tester made is meant differently than the developer thought it would be for.

Retro suggestion number 3

Show the teams emotions in a graphical way: http://tastycupcakes.org/2013/07/moodgraph/ It reflects what let you feel good. How do you prefer to work? What made you feel good. It’s quite obvious that when you feel good, you implement best!

Conclusion

Differ a lot and it will benefit you! Maybe you are thinking: this is really stupid and childish, I’m not going to do any of this. I can imagine that, but I advise you to just try some things out. You are going to have fun for sure!

Overall conclusion

Experiment a lot! Try out new things like TDD, BDD, extreme programming. Find out what’s best for your team. What benefits the team and what brings it down? Bring in the fun! Move out the worries! If you stick to these ‘rules’ you will improve a lot!

Remember that to have trust in what will come and what you do, makes the team enjoyable to work in.

Checklist Refinement phases

Use cases

The team knows what is going on,

The title of the user story reflects the actual fix,

The team knows what the fix is for, or why the customer needs the feature,

The team knows how to reproduce the bug, or how the new feature must work,

The team has created (some) use cases.

Scenarios

The team has figured out and talked about different scenario paths,

The product owner is satisfied with the scenarios,

The team has filled the scope and knows what is out of scope,

The team is sure it can demo the user story self-explanatory at the review.

Consequences and Risks

The developers have a general idea on how to implement it,

The testers know which tests are already there and which ones they should add or alter,

The developers know which unit tests and integration tests already exists,

The risk analysis is filled in.

Tamagotchi

Maybe you have heard of the term 'Grooming'. It was the term I used for refining backlog user stories, but since I heard that grooming was associated with making contact with under-aged children, I prefer to use Refinement.

Nursing

Now the stage is set to talk about refinement and my little experiment with it.
If you have trouble handling user stories in your sprint and underestimate or overestimate a lot, you might want to use my approach for having control over it. If I was asked to come up with a name for this approach I called it: Nursing. In this blog I will walk you through the concept of nursing and tell you step by step what we do from-out the 'Trenches' of my scrum team.
I immediately thought about the tamagotchi toy. You have to feed it and give it attention, because it dies if you don't.

First day of the sprint

This is where it all starts to happen. We have just created a brand new sprint and we are about to start working on it. From the planning, where the current sprint is just formed and agreed, we look beyond the sprint and try to figure out what the upcoming sprint may look like. In practice, we create an other sprint on the shelve and fill it with the top of the backlog, of-course agreed with the product owner. This is the beginning of a two weeks mission to clarify the hazy and misty image we got of the next shelved sprint.

Three stages to become familiar with each user story

There is an order to get familiar with an user story the right way. Developers usually have the urge to immediately start with implementing and finding a solution for the feature. In short, all disciplines kind of lean towards another direction, which is in their interest area. In other words: we create our own image of the feature and keep it for ourselves. I'm a little bit exaggerating of course, but this is what mainly happens.
You can divide 'knowing the user stories' into three stages. (At least, that's what I came up)

Stage 1: Use cases

In stage 1, the team tries to find out what the user story is about. And the most important thing is, why does the user wants this feature? Try to get to the questions behind the questions. Questions might be: 

• Most of the time, the feature is a solution. But is the feature THE solution the customer really needs? 
• You might also consider if you are trying to create some kind of workaround? 
• Which customer needs this feature and shouldn't there be a permanent solution for this 'problem'? 

You can ask all kinds of questions here. But be alert that you stick to the use cases and not trying to create scenarios or solutions at this stage! (Maybe you can break up the feature a little bit into several user stories! Whoohoo!) (The usual format of a use case (user story) is: As a ... (persona), I want to ..., In order to ....)

Stage 2: Scenarios

So we know what the customer wants and why the customer wants it. We can now talk about scenarios. What kind of personas are relevant for the scenarios and what kind of variations or deviations can you come up with? 

I have to point out that this is not the time to get all scenarios thoroughly correct at this moment. Again, it's only to make everyone in the team aware of the situation and get a good feeling about: what is about to happen during the next sprint. You must be all on the same page. (The usual format for a scenario is: Given ..., When ..., Then ...)

Stage 3: Consequences and Risks

This is the stage where we find out what the current status of the code is and what kind of tests there are. We have to know the current situation of the implementation before we are going to work on it. The testers need to know which tests there are and need to find out what more of them need to be made. The developers trying to find out technical debt, dive into the code and see what they are up against.

Estimation time!

Now you nursed your backlog well enough, it's time to estimate. Everyone now knows what to expect from the user stories, so estimation should go smoothly.

Recommendations

• Try to not find a solution during the refinements
• try to get as familiar with the user stories as you need to, to end up with a good feeling about them and therefore create trust.
• If you do not nurse the next sprint well enough, it might become infected and therefore less controllable.
• What you can do with less people than the whole team, you might want to consider to actually do with less people. Like one tester, a developer and a product owner. For example: create scenarios. But you have to present them to the team at the next refinement.
• Before the end of a refinement, you can make tasks to be done, before the next refinement begins, like investigation tasks. Find out what you want to do together, or you want to do in sub teams.

One more thing

You maybe wondering where the solution comes in. I know for sure that everyone in the team has thought about: how are we going to implement it? When you start a user story, you can have a brainstorm about that. 

The way it looks like in the user interface is absolutely not the most important thing! You need to find out during the implementation. The most important thing is that you have implemented the feature in the most simple way. Tweaking comes later. Feedback will give you new ideas.