Does your team have a project charter so they know what to do for this project? I see too many teams try to start work without one. That leads to feature factories, apparently random work that does not add value, or worse, a product that’s partly done in too many areas. Teams start without project […]
I’ve been speaking with several possible clients. They’re having trouble with Scrum. The managers don’t believe the teams need product owners, so the teams don’t have POs. The managers think a Scrum Master can support at least four teams. The teams start a lot and finish very little. The teams think they have too many
You’ve got an impossible project. You have no flexibility. The project is a fixed-price, fixed-scope, fixed-date project. And, you have a specific team to do the work. (There are other impossible projects. Such as when you have a collection of people who multitask among several projects.) Can an agile approach save these projects? No. An agile
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
We hear a lot these days about project-based organizations vs. product-based organizations. Much of what we do in software is in service of products. Products tend to evolve over time. When we work on projects, we learn from the experience. However, once we finish this release, the “product” (the output of the project) doesn’t change
Bob Sutton (@work_matters) tweeted this the other day: Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others I retweeted it and we had some back-and-forth about what to call people i organizations. Let’s eliminate these words for people who are not managers: Individual Contributor: There
I keep encountering confusion about what scaling agile is. I’m writing what I think is a 4-part series to define it so we all talk about the same thing. When I ask people to define what they mean by scaling agile, they talk about these possibilities: They have agile developers. They want agile testers. This is
Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox. I like timeboxing many things. I like timeboxing work I don’t know how to start. I find short timeboxes help me focus on the
I started this series writing about the need for coaches in Coaches, Managers, Collaboration and Agile, Part 1. I continued in Coaches, Managers, Collaboration and Agile, Part 2, talking about the changed role of managers in agile. In this part, let me address the role of senior managers in agile and how coaches might help. For years,
In Coaches, Managers, Collaboration and Agile, Part 1, I wrote about circumstances under which a team might want a coach. It wasn’t an exhaustive list. It had several questions defining when coaches might help the team to become agile, not be cargo cult agile. One of the reasons we might need coaches for a team is because