I graduated from the University of Bristol with a BSc in Economics. After spending a year travelling around the world I joined Accenture in 2006 where I worked with Government and non-profit clients. ...
Ashni Asher, Consultant
View Ashni now
It's the people that make Berkeley different to other consultancies.
Bright, friendly, down-to-earth people who are both thinkers and doers. Working by your side, as consultants and colleagues, to get the right results.
We’re about being there for our clients when it really matters. When it absolutely has to be right. Doing the right thing is both our ethos and sweet spot. And it’s why clients turn to us again and again.
Whatever your long term career goals, we’re here to support you. Through an open dialogue, we help our people to build the capabilities, experiences and networks they need to boost their careers.
Home > unspun > unspun 26 - Cutting to the chase > Agile
If you work in or around IT you will have heard of Agile Development. You may have direct experience of working with it on a project, or you may only know the name, but it’s hard to deny that it’s an increasingly popular and prevalent means for IT and business teams to collaborate in order to deliver change. This article addresses some of the myths surrounding Agile, and highlights some of the key lessons learned from our experience.
Chances are that if you work in or around IT you have probably heard of Agile Development. You may have direct experience of working with it on a project, or you may only know the name, but it’s hard to deny that it’s an increasingly popular and prevalent means for IT and business teams to collaborate to deliver change.
Agile is a delivery framework that promotes collaboration between development and functional teams for the early and continuous delivery of valuable software. The Agile Manifesto, which sets out the values and principles of Agile working, was created in 2001 by a group of software engineers frustrated by the long lead times and process overheads of traditional “waterfall” delivery methods. As an alternative, they proposed a framework that embraces iterative, incremental software development.
An Agile project has some quite different features from that of a waterfall project. Users and developers will co-locate for much if not all of the project. Change will be encouraged, even quite late in the development. The team may produce little formal documentation (relying on interaction instead) and working software will be demonstrated on a regular basis throughout development. These features are all geared to being responsive and adaptive to changing business situations and ensuring technology directly supports rather than hinders business goals.
But Agile is not in itself a panacea; it requires strong and experienced team members working with great discipline to really get the most out of it. Too much focus on tangible software development rather than planning and management means there can be risks of unconstrained scope inflation, budget overruns and delivery delays.
Over the last eleven years, Agile has progressed to develop a cult following amongst the developer community; which has driven its adoption in many organisations with varying degrees of success. In this article, we look at some of the myths surrounding Agile and highlight some of the key lessons learned from our experience.
Undoubtedly some of the principles of Agile can be beneficial across the vast majority of IT projects – start testing and integrating as early as possible; involve business SMEs and senior users throughout the course of the project and don’t create reams of bureaucracy for minor changes – but these principles are not exclusive to Agile and are part of good project management on any project.
If you can answer ‘Yes’ to the following questions, then it may be that Agile would be suitable for your project and organsation:
If you answered ‘no’ to more than a couple of these, then we would recommend that it may be better to continue with a traditional methodology, perhaps cherry-picking agile techniques where appropriate.
Blind adherence to Agile principles can be a license for chaos. Some Agile ‘fundamentalists’ will argue that you don’t need plans and project managers if you have the right developers. We disagree.
It is essential within an Agile delivery to have strong risk management controls. One of the biggest and most fundamental risk management controls is to have a plan.
Within any project the primary variables are scope, quality, cost and time - Agile projects will tend to vary scope to a higher degree than cost or time. A project manager is required to manage these variables, to ensure overall scope control and to define and manage a plan that delivers within the time and budget allocated. This is not withstanding key activities such as managing quality, risks, stakeholder communications and, if applicable, vendors.
The scale and complexity of the project will determine what level of experience the project manager will require and whether they are full or part-time. It is possible that the project manager has dual roles in the project, but this decision should not be taken without assessing and managing the potential risks.
Our view would be, for any Agile project, to ensure that there is a ‘fit for purpose’ set of risk management controls in place, including a project plan, with a Project Manager appropriately experienced and resourced to co-ordinate and manage the project.
A good principle in Agile development is to understand the minimum set of features with which you could go live in your first release – Agile terms this the ‘minimum marketable release (MMR)’. As a rough rule of thumb, around 60% of the available development effort should be spent delivering these. The remaining 40% of development capacity should be available as either contingency (worst case) or to include additional functionality.
Central to this principle is that you need to understand the complexity and volume of your requirements. Failure to perform a high-quality detailed requirements exercise can result in your MMR being based on a set of user requirements (or ‘user stories’) that are either low quality or not fully broken down. This can then cause slower development due to rework or the nightmare scenario where your backlog of requirements is growing faster than your developers are coding. Indeed we’ve heard of scenarios where the volume of user stories has more than doubled during the development phase; suddenly that 40% contingency doesn’t look so large... We’d recommend validating that your requirements are fully decomposed by defining and agreeing both the high level User Interface wireframes and the acceptance criteria before the iterative development ‘sprints’ begin.
As well as detailed requirements, the application development is dependent on key preparatory work that should be completed before commencing development. This should include the solution and architecture designs and functional and technical standards and guidelines. If appropriate, major integration components (for example web services) should also be prioritised to avoid delays to the application development.
In our experience, completing these preparatory steps is important to ensuring efficient and high-quality coding and reducing the risk of rework or significant expansion in the volume of work.
If deployed correctly, Agile can significantly lower the overall risk of a project and improve stakeholder satisfaction. An Agile project will start to build risky aspects of the solution early – giving more time to react to problems. It will also flush out missed or misrepresented requirements through regular user demonstrations that might otherwise have remained hidden until a User Acceptance Test phase; but it inevitably introduces new risks.
There is an assumption that Agile improves transparency and communication across stakeholders; but there is also the risk that functional teams operate in silos or agile newcomers don’t really understand the new terms either performing inefficiently or reverting to old habits.
The key here is often experience. Our recommendation would be that if you are deploying Agile for the first time then don’t put it on a critical and complex delivery; test it on something smaller first and build some lessons learned within your organisation.
Fundamental to Agile is the close interaction between the senior users / subject matter experts and the delivery team. This will always work best when the teams are onsite together. Collaboration tools can be used to complement this face-to-face time, but if they are a substitute for it then there will be an impact on efficiency. This should be factored into the plans and, wherever possible, mitigated. We would always advise to have these teams in the same location, as a minimum 2 days per week.
In conclusion, Agile can really enable your IT projects to deliver business results more responsively and more quickly, but beware some of the more wild promises of what Agile will enable you to do. It does not negate discipline and rigorous management. If you’re thinking about using Agile on your projects, we would recommend the following:
And finally, Agile is for software. Don’t forget about change management, training, communications and documentation!
Below are some of the key terms used by Agile methods. This list is by no means comprehensive!
The ‘User Stories’ (see definition below) that the team will work on in the future, but that have not yet been prioritised for delivery
Burn up Charts
A means of tracking progress. Typically captured as a graph showing the percentage of User Stories completed
A finite period (typically between 2 and 4 weeks) during which a subset of software is created
MMR/MMF Minimum Marketable Requirements/Features
The minimum set of features with which you could go live in your first release.
A metric in Scrum used to size and estimate Agile projects in terms of units of scope rather than hours/days
The most widely recognised application development framework within Agile
The “Scrum” term for a software development Iteration
A way of defining the functionality required of a system, expressed in language that is clearly and simply understandable by the end user of that system
A traditional software delivery methodology that prescribes containment of activities into contiguous and non-overlapping phases that must be completed before the next can begin (e.g. analysis, design, build, test)
“Blueprints” of the pages of a website, illustrating their contents and functions
Dispelling the myths of Agile Development
We have placed cookies on your computer to help make this website better. You can change your cookie settings at any time. Otherwise, we'll assume you're OK to continue.