Agile day to day
So far I have talked a little about why we have decided to use agile at Dootrix and what the big picture looks like. Now I want to take some time to talk about the specifics of how it works day-to-day.
Our use of agile is anchored around the principle of delivering working software every two weeks. This means that every two weeks the project owner has something that can be user tested and then provide feedback. This point about testing is the key to understanding why we do things the way that we do.
Testing is never cut
Testing is at the heart of our process. We deliver software; be it a website, a mobile app, desktop software or complex embedded system, that just works. This means that our code has to be vigorously tested and robust. And this also means that the experience of the user is tested and proven to be good.
All of our code is written using Test Driven Development (TDD). Our team analyse the requirements and write the software tests before they write any new code. Only once the tests are written is the code developed. Rather than coding to a requirement each developer writes code to pass these tests. Testing is foundational.
Alongside TDD we run agile user testing. The user stories are considered by the test team. Our developers are then informed as to any user centric code tests that need to be developed to supplement the original tests that came out of the TDD process.
This ‘test first’ approach ensures that we can continue to release working versions of the software every two weeks without being derailed by elongated test phases and endless lists of bugs. When scope creeps and time-lines are squeezed testing is never, ever cut. As a result we deliver software of exceptional quality. It works!
Sprint planning meeting
Each sprint starts with a planning meeting. The principle behind these meetings is that the team, as a whole, owns the project. It’s the team, not a project manager that make decisions:
- How a problem is solved.
- What the estimated amount of time to complete each problem (user story) is.
- What user stories are included in each sprint.
Together the team commit to what will be delivered during each sprint. They sign up to it. They own it.
This is achieve by a process of discussion with the project owner so that all understand exactly what each user story entails and then each team member, individually, assigns an estimate to it. These estimates are put together and a consensus is arrived at.
The next article in this series will look at this in more detail including the fun to be had with planning poker. *smile*
This is the time to have a quick discussion about what happened yesterday and what we aim to do today. The plan is to take 10 mins at the start of each day to get any questions and problems out of the way which enables:
- The team to avoid protracted, and often pointless meetings.
- Individuals to get down to the tasks in hand with all of the resources that they need at the start of each day.
At Dootrix we have found that we do not actually have a stand-up each day. Our teams are, generally speaking, constantly communicating. Maybe we are fortunate to have naturally cooperative individuals. It also helps that the team members are situated close together. Their desks are right next door! Whatever the exact cause it has become clear to us at the moment that we do not need a daily stand-up because there is often nothing new to cover. Instead these sessions tend to happen every two or three days.
Sprint demo and retrospective
At the end of each two week sprint the user stories that were completed are demoed. This serves a number of purposes in the whole process.
- Teams are aware that their stories will be publicly demoed to their peers. This helps to keep them focused, during the planning, on user focused development. The question is asked; “how will this be demoed?”
- Individuals are accountable to their peers. As a team they have signed up, together, to complete the work in a sprint. It is obvious at demo time if somebody hasn’t been pulling their weight.
- All members of the company are invited to demos. This aids transparency and knowledge sharing.
- The sprint demo is generally a fun and social occasion. It is a clear end to each sprint and we have found that it offers some much appreciated down time.
Following the demos is a sprint retrospective. This is the session where the sprint team have a chance to reflect on what happened over the last two weeks and how the process can be adapted, adjusted, and improved going forward.
More detail on the retrospectives will come in a couple of weeks.
Rinse and repeat
This basic pattern of planning, collaborating and reviewing is repeated every two weeks. Sprint by sprint a release is completed. Throughout the whole cycle the process is tweaked so as to adapt to the needs of the team to enable them to produce an ever improving end result.
If you want to discuss how an agile team from Dootrix can help your organisation then please get in touch.
Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.
Code like Commandos.
What software engineers can learn from submariners and special forces. At first glance there might not seem be a lot of similarities, but some recent reading has thrown up some […]