Yesterday I completed my Certified Scrum Master training.

It was conducted by Giora Morein from BigVisible. It was an excellent experience and I thoroughly enjoyed it.

It was a two-day program.

Day one was split into two parts. In the first part , we played some scrum games- which was quite cool actually.

We formed 4 teams with 4 members each.
We were given a series of tasks which we then went on to size , prioritize, and execute.

We simulated two sprints and discussed planning and sizing strategies around that.

I think this was an excellent idea- because it gave us all a common ground to discuss the rest of the session. It also made us- the students closer to each other as a team- making learning a community process- which in turn is quite agile, I think. It also added an element of fun to the whole session !

The rest of the day and the second day- we went through the various parts of scrum- discussing definitions , processes, challenge questions and so on. Giora gave us some excellent examples and definitions and analogies .

The one that I liked the most was- where he contrasted commitment with promise. To quote him-

A fireman makes a commitment that he will do his utmost best to save people from a building on fire. He does not make a promise that he will save everyone from the disaster. In software development- we are not in the business of making guarantees- we only commit.

The sessions were very interactive. We got into some lively discussions and he was very patient and took time to answer us all- without ever seeming rushed. We all brought in our real life problems into discussions- which made the session even more meaning full.
What could have been better…

I would have liked to games we played in the beginning to be bit more detailed and the experiences of the games discussed some what more. And if we had tied down some of our discussions back to those games-it would have been slightly better.

But I understand- we were hard pressed for time and overall, I think we did good in terms of coverage and depth.

Do I recommend this training ?

Yes. I would definitely encourage anyone wanting to learn scrum to attend one of these trainings. It was like reading 5 books in two days and having the opportunity to ask author questions instantly.

 

To me – scrum is a way of life- and if you are coming from a waterfall- its a very different way of life…
To effectively adopt scrum- we all have to change our ways… this is in fact ,I think the hardest part – to change our work habits and to change our beliefs.

These are my reflections on what a developer needs to do to be effective in scrum. Much of it is based on what I understand about scrum not entirely about what I have experienced in scrum.

Iterative vs Incremental development

Consider that you have a manufacturing plant which makes shirts.
You get a work order of 50000 shirts.
What would you rather do ?

A. Make 50,000 collars first and then 10,000 arms next and then…
B. Or would you rather make 1000 shirts and then another 1000 shirts and so on…

I guess you know – I want you to select B. :)
Actually – a part of me wants to choose A- because that is probably more efficient process.
But would you rather have efficiency or mitigate a huge risk ?

If it was only efficiency I was bothered about- I would probably choose A.
But if it was my dime on line- I guess I would choose B.

To translate this into a software development process…
You have to write a CRUD screens for some object
A. Would you rather do the Data Access layer first , and the service layer and then UI layer ?
B. Or would you do the entire layer first and then keep on adding functionality to the product – across all layers

I have always coded as in A. To move on to B- would be a big shift for me personally.
But its difficult to deny the benefits of this approach.
Quick delivery, quick feedback, less wait time for users, validation team gets to test sooner and so forth…

So while A maybe be better for me as developer – B is probably better for the team in general…

Note: In the earlier example- I didn’t suggest a shirt at a time. You need to find your own balance between the two extremes.

So why is this important in Scrum ? In every sprint, you want to produce a potentially shippable product- 50,000 collars aren’t shippable though 1000 shirts are…

Software development is more than coding
Discuss with a developer a development task- She\he will probably not think beyond the coding part.

For us (developers) ,software development is almost synonym with coding. Everything else- testing, configuration,deployment , data migration – all seem so auxiliary.
But in truth- software development is more than coding.
The other tasks- maybe not as mean as coding (but actually in some case, and I would venture to say often- they are tougher and more complex than coding itself !!!)
We (software developers) need to think beyond coding and consider all that happens before and after the software is made.

So why is this important in Scrum ? Because in scrum- you will see the roles getting blurred.
The key is- it’s team’s responsibility to deliver product ,rather than developers responsibility to code and QA to test and RA to get requirements

If you are a developer- do not hesitate testing what another developer did or maybe contribute to the requirement specs. Quite an idea- eh?

Another things is- in one sprint, you will see the whole life cycle of the software run from start to finish- What was traditionally kept for the last- is now up-front all the time.

Repeatable automated testing

Ah!  This has been beaten to death on the blog world- so I am not sure what else can I add to this- except that you need to have some sort of testing strategy which is repeatable and automated.

THIS is your insurance policy against future breakage.
If you live in Florida- you buy flood insurance
If you are in software development business- you write repeatable automated test cases.

So why is this important in Scrum ? In scrum, you will be doing stories , and its more than likely that you will be coming back to the same module again and again in every sprint.

E.g.  you develop a search functionality in the first sprint and then you add more search features in the next sprint. To make sure that you don’t break what was coded in the earlier sprints- you need automated repeatable test cases

The burden of testing increases dramatically in scrum- which is almost impossible to keep up via manual testing.

Sprints are not mini-waterfalls
So we discovered scrum- and decided to do iterations.

But iterations alone- doesn’t scrum make.

If you have an iteration of analysis followed by an iteration of design and another of development- voila !!! You have created yourself a scrum-ish waterfall !!!

Not sure if you are better off or worse off then before…

Develop small. Develop complete. Develop well.

So why is this important in Scrum ? This actually ties back to my earlier point of  doing iterative over incremental development. You have to do all in one iteration to have a shippable product. Analysis or design alone do not constitute a shippable product.

Note- I am very hesitant on this- I still prescribe to the old philosophy of upfront design. I don’t mean design all the way- but still spend some time designing the software upfront and discuss with peers before you plunge in head long

Are you done ? or are you done-done-done ?
The first time , I heard about this was from my manager about 8-9 years ago.
When we would tell him that we are done. He would ask us back – Are you done ? or are you done-done-done ?
If you replied back saying that you are done- but …. He would stop you and refuse to listen more till you took back that you are done.

To be done but not  done-done-done – carries a huge weight of keeping track of what all minor tasks remain. And if you have whole bunch of tasks that need to be done before you release your product- how realistic is your statement that you are done.
So – unless you are not done-done-done- you are not done.

Developers are smart people. The moment they are done with the challenging part of the problem- they want to move on to the next challenge. But this doesn’t work well with scrum.

So why is this important in Scrum ? In scrum- when you are done with a story- you don’t come back to the same story in the next iteration
You need to move on.
And the only way to do is to ask- Are you done ? or are you done-done-done ?

 

Ta da da dum !!!

Just finished reading my first book on Scrum. Boy do I feel better now!!!

We started using Scrum @ work few months ago. Before then I was familiar with Agile Practices but had never used Scrum before . So I did what everyone else did- went along with the flow , read few pages off the wiki picking up things as we go along. That worked for a while, but not for long – it was now time to dive right in.

The title

Scrum and XP from the Trenches

How we do Scrum

How to get the book
I downloaded the free electronic copy from infoQ but if you prefer the traditional style- you can get it from here.

The author

Henrik Kniberg is an Agile coach and based out of Sweden. I think he runs some IT company as well.

You can also check out his blog

The book

Like the title says – it is the author’s view of the Scrum from the trenches. The book is a collection of his experiences over the time as they experimented with Scrum. So it is not about how you should do scrum. It is about how they did scrum.

Each chapter title starts with “How we do…”

The chapters are

How we do product backlogs

How we prepare for sprint planning

How we do sprint planning

How we do communicate sprints

How we do sprint backlogs

How we arrange team rooms

How we do daily scrums

How we do sprint demos

How we do sprint retrospectives

Slack time between sprints

How we do release planning and fixed price contracts

How we combine scrum with XP

How we do testing

How we handle multiple scrum teams

How we handle geographically distributed team

Scrum master checklist

The good.
The whole book is written in first person, with the author narrating his direct experiences with Scrum.  Henrik talks not only about what worked for them but also about what other options you have in doing the same thing , in a different manner. He then also compares the options pointing out why those didn’t work for them.

It is an excellent reminder that all projects are different and so is the context for those projects. There can be no single good answer for all situations. You have to find your own unique way of handling things.

The best part of this book is- it is full of practical advice- you can start using what you learn immediately!!!

It is also a very thin book- you can probably finish this in couple of hours.

The not so good

The one thing I was most curious about Scrum was, how does the testing happen in a sprint. How do we churn out a shippable product at the end of the sprint.  But I didn’t get a very good picture of that. Or maybe I didn’t get to read what I was hoping to read- But then it was the Author’s view point – not the way it has to be.

Secondly, there wasn’t much on XP, – just one chapter . So that was a disappointment. The title led me to believe the book would be evenly distributed between Scrum and XP- but it was not

Do I recommend this book?

Yes. Specially if you are new to Scrum like I am . This was exactly what I needed to get introduced to Scrum. I am now ready for more heavy reading now.

However, if you have been using Scrum already, you will learn lot lesser new things than I did. But nevertheless it will still be interesting to read the narrative and learn how the author and his team practiced scrum.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha