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.

Creating a QA process from out of thin air

This week I had the opportunity to present the work I have been doing over the last year to a group of testers at a Testing Professionals Network (TPN) meeting. I enjoyed sharing the changes we have made and how far we have come in a short time.

Agile Acceptance testing with Fitnesse

View more Keynote presentations from ClareMcLennan.

A little more about what I've been up too...

About a year ago, I swapped jobs within my company from being a developer to the challenging and highly stressful job (in the beginning) of QA team lead. This meant I was tasked with building a QA team to test a high load, high availability adserver.

This all happened about a year after the company started when we suddenly found we had enough customers that we had to be very careful about what we released. However, the product had been created with such speed that we had no automatic system tests and it was incredibly hard to get any test to run successfully on our test environment. We had also just hired our first tester, who was struggling to get anything working. So it was a big problem and it needed solving, quickly.

My reponse was to start building an automatic testing system, starting with the area of biggest ROI (return on investment). I chose budgeting as I guessed not going over our promised budget was pretty important for our customers, was almost impossible to test by hand but was a reasonably simple test to autotmate.

From those small beginnings the suite slowly grew. As things started to take shape more and more developers could see the power of the system and were happy to contribute to it. Others required the boss to tell them that they must do it. Now 12ish months later, thanks partly to a re-write and thus the need to test everything, we probably have about 90% functionality coverage with our automated tests. Not only that, but we also have a team of developers who are enthusiastic about getting the tests running.

Having seen several other companies take a long time to develop automated tests I am truly amazed at our process. I believe our success is due to getting everyone involved in the testing process. Making the software developers run the tests really helped. That way they got to see how their system design affects the system testability.

So one of the main themes I had hoped to share in this presentation was that in order to build a good, reliable automated system test suite you generally need to improve the testability of the system under test. Improving testability generally benefitsboth testers and developers, as the tools that are developed also help during development and debugging of the system. For example, we created an installer, tools for checking the system status and ways to easily create test data.

So creating a quality test system quickly, I believe, requires the cooperation of both testers and developers. However, putting such a system in place is tricky because it generally requires a simultaneous culture and technology change.

An example of a culture change required is that developers often believe testers are solely responsible for testing. However, developers can make a huge difference on the testability of the system depending on how they design the system. So to get everyone focused on the end goal, tested and releasable software, it is important that both managers and developers understand that developers and testers share the responsibility for testing the system.

However, if a developer has not worked on a project with a good automated system test suite, then they may not be able to see how they can help the tester. Then, if they see tests running erratically they are more likely to question the value of such tests, than to question the way that they themselves have designed the system.

Thus the first culture change requires the developer to be able to picture how they can assist the testing process. But getting them to make the first changes, requires them to believe that the tests are worth building in the first place.

My approach to tackling this chicken and egg problem, is to be agile. Start with a working tests, then ask for small improvements that make the tests more reliable, or quick, or easy to write. Give some value, ask for an improvement, give value, ask again, give value, ask again...

So my second message to all tests leads out there is don't just stick your head down and suffer with unpredictable automated tests. Think about what you need changed about the system, and make sure your developers listen to you. It may seem like a huge effort for small gains in the beginning, but they all snow ball and save you time in the long run.

Please, take a look at the presentation and send me any comments you have. In particular if there are slides that don't make sense without the audio then write a comment and I'll explain them in more detail.

What small change can you make that will make your system more testable?