Agile methodologies are becoming standard practice for companies all around the world, including Poland. More and more organizations are adapting their structures and their processes so that they can work in this more ‘nimble’ way. But agile is no longer limited to the IT domain, or to the development of software. Today, agile is being adopted for projects within the telecommunication, advertising and financial services sectors, and even Industry.
Here, Marcin Dąbrowski, CIO at ITMAGINATION, explains why agile is the way forward for businesses all around the world, and not just for technology projects.
Throughout ITMAGINATION’s decade-long history and during our ever-deepening relationship with agile, it’s been evident that Polish programmers excel when using the SCRUM methodology, which is based on agile. The lesson we have learned is clear: once our developers adopted SCRUM and agile, there was really no turning back. We started out with agile many years ago, and we remain loyal today. For us, agile is currently the best way of operating in the modern world. Why is agile so right for today’s way of working?
Agile is perfect for the rapid integration of innovative and game-changing ideas, and it empowers our developers and our clients to operate successfully at the sharp end of the market, where the success or failure of a project can depend on how quickly the ‘next big idea’ or ‘killer’ functionality can be built, or how quickly a product or project adapts to constantly evolving customer needs.
The first evidence of agile being used (although it was not yet referred to as such) can be traced back as far as the 1980s. But it wasn’t until the dawn of the new millennium, 2001 to be exact, that agile became a fully fledged ‘thing’, equipped with its own manifesto and set of guiding principles. One of the most important ideas and one that is commonly used to make the case for the use of agile as a project management methodology within companies of all shapes and sizes is the notion of creating a product through short, intensive bursts of work (what many of us refer to as ‘sprints’).
This enables an agile (hence the name) way of working that delivers quick progress that an end user and client can see and use, while retaining the space and freedom for the development team to quickly adapt ideas or respond to influences as and when they arise. The intervals between each sprint (or simply the end of a sprint) afford teams an opportunity to reflect on the work that they’ve done and the path they’re treading. It’s not only a chance to take stock of progress achieved thus far and ensure progress is in line with client needs, but it also allows the team to optimize and even correct its course, if needed.
In addition to the freedom that it affords the project team, agile methodology is also founded on the principle that, in order for a project to be successful, it’s necessary to build a team that features a sufficiently broad spectrum of competencies and knowledge from different domains. When agile is practiced properly, teams aren’t comprised exclusively of Developers, Designers, and Project Managers — instead, individuals from both the vendor and client-side work together, blending technical and domain- or business-specific expertise.
The results of using agile are clear and compelling – closer collaboration, shared vision and a greater likelihood of success.
One of the key reasons for the emergence of agile methodologies has been the inadequacy of, and dissatisfaction with, previously practiced approaches and methodologies, such as waterfall. So, what was wrong with waterfall and similar approaches? Well, for starters, waterfall projects typically take months to complete, and sometimes even years.
Needless to say, the pace of change in almost all industries has accelerated exponentially in the last few decades. In today’s rapidly evolving marketplaces, it’s difficult to imagine that an idea conceived as ‘cutting edge’ a year or more ago could still be considered in the same way today. End-user needs change, markets change and stakeholders need to react or — better still — anticipate such changes. Traditional waterfall approaches to project management don’t allow for such evolution mid-project.
The result is that by the time a waterfall project is delivered, there’s a high probability that it’s no longer relevant to the reality that the business finds itself in. Everything — the business, the market, the end users, the technology ecosystem — has changed except for the project itself. Of course, changes can still be made to the product delivered at the end of the project, but — at this advanced stage — such changes will require significantly more time and investment to implement.
Can a business afford to continue to invest in playing ‘catch up’ while its needs and ambitions continue to evolve? The answer is probably ‘no’ and this ‘no’ sounds the death knell for waterfall as a viable project methodology in this day and age.
Profesor Al Goerner of the University of Missouri conducted research that demonstrates that the inherent value of output-based requirements erodes exponentially over time. The erosion of this value is compared to the half-life of an unstable radioactive atom. The term half-life is defined as the time it takes for one-half of the atoms of a radioactive material to disintegrate or decay.
The pace at which the value of output-based requirements decay has been accelerating – in 1980, half of the requirements were obsolete 10-12 years after being defined. By 2000, it had fallen to 2-3 years. In 2013, it was just 6 months. Needless to say, it’s probably even less today. What lesson should we draw from this?
Simply put, we must prepare for whatever requirements we define at the outset of a project to be obsolete and in need of revision within a period of months. In short, even with a project lasting just 3-6 months, we shouldn’t become too attached to the requirements we define at the outset.
Agile is different because it promotes an environment in which change is not feared, but welcomed as an important part of the process. Thanks to the system of short ‘sprints’, there are regular deliveries of viable pieces of a product (this could be a new functionality or group of functionalities within an app or program). These are accepted and put to use.
In this environment of rapid and regular delivery, changes requested by the client can be integrated at almost any stage of the project — perhaps even as part of the next sprint — without derailing the entire project. All it requires is consensus on the direction to take and collaboration to make it happen. And, as we know, consensus and collaboration increase the likelihood of overall success. Contrast this with a cascade model in which there are precious few opportunities to see and experience outputs, identify mistakes, correct course or even discover new opportunities, and it’s difficult to imagine adopting anything but an agile methodology with a project today.
The Standish Chaos Report from 2015, based on its study of more than 50,000 projects, is one of the most compelling independent arguments in favor of agile over waterfall. The table below proves the hypotheses that a project run using an agile methodology is significantly more likely to be successful than a project run using a waterfall methodology.
The results are conclusive and are consistent across projects of all sizes. The higher success rates are undoubtedly linked to the use of sprints and the opportunity these create for the project team and client to jointly reflect on the direction of the project and, where appropriate, make changes based on changes in the market or simply a better understanding of business or end-user needs … opportunities not typically afforded to stakeholders on a waterfall project. What’s more, studies have shown that teams working to an agile methodology are more productive and less likely to commit errors.
Not every project that is run according to ‘agile’ principles looks the same. Beneath this umbrella term, there are several different approaches to project management that can be given the label ‘agile’. The most popular agile methodologies are SCRUM and SAFe. Companies and project teams need to consider their level of comfort with these different approaches and factor in the size and nature of their project before deciding which approach to adopt.
In our experience at ITMAGINATION, the SCRUM approach works best on smaller projects, where the number of project team members is around 9-12 people. This size of group is optimal for being able to organize itself (a key principle of the Agile Manfiesto) and for being able to effectively identity and work towards the right results for the project.
SAFe, meanwhile, was developed for use in larger-scale projects, where the number of team members can number in the hundreds. Working according to SAFe implies multiple different project streams, with a multi-layer function to manage and review progress. Thanks to this approach, teams are able to plan better, benefit from greater visibility and integrate resources and new ideas effectively, despite the larger scale of the project.
For the last 12 years, CollabNet and VersionOne have been publishing annual reports about the application of agile methodologies around the world. The trend is clear — each year, the number, and proportion, of projects being run using agile methodology increases. Of course, this is no surprise given the benefits compared to other project management methodologies.
According to the 12th Annual State of Agile Report, the time taken to deliver software using agile methodology is up to 75% less than when using non-agile methodologies. Furthermore, employee creativity has been found to increase by up to 55% and team productivity by as much as 61%.
It would be normal to think that these pauses for reflection, intensive sprints and high level of involvement of people from a variety of different backgrounds result in higher overall costs of delivery; that these ‘luxuries’ come at a cost. So, is a project that is run using an agile methodology more expensive to deliver? Or does agile help reduce the inefficiencies and losses incurred in more conventional ‘standard’ ways of managing projects (e.g. waterfall, Prince2, RUP)? Research conducted by CollabNet and VersionOne clearly demonstrates the increasingly compelling argument for agile methodologies as more cost-effective than non-agile methodologies.
Improved creativity and productivity are naturally likely to increase workforce satisfaction. Importantly, though, these indicators (as well as reduced time to market) contribute to greater client satisfaction. More and more of the world’s largest companies are adopting agile methodologies, indicating that the practice is no longer limited to the software or IT industries.
The CollabNet and VersionOne research seeks input from a variety of different disciplines, representing brands from all over the world. More than three-quarters (79%) claimed that they knew of at least one team or project within their organization that operated according to the agile methodology. The most-enthusiastic adopters of agile were, naturally, technology companies, though it’s interesting to see that companies from the financial sector and professional services sectors rank second and third. And while it’s still relatively early days for non-IT companies, the trend towards the adoption of agile is clear.
Many people naturally raise the topic of how to enter into a contract with a vendor on an agile project when there appears to be so much flexibility. Indeed, it’s difficult to define and agree upon a fixed scope (and so remuneration) when much can change from one sprint to the next, or at various different stages of a project. Increasingly, vendors and their clients create and agree to Product Visions and Road Maps. From this thinking arises a natural tendency towards contracts based on ‘Time and Material’ or contracts with a ‘budget cap’ (an agreed maximum budget).
Łukasz Węgrzyn, a legal expert who has consulted on many agile projects (source in Polish), suggests that transactions for such projects can be based on a variety of different indicators or provisions, but advises on structuring remuneration based on the outputs from sprints and backlogs, and to invest in ensuring ‘definitions of done’ are clear and adhered to. Needless to say, it’s crucial to have the involvement of your project’s key protagonists involved in this process.
Change can be difficult, not least in companies that have spent years — often decades — establishing processes and ways of working. Cultures form and comfort levels become embedded. Many people, and so organizations, are reluctant to change and this can naturally make adoption of agile difficult. It’s probably not surprising to read that the most commonly encountered obstacle to adoption of agile is a lack of knowledge within the organization and a lack of people with experience of running projects in an agile way.
When considering whether to run a project in an agile way, it’s important to remember that the process must start with a strong Product Owner who has knowledge and experience with agile methodologies, and who is empowered by his or her company to lead projects.
And while it’s important to ensure that the right conditions exist within a company for an agile project to be successful, it’s equally important to recognize that the introduction of agile doesn’t have to disrupt the entire organization – agile encourages employees to think creatively and to remain open minded throughout the duration of a project.
It does not, however, mean an overhaul of all of the tools, processes and procedures used by the rest of the company. For this reason, it’s important to ensure that those people and teams operating in close proximity (but not involved in) to an agile project are made aware of the fact, and are thus able to give the project the space and breathing room it requires without feeling threatened by its presence (or disappointed if they see that a project is changing in shape and direction).
In short, understand your existing culture and, based on its readiness or openness to new ways of working, communicate accordingly and in a way that ensures that everybody in or around an agile project feels comfortable and not threatened by this new development.
Given the benefits of agile and its relevance to the rapidly evolving expectations of companies and their customers, many organizations — both within the technology sector and beyond — should already be considering how ready their organization currently is for agile. Given the commonality between the guiding principles of agile and the evolution of a business climate that increasingly values — and demands — exceptionally quick thinking, agility, creativity, collaboration and an ability to adapt to and adopt new ways of working, one might be forgiven for thinking that there really is no viable alternative to agile for project management.
Learn it. Know it. Done.
.svg){kind=small}
