Trust is Essential for Honesty

July 29, 2011

I recently read and commented on Pawel Brodzinski’s post, Give Honesty a Try. It is commendable that Pawel doesn’t have problems with people being critical of him because he is looking at the upside of knowing the truth. I agree with him –honesty helps us to do the right thing from an organizational perspective and honesty enables us to change and grow personally.

I asked Pawel a question that in all fairness was a tough question (as Pawel pointed out): ”I’d be interested in your take on building an environment where people feel secure enough to talk candidly. Personally, I feel that management has a role in building trust that goes hand-in-hand with honesty…”

As a writer on leadership topics – it occurred to me that I attempt to answer the question myself.

A Product Manager is an Agile Leader

July 26, 2011

As I’ve been gaining some very early experience in product management, I’ve noted some interesting parallels between the skills of a good product manager and a good manger, especially an Agile manger.

For example, one common refrain that I’ve picked up on from other product managers is that product managers need to lead people that do not report to them. They typically cite the challenge of being responsible for a product and counting on the cooperation and efforts of others that they don’t have direct authority over. Product managers, you’re not alone in this!

Diving Into Product Management

July 22, 2011

My transition from development manager to product manager was swift, and I’d sum up my first official month in a product management role as very active. I’ve been designated as the product manager of three products, one of which is a very technical, security-related initiative that is a BIG DEAL for our company. A product that will be a shared platform,involving integration of other products across our company...

My first order of business was to write a Product Requirements Document (PRD) for that very same security product (since we didn't have one). There has been various documents and artifacts produced to support release planning and development, so it wasn't like I was starting from scratch. Since we're a Scrum shop, the team has had a Product Owner in place along with a product backlog (the architect has been operating as the Product Owner until recently) and regular sprint reviews.

Did you notice a couple of warning signs? How about an important, new product under development with a part-time product owner? The absence of a PRD isn't necessarily a bad thing given that there is a product backlog, but in this case it turns out that we did have another problem that surfaced during my writing of the PRD.

Book Review: The Elements of Scrum

July 19, 2011

The Elements of ScrumIf you want to understand the essentials of Agile development and Scrum, The Elements of Scrum by Chris Sims and Hillary Louise Johnson is a must read. Chris Sims has worked with our company on a couple of occasions, providing “experiential training” in Agile development using exercises designed to demonstrate aspects of Agile development and why they work. His excellent training was for this reason that I felt this book would be a worthwhile read, and I wasn’t disappointed.

The book itself doesn’t talk about Agile development in pure theoretical terms, it provides insight on how Scrum teams function by using examples and clear explanations. The first chapter starts with, A Week in the Life of a Scrum Team, providing a short overview of what it is like to be a part of a Scrum team.

Phone Courtesy Isn’t Just for Cell Phones

July 15, 2011

July is National (U.S.) Cell Phone Courtesy Month!

Jacqueline Whitmore founded National Cell Phone Courtesy Month in July 2002, with “…the intent of making cell phone users more respectful of their surroundings.” I guess it’s taken me a while to realize that we had a cell phone courtesy month! This is the first year that I’ve become aware of it. How did I miss that?

The popularity of cell phones, texting, Twitter, Facebook, LinkedIN, etc. all reflect the innate desire we humans have to be connected. Oddly enough, the very devices that enable us to be connected are demonstrating that they can adversely affect our personal connections.

Where Do Unused Features Come From?

July 12, 2011

My last post discussed why Cramming Features into a Product is Bad Business. Coincidently, a related issue popped up in the LinkedIN Agile group discussion, Do you agree or disagree that Scrum is not Agile? – as the discussion found its way to the topic of requirements.

Horia Slușanschi referenced the oft-quoted Standish Group’s statistic that over 40 percent of a systems features are never used. The exact figures from the Standish Group are depicted in pie-chart form below:

How do these unused features find their way into the system in the first place? And what can we do to prevent what is clearly a huge waste?

Cramming Features into a Product is Bad Business

July 8, 2011

“Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’” – Marty Cagan in his book, Inspired: How To Create Products Customers Love.

Hitting this wall is definitely a BAD thing. And it sneaks up on you. Bob Martin discusses this in his book, Clean Code: “Teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Have you ever waded through a mess so grave that it took weeks to do what should have taken hours?“

Managing the Agile Way

July 5, 2011

When I step back and consider our implementation of Agile development and what it takes to achieve a truly beneficial Agile adoption, I feel that ultimately, management is THE significant factor as to whether the organization will reap many of the benefits the Agile offers.

Agile isn’t just something “for the development teams.” Management needs to look beyond a specific framework and understand the operational and behavioral changes that should accompany an Agile adoption. Failure to do so will severely limit the organization’s potential for improvement.

Frameworks, not Processes!

July 1, 2011

I used to cringe whenever I heard someone say, “The process is the thing.” It was what came next that was the problem: a codified, rigid process that eliminated thinking and discouraged adaptation – at least not without a fight. For right or wrong, the PROCESS had to be followed, and this was with a company that said it valued continuous improvement!

Ever try implementing a change to a process – even one for the better – in an organization wedded to its processes? You need passion and persistence, which means that those small, incremental changes are likely never to see the light of day. The cost/benefit on an individual level is too high. Worse, you run the risk of getting dinged on your performance review for devoting too much time and attention on low-impact initiatives.

This is a shame, because the cumulative effects of many small changes can equate to a significant benefit.