Making our developments more efficient
Posted on October 25, 2012 by Matt Clarke
Amaze has been developing software and web solutions now since 1995. Though our development processes have changed over the course of the last decade, our fundamental development approach has always followed the waterfall model and the tools and techniques we’ve employed have been driven by traditional software and project management methodologies.
However, over the last five years the Agile model has been a big catalyst for change in the digital industry. It promised speed, agility and flexibility and above all it may hold the golden ticket to increase productivity. Nonetheless, the struggle still remains that the Agile model only works efficiently if your customer trusts you implicitly and if they have bought into the concept of time and materials. This always remains a challenge as project budgets remain finite and it will continue to present a leap of faith for any customer buying a web solution or software. Nevertheless we persist, we love agile and we believe it can give us the necessary productivity and efficiency gains we just need to wrap it within a traditional fixed price process.
So this is what we are doing
All of our development processes still proceed with the waterfall model, i.e., there is a start, then there are fixed phases and finally, a delivery. At the same time there are capped and managed budgets and delivery dates. As a result, our customers know what they are getting and when they are getting it. When we dig deeper into the phases, we use a mixture of true Agile for development and a collaboration driven approach to get the project into development. I’ll start with the latter to explain how we begin the journey;-
Starting the project is key and beginning it well sets the foundations for its success or not. There are a number of things that we must get right here:
1) Project control and governance
The plan and budget are the fundamental controls in any project. The hardest thing to do is to set out a framework plan for the project when you haven’t even begun your requirements capture or discovery phase. However, this is what we do first. As we begin initial discussions with our customer we use our project planning process to itemise the solution. What I mean by this is that we use our plan to capture all of the discussions that we need to have about how the solution will evolve and we subsequently capture what needs to be discussed, designed and who needs to participate. We then set targets for when these tasks need to be completed and not by how long they will take, setting targets based on experience and then we begin. This forms the basis of our design phase.
Next we document and run workshops and design sessions to hit the targets we set. The plan then goes on to create and determine the governance of the project, ensuring that we don’t lose anything and that we have the appropriate targets and budget controls. As we continue our design and specification process we are then able to evolve our build estimates, team size and run order. Governance goes on to cover more aspects of the project which I will discuss later, but starting it right is our biggest governance step.
2) Delivery and specification
As previously discussed, we use the plan to itemise the project. Itemising addresses all of the discussions about parts of the system, design, and any other questions that need to be dealt with in order to start to specify the solution and allows us to begin to create a framework for our requirements to come together. Each discussion can be grouped into functional and non-functional requirements under our Technical Design activities (TDs) or Creative/User Experience (UX) items. We then start to structure our specification, but this is where, more recently, things have started to change. Our specification is a collaborative knowledge base that our partners, customers and suppliers can all jointly work on to design and specify the itemised elements of the solution. The knowledge base we use for all of our projects is Atlassian’s Confluence. It gives us the necessary collaboration capability to build the requirements, document and database them. At the end of the phase we still attain sign off before we begin build, but the result is a collaborative knowledge base that supports the project and gives the customer, and the team, a clear view of what we are building.
This is where we embrace the Agile model. We know what we are building and how long we have so we are able to define how many sprint windows we will create. The first thing that needs to be to set is your sprint window time. We would recommend two week sprint windows, as this gives ample time for the team of developers to deliver something, but not too much time that we can’t monitor progress against our objectives.
Once the sprint cycle length is defined you can then start to do your planning. To do this, revert to your specification (knowledge base) and look to break down the user stories. The team should then plan around the user stories and this becomes a team approach using the Agile methodology. Essentially, all the team are doing is loading a hopper of work for each sprint cycle which then should be then executed, based on skill, performance and ability. Again we turn to Atlassian, using their Greenhopper product to plan the sprints, load the hoppers and monitor performance against those hoppers. Greenhopper gives us the necessary repository of historical performance, burn down tools and planning boards to do this collectively and efficiently within the team. Here the Kanban approach provides the necessary collective organisation of the team and their status reporting against task.
So during the sprint cycles we can back away from the plan a little and just report progress against sprint. We don’t need to worry about too much detail in the project plan, just key milestones, the sprint cycles and then performance against those sprint cycles. The software does the rest.
During the project we use continuous integration on our builds, managing the build of the software and source control. We have also started to look at automated functional testing, and for this we are looking at platforms such as Teamcity and Selenium testing. We need to do more work to standardise our approach across all our technologies, however automation is key to improving quality and keeping the code base together.
Another area we are addressing at present is the concept of review boards for peer reviewing of checked in code on projects. This sounds bureaucratic, however it is not just essential to sanity check code but also to provide knowledge sharing across the whole solution. We haven’t quite got a full solution rolled out but it is something we are definitely looking to apply to our next round of projects.
This is something often over looked and left to the last minute when it comes to planning. Amaze’s approach is to wrap testing into all phases of the project with the test plan beginning at the specification phase of the project. We focus on acceptance criteria and unit testing with the final wave of alpha and beta testing being performed by independent teams. Again we turn to Atlassian and the Jira platform to manage issues as they are raised as well as to ensure that the correct fix, deploy and re-test cycle is provided. It is vital that all of our projects are fully tested independently for security, cross platform/device, performance and load testing as well as for any compliance requirements such as QCI.
5) Project Governance
Finally we turn back to the overall project governance and programme management. I mentioned this at the beginning of the post, but this is truly the most critical function of any project. Failure to build the right set of principles into the project governance leads to projects losing control and often overrunning. These are our core principles:
- The team own the solution and the project, not the project manager. The project manager must ensure joint and joined up ownership is maintained throughout the project.
- Begin each week as if it’s the last. Keep the pace up on the project and ensure that you are delivering every step of the way.
- Budgets and hours burnt are key, make sure time is not wasted and look at productivity throughout. This includes quick decision making, collective ownership and delegation. Don’t be afraid to offload heads from your project if they are slowing down decision making or complicating things, smaller teams can deliver much quicker.
- The plan must be target driven not reflective. Ownership and weekly deliverables should be driven by the plan.
- Use the tools to report status, removing the need for reports and spreadsheets that are often not read.
- Ensure smooth and open communication across the whole team and your customer. There should never be surprises.
- Deal with problems and never put your head in the sand. If something is difficult, it is most likely a problem that is not going to go away. The quicker it is dealt with, the lesser the impact.
- See the big picture. It’s not just next week’s onsite discovery you need to worry about, it’s the end game, the live project. Don’t lose sight of what we are here to do.
And so to conclude,
Agile is not everything and it will not fix the majority of projects out there, particularly the fixed price ones. It’s not a magic wand; however it has brought about some good tools and collaborative approaches that encourage positive shared ownership for the project deliverables. Each project should be looked at from an ownership perspective, we should look at production values and how we streamline delivery using efficient approaches in order to both share information and to manage how we assign tasks to the development team. The teams themselves need to be exposed to this thinking and be able to contribute to the direction of the project. Above all, projects need to stay results driven, be very efficient and have shared ownership in the end game.