Sign of life
I just wanted to let all of you know that this blog is far from dead. The reason for the recent *cough* quietness is that I'm starting my own freelancing business as IT Consultant and Agile Coach. As if that wouldn't be enough me and my wife are also shifting to Germany.
Bottomline: It'll take a couple of months until we'll be settled again. As soon as that is the case, I'revive this blog.
Till then, hang in there!
The Effects Of A Stable Team
I'd like to talk about a few things I realized in regards of having - or not having - a stable team.
Me and my team went through a lot of instability for slightly over a year. No one got fired or something like that but as the company grows and demands shift, employees move between teams. Due to that I was without a permanent team for a while and just recently got back onto stable ground.
While being on the long road back to stability I realized many different aspects and nuances - some obvious, some not so - that come only with a stable team. I've come out of this with the resolution to prevent any further change to my team if by any means possible.
The ideal sprint length
When I started with Scrum, I was very cautious. I thought that with all these changes and the new mindset that had to settle, the transition would be easier if I started with longer sprints. Back then I started with three week sprints. Now, this length is perfectly well within the commonly agreed upon boundaries. Certainly the three week sprints didn't do any harm but since then I shifted to frist ten day sprints, then one week sprints and I have had much better results with shorter sprints.
I've isolated a couple of reasons why I believe shorter sprints result in higher quality and higher velocity that I want to share:
First, we had a release cycle of roughly two to three months. Having three week sprints simply gives you very little "wiggle room". There too few sprints for any mayor course correction! Mind you, no change permitted within a sprint! With only three to four sprints in a release there is hardly any chance to start with a rough idea at first and custom-fit it during the release by refactoring those parts that did not work. With shorter sprints you simply have more reviews and hence, more feedback loops.
Successful offshoring part 4: Independence
In this series on successful offshoring we already spoke about time(zone) management, the important role of the coordinator and advisable steps during the preparation phase.
Next in my discussion on how to do offshoring successfully is independence. You have to make sure the development team in the offshore location can work as independently as possible.
Like the earlier articles it is equally important to deal with the subject of independence in the planning phase of a project, but also each and every day of its lifetime.
Pen & paper Scrum – 10 days edition
True to the spirit of continuous improvement I just created new printout templates for a Sprint Backlog and a Sprint Burndown Chart for ten-day sprints with pen & paper Scrum.
Hope you find them as useful as I do.
If you're irritated about what pen & paper Scrum is refer to the original article.
Successful offshoring part 3: Preparation
In this third article in my series on successful offshoring I will discuss the preparation of a project that involves a team at a co-location and present several steps to ensure a smooth start.
I give you some measures to keep the project on track and inform you about early warning signs.
If you missed the initial articles which handled the added complexities of time(zone) management, or the second one talking about the role of the coordinator, I recommend you click one of the the links and start there.



