The 2-day session took place in Munich city centre and was led by Boris Gloger, a Certified Scrum Trainer from Germany. The class was a mix a people from various industries and varying degrees of experience with Scrum.

So what happened during these 2 days?

As you would imagine, the first day was a gentle introduction to Scrum: the origins, the principles, the life cycle, the key vocable and so on. At the end of the day, I felt it was a nice but important refresh of the basics.

The second day went a lot more into details as we went through every stage of the Scrum life cycle as well as the different roles in Scrum. Being sucked in projects at work, I took this as a benchmark for the various projects I am involved in. The output is a Scrum@Ciao impediment backlog where every ScrumMasters in the company can add items that the organization needs to tackle in order to truly do Scrum.

As far as the actual content of the training is concerned, there is not much that can be said: the scope was pretty clear and I think Boris did a good job in the way he presented: the flow of the 2 days was well thought and done in a logical manner so that every participant would make connections between the different areas.

On the form of the training, there were 30 attendees that were then split into groups of 6 people. I thought the room was not suited to welcome so many and as such would either expect less participants or a bigger room. I appreciated a lot the little games that we had to play at the various stages: the Martian brochure, the Ball Points, the Scrum simulation and a couple of others. It really helped getting a feeling of the themes that were discussed.

My 2 days summarized in 3 points:

1. I believe now more than ever in the power of Scrum vs. traditional methodologies in software development but also in other areas.
2. I realize that we are only doing parts of Scrum and that it is my responsibility to contribute to reducing the barriers that are preventing us from adopting all Scrum practices.
3. I realize we need to offer more training to the various teams about Scrum and be creative in the way we are going to do this.

Overall a very positive 2 days with only some minor things that could have made the event extraordinary. I recommend the ScrumMaster Certification to anyone involved in product development (software or not). I can assure you, you will have a completely different perspective on product development when you come out of it!

PS: The writer’s block got me for this piece… Hence the little delay! :)

Could it be due to the fact that my privacy settings prevent Facebook from using this data for advertisements? I don’t know, but that seems the only logical reason to me!

Well done Facebook!

It has been a continuous learning process so far and these 2 days could be a great chance to get a level further. Here is in short what expect from it:

1. Although I think I have a good theoretical knowledge of Scrum as well as practical experience, I expect this session to be a nice refresh especially focusing on the role of everyone in a Scrum team.
2. This may be a training - it is for me more of a talking opportunity: the unique chance to share ideas and experiences with others who are enthusiastic about building software differently. I expect a lot of discussion, you don’t get that reading books.
3. I don’t expect an answer to all the questions I may have, but at least some food for thought to get me started. Scrum in distributed teams is a topic I will try to bring up as it is very relevant to the environment our development teams are working in.

I am very much looking forward to it and will be sharing my thoughts here after the 2 days.

Arrived at the local airport, me and my fellow colleagues quickly made our way through the passport check. It was around 13:30 and the sun was shining. It was quite a hot day actually, I remember having to take my jacket off.

Peter is leading the way out of the airport, where our taxis will be waiting for us. It was just 5 of us, instead of 7, as 2 got caught in Munich and couldn’t make it for the trip…

We arrive outside the building and after about 10 minutes, a taxi driver approaches us and tells us he is there with a colleague to drive us to our offices. We’re ready to go, the first 2 decide to jump in the car. The 3 remaining, including myself, will take the next one. The driver is actually already here and comes to us directly: “is it just the 3 of you?” he asks in a mix of Romanian and unclear gestures. We nod, unsure about what the driver was attempting to ask…

The driver looks puzzled. He decides anyway to take us to his car which was parked a few meters away. Looks like we’re ready to go too: luggage in the boot and we all take place. I get the front seat. He takes his radio and seems to tell the taxi company’s HQ that all is okay and he is about to leave…

A woman answers back. The taxi driver replies. She asks another question. The taxi driver answers. He looks at me and tells me something that didn’t make much sense: “blabli blublu blala college blabli bla machina…“. Huh? He tries again… Mhm… It seems another taxi is on the way. Fair enough I say. He starts the engine and takes the direction of the our offices. Finally!

After 5 minutes and more radio conversations he stops the car. We are all wondering what is going on… He looks at me and tells me something which I understood: “you guys have actually booked 3 taxis and only have used 2…“. I can’t believe what I’m hearing. “My colleague is already on the way, he should be here in 2 minutes. 1 of you will have to get out of this taxi and go with him, so that all 3 taxis you have booked will be used“.

I tried my best to talk to him but unsuccessfully: 2 minutes later I had to resignate. I stepped out of the car and went to the other taxi, just so we use the 3 taxis that were ordered, and they can probably make an extra Leu or 2.

Original on the Nike Football blog.

Is it when you picked a methodology like Scrum or XP and follow the associated principles? Is it when everyone in the development team has read the book Agile and Iterative Development: A Manager’s Guide? Is it when you feel totally powerless when asked to get back to a more traditional approach like Waterfall?

According to the above mentioned blog post, “more than practices are required to be agile”. In essence, doing daily stand-ups, having a product backlog, drawing an iteration burndown or doing continuous integration alone is not enough.

Beck argues that all “practices, values and principles” need to be part of the mix in order to be really agile. (read more on Beck’s views over here). So where to start? How do I start being Agile? Really there must be a point to start from…

Do you start with communicating Agile principles around? Do you buy software that allow to manage Agile life cycle products? Do you start doing daily stand-ups? Do you start doing continuous integration? Or do you start being Agile with a small team of talented developers on a small pilot project to get the first feeling of what it takes “to be Agile”?

That’s a lot of questions and the reason why I cannot seem to answer them is that after all being Agile may be something you feel rather than something you teach or learn. From this perspective, I believe learning by doing i.e. using a specific methodology with carefully picked practices would be a good way to get started, get a feeling of Agility, one Sprint at a time.

By the way, beginning of June I will be attending a 2 day training in order to officially be certified Scrum Master. Does that mean I’ll be Agile?

“An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices.”

I see several goals to a Sprint Zero, and this list not exhaustive:

1. Set the development environments for the entire team
This post is a great example of what can be achieved to prepare development environments. This will basically reflect the process you decided to follow within the team or organization.

2. Analyze the current Product Backlog and clarify obscure stories
At this stage the Product Backlog should contain the initial set of stories prioritized by the Product Owner. The development team can already go through every story and prepare questions. Having the big picture will also allow the team to make better architectural decisions.

3. Get familiar with the code or current system architecture
In an organization with a large number of developers and an even larger number of intranet tools, it might often be the case that developers have never worked on a particular tool. In order to flatten the learning curve a little, the Sprint Zero is be the perfect opportunity to analyze the code and DB structure.

4. Start the team dynamics before development starts
It’s the perfect opportunity for everyone to get to know each other and also repeat the Scrum processes (define Scrum times, “done” criteria etc.)

I put this into practice about 1 month ago and had an amazing feedback from the team. The application was a CRM tool which we now need to support. As it was previously developed and maintained by another business unit, none of the developers had any knowledge whatsoever about the tool - no real documentation was either available.

The next 3 Sprints we have worked on since then have always delivered 100% of the points taken during the Sprint Planning.

Note that this could also be used for external companies contracted for a specific job in order to learn the in-house code conventions, internally developed frameworks and so on.

Interesting links:

http://www.think-box.co.uk/blog/2006/06/iteration-zero.html
http://www.danube.com/blog/dan_rawsthorne/sprint_zero

What are the challenges?

1. It’s hard to get the team to speak up
2. It loses interest after a few sessions (”that retrospective again…”)
3. Get the team to understand the value of these retrospectives

As mentioned earlier, generating informal communication in distributed teams is a tricky one. When local teams get to go for lunch, have a coffee break and the lot, it gets all of sudden a lot easier to speak-up during retrospectives. The case for distributed teams is not so obvious.

Are there any solutions?

I guess there are at least 2 ways to solve the above challenges: try to generate informal communication, or be creative in the way the retrospective is lead:

1. Explore new ways of leading the retrospective - do it anonymously, do it via stand-ups (video conferencing), ice breakers at the beginning of the session. The goal is to set an environment that makes it easy for everyone to generate a discussion.
2. Find new agendas for every sessions - be it teamwork, code quality, communication, processes etc. I find the “what went well”, what went wrong” questions to be very vague and not prone to engage discussions. Being more specific gives direction!
3. Make it clear what the goal of the session is - “in this session we will reflect on how we can increase the quality of our product”
4. Follow up on actions once the session is over - Usually the session generates a list of actions the team needs to follow in order to solve the identified issues. Everybody in the team needs to keep them in mind on a daily basis!

As a Scrum Master I need to spend some more time on this part of the Sprint: plan it better together with the team, get value from it to increase developer and customer satisfaction.

Interesting links on Agile Retrospectives:

http://blog.viocity.com/blog/_archives/2008/3/6/3563380.html
http://www.youtube.com/watch?v=qqtPZYigfNI (Google TechTalk)

The latest version of Gmail allows you to tag your emails with labels, which can help you organize them as you wish: from “important” to “Facebook invites” via “Holidays”, the possibilities are endless…

How do I turn Gmail into my favourite to do list manager? Very simple:

1. Create tags of the priorities you want to give to your tasks

I have chosen “1 - To do“, “2 - To do” and “3 - To do” and gave each of them unique colors. Flashy red for the important stuff, and cold blue for tasks that are not so urgent. Only your creativity will stop you here (Note: the tag “important” is not available - sign a native Gmail to do list may be in the works?)

2. Send emails to yourself

As you see below, I send emails to myself with actual tasks as subject. I then tag this email to give it a priority. When a task is done, I remove the tag and archive the email.

This of course lacks some functionality other to-do list managers may have: set deadlines, set reminders etc. You may also argue it is a bit of overhead. However I have found it be very powerful and efficient to get things done. The conversation feature in Gmail also comes nicely into play here to write update about a task’s progress.

The Lifehacker blog has a lot more about managing to-do lists in general and how to get things done.

How do you manage your to do lists?

You can follow me on Twitter at this address: http://twitter.com/njamin

As you can see, I currently use it as a way to publish information like articles I find interesting, some cool tips, things I am doing at work, share some thoughts and share the love (sometimes hate, too). That’s the one side of it.

The second side is that I can follow other people. People who for example focus on posting technology news, links to project management articles, French cuisine recipes, photography tips, computer games reviews and so on… And that’s the interesting part: I get these short messages directly delivered to me (per IM).

On one hand I am always getting content on stuff I am interested in, and on the other hand I share my discoveries with other people - the former being the most addictive part of it all. If you are keen on learning new things, Twitter could be a good place to start!

My verdict so far - Yes to Twitter, but abusing the service could impact severely on productivity as there is a lot of noise on Twitter! Select carefully who you are going to follow!