After a couple of years of project starts and stops that reflected a lack of common direction at my current employer (that was and is an otherwise great place to work), the last several months has seen a changing of the guard up and down the organisation such that an new direction is now agreed on.
For me, that means actual projects that are seen to produce results. One of the new direction's impacts is to use agile development on as many projects as possible, as preached by our new PMO manager. My question on agile has always been: where does the backlog come from? If creating a new product of some sort, then it is the vision of the product owner that gets you started and evolves over time.
But what about 'run the business' projects? Changes to existing process? How do you know what to work on?
The answer is what I call 'agile in context'. The context is the business processes of the organisation, and I mean all of them as defined in a process architecture. Before agile development, a project is scoped by identifying what processes are impacted (given business objectives drawn from overall strategy). The main steps are to
(1) identify process experts in the business
(2) assign a business analyst to work with the experts to first document the as-is process at a task level (we use BPMN 2.0 for consistent modelling approach), then
(3) define the changes needed to create a to-be process
(4) examine all the changed and new tasks to determine if they need automation
(5) define the functions being automated for each task
(6) write the functions as user stories
Voila, a set of user stories to put in the backlog. Given access top those experts (and that is crucial), the above steps take 2 to 4 weeks for a typical project.
There are other aspects of the project that are needed, like the overall systems architecture to support the functions/stories, maybe some data modelling for new/changed data, technical stories for whatever the system architect says is needed...
But all those things support the project in delivering the value of the function-based user stories. Given a backlog, use the methodology of your choice (ours is Scrum) to define the number of sprints, allocating stories to sprints, running sprints to build a solution(s), add/adjust stories based on results, etc. etc. The known value then is that agile delivers results much faster than other approaches
Over the years most of what I have read about agile was (1) focused on what happens once the backlog exists, but that (2) you didn't do requirements, like in the form of BRD, always presented as too big, too costly, and wrong once you start development. Fine, but what did you do to get the backlog, the things that a solution is 'required' to do? How can be your sure you don't build the wrong solution?
Placing agile in context of an organisation's processes answers that question. The above approach to create a backlog is straight-forward and repeatable. I have now finished one of these projects, with six 2 week sprints; previously it would have been expected such a project would take three times longer. Now I am starting process modelling on two more projects and advising on three others. Prognosis for those projects is also good.
So after years (decades) of being against or on the fence, I am now all-in for agile development, in context.
Thoughts, anyone? comments welcome.
