Select Page

Categories

Eleven Things To Remember About People in Middle Management Roles

Eleven Things To Remember About People in Middle Management Roles
By Esther Derby

It’s easy to be critical of managers. A few things to remember.

  1. Most people in management roles want to do a good job, but may not know what to do or how to do it.
  2. People in management roles are dealing with incomplete and ambiguous knowledge. It’s a fantasy that they have all the information and know what to do (which may be held by both managers themselves and people who wonder why their managers do clueless things).

  3. Most people in management roles receive little or no training on how to be good managers. Many people are promoted into management roles because they excel at technical work. This is not an easy transition.

  4. Many people in management roles are working out of a mental model of management that limits their effectiveness.

  5. Many of the role models new managers have aren’t helpful.

Read the Complete Article

Deliverable Map Planning

Deliverable Map Planning
By Esther Derby

I spent two days last week facilitating a planning session for a software project. I was working with a team from a functional organization with a pretty heavy phase-gate process, and a waterfall way of building. The team was fininsh their “definition” stage, and planning for a 3-month construction and test phase.

Most of their planning has been driven by their scheduling tool and senior managers’ desire for a sense of comfort and control, which pushes them towards high-level Gantt charts. (One of the sub-project managers came in saying that he already had his plan: it showed five (5) activities with durations in months.)

Well, that may be comforting to executives, but its useless for managing a project.

So for our planning workshop, we mapped deliverables.

Here’s why I pushed towards deliverables, rather than tasks:

  • Deliverables focus on results, not on activities.
  • Deliverables are tangible — they can be tested, picked up, examined, or used in some other way.

Read the Complete Article

Observations on Corporate Culture and Agile Methods Adoption/Adaptation

Observations on Corporate Culture and Agile Methods Adoption/Adaptation
By Esther Derby

I see (and hear about) more and more companies that are jumping on the Agile bandwagon.

All too often, a top managers direct the organization to implement Scrum or another Agile method.

Sometimes implementing Agile top down succeeds in establishing the a few engineering practices or the workflow changes – they create a requirements backlog, and start having release and iteration planning meetings, and maybe something that looks like a stand up meeting (sort of). But the organization struggles, and pretty soon bits and piece of the Agile method fall away because “they don’t work here.” (Which is different from deciding which practices to adopt to solve the most pressing problems.)

This sort of top down implementation often ignores one of the core factors involved in implementing Agile methods: Culture. (Structure and systems are an issue, too, but that’s for another time.)

Culture has to do with how people use power, how people treat each other, beliefs and practices about motivation, and values. Read the Complete Article

Estimating Is Often Helpful – Estimates Are Often Not

Estimating Is Often Helpful – Estimates Are Often Not
By Esther Derby

Recently, I tweeted, “Estimating is often helpful. Estimates are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

Estimating Is Often Helpful

  • Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..
  • Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions. Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.

  • Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

  • Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.

  • When the group knows enough about the “what” to think about the “how,” they can analyze implementation. Working out implementation details reveals more assumptions, and generates more questions.

Read the Complete Article

Why Not Velocity as an Agile Metric?

Why Not Velocity as an Agile Metric?
By Esther Derby

In response to my recent article on Agile Metrics, a reader asked, “Why did you leave out velocity?”

Even though it’s not perfect, velocity is the best way we have to understand the capacity of teams. It’s the best way we have to bring some reality to planning for releases. Watching velocity over time and looking at patterns in burn downs can alert coaches and managers that something is going on, and they need to investigate.

Velocity is important. But as a metric for gauging how your agile adoption is going, it opens a door to danger.

Here’s why.

  • Velocity is easy to manipulate. Want velocity to go up? Fudge the definition of done and you finish more stories. Change the scale and complete more points (what once was a 2 point story is now a 5 point story).
  • Velocity is easy to misuse.

Read the Complete Article

Metrics For Agile

Metrics For Agile
By Esther Derby

“How can we tell how far along we are with our agile adoption?”

I heard this question again the other day.

Usually, the person who asks the question starts to answer it:

“Number of teams using agile”
“Number of people trained in agile”
“Number of projects using agile”
“Number of certified coaches.”

Metrics like these won’t tell you what you need to know. More likely, they will lead you astray. How? Let me tell you a story.

Years ago, I worked for a company that was “installing” a Big Methodology from a Big Company. (The fact that they thought they were “installing” a methodology was probably the first warning sign.)

Every one in the department attended Big Methodology training. (This practice is sometimes called “Sheep Dip” training).

The VP mandated that all projects would use the Big Methodology.

The Installation Team audited to ensure that project managers and teams were complying and producing the required “work products” in accordance with the Required Work Products grid in the back of the very large Big Methodology binder. Read the Complete Article

Recommended PM App

Recommended PM App

Categories