Umgezogen - moved

Ich schlage mich schon seit Jahren mit der Idee herum, mehr über Softwarethemen zu bloggen. Aus Zeitmangel bin ich leider nie dazu gekommen. Da ich aber im Sommer zu Atlassian wechsle, um dort den coolsten Job der Welt zu machen, habe ich einen neuen Blog angelegt:
http://www.svenpet.com

From now on I will be blogging all software releated stuff here:
http://www.svenpet.com

10 years Agile Manifesto

Thank you Ken Schwaber. You made agile very popular with Scrum. But why is scrum so successful? Maybe because it concentrates very much on processes? This is an easy target. Everybody that was doing software knew, that the waterfall process didn't fit for the software development... and Scrum made it very easy for software developers.

But now we developers recognized, that not just changing the process to scrum makes us agile. If you read the 12 principles of the agile manifesto, you read something like:

Continuous attention to technical excellence and good design enhances agility.

Unfortunatly Scrum doesn't cover any technical software aspects. We should do TDD or follow coding conventions. Yeah we know all that. But there is actually nothing telling us each day: "Have you written enough tests?" or "Have you chosen the names wisely for your variables?" or "Has your last code being reviewed?".
Some very smart people like Uncle Bob have some suggestions how we can turn the steering wheel a little bit in the technical direction of the manifesto.
But don't understand me wrong: Scrum is great and has brought the agile mindset to a lot of people. We just have to recognize that Scrum does not totally equal Agile.

How we do agile

I always have problems to explain the management how we do agile. There is a big process in my company defining how we develop our products... and it looks a little bit like a waterfall process. But we are doing agile in the software department.
I came across a great presentation tool. I clicked together the following presentation in two hours trying to explain how we do agile and how this fits into the overall process.
It is not the whole story... but I'm working on it. For now, enjoy the presentation!

Distributed Agile@myCompany on Prezi

A case study: Scrum with outsourcing teams and fix prices

Since 6 months we are using scrum together with our outsourcing partner. We have the advantage that our development partner works only 60km away from our office, so we can meet once a week in person. In this blog I want to share the experience implementing a scrum-like process with distributed teams, especially with external development partners.

Motivation:
After implementing scrum into our own processes, we wanted to port the success we experienced to our external team (outsourcing partner). We had a lot of luck, because our partner likes to try new things, so we didn’t even change the contract.

Teams:
We separated our work into projects, so the two teams worked on different parts of the system. This made life much easier, because we worked on different branches and the code was only been merged at the end of each iteration.

Iterations:
We decided that a two week iteration length would keep the merge costs relatively low. We made the daily stand ups separately but stayed in contact for questions. At the end of an iteration we were visiting our partner for a project presentation and a small retrospective. Unfortunately we had no resources for placing a project manager into the external team that could discuss issues in the daily stand up each day. A member of the external team filled in that role as a “proxy”. That went quite well, because he also wrote a specification document at the beginning of the project for us.

Tools:
For quality measurements we used Atlassians Cruicible for making “code reviews” each iteration. That worked pretty good and we found some design issues we would have missed by just looking at all changes at the end of the project.
We were using a continuous integration server (Hudson) with some static code analysis turned on (checkstyle and findbugs) to catch the obvious bugs.

End of the project:
Even though we agreed on a fixed price and feature set at the beginning of the project, we were able to change the requirements and discuss them all together (AGILE). We only had to agree on a prize for the new requirements or decided which requirements were not necessary anymore.

To improve:
We would like to use “Skype” for daily stand ups so the understanding for each others problems will be improved.

Conclusion:
Scrum works also great with external partners and fix price projects. But only if you have an honest relationship and using the right tools!