![]() ![]() If anything, the latter are more error prone if done by a person. If you think in terms of value of time-spent by a person it's not difficult to understand that situations where creative problem solving is needed are more valuable than repeatable processes. That doesn’t necessarily imply full-on automation coded up, but could equally be very clear rules for people to make decisions in common situations. In most situations “repeatable without introducing extra variability” means some amount of automated decision making. Once in a position where delivering quality (in every perspective) is no longer a problem, the next question should be around making that repeatable. As a sidenote: a common pitfall when organistaions "go Agile" is a foucs improving the latter part, but there is a danger that teams simply end up building the wrong thing better if that’s the only perspective taken. Or as an open question: is delivering the wrong thing right better than delivering the right thing wrong? Whereas the first perspective is about understanding demand/requirements, the second is about building better processes. Are you delivering the right thing, and are you delivering it right. When thinking about quality there are 2 perspectives to look at. company wide) as it is on a team or even individual level where the product might be a deliverable to a downstream team or a tool for internal use. That’s equally true on a macro level (i.e. At the end of the day, value comes from delivering this product to people who have some use for it. ![]() It doesn’t really matter if that product is a small toy, a complex supercar, a piece of software, or something where the product is more knowledge based like in typical consulting work. At core, the capacity to put product or services in the hand of customers is what drives a business forward and generates revenue. The inside is delivery, surround by quality, automation, frameworks and governance. In it's simplest form, the onion is simply a set of concentric layers. Instead it takes a step back and tries to place the various methodologies and practices in context. It doesn't prescribe any particular actions in the way that some project management methods would. The Onion really is a meta-framework, if you will. In future articles I'll come back to all of those, but for now let me start with big picture and walk you through The Onion. While I do subscribe in part to the Ohno "it's the system, stupid" line of thinking, in the end the work still is done by people and so that's a dimension that has to be factored in as well. The last part to think about is that any process or framework ultimately has a number of people to think about. Instead I mean controlled in a wide statistical interpretation, as in "within the bounds of acceptable variation". When I talk about a controlled manner I don't mean a command-control "manage the detail" style. So any system has to deal with understanding the input and how to make sure that input fits the right goals. Delivering the wrong thing isn't the goal here. It starts by knowing what "the right work" really is. At heart my job is usually very simple to define: create a system in which the right work can be delivered in a controlled manner. As a consultant it was only ever going to be a matter of time before I ended up creating my own model for the world around me: the world of (software) delivery organisations. Imperfect as they can be, they're invaluable in trying to organize the world and create clarity between detail and big picture.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |