A lot, actually. Take bureaucracy, for example: It’s likely that the word is perceived negatively by you and many others. Judging by public opinion one would be forgiven for thinking that this organizing principle has had a bad effect on society.

Yet as a principle, bureaucracy has been tremendously successful over thousands of years, evidenced by the fact that it is the mother of all incumbent systems today. During the 17th century bureaucracy, or ‘rule by office’ became an effective counter measure to governments being staffed by friends, relatives, or those of a particular social or ethnic group.

By definition a bureaucracy is rational, neutral, and merit-based. Perhaps it’s getting the blame for the effects of something else. To my mind the real enemy has and may always be self-interest.

A great article by Tobias Mayer from the Agile Anarchy site, pointing out that to truly live Scrum needs a heart: This heart is the task board.

For some strange reason, communication is often a very difficult thing to get right.

You may be familiar with a children’s game called Broken Telephone, where a message starts at one end of a line of kids, and is passed along in whispers from one to the next until it reaches the last child in line. This child announces the message she heard, which as you can imagine usually bears no resemblance to the orginal and causes much laughter.

Playing for keeps
It happens with adults too, in the work place. Probably more so with software than other types of production, good, accurate communication is vital. Even if two people are talking about a subject they both know well, what one is picturing could be different to the other. The extent of this difference may be subtle, yet material to the outcome of the project.

“The single biggest problem in communication is the illusion that it has taken place.”
—George Bernard Shaw

In matters of communication healthy skepticism can be a good ally. If I am aware that what’s in my head as a result of what someone has told me is likely to be different from what’s in their’s, I can do something about it. But if I assume they communicated the idea perfectly, and I understood it perfectly, there’s likely to be some disappointment along the way.

However, if I am aware of the potential for communication to go awry I need to ask more questions. Really listening to the answers can highlight discrepancies in our mutual understanding. And if both parties are aware of communication’s hazzards, then this exercise can be fruitful rather than being seen as a waste of time. Successful communication comes as a result of both of us not being fooled by the illusion that it has taken place.

‘Done‘ is a valuable technique to check the quality of communication that has taken place. Using it to good effect can show that you’re on the right track, and avoid the disappointment of unmet expectations.

One of the many unintended benefits, in my view, of applying Agile principles to your business thinking is culling a lot more initiatives before they even start. Common sense tells us this is a good thing, but in reality it’s often not perceived that way.

If you’ve set yourself up in business to develop software then that’s what you do, day in and day out, whether it’s a good idea or not. It is inconceivable to many managers that a Team can go through a period in which they are doing nothing commercially productive.

Warm and fuzzy
Perhaps this is a legacy of waterfall (wishful?) thinking, because when everything took so long to do it wasn’t a problem keeping the idea pipeline full. But as you reap Agile’s efficiency gains you may uncover a shortage of effectiveness and creativity within your company.

It’s usually then that you sense the presence of an age-old enemy: Sentimentality. It sounds sweet and is often said to “creep in,” whereas in my experience it is always a scoundrel that barges its way through the door, hand-in-hand with the CEO or another executive.

“We just have to do this,” the executive declares.

“Why?”

“Because we have to. Trust me on this, I’ve got a nice, warm feeling about it. And besides, what else will the Team do? We can’t have them sitting around doing nothing.”

Want a ‘Sentimentality-Buster’? Please provide us with your contact details to get your own Free! copy of a Managing Agile tool, which confronts the rationale behind new product ideas before they get started.

My superpower is listening, really listening, and when I filter out the political correctness, what I hear the executive actually saying is: “Listen sonny, this is my pet project. I’m the boss around here and if I say “Do it,” then you’ll just bloody-well do it.

“Oh yes! And when you make a mess out of this it’ll be your fault for implementing my good idea badly. I want to know now if you’re going to do this or not. If not, I’ll find someone else who will, and then what’s the point of having you around?

“Don’t you realize I get an ego (and bonus) boost by running the biggest dev shop in town. When everyone is always kept so busy I have to hire more people. That’s how it works around here.”

It takes guts and daring – leadership – from stakeholders, management, customers, and the Team to put initiatives to the sword, especially when the alternative is apparently doing nothing. Yet, for everyone’s sake, sanity, and back pocket, this is precisely what you must do. If Agile highlights that your company is not effective or creative enough, this is the problem to solve. Not how do I make everyone look busy.

Peter Tuffin is a wise IT professional with decades of experience. I had the honor of working with him for several years, and during this time we often tried to identify those things – faits accompli if you will – which we just live with: Unwritten rules that are established in our minds through us not challenging the status quo. We bring them with us in the morning and take them home again, safe and sound, in the evening.

Peter raised two of his: “I think these are things that we should practice becoming aware of and challenging more and more. I guess one way to become aware of them is to notice when we have a problem which seems insolulable: Perhaps below that skulks a misconception which needs blowing out of the water. I list them as the idea that we have, what that gives rise to, and what the real issue might be.

1. Idea: All of our developers need to be busy on cutting edge, technically challenging work, otherwise they will just leave.

One result of this is ‘you can’t put good developers onto maintenance projects’ (which all projects become), so the commercial money-making projects end up being over-supplied with mediocre personnel.

The reality might just be that most developers are quite happy working on whatever comes their way, and maybe especially if the product is being used by external users who pay money to use it. Perhaps the real reason for the misconception is that developers have an idea that they need to be exposed to as much as possible so that if they do in fact leave the company they will be able to get a job elsewhere.

But if our primary motive is to hold on to good people for as long as we can (and otherwise why would this issue have come up at all), then perhaps this can be addressed in other ways, such as, for example:
a) allaying their fears that they will not be able to work outside the company (in ways other than exposing them to the cutting edge, like, for example, showing them the reality of the IT world which has more cutting edge to it than a Swiss-army knife and exposure to all of that will take a lifetime and be impractical).
b) paying them enough that they don’t want to make the move.

Finally, I think we should actually ask people if the misconception is in any way applicable to them – at the moment we just assume it.

2. Idea: There is an attitude that prevails that can be worded as, “The customer is always right, and they pay our salaries, and so we will give them whatever they ask for and when they ask for it.”

Many things result from this: We spend a lot of time on unimportant things, sometimes delivering features which don’t really solve the problem (because of the attitude of ‘if the customer is right then they must have expressed their need correctly’, which is not necessarily the case), and sometimes spending a lot of time on features which affect very few of our customerss and sometimes have no discernable commercial benefit.

In reality I would like to translate the idea statement to: “The customer is always right, and they pay our salaries, and so we must keep their relationship with us a happy one at all times.” Keeping the customer happy is a lot broader than just providing product features, and sometimes immeasurably less expensive.”

Here are only two misconceptions. Are you brave enough to identify and confess some of yours and subject them to a similar analysis? If so, let us know by posting a comment.

Here’s a list of production efficiency adjustments we’ve made along the Agile learning curve. Although these may be specific to our circumstances, they may hold some value for you, even if only to spark some discussion:

1. Optimal team size may be no bigger than 5.
2. Build or buy decisions should be in the hands of Business, not Research.
3. The team should get one chance at estimating. If they are wrong then the extra time needed to meet sprint goals is for their own account. This will provide the sort of predictability in delivery times that are needed.
4. Production should continue to enhance the code library for all common product needs. Building new components should be the exception and possibly should only be handled by senior people who have that responsibility.
5. Apprentice coders should not outnumber journeymen and masters on any team. Apprentices must be mentored by journeymen and masters on real commercial projects, not on made-up training projects.
6. A skills profile of each team member must be built up and updated as they grow. Not just their place on the master, journeyman, apprentice ladder, but particular skills like ‘database design’, for example. This is so the right people are assigned to the right projects creating true cross-functional teams.
7. Work not accepted by the Product Owner at sprint review due to time must be allocated as ‘rework’. This enables us to track how much sprint output is not consumed commercially.
8. Divided responsibilities must be avoided so that people can focus on only one project.
9. Meetings not related to resolution of product issues or design must be minimised.
10. Teams must be co-located with the Product Owner and a culture of face to face communication rather than email must be encouraged.

Although your circumstances may be different, I hope these help to promote some thought and discussion.

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.

Accelerate Cape Town’s Guy Lundy was recently quoted as saying, “A vision is a story people tell with their lives.” Everybody, everywhere, all the time. Each one of us becomes so gripped by something—a dream, ambition, fear, greed, drudgery, sufficiency, self-service, our leader’s enthusiasm—that we live it out in a way that speaks clearly to all who choose to listen.

Stop for a moment and listen to the story your life is telling. What story is your team telling? Does their story assure you that they have caught your vision?

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.

I thought you may find it amusing to read through a list of business clichés at Squidoo. I did. It’s no wonder that Business and Development are hardly ever ‘on the same page’.