Agile development negates the software development role

Published on: 22/11/2017

One of the most difficult aspects of developing a new web solution, or any piece of software, is to define the requirements you have of it.  In fact it’s virtually impossible.  How can you be expected to do this unless you know what can be actually developed?!

Development practices try to address the development of new software in a structured process, making the whole process as “Agile” as possible.  The current favourite is Scrum “a framework for developing and sustaining complex products”.  It starts off with a definition of your requirements for the new service.  Recognising you can’t do this yourself, you’ll need a “Requirements Analyst”, who may work with / be a “Business Analyst”.  This person will then produce a brief / spec for a development team, who will employ Scrum methodology.  A Scrum Master will manage the development team / process, with “sprints” and “Retrospectives”, “Backlogs” etc.

Don’t worry about all of this – it looks after itself.  Remember it is described as “Agile”.  Let’s just hope the Requirements were correctly defined and you get what you really want.

It is virtually guaranteed that your requirements will NOT deliver what you actually want!  Why? Because once you have seen the outcome of all this work you will naturally think – “now I’ve seen the outcome, what would be really great would be …”!!!  Too Late!

Alternatively cut out the risk and use XPOR to develop the process yourself!  Could things be any more agile?  Not everybody wants to “own” their own solution.  But you do – that’s what makes the difference - use XPOR.

By the way, for those of us who watch Rugby – the least Agile thing on the park is the Scrum!  Here’s some interesting further reading from a respected Business Analyst.