I thought you may be interested in an article by Derick Bailey. As Derick says, “I know I’m going to rile up some of the Scrum fundamentalists out there.”

“Given my current feelings about Scrum and Kanban, I thought it would be appropriate to outline how I think time boxes and Kanban can coexist,” says Bailey. You can read the full article here.

“A common cause of disaster in software development is that the end product is precisely what the customer originally ordered,” an article in the September 20th 2001 print edition of The Economist said. “In a world moving at Internet speed, a customer’s objectives are constantly being revised, so programmers have to be able to hit a moving target. Is there any formula for coping with this sort of unpredictability?

“With this in mind, 17 leading software gurus holed up in a Utah ski resort in February 2001 to produce a Manifesto for Agile Software Development. Portentous as it may sound, the manifesto represented the distillation of several successful team-oriented techniques, and hoped to inspire innovation groups outside the confines of software development.”

Eliminate ambiguity
In a blog post on July 25th 2009, Rick Garibay stated: “Eight years later, after having applied the principles and values prescribed [in the Agile Manifesto], these values have been tremendously successful at providing the software industry with similar benefits that Lean Manufacturing furnished for Toyota.

“Unfortunately, we’ve also learned that too many individuals and shops have given Agile software development a bad name by using it as a fig leaf to hide behind delivering crappy software and calling it agile, further setting back software engineering as a mature discipline.

“As a result, our very own Bill of Rights has been born. The Manifesto for Software Craftmanship is founded on the original Manifesto but raises the bar to eliminate any ambiguity around the expectations of professional software engineers to not only produce working software, but ensuring it is well designed. Not merely reactively responding to change, but strategically partnering with the business to proactively add value while building a community of professionals that can teach and learn from one another.”

Rick Garibay asks, “Do you believe in these values? Do you agree that as an industry we are still failing to add value and deliver high quality software? If so, I implore you to think about the values as a whole, and if you are so inclined, sign and commit to the Manifesto for Software Craftmanship.”

Is another manifesto necessary?

Several years ago now, not far from where I live a Great White shark swallowed an elderly swimmer. Only her red bathing cap was left.

Tyna Webb was in the habit of taking her morning swim, and despite being warned of increased shark activity in the area at that time, she nevertheless made the choice to keep up her daily routine.

In a groove?
That got me thinking about you. Are you keeping your daily routine, not heeding the signs and signals around you? If so, how is it that you’re expecting different results?

An additional benefit of Scrum’s time boxing is that it affords project personnel a formalized time to inspect and adapt. If these sessions are approached with honest and open minds, and without recrimination, they are powerful to effect the kind of change you need to become continuous improvers of your business.

Being in a groove may not be as advantageous as you think. Blaming stops learning; so too does routine.

At the heart of Agile practices is the Deming Cycle: Plan, Do, Study, Adjust. How often are you stopping to study and adjust?

You know that your products need to keep pace with changes in the market. You know too that sometimes you get stuck in a rut while the market takes a subtle, but significant, change of direction right under your feet.

The likelihood you will face this dilemma increases because of the way you describe what it is that you do. For example, you have probably answered the question, “What does your company (or product team) do?” with something like, “We write software.”

Statements like this are inadequate on at least two levels: Firstly, you don’t just ‘write software’; and secondly, the solutions you provide are useful to others-your users-in the context of their jobs. You should be able to express that in words.

Becoming your solution
A more helpful way of describing what you do starts with saying that you facilitate various processes. “We facilitate the civil litigation process,” may be something a document automation software producer says, for example.

When you start off a project you may choose to facilitate a process in a limited way, to get your product into the market as soon as possible. But as you do more work and gain more experience, you are able to expand the scope of the solutions you offer.

The word ‘facilitate’ helps in two seemingly opposite directions: It implies that you are not actually performing the process, so that you don’t have to cater for everything that could ever be part of that process. Conversely, the concept of facilitation is broad enough to encompass any part of the process you facilitate, particularly new areas you uncover either as the market, or your experience, grows; or both.

This way of thinking enables you to focus on what you do best in a particular process, while at the same time keeping your mind open to new opportunities.

It’s a good idea for each product to have a positioning statement, which is phrased: “For (target market) who (compelling reason to buy your product), our product is (product category) that (key benefit), which unlike (main competitor) our product (key differentiation).” (Call it an ‘elevator test’ if you will.) It’s a good thing for you and those on your product team to be able to quote this verbatim; to revisit this every morning before starting work. Then compare what you’re doing, or more likely should be doing, to honor this statement.

Much of what we do today is based in precedent. The reason we need to do this, of course, is to keep up with the rate of change, the busyness of our own lives. Our dilemma is that they are mortal enemies: Precedent and change. Part of the daily stress we face is in trying to meet the demands of those who want things as they are, and the hopes of those who want things as they will be.

Internet search engines have a lot to do with precedent. We don’t have to think anymore with Google at our fingertips: It’s easy to find out what others are doing and to follow them. I wonder what effect this is having on original thought, authorship, and creativity. You may want to read this poem and afterwards ponder why it is you do things as you do.

The Calf-Path, by Sam Walter Foss (1858 – 1911)

I.
One day, through the primeval wood,
A calf walked home, as good calves should;

II.
But made a trail all bent askew,
A crooked trail as all calves do.
Since then three hundred years have fled,
And, I infer, the calf is dead.
But still he left behind his trail,
And thereby hangs my moral tale.
The trail was taken up next day,
By a lone dog that passed that way.
And then a wise bell-wether sheep,
Pursued the trail o’er vale and steep;
And drew the flock behind him too,
As good bell-wethers always do.
And from that day, o’er hill and glade.
Through those old woods a path was made.

III.
And many men wound in and out,
And dodged, and turned, and bent about;
And uttered words of righteous wrath,
Because ’twas such a crooked path.
But still they followed – do not laugh –
The first migrations of that calf.
And through this winding wood-way stalked,
Because he wobbled when he walked.

IV.
This forest path became a lane,
That bent, and turned, and turned again.
This crooked lane became a road,
Where many a poor horse with his load,
Toiled on beneath the burning sun,
And traveled some three miles in one.
And thus a century and a half,
They trod the footsteps of that calf.

V.
The years passed on in swiftness fleet,
The road became a village street;
And this, before men were aware,
A city’s crowded thoroughfare;
And soon the central street was this,
Of a renowned metropolis;
And men two centuries and a half,
Trod in the footsteps of that calf.

VI.
Each day a hundred thousand rout,
Followed the zigzag calf about;
And o’er his crooked journey went,
The traffic of a continent.
A hundred thousand men were led,
By one calf near three centuries dead.
They followed still his crooked way,
And lost one hundred years a day;
For thus such reverence is lent,
To well established precedent.

VII.
A moral lesson this might teach,
Were I ordained and called to preach;
For men are prone to go it blind,
Along the calf-paths of the mind;
And work away from sun to sun,
To do what other men have done.
They follow in the beaten track,
And out and in, and forth and back,
And still their devious course pursue,
To keep the path that others do.
They keep the path a sacred groove,
Along which all their lives they move.
But how the wise old wood gods laugh,
Who saw the first primeval calf!
Ah! many things this tale might teach –
But I am not ordained to preach.

Why follow others without questioning? Why not chart your own course?

I‘ve just returned from a CIO Forum in Cape Town where, according to Prof Pete Janse van Vuuren, an Executive Partner of Gartner in South Africa, business is demanding three things of the CIO:

1. That they be more flexible.
2. That they deliver quicker.
3. That they become easier to do business with.

Many CIOs feel squeezed. The easiest thing for you to do in these tough times is to cut back and lay off. Yet that may be exactly what your competition wants. What they don’t want is for you to be introspective (improve business processes), innovative (deliver products that enable growth), and positive (attracting and retaining new customers). Although CIOs will have similar budgets to those of 2007/2008 to meet these challenges, overcoming them will see you in a great position in the next upturn.

Splitting ‘I’ and ‘T’
Along with other business units, IT will need to reduce costs and improve performance. But IT is in a unique position to lead enterprise change initiatives, and to harvest value from core technologies already implemented. A focus for CIOs in the next few years is going to be on business intelligence and security technologies, Gartner predicts.

Many of the companies polled by the survey see the possibility of splitting information technology into its component parts, with the CIO taking charge of information whilst the CTO deals with technical issues. CIOs would then outsource their technical needs to the CTO, who would have the decision of how to smartsource the requirement. In any event companies want the CIO to get a lot closer to business than they have in the past.

So big challenges lie ahead for CIOs as you come alongside business to strengthen and extend your position in the market, whilst at the same time matching cost structures and expecations with the reality of lower business activity. Oh, yes. One more thing… be more approachable.

Most companies are paralysed by institutionalised inaction. This causes delays and adds huge cost. People often confuse urgent with important.

It may be easier to make decisions when you wait until they become urgent. Everyone focuses on the issue, and people use the circumstances to justify the means, cutting across lines of authority. Senior executives get involved, other meetings are cancelled, and colleagues commit. Chaos reigns. Letting things slide until they become issues is bad management, not an excuse for half-baked solutions.

But it’s better and cheaper to deal with the important issues before they become urgent. If you don’t have time to do something properly, where are you going to get the time to do it again? Avoid perfectionism, stop waiting for the single correct answer, and go with your instinct. Reversing out of a wrong decision usually costs less than not making one at all. Delegate decision-making to teams—you can trust them to do the right thing.

Make sure you take the difficult decisions first.