Idea exchange on how to make simulation and scheduling projects more successful.

Main menu

Tag Archives: agile

In previous articles we discussed a definition of agility and the potential oxymoron of managed agility. I coined the phrase “well managed agility” as part of the solution. I was asked why I used the word “well” in that phrase. The short answer is that anyone can say they are agile. And anyone can say that they manage agile. But doing both and doing them well is the key.

Good management in general is a topic I’ll leave for later. Today, I will concentrate on managing the process of change.

The most important part of managing agility is to have a single person (or a small team that works cohesively) responsible for the agility. Ideally this person, who I’ll call the agility manager, should be knowledgeable and sensitive enough to understand:
1) What the stakeholders want,
2) What the stakeholders need, and
3) The issues involved in delivering the above two items.

The project demands a lot from the agility manager. It demands the ability to get inside the heads of stakeholders and really understand not only what they want, but what they really need. Sometimes even the stakeholders don’t know what they need until they see it (or miss the lack of it). The agility manager must also understand the issues and tradeoffs on the development side of actually meeting those needs (including deadlines).

Some common agility challenges include:
• The system being modeled changes (perhaps the design has evolved, or “assumed” aspects have just come to light)
• The stakeholder objectives change (date, modeling details, purpose of model)
• Modeling problems are discovered (modeling or data collection may be more difficult than expected)
Often changes like these make current plans invalid. Of course the stakeholders want it all and many conscientious modelers will want to say yes to satisfy the stakeholders.

To do the job well, the agility manager must be someone who understands all the above aspects and who can take the broader view to determine what action best serves the stakeholders? Choices like adding feature A versus doing a more thorough job implementing existing feature B, when you don’t have the time or resources to do both. Or when a project is running behind schedule, is it better to schedule extra effort, remove some features, or postpone the delivery date? Only a very knowledgeable manager can correctly make these decisions by carefully weighing the benefits/rewards of each action.

Even better, the most effective manager will try to avoid having to make big decisions like the ones above, by instead making correct calls on numerous similar small decisions that arise on a routine basis. In a future installment I will discuss managing the “routine” and some tools and processes to facilitate that.

Last time we talked about a definition of agility: The capability of being flexible and responsive to changes in the world around you. And I suggested that Well Managed Agility is one part of the solution for the question of “How much agility is enough?”

Is Managed Agility an oxymoron? It can sound like one. And some people equate agility with a lack of management, a free-for-all. That can be true when agility is taken to the extreme and poorly implemented. But agility certainly can be managed in many ways.

The first step to managing agility is simply acknowledging that agility can and must be managed.

I once joined an organization where there was major project in process that was getting later every day. The later it got, the more the stakeholders realized that the originally planned results would no longer meet their needs. So the stakeholders insisted on changes. The organization, who felt bad about the late delivery, almost always said yes in a futile attempt to placate the customers. Unfortunately, the more changes that were accepted, the later the project became. My job was to bring the project back on schedule.

One aspect to getting a project back on schedule (we will discuss others in future blogs) is learning to say no. In this case I changed the process so that all major decisions, and all communications with the stakeholders, went through me. This was not because I was any kind of an expert. Quite the contrary – I was a novice at the subject matter. But I did know how to get the right people involved to exercise good judgment. And I did have the guts to say no when it needed to be said.

The salesperson involved was livid – “You CAN’T say no to a major stakeholder.” My response: “Watch me!” The alternative of saying “yes” with the knowledge that delivering is not possible, is just flat out lying to your stakeholders. While no one wants to be told no, I think that most people would prefer an honest “no” to a dishonest and meaningless “yes”.

As expected, the primary stakeholder was initially angry when he was first told no. But he soon realized that this was the first time he had been given an honest answer. And this was actually the start of what later became a great and very positive relationship. The salesperson also became a friend for the same reason.

Next time I’ll talk about other steps to managing agility. In the mean time, if you are working on a project that is behind schedule, start practicing the word “no”.

Agility is the capability to be flexible, responsive, and adaptive to the changes happening around you. When a stakeholder asks you to deliver something you had not planned on, your response is a measure of your agility. But how much agility is enough?

I was once part of an organization that was extremely agile. Whenever anyone in the organization had an idea, it would send the developers off in a new direction – quite often before they were half done implementing the previous idea. It was like a rudderless sailboat. Although we had an intended course, we never followed it and were instead at the mercy of the wind to see where we were headed that day.

I have also been in an organization where they wanted detailed plans for two years ahead, and any deviation from the waterfall plan required an “act of God”. In this organization we generally knew exactly where we were going. Unfortunately, we also knew that if and when we eventually got there, we would be in the wrong place. The world never waits. A goal set to satisfy stakeholder needs today will rarely match stakeholder needs two years from now.

Obviously each of these extremes has its pros and cons. I often wonder why so many organizations seem to live at one extreme or the other. I think neither is the right answer for most organizations.

So how much agility is enough?

There is no absolute right answer. Each organization and project will have its own right answer, and even that is likely to change over time. But I believe for most organizations and projects, the answer should involve what I call Well Managed Agility.

Next time I’ll talk about what I mean by well managed agility and how you can achieve it. In the interim, I’d love to hear about your experiences with agility or lack of agility.

This article continues a brief exploration into how you can be more successful in your simulation projects. (Look here for part 1.)

Here is a second set of important issues that should be considered.

Agility – You can count on the fact that what you are modeling will change. If the system itself is not changing, the detailed project objectives will. Use a technique that allows you to stay agile enough to cope with the inevitable changes.

Solve Problems – Don’t see yourself as just a model-builder. See yourself as a problem-solver. Think outside the box. Recognize opportunities. Don’t simply provide a service, add value.

Software – Software selection is often difficult, particularly if budgets are tight. Domain-specific or generic? Easy to use or flexible? Established product or state-of-the art technology? Many factors must be considered.

Know Your Stakeholders – Who is funding the project? Put yourselves in their position and determine what their concerns are and what they would like and need to see from this project.

Credibility – While simulation provides a degree of objectivity, to many it is still a “black art”. At the end of the day if you don’t have personal credibility, all the backup data possible will not be able to sell your ideas.

Certainly this was a very brief treatment of only a few key factors to success. Future articles will discuss these and others in more detail.?