Agile Practices in Reality

I am reading up to write the Agile Analysis Certification exam; and it is so exciting because it so clearly articulates some thoughts that I’ve been mulling over on a particular issue – how to ensure a delivery/implementation adds value by the time it is delivered, bearing in mind the time gap between the time the initiative was submitted, and the time taken for the code drop. Some very familiar terms within the solutions delivery space are ‘scope closure’, ‘completed design/integration/architecture’, ‘out of scope’, and ‘change requests’.

Agile Extension practices advocate that what makes a truly agile space is being able to conform to current realities to ensure value is given with the delivery. Overlaying this in reality gives a whole new perspective on scope closure, which currently ensures that a user team coming back to change what has been earlier agreed on will have to go through a change request – it is either the current delivery goes ahead to deliver what has been earlier promised or it is halted to accommodate the new changes leading to additional costs, or completely cancelled to accommodate the new/enhanced requirements.

You hear developers saying the code already developed will be compromised; the design team says they have to go back to the drawing board, the BA team saying they have to do impact analysis all over again, the vendors claiming certain work efforts billed have been used up and cannot be transferred, thereby requiring a new commercial proposal; the question burning through my mind in this agile era is; ‘how can these agile practices be applied in reality while combating the risks of additional cost and longer delivery time’?

 

Learning Objectives

The business analyst needs to understand that to ensure deliveries are truly agile, the requirement documentation must be extensive yet simple. The “extensive” comment here is not referring to wordy or bulky documents but to clearly spelt out scenarios, use cases, business rules, system interactions and what will not be delivered with reasons why. In addition, the documentation must not be one that will lead to a rigidly built system. Care must be taken to ensure reusable and configurable code that ensures the ability for changes in requirements at short notice at any stage of the delivery process, especially during SIT (System Integration Testing), IAT (Implicit-Association Test) and UAT (User Acceptance Testing) as these are the stages where changes become expensive, prohibitively at times.

 

Key Arguments

1. The agile mindset must be applicable across the entire IT space for all teams who are involved in the solutions delivery value chain.

2. There are specific practices that must be embraced by each team in the value chain to ensure a truly agile environment – extensive requirements analysis and subsequent documentation from the BA, reusable design/integration from the design teams, reusable/configurable code from the developer, an open mind from the tester/QA personnel.

  

 

---

 

About the Author

Olabisi Adesina is a senior business analyst of 10 years and counting with Telecoms domain expertise in Africa and North America; and some work in research/healthcare. An avid follower of trending, innovative and value adding applicability of best practices in Business Analysis. Olabisi holds several globally recognized IT industry certifications (CBAP®, IIBA®-AAC, PMP, ITIL, Six Sigma Green Belt); but he always passes the message across that his core certifications are CBAP and IIBA®-AAC while the others are simply add-ons to support it. In addition, Olabisi holds an MBA from Bradford University in the UK and is currently working towards getting TOGAF 9 certified and becoming a regular content contributor for IIBA.