Creating a Global Engineering Culture

“Fixed price, fixed deliverables, and fixed schedule” contracts are just about the worst way to write contracts involving software, yet they are the most popular – so what are some techniques to use to fix that?

Organizations that perform professional services for software development or develop software on a work for hire basis are usually engaged bound by extensive contracts.  These contracts are typically characterized as “fixed price, fixed deliverables, and fixed schedule.”  These, of course, are the vertices of the “Iron Triangle of Software Development” and foreshadow a poor outcome due to issues that make the requirements gathering and project estimation phases that precede contract negotiation so prone to error.

Given this, the question becomes one of “how can I engage clients in a way that allows us each to achieve our goals?”  If Agile and Lean methods are the status quo for good development practices, how can I write contracts for development services that embrace this mindset and let each side achieve it’s goals better?  This lecture and roundtable explores the many facets of this question and provides the attendee answers that they can use going forward.

For many, the idea that you can transform an organization from the PMO outwards seems odd, if not impossible.  But my experience says that this is becoming a trend that more and more clients are asking advice for. 

We know that for an Agile transformation to work, we need to engage not just the Delivery Teams to approach work differently, but we need a change agent high in the organization to support that change in mindset.  I’ve always found it difficult to find that right person in an executive leadership role who is willing to have the courage to “bet the company” on a new and unproven approach such as Agile and Scrum.  As coaches, we tend to start “pilot” projects, and hope that traction will occur “once everyone sees the great results that we get.”  But I think that this approach is fraught with peril of not getting the right project to start with, not getting the right results immediately, and not motivating people by seeing results from a process that they are not comfortable with.

I think I’ve come upon a new approach that works better.  Instead of trying to “sell” Agile at an Enterprise level, embrace pure Lean principles high in the organization and work with the PMO leader at the organization.  Once they are comfortable with ideas such as “more leadership and less management”, “shorter concept to cash cycles”, “enabling Lean Startup mentality for disruptive product development”, “always looking for the elimination of waste”, “exploiting variability through appropriate cadence control and appropriate utilization rates”, “delegated authority”, “continuous improvement”, and “rolling planning”, the PMO becomes a terrific agent for instituting change, because they are usually already endowed with the right responsibilities and accountabilities that can push the organization forward.