The last MassTLC meeting in July on “Taking your Agile Development to the Next Level – Best Practices and Methodologies” triggered all kind of thoughts; for example:![]()
- lingo is different by the substance is the same
- finally software engineering get’s to adopt practices that have been applied in other practices
- the real problem of resource overloading has not been solved!
Coming from the world of the Mythical Man-Month and The Soul of a New Machine but also practicing for more than two-decades project management following the warnings of the Critical Chain and the Goal with the theory of Constraints (by Goldratt and others) led me to write this blog. The basic idea is the triangle of trade-offs (to the right).
The goal of the Product Development Organization is simple: Deliver the highest business value in the shortest time. Notice that business value has replaced the best quality or excellent product or most customer desirable (ala Good to Great). Notice also that the shortest time has replaced the lowest cost or other variations.
The challenge: But how we do so in a repeatable fashion (i.e. applying development processes) without discouraging new initiatives and innovation in the organization? Before we answer this question, let’s summarize the state-of-the art in processes.
Summary of Agile Processes
There is plenty of literature in this matter; if you have not seen the spectacular work by Mike Cohn at Mountain Goat Software, you owe to review his open presentations. This is only a repeat of the high level bullets from Mike:
|
|
But how do the above processes scale to projects above 10 developers, non-collocated? How do we deal with the Flat World challenge: use Scrum of Scrums; use the Scrum of Scrums or Scrums; create Communities of Practices, etc. Again, these topics are well described in the literature and I would omit for brevity.
Trade-offs
For projects beyond “just software”, i.e. projects involving hardware development, systems engineering, embedded coding, user interfaces, device drivers, application software, all of them to be fully synchronized and with predictable deliveries, the senior manager is faced with the following tradeoffs:
And because “our Public Company bosses” really care about Predictability and Fastest Time To Market (ignoring for this quarter the Efficiencies), we should think about the Conditions for Predictability. Here are my thoughts on this matter.
Less Predictable |
Managed |
Very Predictable |
|
|
Team co-location |
Distributed |
Can be distributed for medium TTM |
Required for fastest TTM |
|
Dedicated Team Members (one project at a time) |
Not required |
Only 20% interruptions |
Required 100% dedication |
|
Integration of Eng Team with Prod Mgmt Team |
Separate orgs: dynamically changing specs and priorities |
Separate orgs: |
Separate orgs: the what is fixed Integrated orgs: highest efficiency and scalability |
|
Technical Aspects |
No past experience or know how |
Have the expertise |
Have done similar before |
Metrics
No process and no business can run with some level of quantitative metrics of performance. This is especially relevant to high-performance teams. Here is an example of oversimplified metrics:
- Fixed TTM projects. Example: released within 2-weeks from forecasted date; assumes stable+dedicated resources and fixed features
- Fixed Features projects. Example: released within 4-6 weeks from forecasted date; assumes stable resources and manageable features
- Global project optimization. Example: 80% of the Projects will be completed within 80% of the forecasted dates; forecasted date will depend on Proj. Mgmt Type
Know thy Management Style
Finally let’s also recognize that each one of us as managers has a different style; no matter what processes we follow or not, no matter how much we try to promote innovation, what really matters is your personal s
tyle. How you listen, how you understand the status of the deliverables, how to convey urgency, how you promote self-organization and new initiatives is your style. The most concise set of management styles are the X, Y, Z ones:
- X = shut-up and dig
- Y = you are smart and I can help you
- Z = part of the family, keep everyone involved
But the WSJ has the view I really like: “Leadership is less about your needs, and more about the needs of the people and the organization you are leading. Leadership styles are not something to be tried on like so many suits, to see which fits. Rather, they should be adapted to the particular demands of the situation, the particular requirements of the people involved and the particular challenges facing the organization”, WSJ April 2009
I have found helpful to describe my style using the WSJ attributes with a spider chart – just as an example.
I would love to hear your views!
