Category: People

Do Agile Development Teams Need Multiple Product Owners?

Enterprise agile development is different. Developing software using Scrum, Kanban, Lean or XP is just not the same on an enterprise scale. Consider the stressed-out, over-burdened, Product Owner. Is it reasonable to expect one Product Owner to provide all the answers to the software development team’s questions? You can argue that it’s the Product Owner’s […]

Say It. Do It. Improve It.

Have you ever noticed that some people avoid the spotlight? That is, they like to work on low-key projects that don’t get a lot of corporate attention. I’m not in any way suggesting that they don’t work hard. They simply don’t like drawing attention to themselves. Along comes an agile development approach using Scrum, Kanban, […]

Scrum Is Not Stressful But People Are

I’ve heard complaints that the Scrum approach to software development creates a lot of additional stress. Really?  That perception needs further analysis. The team commits to a delivering a set of stories by a target date. That’s stressful. They have daily standup meetings to report progress and discuss impediments. More stress. They have to satisfy […]

Retrospectives Work When They Are Impersonal and Impartial

Retrospectives are a terrific way to continuously improve any software development process. As long as the organization is committed to improving itself, rather than protecting the status quo, there is nothing better than regular retrospectives. So why are project retrospectives often ignored or under used? There are many articles across the Web describing how to […]

Software Outcomes Matter, Test Results Don’t

How do you determine the success (or not) of a software project? How do you measure the final outcome? How do you know if the project delivered what was expected? You might be inclined to refer to the number of remaining known defects, the number of test cases, the improvements made in the code, the […]

Simple Math Doesn’t Work in Software Development

If building a particular software system is scheduled to take 5 engineers, 6 months, then simple math says that 10 engineers can build the same system in 3 months. (That’s twice the number of engineers and half the time.) Okay, okay. I know. Some additional communication overhead will be introduced by adding people to the […]

The Peter Principle Is Real But Agile Techniques Can Beat It

What causes the “Peter Principle” to rise up and ruin someone’s career? According to the principle, named after Dr. Laurence Peter, “In a hierarchically structured administration, people tend to be promoted up to their level of incompetence”. That’s a scathing comment. It is often repeated and there are many examples of people who get promoted […]

Don’t Give Product Owners More Credit Than They Deserve

Are Product Owners (PO) all-knowing and all-powerful when it comes to software features and functions? I think they’re sometimes given more authority than they can handle. There needs to be a balance between business needs and technology constraints. Here’s a specific example to illustrate my point. Let’s say the agile development team is asked to […]

Resistance to Agile Development Is Not Inevitable

Many companies would like to do a better job at developing software — better quality, better delivery times, better cost / benefit. Here’s the problem, getting better means changing and change is hard. It’s widely perceived that most of us are resistant to change. I’m not convinced of that. I think most people, including me, […]

To Be Agile, Establish Team Metrics Not Individual Ones

One of the points in my article, “10 Tips for Succeeding with Enterprise Agile Development”, is to focus on teams not individuals. Many firms have a difficult time with this concept. Large enterprises go to great lengths to manage individual performance — setting personal goals, rating staff members, tracking distribution curves, conducting annual reviews, creating […]

It’s Time to Redefine the Scrum Role of Product Owner

Are we expecting too much from our Product Owners? I’ve read many descriptions of the role and the responsibilities for a Product Owner in Scrum. Some of those descriptions seem over the top and appear to expect too much from the role. Comments like “willing to make hard choices” ( and “the single person responsible […]

Build Relationships Not Risk Management Tables

People who are good at the command-and-control approach to software development are always right. That’s correct, they are always right — every time. That’s ridiculous, you say? How can they always be right, you ask? It’s simple. They commit to schedules, costs and feature sets. Then, they pull out a risk management table and tell […]