Earlier this year, we wrote about our product development lifecycle, providing step-by-step insights into how we approach our projects and deliver maximum value to our customers.
One aspect of the inner workings of Vivify Ideas (and any other self-respecting software development company, for that matter) was not really covered in enough detail — the Agile practices that have become staple for modern companies that do software development.
In other words, today, we will be talking about how adopting various elements and practices from different Agile approaches can impact the software development process. We will be looking inward for this, examining our own practices; but we will also drawing from research published over the years which investigated the effects of Agile on software development processes around the world, in a number of companies and case scenarios.
Handling Requirement Changes
Regardless of how detailed the initial product requirements definition is and how good the relationship with the customer is, the simple reality is that the requirements can and will change for any given product sooner or later.
This can happen for any number of reasons, from the simple change of heart on behalf of the customer, through the organic changes that stem from developing a living product to fluctuations of the marketplace and anywhere in between.
The requirement changes can also occur at different times in the software development process and, depending on the exact time, their impact will vary from a minor nuisance to a catastrophe of biblical proportions.
Software development companies that are agile are better equipped to deal with such changes. For one, this is true due to the incremental nature of agile software development. Instead of shipping iterations every few months (or rarer), agile teams do this more frequently, meaning that the requirement changes can be addressed much quicker, reducing the amount of time needed for reworking code that is no longer wanted.
Constant inspection and embracing an empirical approach to developing software only adds to this adaptive nature of agile software development.
When all parties involved are applied to inspecting all work that is being done and introducing continuous testing, problems and mistakes are noticed much earlier, giving the teams more time to address these issues and avoid building on top of a foundation that is guaranteed to fail.
Another reason why agile software development companies handle requirement changes better is that outside stakeholders are usually much more informed than with traditional approaches. They are given insights into the team working on their product and they can voice their opinions and suggestions more easily. This kind of open cooperation makes handling requirement changes faster and more efficient.
It is probably safe to say that this adaptability has an immense impact on the software development process and a positive one at that.
Enhanced Stakeholder Participation
Every software development process features stakeholders, regardless of how complex or large it is or what the business side of it looks like. Even the tiniest, independent one-person project aimed at unspecified users will have at least one stakeholder — that one person.
More commonly, stakeholders will involve the customer, the various parts and people in the development company and everyone else who might have an influence on the process and its outcome — the product (like for example a legislative body of some kind).
In such projects, the level of participation of stakeholders and the different relationships between them can greatly influence the day-to-day functioning of everyone involved and the final product.
We could take a hypothetical and somewhat caricatured waterfall process as an example of poor stakeholder interaction:
- A customer comes in with a list of vague, half-nonsensical requirements,
- Leaves the development company to do the planning,
- Comes back to okay and nix planned features
- Disappears for months on end (only occasionally pressuring project leaders to pressure the development team)
- The development company says nothing
- Comes for the final demo
- Decides it’s not what they want
- Asks for 95% of the product to be changed
- The development company says okay
- Go back to #1. Repeat
The amount of resources that will be wasted on a product that will come out of this half-relationship will be stupendous and the product itself will most likely fail spectacularly when released.
One of the biggest strengths of the agile approach and implementing agile practices is the improvement of stakeholder participation and engagement.
From the very start, agile software development companies invite the customers to collaborate closely on the various preparatory phases which may include the likes of requirements analysis, creation of product draft, planning and the creation of a Product Backlog (if the Scrum framework is employed).
Due to its emphasis on transparency and inspection, agile approaches also allow the stakeholders to have as much insight into the actual development process as they wish either during structured events or through simple communication that is always at the core of agile software development.
However, it is important to point out that enhanced stakeholder engagement goes beyond external stakeholders. Namely, people who fill various roles within the development company will also feel more engaged within a company that has adopted agile principles. They will have a better understanding of the entire process (especially important for larger projects with multiple teams), the reasons they are doing what they are doing and the value of the work they put in. In addition to this, agile teams often cite knowledge sharing as one of the best things about adopting agile.
Above all else, adopting the agile approach helps software development companies add value through every step of their process. In those companies that go all the way with agile, this happens through an intricate interaction of various ideas and practices, as well as the change of the mindset.
Let’s take Scrum as an example (mostly because we have the most experience with it). A software development process that takes place within the Scrum framework maximizes value across the board.
It starts with maximizing the value of the product that is delivered to the customer by releasing regular increments of a working, valuable product; by getting early feedback; by being able to identify and remedy issues quickly; by testing continuously and by letting the customer remain involved with the project throughout.
Scrum also maximizes the value of and for the team.
Thanks to Scrum’s accent on transparency and constant communication, the team grows and becomes better more rapidly with members of the team expanding their skill sets and becoming better at what they do.
The team also gets value thanks to the fact that the Scrum framework gives them a certain autonomy and helps them avoid the stresses of a more traditional software development process where they get inundated by assignments and tasks that are pushed on them.
Of course, the company that adopts agile software development also gets value out of it. Its products become better, the customers are more satisfied and its employees experience better job satisfaction.
The software development process is a living thing and no process is the same. Therefore, it would be somewhat naive to believe that absolutely every software development project or team has to (or even should) adopt Agile.
That being said, the many positive impacts of agile practices on the software development process can only be ignored at one’s own peril.