Can UML be used for Agile methodologies?
As someone who cut my BA teeth on UML (Unified Modelling Language), I have traditionally been very biased towards using it as a means to document business – and functional requirements. Not that I do not believe that there are not very good alternative documenting methods out there… but simply because I’ve had great results in using it as a comprehensive and standardised method of modelling requirements.
Of course not everyone understands UML. It is also not necessarily always used in consistently similar ways. I have however found that for those who take the time and effort to learn how to use it and how to benefit from its cross-referencing and layering abilities, find it incredibly useful. The ability to model complicated systems in a methodical, simple way as well as the abilities of rolling it out across huge development teams scattered across multiple geographical locations, make it a very difficult argument to not have in your analysis armour…
But then the question … is UML geared for traditional “waterfall” – type projects only? How does it measure up in the agile world? Times are rapidly changing and in the economies we find ourselves in at present, share holders require faster delivery, shorter project life cycles, more proof of concepts and more flexibility to change their requirements at any given moment. No wonder agile methodologies have recently become so popular. They speak to solving all of these demands in practical ways and hence are quickly gaining momentum and are being adopted at break neck speed.
For those Business Analysts who for years have been doing requirement specifications and have been “throwing it over the wall” this new shift in project delivery cycles, pose several new challenges:
There’s now no 3-6 month analysis phases any more
- “Sign-off” becomes more theoretical, short term. Business don’t wander if their requirements will change, they KNOW it will. Their expectation is that processes and systems will be flexible enough to cater for these ever changing demands.
- Documentation complying to and based on lengthy BRS templates is no longer necessarily useful or required
- Even the matter of “Best Practice” is an ever changing and highly elusive subject.
- Requirements using agile methodologies like SCRUM, are now seemingly reduced to five letter words on post-it notes stuck onto backlog boards…
So where does this leave those of use who so much enjoyed the modelling languages that we’ve been relying on for years? Does this mean that these languages like UML, BPMN, etc. are no longer of value? Have analysis been thrown out the window all together?
Not at all! In fact analysis is now probably more important than ever. The approach and nature of how this gets done, has however potentially changed quite dramatically.
I’ve recently had the privilege to meet Ivar Jacobson during a visit he had to South-Africa. Ivar is known as the father of components and component architecture, use cases, the Unified Modelling Language and the Rational Unified Process. I asked him about the above matter and he just recently happened to produce an eBook based on exactly this very question. (Download his eBook here)
In his eBook he addresses some of these questions above with what he calls Use Case 2.0. He describes how this new version of use cases can be applied across all types of systems, developments approaches and types of requirements.
He describes how the best of what is used in use case and process modelling (as part of UML) can be mapped into the agile methodology approach using user story identification, backlog planning and iterative approaches. He then shows how Use Case slices can be mapped onto Kanban boards.
This would probably be quite a departure for most from the conventional way of modelling requirements, but given the increasing popularity of agile development methodologies and their need to still have solid analysis to be done, this strikes me as a very workable approach to bridge this perceived gap in modelling requirements coherently and not over documenting requirements during lengthy analysis phases.
It would be great to get your views on this approach and also on what you have found works for your organisation in modelling requirements in the agile era…
I would love to hear your views on this!