In Part 1, I suggested that when we organize by function, the recognition and rewards might prevent a successful agile transformation. In this part, I’ll discuss an option for a product-oriented organization. Consider a Product-Oriented Organization Instead of organizing by function, consider a product-oriented organization. Again, I am not saying this is the only way […]
You might remember I’m working on a book with Mark Kilby. It’s From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver. We just published a new version of the book. We rearranged the entire book. In this version, we added a chapter called “Avoid Chaos with Insufficient Hours of Overlap.” That one chapter might
Create Successful Schedules: Three Tips to Rolling Wave Planning Do you ever feel under pressure to finish “all” of whatever this project is? And, the project might unfold in various ways, so you can’t quite plan “all” of it? Enter rolling-wave planning. You don’t have to know everything. You only have to know where you
Many new-to-agile teams use some form of iteration-based agile approach. Often, in the form of Scrum. Back in Time You Spend in Agile Meetings (near the bottom of the post), I enumerated all the possible meetings. I suggested the team review its WIP limits and think about limiting the WIP for the entire team. When the
Whenever I teach agile approaches, I discuss the possible meetings a team might choose. Some people turn to me in dismay. They start adding up all the meeting time and say, “That’s a lot of meetings.” Could be. Especially if you use iterations. You might have these meetings: A retrospective once every two weeks. A
As I work with people to use agile approaches, I see many organizational constraints. I’ve been trying to find a visualization for what I see. I don’t know if I’ve got it yet, but here is my sum-of-the-parts image. The organization’s culture drives decisions (or not!) about the strategy. Strategy, with any luck, creates clarity
Agile approaches can help a team release more often. When a team releases more often, the product people can replan the product roadmaps. The project portfolio people can replan the project portfolio. Not every team releases often enough to take advantage of replanning small and often. Everyone falls prey to “too much” thinking. The product
One of the problems I see in projects and organizations is when people wish for certainty. Too many agile project managers and Scrum Masters want a known velocity. They don’t realize that velocity is a relative capacity measurement, not a guarantee. Product managers, the people who manage the project portfolio, all seem to want certainty
Sometimes, teams have trouble releasing their work, showing the value of the work they’ve completed. There are many possible reasons for this release problem: The team doesn’t have sufficient working agreements about what “done” means. I’ve written about frictionless releasing. In Create Your Successful Agile Project, I wrote about the done, done-done, and done-done-done words we
Mark Kilby and I have finished the first four chapters of From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver. We thought we had five finished chapters. Then we realized how much more work we had, to move from Google docs to Markdown. Sigh. We have four finished chapters 🙂 And, we know how to collaborate in