Nethouse has a recurring internal event called Brainday – a day to innovate, a day to learn new things or to do whatever makes you happy. This Brainday we tried to do the impossible – to create a system from scratch in one day. We (Nethouse) had a real business issue we needed to solve and since it was not a very complex issue we decided to try and remedy it in one day. This text describes how we created a method we dubbed extreme agile to accomplish this, not to describe what we accomplished.
The below description of the method we used requires some familiarity with agile practices such as Scrum, Kanban and XP.
The method we created for this was a lightweight agile method dubbed Extreme Agile. The setup was three time boxed sprints of two hours each. Each sprint contained a short planning in the beginning as well as a demo and a short review (or retrospective) in the end, all three five minutes each. Before this we had an hour of defining the requirements and the overall solution. The schedule for the day looked like this:
- 08:30 – 09:30 – Introduction, requirements and overall solution definition
- 09:30 – 11:30 – Sprint 1
- 11:30 – 13:00 – Lunch
- 13:00 – 15:00 – Sprint 2
- 15:00 – 17:00 – Sprint 3
- 17:00 – Final retrospective and end of day
We decided to have all involved people in the same room. The product owners, the developers, the testers and the agile coach. We decided this so the feedback loop would be extremely quick and no questions in requirements would ever be unclear. We also applied pair programming for developing this. Unfortunately we had no testers available, so the product owners had to be the testers as well.
The requirements and solution definition
The requirements gathering was very informal and was merely the product owners describing the problem they had. Some detailing of the requirements were done to have just enough to start the development process. The idea was that the requirements would be detailed as the day went along.
The developers was encouraged to use techniques and patterns they were very familiar with so the focus could be on the development (hence minimizing the visits to stack overflow :-)). Furthermore the focus was on creating the output first so there always would be something demo ready at the end of the sprint that the product owners could see and give feedback on.
The session also included a prioritization of what functionality should be created first. This was at a high level for instance to be able to view the data before editing it or to input data before viewing it.
The sprint planning
At the sprint planning we defined only the basic goals for what the sprint should be – what output should we be able to produce? The goal was defined on a very high level for example: “We must be able to edit data”. We also specified how to test what was produced. To track all this we used a white board. The sprint planning was a total of 5 minutes at the very beginning of each sprint. In the beginning we included less things in the sprint since we did not know the speed of the team.
The demos were a quick demo of what output had been accomplished in the sprint. Any parts that was not completed at the end of the sprint were tracked on our whiteboard. If they should be included in the next sprint or not was left to the next sprint planning.
As for the reviews (or retrospectives if you will) they were also 5 minutes each. They were within the sprint, right after the demo. Each member of the team (product owner, developer, tester and agile coach) was allowed to name one thing that was working good and one point of improvement. Together we then decided to fix one of the points of improvement for the next sprint.
We used a single whiteboard for all the purposes of the day: requirements, prioritization, bug tracking, technical debt, sprint planning and sprint reviews.
Did we succeed then? Yes we did! It was perhaps not the most elaborate system created, but it was usable and with actually just one point of technical debt. This was a great way of getting an initial version that would be usable in the future and extreme agile really matched our needs.
At the end of the day we had a final retrospective for the whole team with the same rules as before: one good thing and one point of improvement.
The positives: the length of the sprints were good, all people involved were in the same room and that pair programming was a must!
The points of improvements: Make sure that the test and developments environments were up and running. This should not have to be dealt with during the day.
When to use Extreme Agile?
Since this was the trial run of this method the recommendations can only be from what I believe to be applicable.
Proof of concept. Creating a proof of concept is as I imagine it the most useful area to use extreme agile. With this you can create this in a very short time with great results, and have fun at the same time.
Hackathon. Hackathons are places where a method like extreme agile also could be used, when the pace is fast and the focus is high.
Kickstart. To kickstart a project extreme agile can be used to take some first steps.
I believe that extreme agile is more applicable in short bursts of development. In a time span of a day or so it would be usable, not in long term developent. This since that would entail some more elaborate tools for documenting and testing which slows down the feedback loop which is one of the main points.
Be focused – make sure that all participators are focused on the task. Unfortunately I had unplanned other engagements that I had to attend to. Fortunately my colleague Björn was able to assist and add some great ideas to the mix.
All in the same room – this was a home run. The requirements were always clear since the product owners were at the farthest on the other side of the table.
Use pair programming – Initially we did not use this method, but when we did we got great results.
Make sure test and development environments are prepared – We did not prepare this and it was a pain to have to focus on this during the day when the focus could have been put solely on the development process.
Use a real problem – It was a winning formula to have a real problem to solve. This was a real business problem for Nethouse we needed to solve. Not a big one, but still a nagging issue that we knew could be remedied.
Continuous integration – At the end of the first sprint we realised that to be able to test this we would need to continuously deployment to the test environment. Unfortunately we had issues with the test environments and were not able to work with this.
Big thanks to Gustav, Björn, Åsa, Patrick, Jimmie and Viktor for hepling out and participating.