Commitment Series – Trust & Collaboration

The Link Between Relationships and Getting Lean … is Trust

The large link between these relationships, as in all relationships, is trust.  Trust that commitment means intention to work on it, and not guarantee.  Trust that folks will work actively to fulfill their commitments, regardless of external pressures or difficulties.  Trust that ‘the system’ will keep producing regularly, largely as it has in the past (and hope for a little better).   Despite years of practice spent in low trust methods, we have not been able to overcome the benefits or success of trusting workers.  Projects completed based on better and better Command and Control approaches to project execution has not yielded order-of-magnitude improvements.  In fact, it can be argued that project successes have decreased despite more completed checklists, more comprehensive contracts, more planning, and increased tracking.  Despite increasingly complicated techniques for pre and post-production validation mechanisms designed to try and catch every mistake before delivery, we are not able to approach six-sigma quality with any regularity.  Refer to Deming’s ideas about building quality into the system (Point 3 in Deming’s 14 points)


Lean itself, does not regularly talk about commitment or cross-department relationships specifically.  Many implementations in manufacturing-based circumstances frequently talk about six sigma quality and Service Level Agreements.  While a slightly different context, these can be interpreted in a way to mirror commitment, albeit in more of a promised throughput, rather than delivering specifics about the work.  The major limitation of these forms of commitment are caused by their reliance on standardized work.  Many have discarded thoughts of using SLA for software product development based on this assumed limitation alone. 

The far more ubiquitous context of commitment within Lean is the commitment to trusting the workers (Deming’s 14 points).  The ‘system’ is responsible for producing the work.  If the system is not capable of consistently delivering on the desired commitments, it is unlikely that getting people to say Yes to the commitment will sustainably change that fact.  Deming quipped “the system is perfectly designed to deliver exactly what you are getting out of it”.  If you want something else delivered, trust the people by asking them how we can change the system to change what is regularly delivered.  This is similar to someone who dates another because they love some parts of them, but not others.  Then hope enters the scene.  Maybe they can date them, and just ask their partner to change away from those distasteful aspects.  That way they can stay in their imagined relationship long-term and life will be great.  If done without asking the partner if they want or can change these aspects, disaster results.  If the organization doesn’t change the system from the inside (it’s core), it is increasingly unlikely that the marriage of people and process that combines into ‘the system’ will be successful in delivering different results. 

Trust the historical patterns, or actuals, of the system.  Get to know the system at work from the inside.  Trust the people that you’re with, offer encouragement and inspiration, and accept the results.
Asking for surface assurances based on little understood risk functions doesn’t work.  Denying weaknesses by substituting contracts for trust doesn’t work.  Assuming that getting commitment transfers the risk of not getting a specific delivery doesn’t work. Shoot for collaboration, communication and trust.  Invest in improving the inside.

A Healthy Relationship

Though not as commonly discussed in Lean or Agile circles, trusting your own group and those that are part of the same greater flow of work is a key tenet.  In addition, the need to work closely together is reliant on the groups first getting on the same page.  We temporarily lost the ability to be on the same page, with regard to work commitments, and that partially started to erode the trust.


In borrowing heavily from the works from Deming on management AND the Agile Manifestoon ‘Individuals and interactions over processes and tools’ and ‘Customer collaboration over contract negotiation’, there seems to be plenty of improvement opportunity.  Despite our growing numbers, we have the chance to keep our Sales, TAMs, Product, and Engineering areas collaborating like few software development shops on the planet. 

Our Sales and TAMs group can work with the Product and Engineering groups to not only inform Enablement plans, but also ensure the proper injection of the voice-of-the-customer into Initiatives.  They can both participate more in Portfolio allocation decisions and understand at a deeper level the reasoning behind some of the Roadmap drift. Not only can they help Initiatives get set up and prioritized to succeed, but can continue to collaborate throughout the enhancement’s development journey to enablement. A colleague recently reminded me that just because you gain a commitment or contract from another party, doesn’t necessarily move any of the risk out of your hands to them. If an initiative or specific enhancement who’s benefit or pain is being felt by an area still continues being at risk for it until the benefit is realized or pain alleviated. Lend a hand on getting it successfully across the line, or minimally understand why something else was chosen. 

Our Product and Engineering teams, they can communicate priorities and product visions better through their Portfolio of Initiatives.  They can be up-front and transparent, internally, during the times when the expectations around deliveries are not crystalizing as expected.  Engineering, especially, can professionally demonstrate that they are dedicated to delivering consistent business value, and that this business value is directly aligned with the product and Rally’s vision. 

In the end, frustrations around promises made and not kept, expectations set and not realized will build.  The fact that this will happen is not prediction, but almost unavoidable.  However, the important thing is what we do about that.  It is not an accident that implicit trust has long been one of our Rally Values.  Trust that each group is doing great work, and offer help to see if you can collaborate to improve the relationship and mutual success. Demonstrating that we can collaborate well between departments can differentiate us from other (even fully Agile) companies. 



SummaryCommitment Expectations, Engineering’s Perspective, Good Relationship, Trust


~ by greg frazer on February 14, 2013.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: