Early on in my agile practice, I believed in generalizing specialists. I even wrote Five Tips to Hiring a Generalizing Specialist. However, if a team becomes collaborative, I no longer think we need generalizing specialists. That’s because the team works and learns as a team. If a team is willing to collaborate as pairs, a […]
I’ve led various project kickoffs over the years. Back in the closer-to-waterfall days, we had to introduce ourselves to each other. We could then move to the project purpose and release criteria. Now that agile teams stay together, we can change the kickoff to more project-specific work. I wrote an article several years ago, Keys
Some of my clients have struggled with their project governance as they move to agile approaches. In the past, they’ve asked for estimates and costs—by requirement—and then tracked the variance for those estimates and costs. The governance people do not record assumptions. They only record estimates and actuals. They want to “measure” the project success
Your customers can’t take your product more often than once or twice a year. Because the product doesn’t need to leave the building, the teams don’t release internally. Nor do the teams demo on a regular basis. The teams miss the feedback loops so critical for an agile approach. Their agile transformation falls apart. Rethink Your Definition
One of the big problems I see with a product orientation (as opposed to a project) is in preparing for ongoing work. You might not start the next project for this product after you complete this project. You might have to round-robin projects for various products because you don’t have enough people to do all
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
Project advances might be rare. However, you can take advantage of seeing the conditions to create your advance. I’m at the Agile 2018 conference this week. Yesterday, I was scheduled to deliver my Agile and Lean Roadmapping talk at 10:45 am. However, the room was full 15 minutes in advance. I checked with the volunteers—yes, they
Do estimates make you slightly crazed? Maybe you want to roll your eyes at the organization’s confusion between your estimate (guess) and a commitment. You’re not alone. I wrote an article about estimation, How to give IT project estimates—and when not to estimate at all. If you’ve ever struggled with estimating work, give it a read.
Mark Kilby and I are almost done with the chapter on geographically dispersed teams with no (or very few) hours of overlap in our book about distributed agile teams. We are looking for any example of a team—agile or not—who successfully used/is using Follow the Sun. Follow the Sun is a great idea. The idea is
As Mark Kilby and I work through the images and text for the geographically distributed teams book, I wanted to clarify what collocated and distributed mean. Collocated teams sit near each other in space. However, not everyone agrees on what is “near.” In Developing Products in Half the Time, Smith and Reinertsen use the Allen