Moving beyond the principles of Agile Software Development
Phil Ealey Agile evangelist IT PM / Software Development-Delivery Manager Following Agile principles doesn't guarantee effective practice especially around handling change but reflecting and understanding why these principles exist can lead to improve practice
Having worked with Agile from the earliest days as the industry evolved from Waterfall and the need for change driven mostly by numerous high profile failures, we find ourselves in a paradigm called Agile. However some projects miss the often unsaid goals of the Agile approach and in doing so cause projects to cost more and take longer than they should. Agile principles describe a way of working or in other words how to be Agile and some believe that just by implementing these, they have become Agile enough but in doing so they can miss key context and it is this context of 'why we do them' which can make a huge difference. Understanding the why for some will not only lead to a better understanding of the principles but also better outcomes for businesses. This what I see as the 'why' which are associated with 'change' The business perception of what a successful outcome looks like often changes during the project and the team needs to embracing change if it is to keep track with the evolving company's vision and produce a successful and not obsolescent outcome Change is cheaper and easier the earlier that is discovered Plan the order of work so that late discovered changes are as easy and as cheap as possible to implement Few changes are free, so make change visible and accountable Avoid complexity where possible as it is expensive and slow to develop and very expensive to change Releases of working software drives company critical feedback for change The main objective is success (which can be measured by the degree of Customer satisfaction, achieving lowest time and cost to deliver and attaining an adequate quality) These along can't bring success as software development isn't just about these factors and other aspects must also be optimal. Expanding on Why.
The business perception of what a successful outcome looks like often changes during the project and the team needs to embracing change if it is to keep track with the evolving company's vision and produce a successful and not obsolescent outcome. Very few successful software projects finish as they start out. There are a number of reasons including: The company doesn't have a full grasp of what it's trying to build and learns as it goes along giving rise to change The company as it sees early releases realises these don't match their expectation and feedback creates change The market, technology or revenue opportunities change whilst the project is underway and the shape of the deliverable need to change to retain a competitive advantage The company's internal needs change forcing change to the deliverables. As a result it is important to not just embrace change but to implement change as efficiently as possible. Change is cheaper and easier the earlier that is discovered Like finding bugs, the earlier change is discovered the less refactoring and waste is caused. Early discover doesn't mean that the change has to be incorporated straight but may instead be rolled out as part of the backlog at the appropriate time. Plan the order of work so that late discovered changes are as easy and as cheap as possible to implement In general, requirement elaboration or coding work should be delayed as much as possible. Features and Epics should be sketched out to give the team a sense of direction but the more detailed and time consuming work should be planned for as late as possible. Elaborating User Stories in advance or writing code is often attractive but a change may come along invalidating this work and causing many hours of User Story generation, coding and testing to be thrown away. There are exception to this guidance around Architecture, Frameworks and Non-functional requirements (NFRs) which often need to be considered as a whole and put in place beforehand. Here special care should be taken to have as much foresight as possible to help ensure architecture and frameworks are not just fit for purpose but also flexible enough to accommodate some change. In my experience exploring NFRs in particular are crucial to avoid later architectural churn. This aspect is challenging and achieving the wrong balance can cause either too much flexibility with increased complexity and cost or too little and the impact of later change can be massive. Few changes are free, so make change visible and accountable Although development teams work hard to accommodate and minimise the impact of change, few changes are free and most will have some impact on development , BA work or beyond. Quantifying the impact, be it additional time and cost or agreeing a trade for other features, helps keep the business focused on what's important and discourages a perception that Agile working can accommodate any amount of change without disruption or cost. Avoid complexity where possible as it is expensive and slow to develop and very expensive to change Complexity is bad news for development. Not only does it take longer to implement, longer to get acquire feedback, it may need specially skills, it may be difficult to effectively test and worse, when change comes along later it can cause huge waste. Code functionality may no longer be well understood leading to poor implementation, rounds of refactoring and ongoing quality issues. Releases of working software drives critical feedback Getting to market quickly is often critical to most businesses, however software can be notoriously slow to develop. Getting out early releases even if incomplete will help validate what the company is driving towards and can give opportunities for critical feedback exposing business or technical flaws early so cheaper corrective actions can be put in place. This initial period is often the best time to demonstrate approaches to risky future functionality through prototyping and through that gain important feedback and direction as early as possible. It is worth remembering that early releases of less than fully featured software may be acceptable to some new customers. This give the opportunity for real life feedback (and early revenue) to underpin and guide development.
The main objective is success (which can be measured by the degree of Customer satisfaction, achieving lowest time and cost to deliver and attaining an adequate quality) Getting useful software delivered as early as possible and at the lowest cost is what any software development projects should aspire to. Although costs and timeframes can be forecast before project construction, it is often the project retrospective and not the attainment of set targets that gives insight into assessing if development was optimal. Like most processes, reaching best practice comes from experience, iterative learning and tuning the way things are done from sprint to sprint and from one project refection to the next. Conclusion Working in an Agile way doesn't automatically mean that embracing change or working practices are as efficiently or as cost effectively as they could be. When implementing Agile principles think about why they were chosen and how work practices can be tuned and implemented in an environment which underpins the factors making up successful outcomes. Phil can be contacted via Phil.Ealey@BTInternet.com
References: 1 Kent Beck et al (2001) Agile Manifesto www.agilemanifesto.org/principles.html