Tag Archives: roles

Practising your Process

My very sincere thanks to Simon Powers for posting the ‘onion diagram’ in his ‘What is Agile?’ post on LinkedIn and for answering my question. The post is also available on his own blog http://www.adventureswithagile.com/2016/08/10/what-is-agile/
It shows ‘tools & processes’ separate from ‘practices’. I’ve been thinking for a long time about whether there is any real difference between process (what) and procedure (how) or if they are simply different levels of detail. I think I’ve just been convinced that the equation I’ve been searching for is:

  • process + practises = procedure

Simon actually listed in his answer to me, ‘roles, interactions and artifacts’ as the difference between the set of Agile practices and the set of Agile processes, so I’ve corrupted his definition for my own purposes but I haven’t broken his diagram so I hope he’ll forgive me. (Or maybe I don’t understand whether the layers of an onion diagram are inclusive or exclusive.)

I think making the process one of the practises would make the function recursive and this is supposed to be one of my Lisp rest-days. If my process diagram shows roles or artifacts then I’m sure I’ve moved into the realm of specifying practice. Interactions may be input-output that is part of the definition of the process, so it is probably necessary to split them down more, into message type & format.

Actors and Roles

For some time I’ve been thinking that while the ideas behind top-down analysis or functional decomposition are useful, our model may be untrue. It is quite compelling to believe that the atomic functions in a complex system build up to form compounds and crystal structures and rock formations naturally but what if it is all a sea of atoms and we are seeing faces in the breaking waves? Our over-active brains, so keen to classify and pattern match, could be deceiving us.

The first person I ever heard express a similar view was a trainer explaining the PMBOK, the ‘Program Management Body of Knowledge’. He explained the lowest level of the standard then asked us, in two teams, to guess how related functions were split into named sets. We came up with completely different answers. “That’s right” he said. The groupings were arbitrary: notice some similarities, think of a name, find more functions that fit that description or change it, repeat.

The ‘application landscape’ of an ‘organisation’ (another constructed hierarchy) is a sub-network of the organisation’s business processes. We could draw a huge network of tiny processes, connected by message flows but we prefer to simplify beyond necessity and discuss systems and sub-systems, products and services. If we found a competitor to be out-marketing us, we’d cut it a different way; or we’d restructure departments to show how much we’d changed.

Today I was discussing how the job of Project Manager might be split into its constituent roles. Mapping roles is something I’ve thought about many times before. Today, I suddenly saw for the first time that ‘role’ is only the name we give to a set of functions that we consider to be related in some way.

I realised when I asked “Can you write user-stories for roles/’actors’?”, thinking of using a conventional format for Agile user-stories and saw that you could:
“As a [role], I [do a type of thing] so that [the business value it provides]”
The things you do define the role, not the other way around.
If a role is nothing more than a named set of functions, and standard job titles are just a design pattern for a typical set of functions then everything is mutable.
Similarly, if your organisation is performing the wrong set of low level functions, no amount of departmental deckchair shuffling is going to help.