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,
I spoke at Agile 2019 last week. I had both a great time and a heart-rending realization. The great time was meeting and reconnecting with people. The heart-rending realization is our industry is in big, big trouble. Here are my thoughts and where I think the “agile” industry is headed. Problems I See with “Agile”
One of the experiences people miss in distributed teams compared to collocated teams is the ability to serendipitously bump into other team members or just other people. They like the idea of having random encounters to share what they did for the weekend or, more importantly, discuss problems they are struggling with at work. Sometimes
At the Influential Agile Leader workshop earlier this year, I led a session about scaling and how you might think about it. I introduced the topic and explained that “scaling” might not be the answer. My experience is that when people use frameworks for larger efforts, they experience these unexpected side effects: The framework actions
I suggested ways to think about more agile budgeting in part 1. I didn’t tell you why. How do you budget your own money and time? If you’re like me, you have a plan for the year. I evaluate the plan—my products, services, and clients—on a regular basis. I always evaluate monthly. Sometimes, I evaluate
Too often, organizations want to budget for an entire year. The managers run around for two or three months in advance of that fiscal year, attempting to predict a ton of things: Estimates for not-well-defined projects or features, Capital equipment or tool needs, “Headcount” aka, people needed. Then, the organization doesn’t finalize the budget until
Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning. They’re not living the principles of the agile manifesto. That insufficient collaboration means the PO