Cultivating your project

Running a successful project is like cultivating a garden. We plant seeds and we nurture them to bloom. Below are project seeds-for-success, which, if nurtured, will create a thriving project.

1. Establish a Vision

A project that lacks a coherent vision is bound to fail. The vision must be broad enough to inspire, yet specific enough to target. JFK’s vision that “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.” is the perfect example of a vision statement. It defines the goal concisely, and allows each person to envision their part in the process, while providing a meaningful timeframe.

2. Align your people

Once your goal is recognized, the resources at hand must be directed appropriately. Each participant must understand his part in the process.
Conflicts and duplications of effort can be avoided; if not, they should be resolved rapidly. Different tasks have differing timeframes; when resources become free, they must be redeployed in a timely manner.

3. Identify and track your risks

In any project, there are risks; from project budget shortfalls to platform changes to personnel and resource shortfalls. Not only must risks be
assessed, they must be addressed – ranked by loss potential and probability of occurrence. Establish a top-10 project risks list and review it regularly.

4. Understand your project’s scope

Defining the scope of any project is crucial. “Scope Creep” (sometimes called “Kitchen Sink Syndrome”) refers to uncontrolled changes to an
approved project; generally feature additions, and usually without proper budgeting of time and resources. Every Project Manager knows that
’scope creep’ is the death of many projects, yet somehow it remains one of the major risks for any project. Not only does it throw off schedules
and budgeting, it will often shift the focus of the development team, leading to a loss of the initial vision (#1), and misalignment of
resources (#2).

5. Measure progress

Milestones are a must. They enable the progress of a project to be measured and controlled. The inability to make track progress is the
inability to make progress. Milestones set deadlines within a project. They may mark occasions where a transition occurs or where key questions may be answered (or decisions required) that could alter the course of a project

6. Adapt your plans

“No plan survives contact with reality” is a truism that every project manager must take to heart. As good as an initial strategy might be, no
strategy can take all contingencies into account. Analysis must take place in order to note areas of concern and to plan how to deal with likely
problems in the near future. This is tactical planning, not strategic. Tactics are ‘in process’, or in military terms, ‘battlefield’ choices which
must be made. The initial strategy is not being discarded here, the object is re-alignment with the initial strategy as best as possible on the fly.

7. Adapt your people

In almost any project, there will always be an area where skills are lacking within a project team. A successful leader not only develops the finished project, but also the people involved in the project. Improving technical skills, increasing effectiveness, and boosting morale and retention leads to the success of not only the project, but the company as a whole in the long run.

Take a look at your project using the points above; which ’seeds of success’ can you nurture?

What are you doing on your project?

What are you doing on your project? A tricky question with so many replies; coding, planning, problem solving? We approach portions of a programming project in different ways; what drives our different approaches?

A comment on a previous post discussed the need for using the right tool for the job I agree; we need the tools that are applicable to the circumstances we face.

So we need a model of the different aspects of work we do in very general terms so that we can apply our model when we need it. Cynefin is a sense-making framework, derived by David Snowden et al, describing contextual complexity and how people act within different contexts. Why introduce this framework rather than some other? Cynefin links how people react to the context of what they know to characteristics of that context. For the purpose of our discussion I’m going to summarize; do take time to read ref 1. Cynefin introduces many insights and Refs 1 and 2 are worth reading.

We’re going to refer to Figure 1 ‘Cynefin Domains’ diagram from ref 1. In the bottom-right we have the domain of known-knowns. Cause-and-effect relationships are known and undisputed. Best-practice techniques are effective in this domain along with standard operating procedures. The decision-model is ‘Sense-Catogorize-Respond’.

Let’s compare the Known-Known domains with a model of a software project. What activities could we associate with this domain. Bug-triage come to mind. We have regular meetings to review bugs associated with our software. We test and record the bugs (Sense), set priority and severity for each bug (Categorize) and then set a plan for dealing with the bug (Respond).

Another example is a Gantt chart (Ref 3). Typically our Gantt charts are a visual description of a work-breakdown structure (WBS) and WBS shows how tasks depend on each other. So WBS is a statement of expected cause-and-effect. Know cause-and-effect also describes Waterfall methodology.

Above the ‘Known-Knowns’ we have the domain of the Knowable. We may not know everything in this domain, but, if we expend effort we can discover things. Snowden et al assert people typically don’t expend time and effort discovering things and, instead, rely on expert opinion.

Using our Gantt chart example; in the software world, as many have experienced, the expected cause-and-effect rarely occurs. Weekly schedule review meetings are an example of revising schedules to reflect what we learned and have placed into the domain of Known and update our Gantt charts! Another tactic is to provide estimate variances on Gantt charts. A common expectation is that estimates will improve over time (Ref 5). By providing estimates we’re acknowledging we don’t completely know about the work-in hand and we use estimates to express our level of uncertainty.

The decision model in the Knowable domain is ‘Sense-Analyze-Respond’. In my opinion this is the manner in which most software projects execute. We don’t know all the implications of implementing features (we don’t know all the features) and we undertake a program of adding code and then observing how our system operates. Unit-testing is an example of this approach as is build-and-test and continuos integration. A key measure of ‘Sense-Analyze-Respond’ is the rapidity of a response. Both unit-testing and continuous integration aim to provide a response of the order of minutes.

For this blog-post we’ll look at Scrum and it’s context. Cynefin gives us the two domains of the Un-ordered; Complex and Chaotic. Complex’s decision model is ‘Probe-Sense-Respond’ and Chaos’s decision-model is ‘Act-Sense-Respond’.

One of Scrum’s tag-lines is ‘Control Chaos’ and it appears in one of Scrum’s web-sites (ref 4). I’ve been wary of the claim that chaos is being controlled. From a Cynefin perspective Scrum occupies both Un-ordered domains because Scrum’s sprint/retrospective feedback loop approach fulfills the needs of both domains decision-models. In Cynefin terms Chaos is being changed to Complex/Knowable or Known; whether or not that constitutes ‘control’ is open to debate.

Before we move on we need to look at Cynefin’s fifth domain; the domain of disorder in the centre of Ref 1 Fig 1. Snowden et al use the disorder domain to illustrate why decision makers (managers, project managers and programmers, us) can disagree on what domain they are in. Cynefin provides insights into the effect of people’s different perspectives on a situation with the observation that it’s easy for people to identify the extremes of any given domain but hard to definitely agree on subtleties of domain characteristics. For example; I may believe a project is in the Complex domain but you may believe everything is in the Known domain. The insight from the Cynefin model is that interpreting the Disorder domain is a matter of personal bias. From a software development perspective this manifests itself as disagreement on the approach to solving project-related issues; a lack of consensus.

So do we use the right tool for the job? Given Cynefin’s domains we have tools and techniques that are applicable in a given domain; e.g. WBS for Known/Knowable, Scrum for Complex/Chaotic. In an earlier post I mentioned Ken Schwaber’s statement that 30-35% of Scrum projects succeed and I wondered what happened to the other 65-70% of projects. Cynefin gives us a powerful vocabulary for describing the knowledge we have about a project, but, given my brief descriptions here we haven’t touched on other facets of a software project; specifically the people involved and the organization hosting the project. To get a thorough answer to our ‘right tool for the job’ question we’ll have to factor-in people and host-organization. The effect of people’s bias on interpreting the Disorder domain opens an interesting line of inquiry for the future.

At the beginning of this post I posed the question ‘What are you doing?’ Now I can re-state the question in two parts: On your project, how much is known and how much is unknown? Are you adapting your approach based on what you know and what you don’t know?

Here some questions I’ll be addressing in future posts:

Can we specify what a self-organizing team should aim at? One big criticism of Scrum is that telling a team to ’self-organize’ isn’t enough. Is it possible to provide guidance on how a team self-organizes without compromising the intent of internally (self) structured organization?

Can we synthesize new development techniques that are better adapted to each Cynefin domain?

Where are other Agile methods applicable? Could we map them to Cynefin? E.g. the ‘Tracer-bullet’ (ref 6) technique would be a ‘Probe-Sense-Respond’ approach associated with the Complex domain.

How do we know which domain we’re in? How do we shift from one domain to another within the context of a software project?

References and links:
1.
http://www.research.ibm.com/journal/sj/423/kurtz.html
“The new dynamics of strategy: Sense-making in a complex and complicated world
C. F. Kurtz and D. J. Snowden”

2.
http://tinyurl.com/yoda8h
A Leader’s Framework for Decision Making
David J. Snowden, Mary E. Boone

3.
Wikipedia, Gantt Chart
http://en.wikipedia.org/wiki/Gantt_chart

4.
Scrum website
http://www.controlchaos.com/

5
The Cone of Uncertainty
http://www.construx.com/Page.aspx?hid=1648

6.
http://www.artima.com/intv/tracer.html
Tracer Bullets and Prototypes
A Conversation with Andy Hunt and Dave Thomas, Part VIII
by Bill Venners

Why do some methodologies fail – re-framing the question

After a past experience with Scrum I wanted to write about the conditions under which Scrum projects can fail. A Google search located a presentation from Joseph Pelrine and Jiri Lundak describing a workshop they ran to reveal why Scrum projects fail (http://tinyurl.com/9j2az6). Pelrine and Lundak’s workshop starts by considering the conditions for project failure. This seems like an important first-step but I realized the question may be misleading.

I’m going to use a different approach by asking the question; under what conditions is Scrum applicable? Why ask the question? I was watching Ken Schwaber’s Google Tech Talk video titled ‘Scrum et al’ (http://tinyurl.com/j58cr). 29 minutes into the video Ken states 30-35% of Scrum implementations succeed. What happened to the other 65-70% of Scrum implementations?

After further consideration the question can be broadened to other tools/techniques/methodologies for running software projects, for example; under what conditions are Gantt charts applicable? or, when is waterfall development applicable?

Changing the question helps me address other persistent questions like; why do we still use Gantt charts? Why is waterfall development still used?

Take a look at your own project; what tools, techniques and methodologies are you using? Now comes the hard question; why do you use them?

What is Mission Critical?

So what is ‘Mission Critical’? The term gets used a lot and, frequently, confused. Here’s a clarification for the perplexed.

Mission Critical is describes something that your mission cannot succeed without. For example if you’re flying a plane your engines are mission critical. If you have an website that generates all your company revenue it’s mission critical.

Often mission critical is confused with two other terms; safety critical and high-availability. ‘Safety critical’ describes a system that, if it failed, would put lives at risk. Your car’s brakes, air-traffic control and are examples of safety critical systems.

High availability is used to denote systems that meet a designated level of operating continuity. For example your telephone system appears to run at all hours, day and night; also described as 24×7. In fact our telecommunications system has a high-availability of, at worst 99.999% uptime, equivalent to approximately five minutes of downtime per year. Many of the systems we use today have become high-availability systems, like ATMs, cable TV and web-sites. In general many businesses maintain some presence 24×7.

Although mission critical and high-availability systems can be useful, building them can incur extra costs. A wise step in creating any system is to identify only those components that are require to e mission critical and, possibly, high-availability.

They key to successful mission critical operations is understanding what your mission is; these questions can help:

What’s your mission?
What systems support your mission?
Which support systems are high-availability systems?

Take a look at your own software project and see how it measures-up against these questions.