Monday, 7 April 2014

Monday Thought: Is it Done?!

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 24 March 2014 17:37
To: Dev All
Subject: Monday Thought: Is it Done?!

In our previous Retro we discussed our Definition of Done (DoD) and we are now in the process of formalising it. The DoD should be a agreed & shared among all teams so I invite you all to take part in this discussion and come up with the bare minimum that we understand as DONE.

Scrum requires Teams to build an increment of product functionality every Sprint that is potentially shippable. To do so, the increment must be a complete slice of the product, additive to all prior increments and thoroughly tested, ensuring that all increments work together.

n Teams, 1 Agreement! 
Asserting that functionality is done might lead someone to assume that it is at least cleanly coded, refactored, unit tested, built,and acceptance tested. Someone else might assume only that the code has been built. If everyone doesn’t know what the DoD is, the other two legs of empirical process control don’t work. When someone describes something as “done”, everyone must understand what “done” means.

Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the DoD does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all PB items in the increment.

That may be too much! No worries! When Teams aren’t yet able to include everything required for implementation in their DoD, this must be clear to the PO. The remaining work will have to be done before the product can be implemented and used.

But we already have a big Code Best Practices document!
The DoD is not a set of best coding practices. You are expected to  be using the Team Best Practices when doing your code but the DoD sits on top of it, at a more business level and is shared among the teams and Product Owners who know what does it mean for a certain story to be Done.

Where to start? Simple as we can. A story is Done when:
  • It has being tested (unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration)
  • It has being documented (code comments, type hints, confluence – if required, etc)
  • It has being pair reviewed
  • It has being validated by QA
  • It has being checked by Product
Is this enough? Is it too much? Keen to hear your thoughts!

Best regards,

This is part of my email experiment that I sent - every 2 weeks - to the dev team I am part of, aiming to inspire them to acknowledge and question What we do, Why we do it, and How we do it

Wednesday, 2 April 2014

Tips for Scrum Alliance's CSP Exam

The CSP Certification was on my radar for a long time but it was just one of these things I kept delaying, until I read about the changes to the certification process after January/2014

What has changed?

From 31st January/2014 onwards in order to apply for the CSP Exam you will need to have years of experience PLUS a set of SEU, continuous education units that you accumulate through attendance to Scrum-related conferences, presentations you give, blogs you write etc. The conferences and trainings will need to be endorsed by the Scrum Alliance for you to be able to claim units. Basically it means it is going to involve a lot more work.

The Exam

As I recall there were quite a few questions related to Ceremonies (specifically Retrospective, it’s phases, scope, goals, etc), Scrum Roles, Refactoring, TDD, Spikes, purposes of CI, ideal team structure, Acceptance Tests and how they are used in Agile, team Estimation, team structure, PDCA (plan-do-check-act), intentional and emergent design, "what would yo do if your team is failing to commit or under-delivering" (would you increase the sprint? make it short? and so on), about the variables involved in calculating ROI, ...
I found the exam tiring. It was not only about waking up 5am, driving for almost 4h from London to Whiterby and having to go through a 3h exam with 150 questions.. the questions are tricky. You are always left not knowing if you have chosen the right option although you are sure you did :-) Many of the questions are along the lines of "find what is THE BEST option among the ones bellow" and this is the catch. The options are all technically right but to find the BEST one...

I guess most books tend to repeat a lot of the same stuff, from all the reading material recommended by Scrum Alliance (25 books!) these are the ones you should read if you have the time:

1) Essential Scrum – Kenneth S. Rubin
2) Succeeding With Agile - Mike Cohn
3) Agile Estimating and Planning - Mike Cohn
4) User Stories Applied for Agile Software Development by Mike Cohn
5) Agile Software Development - Alistair Cockburn
6) Agile Software Development with Scrum - Ken Schwaber and Mike Beedle
7) Agile Product Management with Scrum - Roman Pichler
8) Extreme Programming - Kent Beck
9) Agile Retrospectives, Making Good Teams Great
10) DoBetterScrum-v2
11) Scrum Papers
12) Scrum Primer
13) CSP Preparation PDF


I read only 2 books and the rest was be based on PDF's and Exam Simulations. I also complemented that with a lot of simulation tests.

I was a bit concerned about my strategy but at the end it worked so I guess I can share my notes and what I read. I believe previous professional experience really helps with the questions.

I have read the following books:
If you could bother I would also add another one to this list:
I have also gone through the following PDFs:
For questions and test simulation I used the free version of the following sites:

Some of these sites randomly select the questions so you can do these as many times you want, until you are satisfied with the results. I would definitely recommend Scale Study and since is quite affordable would advise you to seriously consider paying for it. Their questions resemble a lot what I saw in the exam.

When your time comes, don't spend hours in a single question, there are 150. Answer them as you go and flag the ones you are unsure. In my case I did all the test in 2h and spend the last hour checking the ones I flagged. Funnyly enough I had flagged 40% of them :-)

Personal Notes

I created a few documents containing study notes from the books and PDFs I have read and also the best questions I have seem while taking the mock exams. I am also making available my Ebooks and Agile files.

A digest of the few PDFs I have read. I am yet to write a big one that merges all this information.

Study notes from books and other readings a a full list of questions about the Agile world.

All books mentioned in this post and much more.

Additional Reference

Right from the start I've joined the Scrum Alliance CSP Exam Prep Study Group in Linkedin and went checking the notes of people who have done the test and were sharing their tips, notes and reading links. Among the ones worth having a look I would mention:

Saravana Bharathi's site, Agile Karma, contains a useful Reading List and also some more tips and useful links.

I would also recommend checking other Linkedin Agile/Scrum Groups since they always have a lot of useful information as well as already stablished blogs and websites such as

Scrum Alliance’s Agile Atlas contains many articles from top contributors
Scrum Training Series, with loads of videos
Source Making, Great info on Design Patterns, Refactoring, …

Team Dynamics

Pair Programming


Scrum Alliance Recommended Bibliography

Title: Succeeding with Agile: Software Development Using Scrum
Author(s): Mike Cohn

Title: Agile Estimating and Planning Author(s): Mike Cohn
Publisher: Prentice Hall

Title: Agile Product Management with Scrum Author(s): Roman Pichler
Publisher: Addison Wesley

Title: Agile Retrospectives
Author(s): Esther Derby and Diana Larsen Publisher: Pragmatic Programmers Publication Date: 2006

Title: Agile Software Development with Scrum
Author(s): Ken Schwaber, Mike Beedle Publisher: Prentice Hall

Title: Agile Testing: A Practical Guide for Testers and Agile Teams
Author(s): Lisa Crispin and Janet Gregory Publisher: Addison-Wesley

Title: Clean Code
Author(s): Martin Publisher

Title: Continuous Integration
Author(s): Paul Duvall

Title: Extreme Programming Explained
Author(s): Kent Beck

Title: Extreme Programming Installed
Author(s): Jeffries, Anderson, and Hendrickson

Title: How Do We Know When We Are Done?
Author(s): Mitch Lacey

Title: Implementing Lean Software Development
Author(s): Mary Poppendieck, Tom Poppendieck

Title: Planning Extreme Programming
Author(s): Kent Beck, Martin Fowler

Title: Pragmatic Project Automation
Author(s): Clark

Title: Project Retrospectives: A Handbook for Team Reviews
Author(s): Norman L. Kerth

Title: Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience
Author(s): Arlo Belshee

Title: Refactoring: Improving the Design of Existing Code
Author(s): Fowler

Title: Retrospectives – The Missing Practice
Author(s): Tim Mackinnon

Title: Scrum Primer
Author(s): Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Vodde

Title: Test Driven Development By Example
Author(s): Kent Beck

Title: The Art of Agile Development
Author(s): James Shore

Title: User Stories Applied
Author(s): Mike Cohn

Title: What is Definition of Done (DoD)?
Author(s): Dhaval Panchal

Title: Which End of the Horse
Author(s): Jeffries

Title: Selling Agile – How to Respond to Concerns from Management, the Business, and the Team
Author(s): Michelle Sliger and Stacia Broderick

Monday, 24 March 2014

Monday Thought: "Why do we do What we do"

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 24 March 2014 17:37
To: Dev All
Subject: Monday Thought: "Why do we do What we do"

The road to empiricism and continuous improvement is about a diligent questioning and analysis of everything we do.

The “Scrum Bible” is only 16 pages and easily digested, but as we experience, making it work right is a whole different game :-)  The are no Scrum flavours, there are no "Scrum but”s.. You either do it or don’t. Simple as that.

For those who care about people over process, here goes a PDF for bit of evening relaxation.
It worth to see what is prescribed in there and how we apply to our reality.

Have you all a great week!

This is part of my email experiment that I sent - every 2 weeks - to the dev team I am part of, aiming to inspire them to acknowledge and question What we do, Why we do it, and How we do it

Sunday, 23 March 2014

Trad in Millstone

The forecast was uncertain but hey.. it’s England right, forecasts are always uncertain. So after setting the wrong address to Bruno’s address and Alex forgetting his food at his place he finally arrived at the Peak late at night. We went camp close to Millstone, way deep into the woods to avoid any trouble. It was cold and damp but I still had an amazing sleep. Woke up very early with Alex rushing not too take too long to start climbing only to realise the rock was too cold :-)

I manage a bad style accent of Embankment 2, VS 4c (1st pitch only since the 2nd was wet). Crack climbing is not my thing although I do enjoy it. I had to stop every once in a while to try to get some feedback from my cold hands. Polar wind coming up my trousers...

On my way up Embankment 2, VS 4c

After this pre-warm up Alex decided to give a go at Shaftesbury Avenue, HVS 5b. That bit was already in the sun, the rock was not as cold but the wind was still merciless. I followed but took a while to figure out the right way to pass through the overhang.

The joys of crack climbing, Shaftesbury Avenue, HVS 5b

After that what was cold got colder and it started raining. We hid under an old construction drinking coffee and waiting to see what’s going to be. It would normally take up to an hour for the rock to "dry", we would gear up, get ready and it would start rain again.. Two times this happen, we were reaching the end of the afternoon but Alex still wanted more.

Bruno was fed up with the weather and went to the car. We stay put. At some point another break in the weather and he went for Embankment 3, E1 5b (1st pitch) which although was “sort of dry”, still looked wet. Great lead specially considering the dark clouds that were now defiantly heading our way. He got stuck in the crux but after a bit of motivation - "Alex dude, you either get it done or come down coz the rain is fucking coming now" - he finish in style just when the fat drippings started.

By the time we coil the ropes it was proper rain all the way. After a pub lunch we headed back to the woods only to be surprised by a cops car checking our car by the road. Yeah.. cannot camp in private land, nowhere to go, no b&b's with space so ... by 1am we were all back to London.

A short but intense great effort :-)

23/03/14 Embankment 2, VS 4c (1st pitch, lead OS, No rests)
23/03/14 Shaftesbury Avenue, HVS 5b (followed, with rests)