Project Management

"Product? Project?"

Estimation Alternatives, Part 2: Products vs. Projects

by

"Product? Project?"“I don’t understand products vs. projects. What’s the difference?”

When I share some of my stories about working with product development teams, some people look at me as if I’m describing the impossible. They seem confused when I tell them about agile teams that didn’t have to provide story point estimates to management or normalize points across teams. What I’m talking about is so far outside of their experience, they can’t conceive of how it could work. One of the most challenging things for me to explain to people who haven’t experienced both is the difference between project- and product-based organizations.

Continue Reading→

Estimation Alternatives, Part 1: Feature Budgets

by
A metal pail filled with hundred dollar bills.
A powerful estimation alternative is to treat project funding as a budget and charter teams to spend it effectively.

The most common question on any project is, “How long with this take?” This question isn’t too difficult to answer when the work is small – a few minutes to a few days. Problems start when someone wants an estimate for a chunk of work you can’t complete in just a few days. Requests for estimates like this come from a need to make higher-level planning decisions. But estimates aren’t the only way to make these decisions. Over the last fifteen years of working with agile teams, I’ve seen value in exploring estimation alternatives. Two, in particular, come to mind, the first of which I’ll describe here: Shifting conversations about estimating to budget discussions.

Continue Reading→

Agile Leadership Myth #3: Leaders & Managers will figure out what their agile role is magically

by

We have done a huge disservice to leaders and managers, as well as teams.  There are plenty of people that will say we don’t need managers and leaders. People can lead themselves. While there is an aspect of this that may be true, there are a lot of steps to get close to that idea.

This article will explore what leaders and managers need to do to succeed as they get started with agile or to help teams move from individuals to a team or even a high-performance team. It builds on Agile Leadership Myth #2: Self-Organizing Teams Don’t Need Any Help.

Continue Reading→

Agile Leadership Myth #1: Telling people “You Are Empowered” Actually Works

by

A major challenge we run into when helping organizations shift or improve is leadership misconceptions. Agile leadership myths cause a lot of these misconceptions. We need to help avoid falling into the trap of these common myths because they limit our success. A root cause of many of the myths is that people simply don’t know what else to do. For example, Myth #1: ‘telling people “you are empowered” actually works.’  Leaders often don’t know what else to do, other than tell teams they are empowered. We see this with Development Teams, Scrum Teams, Delivery Teams, AND Leadership Teams.

A bit of background — there are many agile leadership myths out there. These myths (or assumptions) limit leaders ability to improve, help others, and succeed. Many myths seem to occur at a nonconscious level, meaning they function like many biases. People are not even aware, consciously, that they are happening.

Continue Reading→

Scientific Management does not work

Limit Engagement, Limit Success – Scientific Management Problems

by

We require environments where people can provide input and ideas. If we limit engagement, we limit success. We still have organizations who either believe or act like they believe some types of workers are “stupid.” This idea dates back to the ideas surrounding Scientific Management, Fredrick Taylor, and Henry Ford. The concept of the stupid or unskilled worker that I mentioned was common in the early 20th century. In various writings about agile and agile ideas, we often refer to or see references to avoiding Scientific Management, Classic Scientific Management, or Taylorism. These management ideas limit engagement from people, which is going to limit success.

Understanding the past can be quite helpful to see where you might be able to improve today. 

Continue Reading→

Why Project Retrospectives Are Challenging

by

Project retrospectives are challenging. I spoke a bit about this in lessons learned vs. project retrospectives. You might look at a merger, acquisition, implementation of a new ERP system, or even a major upgrade of an ERP or CRM system. These are non-reoccurring events. A retrospective of this type is quite different from a typical agile retrospective, primarily because on this type of project, people will change and the project will not repeat (the definition of a project is that it is a unique endeavor). At issue here is the fact that if the people will not be the same and the project does not reoccur – then they can’t come up with actions they will apply right away based on what they learned. Ideas for change often just end up in a spreadsheet, a book shelf, or some electronic tool. A big book of “lessons learned” that sits on the shelf gathering dust does not provide much, if any, value.

Continue Reading→

Agile Safari – Best Agile Project Management Software

by

No, I don’t hate agile project management software — it can serve a purpose. At issue is if there is an actual purpose and if it is misused. Often the software stalls progress or worse, move us backwards. For any readers who are not familiar with agile or don’t work in software — the idea here is that instead of using the monitor to display some type of software tracking tool, the new scrum master just used sticky-notes and stuck them on the monitor. What is the simplest thing that works in your world? 

Continue Reading→

Agile Safari – What’s Not Being Said?

by

Have you been in a situation where no one would bring up the problem that everyone knew was “in the room?” I’d guess that everyone has been there. So often, we don’t bring up the “elephant in the room.” For anyone who has not heard of this, the elephant in the room is a saying for the real or obvious truth that is not being addressed. Given an elephant in a room would be hard to miss, when people ignore it, they are typically pretending it is not there.

Continue Reading→

Facilitating with The Focused Conversation

by

I was presenting Building Antifragile Relationships and Teams at Santa Barbara Agile recently and as we worked on ideas for a conflict protocol, we started discussing the common theme of “facts vs. feelings”. I’ll point out that there was not a hard-line view in the group as to one way or another, but it came up and opened up a nice discussion on the topic.

Facilitating with the focused conversation
The Focused Conversation Poster.

I mentioned The Focused Conversation as a great tool you can use to help structure a conversation. Focused Conversations include four important categories of questions — objective, reflective, interpretive, and decision focused questions. The acronym ORID is sometimes used to describe The Focused Conversation.

The structure also provides a way to hear all of the voices that need to be heard within the group or team. You might even use this as part of an agile retrospective. Using the tool is another way to build antifragile relationships in teams and organizations.

Continue Reading→