Unless you work in the financial services sector, where risk management, formal approaches to risk elimination and rigorous change management processes dictate a highly formalised traditional approach to software development, then you would certainly have asked yourself the question: “Is there a better way to develop defect-free software quickly and effectively?”
In short, the answer is definitely
I am fortunate enough to be part of a business which has utilised agile software development methodologies, albeit without a formal identifiable name initially, for our commercial shrink-wrapped software development projects since as early as 1991. The approach has ensured close focus on customer requirements, legislative changes, simplicity and incremental feature releases, and in turn, has improved software delivery and software reliability, has decreased software development costs, which in turn increased financial margins, improved customer retention rates and lowered analyst and developer churn rates in the process.
In time we began to realise that our approach, at least partially, approximated what had by then become known as Agile Development and we adopted useful portions of both XP and SCRUM as our systems development methodology.
This hybrid XP/SCRUM approach placed careful emphasis on customer intimacy in the development process rather than relying on reams of rapidly dating requirements, specifications and designs. It leveraged developer, analyst and tester experience, courage and domain-expertise in creating a richly test-driven approach to software R&D in an environment of pair-programming (for knowledge dissemination and succession planning), empowerment, innovation and responsiveness.
A common misconception of traditional evangelists when evaluating the Agile approaches is to assume that product planning, risk-management, project management and accountability is absent when deploying agile development. Irrespective of the system development methodology deployed on any software project, including XP or Scrum, planning remains an integral part of the ultimate project delivery. How this planning is conducted varies markedly, however.
Whilst XP by definition relies on small agile coding groups working on software features which can be delivered in a relatively short timeframe (in my experience between 1 and 3 months is optimal) a concept known as time-boxing, the project managers need to retain a strong view of the ultimate long-term strategic goals and objectives of the project even though user requirements may at times be altered or amended due to changing customer needs which are identified through early customer involvement in the coding and testing of the features, thereby providing early and very regular feedback loops for the analysts, developers and customers alike.
Because customers get to have early input into the design as well as “see” and “experience” the application early in the development process, customer acceptance is less traumatic and disruptive than the “big bang” approach of traditional system development methodologies.
Projects in our business typically follow a similar approach.
Firstly, we plan “the system” at a high level, conceptualising the apparently critical features, requirements and characteristics of the system in much the same way as the Waterfall method. However, at this point we do not “fret the details” and aim largely for a conceptual framework with anticipated resources, timelines, rough estimates and broad functional requirements.
Secondly, we insert multiple “exit points” or project milestones into the plan and we ensure that we do not exceed a maximum of 3 months (even shorter time-boxes are preferable) between each delivery milestone.
Thirdly, we ensure that the software is “deliverable” and sufficiently complete at each milestone to be workable for end users in order that they be able to deploy a fully workable solution, run beta, or, at the very minimum, perform live-testing at each milestone.
At this point we revert to a true Agile model with each team roughly following the overall high-level plan but working in small agile teams, together with selected customers, worrying not so much about the plan itself, but rather the as yet undiscovered customer requirements and needs, within the scope of the project, which are rapidly reduced to code and software in a useable fashion.
Intertwined with the development approach is a strong test-drive-development (TDD) flavour which ensures weekly builds, iterative early testing, constant feedback loops, and, a real focus on the detection of defects as early as possible in the software lifecycle.
Project teams are rewarded for reflecting customer requirements, for meeting delivery milestones, for software quality, reliability and the fact the software works, and, the accountability which the team assumes for their communication, teamwork and the overall project.
“Perfection” in this approach is defined by progress and customer satisfaction not by a prescriptive initial plan, even though such a plan does exist and gets altered constantly during the lifecycle of the project - the plan remains a guideline.
Share