Many product owners and customers believe they know the problem they want to solve. That fake certainty causes them to define solutions, instead of solving the problem at hand. John Le Drew and I pair-wrote an article describing this problem and how to solve it. See Eliminate Fake Certainty and Solve the Real Problem. Yes, I’ve […]
I’m catching up on my podcasts and just listened to Seth Godin’s Akimbo episode about honest signals. (Do listen.) It’s about the signals we send that are honest or dishonest and why we might choose one, the other, or both. I started to think about the management signals we send, especially in an agile transformation.
I’ve been pair-writing a book with Mark Kilby, From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver. We hit a big milestone today: We published the first complete draft today. We’ve been working on this book for a year. It’s much better because of our collaboration. We reflected a little on our success to
I’ve been thinking about my clients who’ve had success moving from a project-based/resource-efficiency organization to a product-based/flow efficiency organization. They had these things in common: A senior person made it safe for the managers to create experiments. They created very small experiments (either managers or teams, or together). The senior manager often asked a question
Cliff, an IT Director, was concerned. One of the projects was a mess. It didn’t seem to matter how much or how little the team had for requirements. The team never seemed to release enough on time. Cliff had only been with the organization for four weeks. Yet, that team seemed to have more trouble
How do we move from a project-based organization towards a product organization? There are at least two systems of work we need to change: The management system and the culture of management How the teams work and their team culture. I’m not sure it’s that simple to explain. There might be more systems I don’t
How could we organize if we want flow efficiency? We would reward managers by their span of service instead of control, part 3, stop organizing by function, and move to something that looks like a product-based organization? My transforming idea for this question was to think about the organization as legacy code. We understand how to
This series is about how you might move to a product-based organization. Part 1 was about how when we organize by function, the recognition and rewards might prevent a successful agile transformation. Part 2 was about one possibility for moving to a product-based organization. Before we get to who moves where, we need to consider the manager
If you’re thinking about an agile transformation, you already know about feature teams. You might even call them/use them as product teams. You might wonder about organizing all the work as product work. See Your Current Organization Many organizations use functions to organize people. The “Typical Product Development Organization” shows the kind of organization I
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