Often times, the process and procedures that development must follow in order to comply with CM needs were developed by the people who receive the outputs of development but who dont necessarily perform the development activities themselves. These process-area experts are the process designers and the developers are the end-users of their process.
The conclusion of CM to an interface, not an implementation was to essentially invert or "flip" the relationship between who is the process "producer" and who is its "customer." The Principles of Lean Thinking suggest that processes should be designed by the practitioners who are most intimately familiar with performing the activities and their reasons for being a necessary step in the process: Those who receive the outputs of that process are its customers, and they get to specify the requirements, but not the implementation.
If true, this could perhaps be a statement of a different principle that we might call The Customer-Inversion Principle of Process Design:
- Upstream Development procedures should not depend on downstream CM procedures, both should depend upon the abstract interfaces represented by development's exit criteria and CM's entry criteria.
- Procedures should not be designed for their practitioners by the upstream customer of their results, Practitioners should design their own procedures to meet the requirements of their upstream customers.
It also somewhat "inverts" (or at least turns on its head) what might be the more stereotypical perception by many agilists of CM as "controlling opponents" into one of "collaborating customers", and hopefully helps lend some a new perspective about how to successfully pair with other organizational stakeholders making additional demands upon the use of more formal standards, documentation, and tools upon an agile project. (See my earlier blog-entry on Building Organizational Trust by Trusting the Organization.)
Surely there must be some exceptions. What about when development has absolutely no CM knowledge or appreciation whatsoever? Should a knowledgeable CM person define development's CM activities for them?
To me this sounds similar to the situation of an expert needing to play the role of coach for a more junior engineer. A more directive or coaching style of leadership may be required, where CM doesnt necessarily give all the answers, but still plays a strong collaborative role in specifying not only their requirements, but in educating development about existing SCM patterns and their applicability and context, and helping them choose the most appropriate patterns and tradeoffs to design the CM procedures that development should use.
If development is not yet able to understand and/or is willing to be initially "told" what to do - then "telling"/directing (instead of coaching) might be the first step. But ultimately I believe practitioners of a process need to feel a sense of ownership over their own process and procedures if they are to continue being effective. By helping them understand the process requirements, and the applicable patterns and principles, we help them become better developers, and better advocates of effective CM. At least that's been my experience.
What do you think? Does it sound nice in theory but not work "in practice" in your own experience?
4 comments:
I think it depends on your team and the leadership within the team.
Many people are just focused on the job so never take the time to think of process.
If people are new in an organization they are more interested in fitting in and proving themselves, not upsetting the apple cart.
I think expecting a team to do everything is as mistaken a direction as thinking the team does nothing. Why the wild swings between approaches? Can't we realize everything is the production of multiple interacting forces. Trying to simplify life by saying one part of the forces don't exist is just hiding from reality.
Hi Tod! Point well taken about leadership styles/needs and teams of predominantly new or inexperienced members. There is just no substitute for knowledge and cluefulness.
Regarding "expecting the team to do everything" and the "wild swings between approaches" - I was thinking that this was actually the more balanced approach. Instead of expecting either party to do everything, I thought I was suggesting they engage in a two-way collaborative partnership (with the practitioners treating upstream stakeholders as "customers").
This would achieves separation of concerns for process design by separating process interface from implementation and policy from mechanism. In doing so it also adheres to principles of lean thinking and agile values of collaboration over constract negotiation.
At least that what I was hoping :-)
I can definitely see the need to agree interfaces with the customer. The obvious parallels with dependency inversion in OOP show that the approach isn't only plausible, but is desirable.
In order to maximise the throughput of the team, would you agree that this 'customer inversion' should be used only when looking to solve a customer's problem with how they interact with the team? That way, the developers can choose a process that best suits them.
Should we deviate from this nirvana if the customer has no immediate issue with it?
I'm thinking of the way in which I do OOP. The dependency inversion principle for instance, I don't implement it straight away, I just use it to alleviate certain types of pain.
Hi Tim! You ask "should we deviate from this nirvana if the customer has no immediate issue with it?"
Good question! I admit I dont have a ready answer. My first reaction was to think "sure! why not!" My next reaction was, how do I know if the customer has no issue with it? Did I try to find out if they did? or did I assume they didnt simply because they hadnt yet tried to inform me? Did I do a good enough job of asking in an appropriate way? Did I miss an important stakeholder?
I think those are all good questions to ask. Maybe the answer to them in any specific instance is less important than making sure to ask them, and to listen to the answers I hear back.
Thanks for making me think about that!
Post a Comment