Thanks for reading and see you there!

Cheers
Charl

That got me thinking about you. It’s likely you’ve been mauled too. Not by a lion, but by something more powerful and pervasive: Bureaucracy. And you’ve got the scars to prove it; yet somehow you’ve made it through.

Bureaucracy is the mother-of-all legacy systems. It directs what you do and how you do it. And if you want to overturn it, or simply change it a little, or arrest its operation for just one team, it won’t let you. I’ll bet it’s the single biggest impediment to your agile ambitions. But you’re correct to want to change it, because these days bureaucracy is not the best organizing principle we can think of.

Peace, then change
I know it’s a daunting challenge to change something that’s so entrenched in people’s thinking, in their styles, techniques, attitudes, expectations. But that’s the thing: Most people actually don’t think, they just do. Managing Agile is here to help you question the status quo so that your colleagues start asking why. Managing Agile can help you demystify and desensitize the interactions between traditional management and the agilistas.

Notwithstanding they work for the same company, each doing their best, equally responsible for creating stakeholder wealth, Business and IT often view the other as an enemy. This site will give you the information to disarm, to bring peace; then change. It’ll give non-partisan insights into what the other is feeling. It’ll help people see passed the comfort of bureaucracy to the riskiness of change.

Don’t wait for the lions to find you. They will; it’s inevitable if you stay where you are. Change. Get moving. Go looking for lions.

“What are we doing about the poorest people around the world? Why is it that with all our technology, managerial know-how, and investment capacity, we are unable to make even a minor contribution to the problem of pervasive global poverty and disenfranchisement? Why can’t we create inclusive capitalism?”

With opening challenges like this, Mr Prahalad’s book really grabs one’s attention. “If we stop thinking of the poor as victims or as a burden and start recognizing them as resilient and creative entrepreneurs and value-conscious consumers, a whole new world of opportunity will open up,” Mr. Prahalad goes on to state.

Constant innovation
University of Michigan Business School professor CK Prahalad challenges the common beliefs held by business about the world’s poor and introduces us to the Bottom of the Pyramid (BOP), an underserved market of more than four billion people. This is the market companies should be paying attention to, he says.

According to Prahalad, the poor need to seen as a market, but one different from the conventional wisdom. When this happens traditional business concepts are applied to each situation from its distinct perspective. What results are practical, innovative solutions to unresolved problems.

Prahalad demonstrates that making products more affordable to the world’s poor can provide substantial returns to create real partnerships and innovations for established companies.

One may question the realism of Prahalad’s vision and goals. As Prahalad readily admits, “We have a long way to go before the social transformation of inequalities around the world will be accomplished.” But being a long way from reaching that goal should not be a deterrent to working towards it.

Slowing growth and financial crises in overserved markets may mean companies have no other option than to enter these Bottom of the Pyramid markets. When you do, you’ll find it a win:win.

In what way will you apply the efficiency and effectiveness benefits you’ve gained from Agile? What about using these benefits to innovate products for Bottom of the Pyramid markets?

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.

A meeting is a scheduled event of three or more people lasting 30 or more minutes, which may or may not be held in a dedicated meeting venue.

Which aspects characterize ‘bad’ meetings?

1. Meetings that are not with either the team, stakeholders,or market representatives.
2. Having observers, rather than participants, present. Everyone who attends a meeting should be aware of the role they are expected to play.
3. No clear output for the meeting is defined.
4. Big meetings (many participants).
5. Long meetings.
6. Lack of preparation by attendees.
7. Poor time management (starting late and not containing discussions).
8. Filling the allocated time instead of adjourning once the objectives have been reached.

These types of meetings could waste time and money if you’re not careful:

• Routine or regular meetings. These can often become meetings for their own sake. Regular meetings should be held up to the same scrutiny as any other meeting to ensure they are still productive.
• Workshops. These can often turn into long unproductive meetings, yet can also be invaluable if the right people meet with clearly defined decisions to reach.

When organizing a meeting include these three points in your meeting request:
1. Roles. The roles that each of the attendees is expected to play.
2. Questions. What questions need to be answered.
3. Outcomes. What outcomes are required from meeting together.

Adwords introduced a Scrum implementation at Google in small steps with remarkable success. As presented at the Agile 2006 conference this exemplifies a great way to start up Scrum teams.

Jeff Sutherland, the inventor and co-creator of Scrum uses this approach in building the Google Scrum implementation to describe some of the subtle aspects of Scrum along with suggested next steps that can help in distributing and scaling Scrum in a ‘Googley way’.

Video by: Google Tech Talks | Language: English | Running time: 1:00:07 | Produced by: Google, Inc. October 8, 2007 | Speaker/s: Jeff Sutherland

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?

The man below says: “Yes, you’re in a hot air balloon, hovering 30 feet above the ground.”

“You must be a software developer,” says the balloonist.

“I am,” replies the man. “How did you know?”

“Well,” says the balloonist, “everything you have told me is technically correct, but it’s no use to anyone.”

The man below says, “You must work in business.”

“I do,” replies the balloonist, “but how did you know?”

“Well,” says the man, “you don’t know where you are, or where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault.”

My perception, your reality
There’s at least two sides to every story, I’ve come to realize over the years. And this is certainly true in the ongoing spat between Business and IT. I quizzed my business colleagues recently to discover the gripes they have against IT. Here are just seven of them:

1. Developers pad their delivery times because they don’t want to be proved wrong.
2. Development teams always deliver products short of features.
3. IT is always much too slow because of big teams, democracy in teams, too few hours worked by team members, and too many juniors involved in projects.
4. Developers use the market place to test the product, and QA can’t reliably trap the bugs we unfixed that were previously fixed.
5. The result of slow development delivery is animosity between IT and Business.
6. Rather than try to address slow delivery, IT Management defend it.
7. The Development Team lack the industry and business knowledge to spec a solution for the real world.

I understand there’s a fair bit of emotion in these perceptions, and they may be unsubstantiated. But that’s what perceptions are. Nonetheless they are real in the minds of those who hold them.

Far from being provocative for its own sake, I list them so that, through identifying which they are, we’re in a better position to calmly and logically address each one. Yes, each one, from an Agile point of view. Implementing Agile processes in a traditional organization will struggle, if not fail, unless these perceptions are dealt with one by one.

I’m sure there are others. Please let us know your gripes: If you’re in Business, against IT; if you’re in IT, against Business. Don’t feel you need to explain them, just put them down.

Management, Deming argued, is responsible for 85% of variation. Reduce the variation, increase the quality; this was the foundation of his advice.

This is a high paced introduction to the basic concepts that make Scrum great, according to Axosoft CEO Hamid Shojaee. You’ll hear about Scrum terms like burn-down charts, team roles, product backlogs, sprints, daily scrums and more. Managing agile teams will become a little easier when you understand some of the Scrum jargon.

Video by: Axosoft | Language: English | Running time: 7:59 | Produced by: Shojaee, H; Harju, D; Coppola, A | Speaker/s: Hamid Shojaee