Our Agile development teams are expert, cross discipline software engineers. From embedded systems, through desktop software and into native mobile development dootrix are uniquely placed to augment existing software and develop new solutions for your organisation.

Published

By:
On: 17th January 2013

Tags

Agile at Dootrix

Following on from last weeks article about how our agile teams operate at Dootrix I thought that I would offer a little more detail on the reasons why we chose agile and how we implement it day to day.

Our overriding objective is to deliver something to the project owner / client, that works, every two weeks. This has a number of positive effects on both the quality of the deliverable and the team that is working on it:

  • The project owner / client stay involved.
  • Project scope and priorities are continually assessed.
  • The team remain engaged and feel a continual sense of achievement.
  • Testing is never forgotten or cut back.

The role of project owner

At Dootrix the role of the project owner is vital. This is the person in the team that owns the project. They can make decisions about scope, answer questions about deliverables, clarify ambiguity when it arises and they understand the end users or customers of the deliverables. This works best if the project owner is the actual client.

However, this isn’t always possible of course in which case a member of the Dootrix team, not in production, is appointed project owner and it is their job to act on the clients behalf. This does create some extra admin and slows things down a little but seems to be an adequate second best setup. An internal product owner only works if they have the authority to make a decision on the behalf of the client. This is very important.

Sometimes, a decision is made that the client doesn’t agree with. This is inevitable. But we are only ever two weeks away from an opportunity to correct such a decision and it actually serves as a good prompt for the client to take on the role of project owner themselves.

Managing scope creep

Battling scope creep is a challenge that is faced by all project managers. Scope creep, in my experience, is often driven by the client but this is not always the case. Often the team at the coal face on a project will develop ideas for enhancements as they go through the design and build process. Project managers all know that an enthusiastic team will deliver a better outcome. This is the only type of team that will introduce ideas for enhancements and so how to keep a lid on these additions to the scope, while not stifling the teams creativity and damaging morale, is a genuine issue.

These ideas, together with new ideas and changes from project owner are added to the project backlog along with all of the other items (stories) that are currently in the agreed scope.

It is inevitable, as time passes on a project, that priorities will change. A new idea, a new piece of technology, some new feedback from the users or simply the process of designing and building something can revealed that the initial approach wasn’t quite right. The inevitability of such changes can be a major headache for a traditional project manager. However, when running an agile process it does not present a significant problem.

All of the user stories that make up the agreed scope are placed, in order of priority, in the backlog. Every two weeks, at a sprint planning meeting, we decide what stories will be included in the next sprint. Any new stories are explored and explained in this meeting. This results in the project owner having a full understanding of the implications in time and cost of their new ideas. Under agile scope does not creep instead it evolves. This is the expectation from the beginning and so dramatically improves the dynamic between the team and the project owner.

Engaging a team on a protracted timeline

Projects often suffer as a result of long timelines. Teams will often do a lot of background and backend work first to lay the foundations for the whole project. Decisions that affect the whole project are made very early on and, on large projects, can be very costly to change.

Another problem with protracted timelines is that the production team have to wait a significant period of time before they feel like they have achieved anything. We all like to achieve, it makes us feel good. This sense of achievement drives our engagement to continue to achieve.

At Dootrix we deliver working software every two weeks. Each iteration will be light on new functionality but:

  • It works.
  • It’s complete.
  • It’s testable by a user.

To achieve this we only make decisions about an approach when we need to make them:

  • We do not second guess the future.
  • We do not build with future enhancements in mind (except in very specific circumstances.)

Our assumption is that the scope, as we understand it now, will evolve. As such the principle idea is to always implement the simplest solution to the problem that is in front of us.

Of course, this does mean that some rework is required from time to time but the benefits of not making early mistakes, and having an engaged team, heavily out way this potential problem.

Testing and the power of TDD

Clients do not understand testing and, in general, they do not like to pay for it. However, testing is vital and if it is cut then the deliverables suffer badly.

A common project scenario is as follows:

  • Project scope and timeline set with a testing phase at the end.
  • Project scope creeps but the client does not want to spend any more money and expects the timeline to remain the same.
  • Client is happy with your flexibility.
  • Time is remove from the testing phase of the project so that the delivery date can be met.
  • Final deliverables are sub standard.
  • Client is unhappy.

At Dootrix our agile process is underpinned by Test Driven Development (TDD.) So, not only are our deliverables tested as part of every sprint (every two weeks) but each piece of new functionality is designed with TDD. This means that the tests are written first and then the code is written to pass those tests. This approach ensures that all new functionality is thought through fully and designed properly before any code is written. With testing at the heart of the process sub standard deliverables are never the end result.

Solving project management problems

I had a fixed set of problems with projects that I had observed over the years. Implementing agile has gone a long way to helping see those resolved. Our process is being augmented and adapted all the time as we learn, together as a team, what works and what doesn’t.

Next we will look at how agile works day to day as well as some of the tools that we use to help us along the way.

If you are interested in engaging an agile team from Dootrix get in touch for a chat.

Comments

No comments

Leave a comment

Catgories



Get in touch with Dootrix,
we’d love to help

Call: +44 (0) 2392 001 990
Email: help@dootrix.com

Or, get directly in touch with one of our directors

Rob Borley - Director

rob.borley@dootrix.com

Kevin Smith - Director

kevin.smith@dootrix.com