How we do agile at Dootrix
At Dootrix our software teams using the agile framework. In all of my previous roles as a developer, consultant or project manager a variant of Prince 2 has been the project delivery mechanism or choice. So, now that I run my own shop, why have we opted to use agile instead?
Starting from scratch
When setting up Dootrix I wanted to make sure that I attempted to overcome some of the shortcomings that I perceived elsewhere in my career. I have been involved in both product and project delivery in big and small organisations and the difficulties have always been centred around the same issues in each scenario.
- Team collaboration.
- Team ownership of the deliverables.
- Scope creep and the subsequent slippage and battle to maintain quality.
I’m not saying that these issues are directly related to the organisations that I was working in or the use of variants of Prince 2. They are simply the three main areas of difficulty that I came up against again and again. Starting up Dootrix, with no baggage or history, has given me an opportunity to try and do something to prevent these issues from manifesting themselves.
Most of the problems I had come up against on projects were a result of teams struggling to understand their role on a project. The project manager always found themselves in the role of project owner. Acting as a go between between the client and the production team the PM would often find themselves making decisions that they were not best placed to make and making compromises on both the clients desires and how the production team wants to go about the project. Ownership of the client relationship, ownership of the spec, ownership of the production team, ownership of the solution and internal ownership of the final deliverables all tend to fall on the project manager. Over time the technical and design expertise of the production team are lost in an apathetic me-laze of just doing what they are told to do.
Agile turns this on its head. The focus is on the team who are delivering the project with the product owner, preferably the end client, very much part of this team. Together, the team decide the scope, the timeline and how the solution is crafted. The team own the solution and commit to a timeline. As a result the team care about what they are delivering thus increasing the quality of the final outputs.
Clients still try and squeeze in new functionality (scope creep) but as they are part of the team they understand and accept the consequences of this from the very beginning. There is no battle between managing the teams time and the clients expectations because everybody is on the same side.
Agile also prevents long development cycles of little tangible progress. Every few weeks we have working, testable software. We have achieved something. This is a fantastic tool to keep the team engaged and interested in the project.
Here ends the theory.
How we run agile projects
Over the next few weeks I will be posting on how we do agile at Dootrix. Of course, the nature of agile means that we are constantly refining our process to try and optimise it for our needs. The way we do agile will be different from how others use the toolset. Maybe a better description in this case is how we currently run agile projects.
Our sprints run for two weeks. Each sprint starts with a sprint planning meeting. We have daily stand-ups. We end each sprint with a sprint demo and sprint retrospective.
In the coming weeks I will cover:
- The tools that we use.
- Sprint planning meetings, planning poker and the use of story points.
- Running a sprint and daily stand-ups.
- Sprint retrospectives, demos, and analysing velocity.
I do not claim to have the perfect solution and would love your feedback on what we are doing as we go.
Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.
Why testing should be about getting your feet wet
When it comes to designing and developing successful products, quality plays a pivotal part in the process. Effective testing ensures the product achieves the ambitions that stakeholders desire. […]