Agile methodology – fail early, fail often
Nowadays, Agile is used in several areas of development, however the methodology has become more popular in the Software Development industry. Although it may sound surprising, Agile is also used in Building & Industrial Construction, Engineering, Aerospace and Pharmaceutical industries.
Written by Cristina Temian (Project Delivery Manager) and Larisa Iordache (Project Delivery Lead), in the September 2023 issue of Today Software Magazine.
Read the article in Romanian here
Who would have thought that a trip to the mountains in Utah would lead to such a change in the way we handle work? In February 2001, a group of seventeen people met to simply enjoy nature, eat, and drink at a cottage in the mountains. They did more than that, as after their trip, the whole world got to read the “Agile Software Development Manifesto”.
Nowadays, Agile is used in several areas of development, however the methodology has become more popular in the Software Development industry. Although it may sound surprising, Agile is also used in Building & Industrial Construction (more used in the planning phase – design and pre-construction), Engineering, Aerospace and Pharmaceutical industries.
How projects fail and why do they succeed?
Despite its popularity and the vast adaptation of Agile, there are companies that failed to adopt the methodology.
Some organisations think about consider adopting Agile and Scrum because they are popular, without evaluating if they suit the project or services they deliver. Agile is not the quick fix for everything that is going wrong.
While a significant number of organisations have integrated Agile, only a mere 18% have managed to implement it across all their teams (the US State of Agile Survey in Software Development, which reflects the 2022 landscape and it’s based on the experience of more than 3,220 business and IT professionals).
Agile can be a very difficult thing to do if a significant amount of cultural change is required. It is also a very empirical process, which means sometimes you should try and experiment with things to see what works and then adjust and correct (a key idea behind agile is “fail early, fail often”). For that reason, the case studies should be regarded as learning opportunities and not failures.
Dr. Jeff Sutherland, one of the creators of Scrum Agile framework and Agile coach at Openview, presented during an Openview podcast an example of project failure – healthcare.gov. Healthcare.gov is a website run by the US government, also called “Healthcare Exchange”, where the end customer enters some basic biographical information through the site, they can compare their health insurance options and purchase the right plan for them.
Outside of the annual Open Enrollment Period, healthcare.gov operates for informational purposes; it is also a tool to manage existing plans for those already enroled.
After several years of trying to deploy it, after only six days of testing and after only the front-end development of the project was authentically working in Agile, the project went live in October 2013 and only then did everybody acknowledge the issues.
The overall project failed principle number two from the Manifesto: “working software”. High website demand caused the website to go down within 2 hours from launch, four million unique users visited the portal, but only six successfully registered.
Additional problems arose mainly due to the website design not being complete, and because all states were included from the beginning. The team who made the site work in 10 weeks was called the Obama Trauma team on time.com
The key factors to the “war zone” created by the ObamaTrauma team in order to fix the big problem were:
Daily standups – at the beginning and end of the day (each of 45 minutes);
A 24-hour open phone line to connect people all over locations;
The meetings and war rooms were only for solving problems;
Removing the micro-management;
Focus on the most urgent things.
During this period, the website crashed two times. Again, the famous project management challenge arose: putting 10 people on a fix that would take one coder 10 days doesn’t turn it into a one-day project.
In the end, the website started working as expected between Thanksgiving and Christmas and as of mid-February 2014 the report covering the period through January 31st, reflected that the site had processed 1.9 million enrolments.
Personal examples
We are a squad of 6 members (Senior Backend Developer, Senior Quality Assurance Engineer, Junior Frontend Developer, Junior Quality Assurance Engineer, Proxy Product Owner, Scrum Master), plus another 3 members (2 Backend Developers and 1 Frontend Developer) on customer’s side on a mission to deliver working software by the end of October 2023 ’23 working in SAFe methodology.
We will share what was implemented from the model and how well we are integrating the four principles in the day-to-day activities.
Individuals and interactions over processes and tools. Processes and tools are sometimes blocking the team because the documentation is not always updated, and the infrastructure is a bit slow. Through retrospectives, we have shared the feedback and we are looking into adding on a DevOps Engineer to the team and addressing the general issues.
Working software over comprehensive documentation. Documentation is very important and it’s conditioning the releases – the Product Owner needs around 3 weeks to prepare a deployment. We are filtering through what is critical/noncritical documentation before the release (legal/compliance related).
Customer collaboration over contract negotiation. The customer is very open to developers’ insights and feedback regarding ways of working and product usability. It was very important for us to understand the WHY behind deadlines and priority changes inside the team. Dedicated Client Management roles and Delivery Management roles are closely working together to maintain collaboration and navigate contract conditions in favour of the customer, product and team.
Responding to change over following a plan. We are responding to change effectively, but still need clear and complete requirements to be able to deliver working software. Numerous changes in team structure, roles and priorities are confusing.
Let’s go over one more example, focused on a fixed budget – time – scope scenario, where we will see the differences between theory and practice when it comes to Agile Implementation.
The team follows the Agile Structure (Backend and Frontend Developers and Quality Assurance Engineers, Senior Product Owner, Scrum Master). As per the model above, we would focus our arguments in relation to the Agile principles we mentioned at the beginning of the article.
Individuals and interactions over processes and tools. Given that our client received a fixed budget at the start of the year, the first thing we did was to set up a kick-off meeting, to see what can be covered within that specific budget. During this session, we discussed the main requirements that we need to implement, the expectations in terms of time and scope, as well as processes: we were about to establish a new way to provide the estimates, per feature. Having a fixed budget will determine our clients to thoroughly plan what needs to be done in a year. We can see that so far, the focus is rather on processes, than individuals and interactions. In order to bring the attention back to our matter of interest, we made sure that the team is connected with the client, and we constantly provided feedback to both parties involved. Communication is key in this type of situations, and we do believe that constant alignment can help improve/change the status quo.
Working software over comprehensive documentation. This is something that is currently happening, both the team and the client are focused on having the MVP and the discussions are always centred towards the working product rather than documentation. As we can see, even though it might be challenging to adopt Agile in its true sense, some items cannot be ignored, and are adopted by teams regardless of the time/scope/budget relation.
Customer collaboration over contract negotiation. The contract is never put on the table, and each time we face challenges, we remind ourselves that collaboration and honest feedback can lead us a long way. There are times when there are contractual regulations owned by the client (fixed budget, fixed time, fixed scope in some situations). These are dictated by the client’s relationship with the main sponsor. However, what helps is for the team to be aware of these restrictions, and continue collaborating to get the best possible outcome.
Responding to change over following a plan. As mentioned above, in this situation, having a fixed budget, scope and time, constantly responding to change is not a feasible option. More importantly, the plan is required, necessary and constantly updated. Having these three variables locked in place, how do we respond to change? Here are some of the solutions we applied:
When the deadline is represented by a fixed date, the estimates are no longer estimates. They are seen as commitments. Knowing this information, we adjusted the plan, including additional buffers for undiscovered requirements, documentation, bug fixing, etc. In this way, even if there will be additional scope discovered in the middle of the implementation, the buffers will cover for it.
On top of this, having a Product Owner responsible for scope control is important. Whenever we receive requests to add something new, it’s the product owner’s responsibility to remind everyone that the focus should be on the initial and planned scope. After all, the only person responsible with the update of the Product Backlog is the Product Owner, as stated in the Scrum Guide.
Another solution we found was the constant communication with the client. Having a fixed budget and time, we always make sure to update our stakeholders whenever we face a blocker or an impediment and try to overcome the situation together. We mentioned that the Project Plan is constantly updated – this is to reflect the realistic capacity left, in order to be able to come up with ways to stay within the budget while delivering quality.
Given the contractual regulations in place , an ideal scenario would be to change the type of project from “time and material” to “fixed price”. This would mean that even though the three variables would remain fixed (budget – time – scope), we would be able to follow all the Agile principles internally – within the team – until the features are delivered. Unfortunately, changing the type of the project is not something that can happen overnight; therefore, we will continue to find solutions on the spot, taking one issue at the time.
Below you will find a graphic that illustrates a series of indicators, showing the efficiency of adopting the Agile Methodology.
We now invite you to reflect on our examples and let us know what other options you would find suitable. The list is limitless, as there is no secret recipe to overcome these challenges. However, knowledge sharing always helps.
