“Agile” is taking an open and honest approach to software development that is evidence based and promotes individuals and collaboration over documentation, formal process and tools.
“Agile” is a much misused term in software engineering businesses. At its best being “agile” means taking an honest professional approach to software development that values the teams and individuals in the business. At its worst it’s an excuse to cut corners and hack away at code while ignoring the management.
The agile movement was created by developers frustrated with organizational and academic processes that didn’t acknowledge software as a highly complex, team-based, creative process. At their heart agile methods are about empirical feedback, good communication and quality software and since they were created by developers they quickly became popular amongst developers.
The Agile Manifesto gave us:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Agile practices and processes have become popular because they align with professional business ideals and are effective when implemented properly. Many organizations attempt to implement agile processes as a way to move away from dysfunctional waterfall processes. However, these process changes are often implemented poorly because they are considerd to be only changes within the delivery function not changes across the software value stream.
Unfortunately, agile practices (or worse Agile processes) are often implemented by organizations badly. This can lead to a cultural conflict between agile teams and the management culture, despite both aiming for the same thing. As a result, professional individuals can feel constrained by an imposed process that prevents them from doing their job properly. Sadly, both agile team members and project managers often identify with this sentence. In fact, we often see all sorts of people identify with this sentiment as a process chosen by one group doesn’t suit the others.
Scaling Agile – the wrong approach
The term “scaling agile” or “agile at scale” is often used by people referring to a desire to implement the principles of the agile manifesto throughout an organization (scaling up), trying to extend agile practices across multiple teams (scaling out) or at worst simply implementing the language and ceremony of agile practices for every function of a software business.
However, agile practices were created to solve problems related to teams needing to rapidly and efficiently deliver a software product in a team. They weren’t created to link software development to strategic direction, to structure large complex programmes of work, or to deal with portfolio management. Simply applying the same practices to different problems is unlikely to work well.
The situation is further complicated by ideological process implementations that are based on a process that is meant to have all of the answers.
A different approach
Holistic Software Development aims to avoid these problems by combining business management with agile development and lean techniques in a cohesive framework that welcomes other processes and practices whilst maintaining the spirit of agility and the proven practices necessary for complex programmes of projects and software business management. We welcome the incorporation of Scrum, Prince2 or any other process or practice library. Because HSD is free it does not need to pretend to be a silver bullet solution.
Agile and HSD
So, HSD is agile in that it supports the agile manifesto and embraces open, collaborative, empirical progress. the HSD Manifesto is even based on the agile manifesto. However HSD isn’t agile in that is has a focus on business management, requirements and architecture – it’s broader and deeper than agile methods. It is possible to use HSD with a non-agile delivery framework however we strongly recommend iterative or continuous practices and advise extremely strongly against waterfall approaches.
Agile/Iterative Teams follow a lightweight, evidence based, adaptive approach to software development. Delivery is frequent, with regular increments adding to an increasingly rich product.
An agile iterative team will be self-organizing, cross-functional and will deliver regular incremental releases of their product in short iterations or time-boxes (preferred iteration duration measured in weeks). The team will actively engage as a group in detailed planning of their short iterations/sprints and will proactively adapt plans and working practices rather than be directed by management. Self-organization implies the team taking responsibility for their success or failure improving their motivation as they achieve autonomy. A Project Manager may be involved in an agile team to perform leadership, co-ordination and communication activities while the team and Product Customer are responsible for planning.
We recommend Scrum for agile Product Delivery Teams
“Agile” is not just about workflow though, that’s what makes an iterative team. “Agile” is a philosophy, centered in team based social practices where individuals and interactions are valued over processes and tools. Agile teams embrace social interaction, organic networking and a strong focus on working software as the measure of progress. Be wary of derailing agility by focusing on processes (Scrum), measures (velocity) and tools (backlog tools).
Iterative teams are very similar to agile teams and will also deliver regular incremental releases of their product in short iterations or time-boxes but are typically controlled by directive management rather than being self-organizing. Planning is often done for the team by a Project Manager who takes on planning responsibilities as well as performing leadership, co-ordination and communication activities.
From a workflow perspective, Agile and Iterative Teams are very similar in nature, both deliver small parts of a system incrementally, batching requirements into timeboxes and both require regular feedback loops. Typical iteration or sprint durations will be 2-4 weeks, represented by a Sprint/Iteration Plan and the order of feature delivery in the increments is determined by balancing customer priorities, technical risk and technical dependencies. If there is conflict between these areas, we recommend de-confliction using the Product Forum practice.
Agile/Iterative teams are intended to be cross-functional, meaning that the team has all of the skills within it to accomplish all that is asked of it. An team therefore requires specialist capability in user experience, requirements, architecture and design, coding, testing and deployment. In practice, within large organizations some specialists will emerge that float between teams, working with them temporarily to advise others for short periods as required, for example to provide expert UX skills. For more see the Team Forming practice.
Agile and Iterative teams will practice some form of “Reflect and adapt” or continuous improvement technique at sprint/iteration boundaries. For example, teams using Scrum will schedule and perform a retrospective each and every sprint to identify what can be done better or changed to improve team performance. Iterative teams do the same at Iteration Assessments.
For continuous improvement teams will use some simple performance metrics to assess the amount of work being completed, these metrics can also be extrapolated to predict future milestones based on actual performance.