Today, most IT projects are run as Agile projects. But how should we understand the term ‘Agile’ and how does this way of managing projects differ from the traditional cascade or waterfall approach to project management?
If waterfall means well planned, structured and documented, does that mean that Agile means chaos? Mateusz Młynarczyk, Head of the Software division at ITMAGINATION, has over 10 years’ experience in managing IT projects. He shares his experience of working with other project management methodologies and tells us about the route that ultimately led him to Agile.
Project management has been a major part of my professional life for many years. I specialized in project management at university, and although I started my career as a developer, I soon found myself in a position where I was managing teams of developers, and managing projects worth tens of thousands of euros, then hundreds of thousands of euros and then millions of euros.
I worked with local (i.e. Polish) market leaders and I worked with some of the world’s largest brands. Along the way, I had the chance to work with many different project management methodologies. Our team members have the chance to obtain internationally recognized certification such as Prince 2 Practitioner, Project Management Professional and Professional SCRUM Master.
Today, as a team, we need to be up to speed with what the market expects, and we need to be ready to empower our clients to lead in their respective markets.
Before I became certified in Agile, I had worked on a large number of projects for financial institutions and international organizations. Using traditional ‘Waterfall’ methodologies, the onus was always on defining all of the business and functional requirements before starting the project and then building a product that meets those needs. In short, the process looked like this:
That process seems fairly logical, even to this day. However, as I’ve learned in the last ten years, what seems logical in theory, doesn’t often translate into logical ‘in practice’.
These are the main problems I encountered:
One of the greatest challenges faced by leads of IT projects is the changing or lack of understanding of business objectives and expectations during the analysis phase. This scenario of multiple different parties having understood the objectives and expectations differently is depicted humorously in the comic strip below.
Humorous illustrations aside, though, this cascade way of working simply wasn’t working. As it becomes clear that there is a gap between what the finished product does and what the business wants it to do (even if the expectation has changed since the start of the project), the risk of dissatisfaction, budget overrun and missed deadlines increases. Apparently, it wasn’t just me that was noticing.
According to periodic research conducted by the Standish Group, in the five-year period 2011-2015, only around 30% of IT projects could be considered successful, with success being defined as having fulfilled or complied with the criteria set out at the beginning of the project (such as budget, time and scope). While percentages vary slightly across sectors, a surprisingly low success rate was common across all industries.
In theory, the remedy to such problems is the adoption of an agile project management methodology. Projects that are run according to an agile methodology are intended to be realized through a series of short cycles (‘sprints’). These sprints are used to constantly and continually ensure alignment between business expectations and stakeholders, and the progress of the project.
In practice, this means structured, more-regular contact between the business stakeholders and the Development team. In turn, this should result in closer alignment between all parties and a clearer, shared view of the direction of the project and the end goal. Importantly, though, it also allows for some pivot and adjustment within the project (e.g. driven by changing business needs, market trends or budgetary or timeline factors) and it empowers the client to influence and be more accountable for the outcome of a product that is being built specifically for them.
As confirmed by the table below (produced by the Standish Group), the chances of success are significantly higher when the project is run according to an Agile methodology versus a Waterfall approach (wherein all of the requirements are analyzed and documented at the start and all subsequent design and development adheres to the original documentation, without an acknowledged flexibility to adjust course mid-project).
Having managed many IT projects, Agile was not completely new to me. In fact, I had previously obtained Professional Scrum Master certification. But I wanted to broaden my knowledge about how to divide the entire product development cycle into sprints and to learn more about the Agile approach to managing entire projects.
So I embarked upon and completed the process of obtaining AgilePM Foundation certification (check out my certificate). As somebody that has dedicated a significant portion of their life to project management, it is important to me that I’m learning from an established and proven foundation of best practices and standards.
My commitment to the profession and the experience I have accumulated are invaluable, but – as much as we’d like to think we’ve seen and done it all – we’ll never know everything. In this context, certification provides us with the opportunity to test our knowledge against a base of experience even broader and more extensive than our own. And it provides us with the opportunity to fill any gaps that we might have in our knowledge.
So, having managed many IT projects in my career and with Professional Scrum Master certification under my belt, I wasn’t coming at Agile as a complete newbie. I went on a three-day on-site course that concluded with an examination. I’m happy to say that I passed ‘top of the class’ in my group of around 20 other IT professionals!
While on the course, I discovered a very interesting approach to Agile called the Dynamic Systems Development Method (DSDM). The DSDM approach encourages us to leave the finer details of a project to emerge as the project evolves. This approach is based on the high probability that business expectations will change from the start of the project.
As such, the DSDM approach advises us against unnecessarily spending large amounts of time on something that is likely to change. Instead, DSDM advises that we focus on the closest and most-current business needs, to address those and then to move onto the next stage of the project.
Of course, this doesn’t mean that the rest of the requirements can or should be ignored. Of course not, however, they should be acknowledged at a general level at this stage. In this way, we’re able to deliver functionalities and iterations of a project that meet current needs, and we avoid failed attempts to anticipate future needs.
Importantly, we retain the flexibility to pivot or adjust to accommodate new or different business needs in the future. The business benefits by having faster access to a product that addresses its current needs and business stakeholders are able to influence and monitor progress much more closely.
The idea of focusing less on details and allowing them to emerge as a project evolves sounds all well and good, but it naturally poses questions. As a business stakeholder, how to do I budget accordingly and get the right deal if we’re shifting a (seemingly) large part of the work to later in the project? After all, isn’t the devil in the details?
The DSDM addresses this topic in a very interesting way. In the DSDM view, an Agile project will have a fixed timeframe and cost, but the scope of what is delivered within that timeframe and budget might change (this is where MoSCoW comes in handy – read on). In this way (and as the diagram below illustrates) the DSDM Approach to Agile turns the Traditional Waterfall Approach to project management on its head somewhat.
As an Agile project proceeds, the timeline for what is delivered and when is continually monitored and updated. The MoSCoW approach is a useful way for the business and project team to prioritize their needs and functionalities based on the idea of Must Have, Should Have, Could Have and Won’t Have:
Note: The project should always plan to deliver all Must Have functionalities. For this reason, Must Haves should not account for more than 60% of the scope of the project as this would mean that there is insufficient flexibility in the scope. If there is a shortage of time and/or budget, Should Have functionalities will be considered for omission.
Following the MoSCoW approach is something that can be done at the start of a project, but also within the context of each timebox or sprint (typically lasting 2-4 weeks), or cluster of such periods. This approach allows for certain requirements to be assigned one status when considered within the context of the current or next sprint, but a different status within the context of an entire project.
For example, a particular functionality might be defined as Should Have within one sprint but be Must Have within the context of the entire project. It’s important to remember, though, that the percentage of Must Have features cannot exceed 60%, even if a functionality or requirement changes status during the project or between sprints.
This 60% might seem random, but it has been identified by Agile practitioners as the number that, if exceeded, reduces the project team’s confidence that the project will be completed successfully and increases the risk of project failure. As such, if there is a threat that Must Haves will account for more than 60% of a project scope, it’s important to re-analyze the different requirements and functionalities and, if necessary, assign different statuses.
Another thing I enjoyed learning as part of AgilePM certification is the recommendation on the minimum documentation requirements for an agile project and the key roles within a project. I can recall many projects that have been bogged down by the sheer weight of documentation.
Often, that documentation is not read by the people that need to read it and/or it’s out of date by the time the project starts properly. AgilePM does not encourage you to ignore the importance of documentation, but it does provide you with additional flexibility by providing recommendations on what is optional and what is obligatory.
Unlike Scrum, the AgilePM recommendation on documentation relates to the entire project from the initial stages of the project right through to its entire lifecycle, and not just to the implementation stages. It’s a dramatically easier-to-digest and easier-to-implement approach to managing IT projects compared to non-Agile methods, such as PRINCE2.
This has saved us time and the lighter approach to documentation means that it’s easier to ensure that all key stakeholders are informed about the goals and plans for the project.
Agile has become part and parcel of our daily work at ITMAGINATION, and it (or one of its variants) has become our standard methodology for the vast majority of projects that we work on. For a leading bank, we’re working on a mobile app. Working together, we are defining the scope of the project as well as the entire lifecycle of the application.
On an ongoing basis, we track our progress against the roadmap for the entire project. We observe how we’re advancing against the original project plan and we meet with the project sponsor to discuss progress and, if necessary, adjust future actions and directions. In this way, the project continues to progress in line with the evolving requirements of the business.
The business can enjoy and observe the benefits of the developments while, at the same time, evaluating whether any change in direction is needed. In this way, all parties are always aligned and in agreement on the direction that the project is heading, they jointly take decisions, and they all know the implications of those decisions.
The result is a more satisfying way of working, faster delivery of results, and greater positive impact for the client’s business.
If, like me, you enjoy having attainable goals, working as one team with a variety of stakeholders and increasing your chances of success, there really is no alternative to Agile.
Read more about how Agile is used in IT projects in this ITMAGINATION blog post about Agile.
.svg){kind=small}
