I started this series with observations that my clients appear to confuse strategy and tactics. They think agile approaches are tactics and agile tools are part of their strategy. That’s why they want to Buy an agile approach. And that’s why they want to Customize and then standardize on tools. This post is about this […]
In Part 1 and 2 of this series, I wrote about how an agile approach might offer strategic benefits. And because an agile approach changes your culture, I said the agile approach was part of your strategy. So let’s ask this question: Can any tool—agile or otherwise—offer you a strategic advantage? (I don’t see how,
Many of us focus on how efficient we can be. Many of our organizations want to maximize our output for every minute and hour of work. However, if we focus on effectiveness first, we create better outcomes for everyone. We don’t waste time working on things that don’t matter. An Example of Moving from Efficiency
I’m struggling to write several posts and I realized I need to define my terms. I keep seeing managers confuse the strategic and tactical. That leads to large and unchangeable roadmaps and a lot of emphasis on predictability. I don’t know how to offer the level of predictability they want for large and unchanging work.
Many managers feel the need to get more and more done. They feel pressure from customers and salespeople for more features or products. Or the managers might feel the need for more revenue. So they start many projects. When teams have too many projects, teams take longer to finish. This means all that pressure continues
Modern Management: Build Empathy with the People Who Do the Work Here’s a scenario I see too often in organizations. The product teams are supposed to work on several products “at once.” They have several goals for their work, not one specific goal. Why? Because the managers feel too much pressure to reduce the organizational
One of my clients wants to use shared services “teams” as they start their agile transformation. Their developers work on a product for months and years at a time. However, the testers and UI people are part of pools of people. The organization calls these testers and UI people, “shared services.” Shared service-thinking denies the
Have you ever noticed that other people want you to do “more” work? The work has risk—if you say yes to this work, you’ll put every other deliverable at risk. What do you say? You can address this request with a simple sentence: No. That’s it. No. It’s a complete sentence. I bet you feel
Several of my clients have intertwined problems. Everyone agrees they want innovation: Which products and services the organization offers. (The project portfolio) What features the product offers, or the problems the product solves. (The product roadmap) In the team, to solve the problems in a way that will attract users/buyers/customers. (The team’s backlog and how
What risks does your project have? Do you need feedback loops so you can: Cancel the project at any time (to manage schedule and cost risks. Assess technical risks so you can rework the architecture or design to manage feature set risks. Manage what you release to customers so you can manage defect, feature set,