… continued from post … “Being Agile in a Waterfall World (Part 1)”
So how do we work in an agile manner in our waterfall world?
While people like the adaptive nature and speed to delivery of an agile approach in software deployment the one area that raises real concern in big projects is that the Iterative approach will lead invariably lead to “Scope Creep” and attitudes of;
- “I do not know what I want but will tell you when I see it”
- OR – “This is my chance to get everything I always wanted”
- OR – Continuously “tweaking” the requirement and never getting to a conclusion
This is a valid concern where users are not trained/encouraged to focus on what is really needed and/or the IT Delivery Staff are not empowered to push back. It can and does lead to all sorts of problems with scope, deadlines, costs, etc.
What we really need is an approach that combines the accountability scope control, and predictability of a waterfall model, with the agility and adaptability of the agile model. Lets call the approach the Agile-Waterfall and define a set of principles that we would like to be present to govern our projects;
Accurate Project Scoping is absolutely critical for determining commercial & delivery agreements between customer and supplier/IT Dept. So our Agile-Waterfall philosophy should emphasis the following;
- Define the minimum necessary requirements to satisfy the business need upfront (our “must haves”)
- Capture the remaining requirements into a “would be nice to have” grouping
- Organise the project to deliver based on business architecture with realistic functional area sequencing
- Promote the ethic of requesting & building just enough to work effectively
- Measure and report on progress by a deliverable which is a working component not document artifacts
- Utilise Agile principles within the delivery of these components but keep the waterfall control elements to monitor spend of both time & money and also scope creep
- Build team-units that have all the requisite skills to take ownership of delivery of individual components – from requirement to working software
- Build an environment that encourages people getting invested in the project
- Involve the users actively in the execution of delivery
The following diagram is a representation of how a project could be represented to allow us to be Agile within the confines of our discipline scope
We still perform a “Discovery” exercise to gather the vision of the project. The level of detail gathered should be enough to Define Scope and in a Fixed Price Contract define Time and Cost.
The Project is then organized around logical blocks of work that are executed in a sequence that makes business sense. Foundational elements such as major DB modifications, Product Definition & Parameterization Extensions, etc are done first to allow the business components to progress without too much inter dependency. Foundational components also refer to big requirements that span many business areas – although these should be kept to a minimum. High level approaches & guidelines need to be defined to allow the teams to work in a consistent manner.
The requirements are divided into blocks of work that focus on specific business areas and are sized to allow delivery within a maximum targeted sprint time frame, i.e. 2, 3 or four weeks each. The reporting of progress to the project sponsors should be at the Business Component Completion level and no lower
Each business component should have a maximum manday effort and cost allowance to achieve its target. It is the responsibility of the team assigned AND the requirement(s) owner to ensure these limits are not exceeded. Standard Change Control procedures can of course be implemented to cater for those situations where more time is necessary due to under estimation or unexpected complexity. The teams must build the bare minimum necessary to meet the “Needed” requirement; excess features & additional requirements can and should be pushed to subsequent phases. This encourages users to actively participate as they know the delivery organization is only saying “Not Now” rather than “No” to their requests. The business component’s rollup into the deliverable “Phase of Work” for the formal SIT & UAT activities that are carried out once all the components are completed. There should be a Test Support & QA activity running in Parallel to sign-off on the individual business components as they are completed.
Each Business Component can be viewed as follows;
Each Requirement goes through an iterative process to first deliver what is necessary and then within reason/scope deliver what is additional. Each Business Component can be comprised of one or many requirements relating to a particular area. A business component’s team will deliver;
- Working and tested software to the project phase
- Sufficient documentation to justify the deliverable and its approval by the user community
- And Optionally they can deliver excess feature requests & requirements back to the master list for inclusion in later phases.
Each business component team must comprise people with the following skills Business Analysts, Developers, Testers and Users. One member of the delivery team will assume the lead role for monitoring and reporting on progress and issues.
Consider the Principles contained in the Agile Manifesto below (also see http://agilemanifesto.org/principles.html)
- The highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development
- Deliver working software frequently
- Business Users and Development Teams must work together daily throughout the project
- Build projects around motivated individuals with the proper support and environment and trust them to get the job done
- The most effective and efficient way of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote a sustainable development cycle
- Continuous attention to technical excellence and good design enhances quality
- Simplicity – the art of maximising the amount of work not done
- The best architectures, requirements and designs emerge from self organising teams
- At regular intervals the team reflects on how to become more effective and changes accordingly
By viewing how a project is organized and enforcing the scoping boundaries (for budget, effort and schedule control) I believe it is possible to practice each of the above principles for a Business Component delivery structure and work in an Agile manner inside a Waterfall focused project environment.
Some additional thoughts on various approaches and practices that can assist us with moving to Agile in a Waterfall world;
- Get the business community socially invested and involved early and keep them involved throughout the project – To get maximum benefits of using Agile principles in a project it is advisable to setup and staff a Model Office at project commencement. A Model Office is composed of a group of the best users who have an intimate understanding of the company and are empowered to make decisions for the betterment of the organisation. The model office is the liaison between IT Delivery and the user community and from the IT perspective they are the user community. The Model Office manager should in theory report to the CEO or COO. I will deal with the concept, value and structure of a model office in a later post.
- The Model Office should be comprised of people whom the company finds difficult to extract from the day-to-day operations due to there importance. If you are going to spend $Xm on a project surely you want the best people to see the money is directed at the right requirements
- Promote the following basic Design and Coding principles. These are development language agnostic, I will also discuss each of these in more detail in a later post;
Test Driven Development (TDD) & Iterative Coding Write your program/object in steps and making sure each part works before moving on to the next part rather than knocking out 2000 lines of code and then trying to compile and test it. This is a fundamental part of TDD.
Iterative Development Get the basic requirements finished first for assessment, then add in any additional features or requirements which are not beyond the original agreed scope.
Use of Single Function Design provides discreet blocks of code, programs, objects, methods that do “One Thing”. These blocks of code either work or not, they are easy to test and then move on to the next one. You then combine these pre-tested units into more complex structures where all you are doing is testing the combination not the core logic. This leads to faster deliveries, higher quality code and a higher degree of re usability.
DRY (Don’t Repeat Yourself) is a coding model that promotes avoidance of duplication. It is about expressing information/logic in ONE PLACE and leads to better consistency in code and is easier to maintain. Be aware though that using the DRY approach does mean you need to refactor code as you progress to remove the duplication created by the introduction of new items.
Data Driven Engine programming is a technique where you build code that reacts differently to the data used to configure it and data passed to it for processing. Where possible building this type of solution will allow greater flexibility for reuse and more solid code which does not have business logic imbedded in the code, so when change happens you change the control data not the coded logic. This works best with the “Single Function Design” approach.
Defensive Programming is a technique where you check if something will fail BEFORE executing it and make a decision on corrective action or controlled degradation of the application. (e.g. checking if divisor C is 0 before executing A = B / C or if program/object XYZ exists before using it) Do not confuse defensive programming with checking the result of an operation AFTER execution. That is “Reactive Programming”.
Structured Programming Techniques alludes to correct design of code before you sit down and write it and the proper use of structured elements within the coding model to allow for ease of maintenance and understandability.
And finally for any project – Test iteratively and Test Often – From a testing perspective let the users see and play with what has been built as soon as possible. It does not have to be a full blown UAT style exercise but at least get confirmation that the deliverable is OK in the eyes of those who requested it. Finding issues as close to the point of development as possible reduces cost in changes / bug-fixing. If possible introduce a regime of “Continuous testing”.