Is your approach to projects Agile or Fragile?

02 May Is your approach to projects Agile or Fragile?

Agile is close to topping the league tables today for most throw-it-about-word. It sounds great and promises a lot, BUT, are we all on the same page? Does it deliver or is it Fragile? In the context of developing and implementing a business change or technology solution, or both, the purpose of Agile is to deliver something good, quickly and at the lowest cost. It’s a joint process between the different people involved (customer, supplier, provider) to achieve the common goal as effectively as possible.

But what are the points we need to be wary of?

Firstly, Agiledoes not mean that we compromise the quality of our efforts by merely reducing time and effort (business thinking, design, development, testing and deployment), and then wonder afterwards why things did not turn out so well. We can’t forget the law; scope = (time) x (effort). Reduce one, and the others are impacted.

Digging deeper though, it’s worth adding more variables to our law. On the scope side of the equation, consider quality, while on the other side of the equation timing and focus of effort? Not just how much and how long, but what and when. Don’t spend too long conceptualising, but rather create something relatively quickly and assign more scope and budget to business review, confirm, feedback and enhance.

Agiledoes mean an iterative process of thinking, shaping, designing, deploying… and on to trying. We want to get to trying quickly, fully expecting that things will emerge (only) then to cause us to revisit, refine and redo our initial efforts. This really works when we stay focused on the fundamentals and recognise that things are never really fully designed or tested until the people that matter, business users & customers, are actually working the solution, in a real (live) environment.

At Capventis, we advocate Brilliant-Basics, which contains all of the best practice of creating and shaping the solution, while targeting a fast route to deployment and user on-boarding. Then we must factor in time for the business to try out and feedback, and let the project team refine the solution and deliver something truly good; we must Confirm Alignment and recognise this as a formal budgeted stage of the Agile approach. Start with the business and end with the business, allowing good things to evolve. Be strongly Agile, and avoid being Fragile…