Pick it up at Managing Agile

My brand of Agile has a strong business bias, which I suppose is not surprising given my background. My hope that Product Owners increasingly take a business and strategic interest in their products comes out of my experience as well. Because this is very similar to Managing Agile’s hope, most of the material covered by this site is flighted there as well. Not wanting to waste your time reading substantially similar content, it makes sense then to merge these sites together. So from now on you can get practical, agile management content at Managing Agile.

Thanks for reading and see you there!

Cheers
Charl

Man survives lion attack

I met a Malawian, a gatekeeper at a game reserve there, who was mauled during a lion attack. His face is terribly scarred and he’s missing an ear; but he’s alive.

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.

The Fortune at the Bottom of the Pyramid

Book review: The Fortune at the Bottom of the Pyramid: Eradicating Poverty through Profits, by CK Prahalad.

“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.

What Are You Doing?

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.

Been There, Done That

You know what it’s like: You’re in the zone, making real progress, when Outlook reminds you to attend a meeting in the next 10 minutes. Let alone being unprepared, you had forgotten the meeting altogether. And your thoughts are all over the place. “No worries,” you tell yourself, “I’ll find the furthest corner of the room and hope that nobody asks me a question.” What a waste of time and money.

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.

Scrum Tuning: Lessons Learned from Google

Video review: Scrum Tuning: Lessons Learned from Google, by Jeff Sutherland.

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’.

Be Wary of Precedent

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.

7 Gripes Business Has Against IT

I am sure you’ve heard the one about the man flying in a hot air balloon when he realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: “Excuse me, can you tell me where I am?”

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.

Reduce variation

I was interested to read an article in the latest edition of The Economist about W.Edwards Deming (1900-1993). Deming, who was awarded the Order of the Sacred Treasure, second class, the highest Japanese award ever given to foreigners, for his efforts in helping improve product quality in Japanese companies, is once quoted as saying: “If I had to reduce my message for management to a few words, I’d say it all had to do with reducing variation.”

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

Scrum in Under 10 Minutes

Video review: Scrum in Under 10 Minutes, by Hamid Shojaee.

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.