One of the least glamorous parts of Agile development for most Product Managers is the process of backlog grooming. It can be a challenge to get teams to engage when they’re in the middle of a sprint, it can be difficult to convince stakeholders to refer to the backlog instead of the Product Manager for simple questions, but most of all it reminds us of the gigantic list of things that we’re not doing — which is a source of frustration for any Product Manager. However, maintaining a clean, healthy, and vibrant product backlog is essential to the success of not only an Agile product team, but to the organization as a whole. When backlogs are clear, prioritized, and public, people can freely and regularly review it, raising questions and concerns as they come up rather than waiting for a big bomb drop of feedback during some strategic planning session. If you’re a fan of my blog, you know that I strongly believe that it’s the little work in upkeep and transparency that transforms an organization from just “doing” Agile to “being” Agile — and the product backlog is the number one arrow in your quiver to make change happen.
Accepting Uncertainty is the Key to Agility
I’m often asked what the key to being “agile” really is, and over the years I’ve managed to come up with a clear and concise answer: accepting uncertainty is the key to agility. It is perhaps the single most fundamental culture change that companies must go through when making a true transition to Agile development, and it’s often the biggest stumbling block that prevents them from fully becoming agile. You can see this in so many anti-patterns of Agile development: long-term, specific roadmaps; set dates and forced marches; iterations that are dictated, not created by and for the teams; and so many others. All of these behaviors stem from an organizational inability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along.
“Agile” is More Than a Buzzword: Three Truths Behind the Manifesto
It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…
Knowing Your Effort Budget
It’s amazing to me how often I talk with someone about a project they’re working on, and when asked “what’s your budget on this” they just look at me with a blank look. Let’s be real for a minute — everything we do in product design, development, and management has limits. We have limited resources. We have limited time. We have limited energy. But all too often we just assume that everything that we’re doing requires 100% of our effort, 100% of the time. But that’s simply not true. Some things are more important than others. Some things require more time and effort and energy than others. Some things that we do can slip through with a smaller amount of our attention than others. We instinctively do this, but we rarely actually plan it — and that’s to our detriment and to the detriment of our stakeholders. Laying out a clear understanding of the amount of effort that you’re expecting to spend on any given project or component can be an essential tool in any Product Manager’s belt.
That Which is Urgent is Not Always Important
We’ve all been there — that sudden call from one of your Sales team with a customer “on the hook” but they only need this one more thing to close the deal. Or maybe it’s an escalated issue from your biggest customer that lands in your mailbox with gigantic ALL CAPS AND EXCLAMATION MARKS!!!!!! Or worse yet, it’s your CEO who “stops by for a quick chat” about something that he overheard at an industry event last night. Regardless of where these things come from, they all have one thing in common — they’re urgent. They require your time now. They simply cannot be ignored.
Or can they? Or more accurately, should they be ignored? If you ask me, the answer is absolutely. Things that are “urgent” are thrust upon us by others with some expectation that we’ll drop everything and deal with them — not on our terms, but on the terms of someone else. Here’s why you should beware of the urgent and instead focus on what’s important…
- 1
- 2
- 3
- …
- 8
- Next Page »