Super-charge your daily stand up

Some Scrum followers believe that Scrum must be followed exactly otherwise it's utility is reduced, but since my top strength is creativity, I really struggle to do the same thing, in the same way, day after day.

And I don't believe I'm alone as someone who benefits from a little variety in the daily routine. For instance, one of the top tips for sticking to an exercise plan is to not always run around the same block, but to vary the path and companions to to keep it interesting.

In the same way,I believe that we can avoid our Scrum teams getting "stuck in a rut" by occasionally changing how we express the three core questions:

1. What did I do yesterday?
2. What do I plan on doing today?
3. Do I have any impediments?

For me the questions are one specific implementation of questions that achieve two main aims:

• Prevent duplication of effort, by
  • Sharing knowledge about what has been learnt/created that others in the team might like to know/use. (Q. 1)
  • Making sure no two people are independently working on the same task (Q. 2)
• Looking for ways to help each other, so the team velocity increases. (Q.2, Q.3)

I believe there are many other sets of nearly equivilent questions that would result in the same information getting shared but produce a different feeling amongst the team. And by chopping and changing the questions we could inject a little spice into our standups to keep them feeling fresh and vital.

For instance, imagine a scrum team that is treating the stand up just like a progress meeting where team members feel they are reporting to the project manager. They could super charge their daily stand-up by changing the questions to:

1. What did I learn / create yesterday that will be useful for others in the team to know? (This doesn't require an answer if all tasks went as expected but might if I have something the rest of the team will find useful or hit road blocks)
2. What are my general plans for today?
3. What help would get me their faster?
   

Hopefully these questions challenge the speaker to think more about sharing knowledge and less about justifying yesterdays work by constructing as long a list of things worked on as possible. (Which as another member of the scrum team I find excruciatingly boring....please stick to the interesting stuff).

In a similar vein, I've seen many teams where everyone is working mostly individually and not helping each other much. I guess this is common in our strongly individualistic Western culture where asking for help is often seen as a sign of weakness. I even see this in my 95 year old Grandma (and in all my Grandparents while they were alive) who struggles to have people help her, despite spending her first 85+ years in round-the-clock faithful service to her family and the community in general.

But we're missing the point! The whole point of Scrum is to find ways for the team to increase their velocity by working together. To use the strengths of the team in harmony to work more efficiently and to be more engaged with work.

But the thing is, I don't find many competent mind readers on the Scrum teams I work in. So the next best thing I can do, is to be humble and honest and let others know what I am struggling with, or even what is sapping my energy. Because you never know it might be exactly the sort of thing that floats the boat of someone else in the team.

So I wonder what would happen if for one sprint everyone in such teams committed to the challenge of completing the following statement at every stand up.

• Today I could work a little more effectively if only someone would ...

For me, impediments bring about mental images of huge things that I've tried three different approaches to get round but I'm still stuck on. Whereas this statement focuses more on identifying opportunities for collaboration, however small. This is because good teams also help each other by removing small frustrations during the day to keep the energy up and the work moving.

For instance, the other day I got my team-mate a coffee, not because he's more senior than me, or because I'm the woman in the team. I got him a coffee because I was leaving the meeting and he wasn't, and he happened to mention he could do with a coffee (with a look on his face that confirmed he needed a pick-me-up). If the roles were reversed, I know he'd do the same for me. This is one small example of true team work.

What would happen if everyone in your team asked for a little bit of assistance everyday?


Are you honest and humble enough to start asking for help and to charge-up your Scrum team with super team work power?".

If you ask me, it's a lot easier to learn to be open and humble, than training everyone around you to read your mind!

Is Feedback the new Agile?

Lately I've been reading a good book on change, Influencer, the power to change anything. It was talks about the fascinating methods of Dr Mimi Silbert, who by creating an environment full of constant feedback about performance, helps career criminal change their lives forever. For instance, within hours of entering her Delancey Street Foundation, recruits will already have started working in the restaurant, setting actual tables and feeling the satisfaction from having achieved something new. (A sense of achievement is one of the best sorts of feedback there is.)

To see the power of feedback for yourself, take a graduate employee on her first day and give her a very small task to do. (Adding her name and team wiki and fixing up the layout is ideal.) Make sure that within an hour, and then several times through out the day, she gets feedback from completion of tasks. See how this sets her up for the rest of her time in the job. I've done this with many new graduates and always has good results.

After reading Influencer, I started thinking how all this applied to software development and I quickly saw some correlations with Agile methods. I started thinking to myself, "Is Agile all about feedback? Can we can simply replace the Agile Manifesto with a simple pledge , 'Thou shall give and receive feedback as much as possible?'" Well maybe that was taking it a bit far, but there certainly seemed many parallels.

For instance, continuous integration and unit tests must be obvious ones. The aim of both is to fail fast. That way you get your feedback as soon as possible that the code doesn't work.

And what about Scrum? When I was taught Scrum, the feedback cycles were strongly emphasised. First there is the daily standup meeting which gives feedback about how current sprint is going. Then there is the retrospective which gives feedback about how the sprint process is working. Bingo another one.

Pair programming (an opportunity for feedback into better ways to do whatever you are doing right now) is another. As is delivering small features regularly (feedback to the customer on how the process is going). And then there is keeping tasks small (feedback to the programmer that they have succeeded). The list just kept growing. So Agile may be more than just feedback, but nevertheless feedback seemed to be a huge part of Agile.

Then a slightly adventurous idea came to me. I thought "Lets turn the question upside down". Knowing what we know, that feedback is a powerful motivator for behaviour change, how can we improve feedback in our development processes to make them even more Agile?

Suddenly I was flooded by questions. How can we get our automated tests running faster? Have better coverage? Give each other more feedback about what behaviour we like? And behaviour we don't like? Reduce our units of work so they're finished quicker? Get our features to our customers faster? Give our programmers a better sense on completion for each card? Let our testers see the bugs they found have been fixed? Share the improvements the customer feels with the whole team?

These questions are the same questions we have always been asking. The difference is now we are emphasising giving each individual team member feedback about the results of his or her actions. With this in mind, it offers new possibilities for improving processes.

After all if feedback can tame the urges of hardened criminals, I believe it can work a power of good on our customers, programmers, testers and even our development managers.