It’s time to wrap this series. I started asking if you actually need an agile approach in Part 1 and noted the 4 big problems I see. Part 2 was why we need managers in an agile transformation. Part 3 was about how people want a recipe. Part 4 was about how “Agile” is meaningless
I started this series asking where “Agile” was headed. (I didn’t like what I saw at the Agile 2019 conference.) Part 1 was about the 4 big problems I see. Part 2 was why we need managers. Part 3 was about how people want a recipe. This part is about what “Agile” or “agile” means.
I started this series asking where “Agile” was headed. Part 1 was about the 4 big problems I see. Part 2 was why we need managers. This part is about how people want a recipe, The Answer, for how to get better at “Agile.” Before we can address what an answer might be, your need
In Part 1, I wrote about how “Agile” is not a silver bullet and is not right for every team and every product. This post is about how management fits into agile approaches. Too often, managers think “agile” is for others, specifically teams of people. Teams need to figure out how to manage their WIP,
Note: I had a technical problem with my site and lost this post, even though I had published it. This is the restoration. If you subscribe to my feed, you might see this twice. I’ve been working with some clients who are trying to find the magic way to slice and dice their project portfolios.
Years ago, Roy Osherove interviewed me about project management, agile thinking, hiring, and management. We had a great conversation. (See Roy’s Archived Interviews page for my interviews with him.) I just listened to some of the questions and answers. If you are not sure about effective management, listen to the interviews. After a nudge from
I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people: People are resources Resources can multitask on several projects at a time If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas
Several recent clients want help with these problems: Estimation isn’t accurate. Because the estimation isn’t accurate, management can’t predict when they can release anything. Managers can’t manage the capitalization (a way to move from expensing software to capitalizing it). Teams can’t seem to ever deliver a finished feature. The work in progress everywhere is quite large.
Last August, back at the Agile 2018 conference, I had a chance to record a podcast with Howard Sublett. Howard is a terrific interviewer and a good friend and colleague. We spoke about Making Roadmaps More Agile. We had a blast. Several times, I surprised him with some of my thinking and experience. (Since I’m
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