Brian Weigel, Senior IAM Consultant, SecureITsource, Inc.
Welcome back to our discussion of Agile development in Identity and Access Management programs! If you missed the intro article, it can be found here. If you are new to this series, click here to start from Part 1. Today, we will be talking about the third tenet of the Agile Manifesto – ‘Customer Collaboration Over Contract Negotiation’. Again, all feedback is welcome and encouraged!
Contracts are a valuable tool for formalizing agreements between parties, and providing protections should one party break the agreement. From software license agreements that almost no-one reads before accepting, to employment agreements when starting a new job, they permeate our society. If you work for (or with) a company that provides professional services, statements of work and non-disclosure agreements are quite common as well. These are what I would call ‘formal contracts’. They are legally binding and enforced through either binding arbitration or a court system.
The principles of Agile Development refer to a different type of ‘contract’, ones that I would call ‘informal contracts’. These are far more subtle, but can be quite bothersome and counter-productive. Anyone who has worked with application development is well aware of (and often cringe at the phrase) ‘requirements document’.
In the traditional development model, the process begins with ‘requirements gathering’ that involves an often lengthy process of defining detailed use cases, ideal path, alternate paths, etc. in exacting detail. At the end of this process, a final ‘requirements document’ is created and sent to the business owner(s) for formal sign-off before it is handed to the development team to implement. Once the requirements are finalized, the development team heads off to implement them in another lengthy phase that often lasts several months and can easily last years. During the development phase, the business has little visibility into what’s being created, and is discouraged from requesting changes. There are some major problems with this approach, however. Let’s go through them and see how the Agile methodology seeks to address them.
The first major issue with the traditional model is that the entire ‘requirements gathering’ phase can last for months or years. While the initial phase is in progress, development is significantly hindered until the requirements are finalized. While developers often will begin working on draft requirements before they are finalized to help keep pace with the overall project timeline, this can lead to lost productivity and extend the timeline of the project unnecessarily due to the inherent volatility of potentially changing requirements. Agile seeks to address this by using a cyclical on a significantly shorter timeline.
- Define: Work with business to understand what problem they want to solve or issue that they want to have addressed, as well as any constraints. This is kept high-level and using business-friendly language.
- Develop: With a mutual understanding in place, the development team can work to implement that request with some latitude and freedom to define how to implement to better align with development and implementation best practices.
- Demonstrate: After a relatively short development cycle – usually 2 weeks to 1 months – the development team comes back to the business and shows what they have implemented (preferably with a live demonstration of the application in action). The business gets to see what they would actually be getting.
- Review: Once the demonstration is complete, the business and development team have a conversation around what the business liked, didn’t like, and what else they’d like to see. Items discussed on the latter two topics feed back into the ‘define’ step and the cycle repeats.
The second major issue specifically involves the static nature of requirements once development begins. With ever-increasing complexity of business operations and dependencies, integrations and interactions with other technologies, and increasingly complex systems, it is almost impossible to foresee and define in advance all possible use cases for a given process. Something is almost always missed, assumed, or overlooked, only to be discovered well into the development stage (and often not until after development is complete and the customer begins User Acceptance Testing), further delaying final delivery and delaying the project timeline. The cyclic nature and frequent customer involvement in most of the Agile development cycle (see above, they are part of 3 of the 4 steps) helps ensure any oversights or problems are identified and addressed in a far more efficient and timely manner.
The final major issue is also related to the time aspect of the traditional model. Businesses are living entities and compete with many others in a rapidly evolving landscape. As such, the requirements defined today may no longer apply next year, or even next month. With a protracted development timeline, there is a considerable chance that the final product will meet all of the initial requirements but be too late to deliver the desired value, or worse, no longer be relevant to the business. The final negative with this approach is that it also maximizes the time-to-value aspect of the project in increases the risk that a competitor will release similar functionality before you and lose your strategic edge. Agile development seeks to address this with the reduced cycle time and by introducing to concept of a ‘minimally viable product’. More on this in a future article, so stay tuned!