This is the final post on the problems of business process models for automating work, and one that sums it all up: hand drawn business process models simply are not agile enough.
Business Process Models are Not Agile
4
Tag Archives: Agile
Agile Best Practice: Start with the Empty
A co-worker on an agile project was showing me a feature he was perfecting, and it was looking pretty good with features to add and remove various settings as per the design. I wanted to try it. He said “sorry, the create function is not implemented yet.” It got me thinking…. Continue reading
AdaptiveCM Workshop in America for first time
The Sixth International AdaptiveCM Workshop will be associated with the EDOC conference this year, which will be held in Quebec City in October 2017 and is the first opportunity for many US and Canadian researchers to attend without having to travel to Europe. Continue reading
Wirearchy – a pattern for an adaptive organization?
What is a Wirearchy? How does it work? When should it be considered? When should it be avoided? What are the advantages? This post covers the basics elements of a Wirearchy. Continue reading
Emergence versus Entropy in Management
Julian Birkinshaw professor at the London Business School had an interesting article in Forbes a couple weeks ago titled “Managing Complexity: The Battle Between Emergence And Entropy” which comes close to, but falls just short of, making a good recommendation for dealing with complex organizations. Continue reading
The Origin of Reductionism
I have written many times about how culturally we have a tendency to want to simplify problems, and solve the separate parts, and this is reductionism. Scientific management is based on this idea, and it is one of the ideas that leads to problematic BPM implementations when your the process is truly complex. In this post I consider where reductionism cam from. Continue reading
Race-cars, Drivers, and Mechanics
I met with a Fujitsu executive last week, and we naturally got onto the topic of software development methodology. I presented my case that it is critical that programmers know the actual customer because 90% of all decisions that effect usability are made by the lowest programmer. He countered with a story from his own experience of how a race car mechanic and driver have to work as a team. Continue reading
