I haven’t been posting much on case management lately, and have been focusing on other topics. One post I read the other day about software development really got me thinking about unstructured processes again – I thank Mike Gualtieri for his great post on “Agile Software Is A Cop-Out, Here’s What’s Next“.
Mike makes an interesting point about agile software development methodologies. Whenever I hear about agile methodologies I get confused – since top software developers and designers always used agile as part of their bag of tricks – just never codified it to death. That is what I see as the main failing of agile it started as a way to spread knowledge aen experience, but is now trying to morph into a standardized methodology. It took various apparent truths about software development and then tried to build a set of “rigorous” processes around them. The problem is that “agile as process” took on a life of its own and lost the original purpose. From my perspective that is why a manifesto works much better than a methodology/process – but once a manifesto is hijacked by consultants and vendors – they immediately make it a “process”. I actually think that is what is happening in the case management\bpm debate too – what needs to remain as a flexible methodology supported by tools, is slowly being killed so that it can be standardized.
What I don’t get is that software development is a shining example of what people in the process community call knowledge work. As far as I can tell, a lot of the latest thinking around managing knowledge work is being done by the business process and case management communities. Even though most of the people talking about tools for BPM and case management are software developers themselves – the tools and methodologies advocated by BPM\Case management are not being adopted by the software development and operations community themselves. I see this as vendors not eating their own dog-food (or maybe not drinking their own Kool-Aid) and I have been posting about it for a while – see my last post on this and Scott’s great rebuttal here.
So from my perspective a lot of the thinking around knowledge work is for techies and analysts talking about “other people’s knowledge work”, not for the work they themselves do. I don’t understand the wide gulf between knowledge work as it is done by software developers, consultants and analysts – or any other “specialty” knowledge work, and the work done by “standard” business process knowledge professionals and executives (who seem to called case workers by the community?) –
1. All software development in commercial enterprise is being done in service of a business process – therefore all software development should also be considered part of business process management. It is a sub-process of the overall business “aha to ka-ching” process – from an idea to increase\enhance business to the implementation and deployment of that idea through software.
2. Software developers are knowledge workers. Their macro processes are the same as those for any knowledge worker. Like any knowledge worker they also use specialty tools, tailored for their specific domain. Therefore a BPM tool that isn’t used to support software development as a process (e.g. Waterfall and ITIL, or Agile and Iterative methodologies) while connecting to domain specific tooling is a cop out, a way for vendors to say “use this tool for all other knowledge processes, but of course I won’t use it for mine”.
3. Analysts and consultants are knowledge workers- if they aren’t using a tool for managing their own knowledge work, then they too suffer from the “all knowledge work except mine” syndrome. If all they use are standard productivity tools for their work (e.g. email, wikis, blogs, twitter, word processing, spreadsheets and presentations) – then I would ask them what is keeping them and their organizations from adopting the tools they say your organization should adopt.