We live in a day and age where there’s a ton of information and mis-information out there about pretty much every topic imaginable, and Agile development is certainly not immune to this phenomenon. In fact, anyone who looks for help in pushing through an Agile transformation in their organization is immediately confronted with a vast array of presumptions and preconceptions about what Agile is, why it matters, and most importantly what it delivers. The simple truth is that the reality of an Agile transformation — both in process and in outcome — is often so very far removed from the myth that we as Product Managers need to be ready, willing, and able to step in and manage the expectations that our stakeholders have about what’s going to happen and what they’re going to get from it. Here are three very common preconceptions that simply must be squashed for us to lead a successful cultural transformation.
The Many Hats of the Product Manager
Sometimes an idea just strikes me out of the blue and sounds interesting enough to sit down and write a little bit about. This is one of those posts, spurred on by a discussion I had today with a newly-hired Product Manager with almost as much experience as me. As we were talking about our past experiences, where the current company is at, and how we can work together to improve some of the practices and procedures throughout the organization, I started to think about all the different things it is that we actually do as Product Managers, and all of the hats that I’ve worn in the past. These are some thoughts on a few of these hats…
Why Does Agility Matter?
We tend to take the fact that agility is important as a given, when the reality is that not everyone in the business world has reached the same conclusion. Thus, it’s important sometimes to take a step back and examine why agility actually matters, so that when we’re faced with people who aren’t as convinced as we are, we have salient points that we can raise to help them understand the value that agility brings with it. Here are a few important things to remember when thinking about why agility is important in our jobs…
Why “Scrumbut” Shouldn’t Be a Bad Word
There’s a term that gets floated around the Agile world by what I like to call the “textbook Scrummers” that really bugs the crap out of me, so much that I decided to write an article about the concept, and why I think it’s a wrong-headed, anti-agile concept. The concept is known as “ScrumBut” (a shortened form of “We do Scrum, but…”) and as the folks at Scrum.org describe it:
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.
In theory, this concept sounds harmless — after all, Scrum is a very specific methodology, with specific ceremonies and deliverables that are designed to achieve specific goals and specific benefits. The problem lies in the fact that these methods are not the only way to achieve those goals, though the companies who provide Scrum training would be loathe to admit it. Here are a few reasons why “ScrumBut” really isn’t as bad as those “textbook Scrummers” might have you believe…
A Product Manager’s Guide to Technical Debt
There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
- « Previous Page
- 1
- …
- 4
- 5
- 6
- 7
- 8
- …
- 11
- Next Page »