Explore implementation challenges faced by Agile principles
Last week I asked the question “Have you read the Agile Manifesto?” , and started a series of posts that look at 12 Agile principles, and have a bit of an in-depth look at the implementation challenges.
I feel like Agile has failed to deliver on its promise. I believe the reason for this failure is not a fundamental flaw in the Agile process, but rather because it is poorly implemented in most cases.
This time, I’m looking at the second principle that goes a bit like this:
We welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
I think You might end up saying this for all of these principles, but it’s intuitively clear that making changes to a product that give the customer a competitive advantage would be a good idea for the customer, presumably also for the software company.
It is not unusual for a part of the program to take months or even years to deliver, nor is it unusual for business requirements to change significantly during that time period. Requirements should really be expected to change over the course of the project, including the later stages of the project.
If the development company can manage these changes, and incorporate customer feedback all the time, then the outcome for the customer will ultimately be better. This should be good for the software company as its reputation will benefit, and the bottom line is presumably with it.
We’ll discuss technical and relationship management challenges soon, but one problem that’s really clear in applying this principle is lawyers.
Or more specifically, contracts. Often, if not always, there will be a contract to deliver software that does a certain thing, or meets a certain set of requirements. This contract will be agreed upon before the coding starts and will specify delivery dates, payment milestones, penalty terms, performance requirements, and a whole other list of things that are emphatically set out. Not graceful.
There is nothing “agile” about sticking to a legally binding contract. And there really won’t be – it’s just the way business is done.
Many supposedly “Agile” projects start with a set of contractual terms Must realized. It’s then up to the technical team to be agile, but only as far as they don’t miss any deadlines, skip any features, release any penalty clauses, or…you get the idea.
This contractual deficit cuts both directions. As the project progresses, an advantage can be found to be redundant from the requirements. But, developers may find themselves creating said features anyway, since there are contractual requirements to offer them. Likewise, the customer or client may find that he cannot add something that he has discovered he wants because it is not in the contract or is specifically excluded.
Working on projects mired in contractual disputes can destroy the spirit of the teams involved – on both sides of the fence. There really is nothing worse than creating functionality in an app that you and the customer know literally won’t be used, but doing so fulfills a contractual obligation that neither side will undo. An exercise in absurdity that I would like to bet more than a few readers could identify with!
Despite contracts and legal issues, making changes late in the day can be incredibly technically challenging, sometimes to an unattainable degree. If a customer suddenly decides they really want a web app, and not a desktop app, there will be prominent Rework, no matter how good the product is designed.
Even the least extreme examples of changing requirements late in the day can be challenging. Make changes to the way product functionality becomes progressively more difficult as the project approaches completion. Even with serious adherence to good coding practices, segregation of interests, etc., there is simply no way around this.
Of course, none of these changes that occurred late in the day will count toward the contract.
For this principle to really apply, and work as intended, there must be an endorsement for this at the organizational level, and this recognized at the start of the project.
This requires that a very robust change management system is in place, that the contract recognizes the change management system and allows explicit approvals of changes in scope. (I expect any lawyers reading this might have had a heart attack)
Change management processes and procedures should be written in such a way that it can support the failure to provide an agreed portion of the functionality, and also not lead to a customer being asked for a refund. (this is difficult). Likewise, it requires consultants to offer jobs that were not initially specified without increasing the price. This is also difficult.
Good change management begins with open and honest personal communications within the program organization and externally with clients. For example:
- Developers must be open and honest with their management when they are late for a feature.
- Management must accept that estimating features is difficult and that developers will sometimes fall behind
- Management must deeply understand contractual requirements and act quickly when a customer requests something that is not in the contract
- Similarly, management should prevent the development team from working on features that are not in the contract (developers are sometimes neglected)
- Customers should have a channel/forum where they can express their changing requirements
There should be a formal process in place to record the changes that arise from these discussions, charge them (if necessary) and attach this to the contract.
For the technical team to be able to integrate Project Level Change Management, the software must be written in a highly modular way, so that making changes in one part of the software is as less likely to have side effects in another part of the software as possible. There are many patterns, practices, and coding patterns that help in this regard.
If it is accepted that the functionality, and therefore the code, will have to be changed during the development process, it will be necessary to implement a robust automated regression test. This will give developers confidence to make changes, and it should give management and customers confidence that doing so won’t generate any (or many..) new bugs.
Building into contractual and technical change management processes to support this principle is very challenging. The benefits are (of course) obvious, but the path to Elysium is fraught with dangers.
Retrofits to the Brownfield project may be impossible depending on the contract that supports the work.
But, if the goal is to operate in a truly ‘Agile’ way, none of the 12 principles can be ignored, and so efforts must be made to move the team and the organization as a whole into a mindset of accepting technology – and contractual. Changes throughout the project lifecycle.