Podcast available for download with this article click here.

We’ve been developing software and web solutions now since 96. Our development processes have changed throughout the last decade, however our fundamental development approach has always been waterfall and the tools and techniques we’ve been using have been driven by traditional software and project management methodologies.

In the last five years Agile has been a big catalyst for change in our industry. It promised speed, agility and flexibility and above it may hold the golden ticket to increase productivity. However the struggle still remains that Agile only works efficiently if your customer trusts you implicitly and is bought into the concept of time and materials. This always remains a challenge as project budgets remain finite and it will continue to remain a leap of faith for any customer buying a web solution or software. But 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 our development still remains waterfall. i.e. you have a start, you have fixed phases and then you have a delivery. Equally you have capped and managed budgets and delivery dates. Our customers know what they getting and when they are getting it. However when we dig deeper into the phases we use a mixture of true agile for development and a colloaboration 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 starting any project 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 key fundamental controls in any project. The hardest thing to do is set out a framework plan for the project when you haven’t begun your requirements capture or discovery. However this is what we do first. Immediately as we begin discussions with our customer we use our project planning process to itemise the solution. What we mean by this, is that we use our plan to capture all the discussions we need to have about how the solution evolves, we capture what needs to be discussed, designed and who needs to participate. We then set targets by when these tasks need to be completed, not how long they will take. We set a target based on experience and then we go for it. This forms the basis of our design phase. There are technical design(TDs) activities or create/ux (UXs) design activities. We then document and run workshops and design sessions to hit the targets we set. The plan then goes on to form the governance of the project to ensure we don’t loose anything and we have the appropriate targets and budget controls. As we continue our design and specification process we then are 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) What are we delivering, what is our specification?

As I discussed above we use the plan to itemise the project. Its worth discussing itemising a project and what we actually mean. Itemisation means all the discussions about bits of the system, design, questions and answers that need to be dealt with to start to specify the solution. By itemising the project what we are doing is starting to create a framework for our requirements to come together. Each discussion can be grouped into functional and non functional requirements under our TDs or UXs items. We then start to structure our specification but this is where things have changed more recently. 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 our projects is Atlaissions Confluence it gives us the necessary collaboration capability to build requirements, document them and database them. At the end of the phase we still 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.

Next up is the build

This is where we embrace agile. We know what we are building and we know how long we have. So we are able to define how many sprint windows we have. The first thing to set is your sprint window time. We recommend two week sprint windows, this gives ample time for the dev team to deliver something, but not too much time that we can’t monitor progress against objectives.

Once the sprint cycle length is defined we can then start to do our planning. To do this we revert to our specification(knowledge base) and look to break the user stories out. The team then plans around the user stories. This is a team approach using the agile methodology. But essentially all the team are doing is loading a hopper of work for each sprint cycle to then execute, based on skill, performance and ability. Again we turn to Atlaissions 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 off the plan a little and just report progress against sprint. We don’t need to worry about too much detail in your project plan, just key milestones and the sprint cycles and performance against those sprint cycles, the software does the rest.

During the project we use continues integration on our builds so we manage the build of the software and source control. We are also starting to look at automated functional testing. Here 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 improve quality and keep the code base together.

Another area we are also addressing is the concept of review boards for peer reviewing of checked in code on projects. This sounds bureaucratic, however it is 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 its something we are definitely looking to apply to our next round of projects.

Testing

Often over looked and left to the last minute to plan for.  Amaze’s approach is to wrap testing into all phases of the project.  The test plan starts up 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 either within Amaze or externally via our partners. Again we turn to Atlaisson and the Jira platform to manage issues as they are raised and to ensure the correct fix, deploy and re test cycle is provided.  It is also key that all our projects are fully tested independently for security, cross platform/ device, performance and load testing and any compliance requirements such as QCI.

Project Governance

Finally we turn back to overall project governance and programme management again.  We mentioned it at the beginning of this article however it is the most critical function of any project. Failure to build the right set of principles into the project governance leads to projects loosing control and often overrunning.  So these are our principles..

1) 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 on the project.

2) Start each week as if its the last.  Keep the pace up on the project and ensure we are delivering every step of the way.  There’s not time for last minute saloon on any project this is not University.

3) Budgets and hours burn are key.  Make sure we are not wasting time and we look at productivity throughout.  This includes quick decision making, collective ownership, delegation. Don’t be afraid to off load heads from your project if they are slowing down decision making or complicating things. Smaller teams can deliver much quicker.

4) The plan must be target driven not reflective.  We need to drive ownership and weekly deliverables using the plan.

5) Use the tools to report status, removing the need for reports and spreadsheets that are often not read.

6) Ensure smooth an open communication across the whole team and your customer.  There should never be surprises.

7) Deal with problems never put you head in the sand.  If somethings difficult it is most likely a problem that is not going to go away the quicker its dealt with the lesser the impact.

8) See the big picture.  Its not next weeks onsite discovery you need to just worry about, its the end game, the live project.  Don’t loose sight of what we are here to do.

So to conclude

Agile is not everything and will not fix the majority of projects out there, particularly the fixed price ones.  Its not a magic wand, however it has brought about some good tools and collaborative approaches that encourage good shared ownership in the project deliverables.  Each project should be looked at from a ownership perspective, we should look a production values and how we streamline delivery using efficient approaches to both share information and to manage how we assign tasks to the development team.  The teams themselves need to exposed to this thinking and able to contribute in the direction of the project.  Above all we need to stay results driven, very efficient and share ownership in the end game.