Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts

Monday, 10 August 2015

Using Aspects of Lean Coffee to Drive a Retrospective



Those who have been following my blog may have noticed that I have not updated it as frequently as I normally would, or would like to.  There are been a variety of reasons for this, I am writing a book which is taking a lot of my spare writing time, I have not had much of interest to write about and finally over the past year my role within testing has changed to one of being a scrum master for agile teams.  It has been an exciting and challenging role which over time I may blog about.  It has been strange since people have commented that I appear to be a natural in this role and part of me thinks this could be due to my skills as a tester that helps in this role.  I am still trying to get involved in some testing and hopefully there will be opportunities for me to do this.

This post is about an experiment I attempted with a scrum team recently for the retrospective.  I am unsure if I obtained this approach from somewhere, or it was just an idea I came up with.  I have decided to share it  via my blog for others to see if they find it useful.

A common approach to retrospectives is to get the team together and discuss what they felt went well, what could they improve and to have some actions for the team.   The way I have run this in the past is we take each of these statements and get some feedback from each members individual perspective.   Some of the questions that can be used can be found here - http://www.benlinders.com/2013/which-questions-do-you-ask-in-retrospectives/

What I found was these retrospectives did not appear to be that engaging and after awhile became a little stale.  So I had an idea to change the dynamics by introducing a lean coffee (http://leancoffee.org/) format.  Lean Coffee is a structured but agenda less meeting, which consists of three steps:

(1) Set up a Personal Kanban

This basically means create a series of post-its to represent
  • What we are currently discussing, "In Progress"
  • What we have discussed "Done"
  • What actions have comes from the discussions "Actions"

(2)What to Discuss

This can be any topic  that you wish to discuss, for the first retrospective I ran in this way I used the following:

  • Shout outs
  • What was good.
  • What was Bad
  • Improvement Ideas

The first four were placed upon the wall and then I gave the team members a set of post-its and pens to write down their thoughts for each of these titles. One post-it per comment

Shout Outs:
Who do you know who went beyond their normal day to day work to help the team.  This could be someone within the team or outside our team who helped support the team.

What was good
What do you feel went well in the sprint.
What made you feel good about what the team did,


What was bad
What do you feel went wrong in the sprint
What made you feel bad about something in the sprint

Improvement Ideas
How can we improve what we do?
What ideas do you have to make the team better?

(3) Vote and Talk

Once we had done this everyone was encouraged to go up and look what others had written and at the same time we decided to group similar comments together. After this we had some cookies, always bring cookies to a retrospective, I moved the In progress post-it over to the 'shout outs' column and people started to explain what they have written,  It was interesting that it was someone outside our team that people felt had added value to the team.  From this we as a team sent an internal gift and a recognition for their work.

Once we had finished with the 'shout outs' we moved this column to 'done' and move the 'in progress 'sticky to the next column  'What was good', we followed the same approach and everyone had opportunities to discuss what had been written.  At the same time any actions that came from the discussions was added to the Actions post-it.  This approach was then done for the rest of the columns 'What was bad' and 'Improvement ideas'.

The dynamics of the team during these discussions was far greater than at any of the other retrospectives and I felt as a scrum master it worked really well to encourage the different members of the team to participate.  Part of being a scrum master is to keep the various ceremonies you have for the team 'fresh' and 'interesting' and in this case it appeared to work well.  Will it have the same affect the next time, I am unsure however it is one more tool I can use to help the team. Let me know of your approaches to keep the team motivated and encouraged.  Also if you try this approach let me know how it works for you and your teams.

In Lean coffee you would normally VOTE on the topics you are interested in using dot voting,

"Each participant gets two votes. You can vote twice for the same thing or for two different topics. Simple put a dot on the sticky you are interested in. Tally the dots. "

Update: I have run this approach a couple of times since the first trial and  it appears to work very well.  I have tried to prevent it from being too routine and have changed the questions that are posted.  I have used titles such as "What was positive about the sprint" , "What was negative" "If we could improve on one aspect what would it be".  It is important to create varieity in the retrospective even if you are using the same approach.  It helps to keep the team interested and motivated.  Cakes and cookies help too!

Friday, 19 September 2014

Agile testing activity checklist

As the barriers between development and test blur when working in scrum teams and being agile, the testing activities can sometimes be lost.  There may be occasions where there is no testing expertise in a scrum team and the scrum team members struggle to know what to focus on regarding testing activities in their sprint.

Since this was becoming an issue with some of the teams I was involved with, myself and others came up with a testing activities checklist based around Lisa Crispin and Janet Gregory agile testing quadrants.

The rest of this article shows this checklist.  Please feel free to adapt and change this checklist to meet your testing needs in agile scrum teams.  The only caveat I make on this is that if you find it useful please let me know.

Testing Activity Checklist
This is an example template for Scrum teams to use as a checklist for testing activities carried out during a sprint


Sprint Number:
Does the scrum team have any testing expertise
Yes / No 
Has the scrum team done any testing activities in this sprint?
Yes / No 


Unit/Component (Q1)

Check
Response
Comments and Justifications
Do Unit Tests exist?
Yes / No

What is the level of unit test coverage? (Sanity, bad input, edge cases, regression etc.)


What is the quality of the unit tests? (per quality key table below)


% Code coverage and have you met your target %? (Which tool used?)
nn%

Has any state coverage been done?
Yes / No

Zero static analysis violations
Yes / No

All check-ins have code reviews?
Yes / No

All check-ins have unit test reviews?
Yes / No

Are unit tests automated in a CI?
Yes / No

How often are unit tests run? (every check in of development code/nightly/other)


Unit testing added to Definition of Done (DoD) 
Yes / No



Functional (Q2)

Check
Response
Comments and Justifications
Functional tests exist?
Yes / No

Have acceptance test criteria has been reviewed?
Yes / No

What is the coverage of functional tests (See below - coverage key)
0-3

Are functional tests automated?
Yes / No

A CI System is being used for automated system tests?


How often are automated functional tests run? (every check in /nightly/other)


Are functional tests run against latest build?
Yes / No

Has manual functional testing been done (exploratory)?
Yes / No

Functional tests added to DoD 
Yes / No




Coverage (Key)
0
We have no good information about this area
1
Sanity Check: Major Functions & Simple Data
1+
More than sanity, but many functions not tested
2
Common cases: All functions  touched common/critical tests executed
2+
Some data. State or error coverage beyond level 2
3
Corner Cases: Strong data, state, error or stress testing

End to End (Q3)

Check
Response
Comments and Justifications
Has exploratory testing been done? (if not give justification)
Yes / No

How much time has been spent on exploratory testing (number of sessions)
nn

How has exploratory testing sessions been captured (Wiki/other tool)

What is the quality of the acceptance criteria (see below for definition of testing quality)


Acceptance criteria tested
Yes / No

Demo criteria tested
Yes / No

E2E customer tests added to DoD 
Yes / No



Quality Key
**
We know of no problems in this area that threaten to stop go live or interrupt testing, nor do we have any definite suspicions about any
**
We know of problems that are possible showstoppers, or we suspect that there are important problems not yet discovered
**
We know of problems in this area that definitely stop go live or interrupt testing

Non Functional (Q4)

Check
Response
Comments and Justifications
Nonfunctional tests exist
Yes / No

Which types of Non Function Tests exist?
Performance, Reliability, Usability, Stress, Spike, Scalability, Endurance, Volume, and Security (e.g., CSDL)


Yes ? No

Have nonfunctional tests been added to DoD
Yes / No



Testing Activities Definition of Done


Check
Response
Comments and Justifications
Has all DOD criteria been met for each quadrant?
Yes / No

Zero open defects in the sprint
Yes / No

100% of all possible automated  checks running (Unit, Functional / E2E)
Yes / No

100% automation pass rate.
Yes / No

Exploratory testing target met (% possible time spent exploring)
Yes / No

CI Builds are in place
Yes / No

Sprint demos and feedback given.
Yes / No



Testing Quadrant Dashboard
This is a simple checklist dashboard.  It is either green or red, have all the activities listed above for each quadrant been completed.  Yes=Green, No=Red.

Q1
Q2
Q3
Q4
 Green = Met DOD for that Quadrant /  Red = Not met DOD for that Quadrant

I have also uploaded a word document version here so you can adapt and change it to suit your needs.


Postscript:

I will be running a Creative and Critical Thinking workshop in London - Thursday 16th - Friday 17th October 2014