Viewing entries tagged
transparency

Is NO The Right Response from Agile Teams?

Comment

Is NO The Right Response from Agile Teams?

No is a very tricky word. I often talk about agile teams needing to “just say No” to various things. For example:

  • If their Product Owner expects them to deliver more than their capacity
  • If their Boss asked them to deliver faster and it would violate their Definition of Done agreements
  • If a Team Member continues to “go it alone” and refuses to collaborate as a team

Then I’m looking for the team to say No. Whenever I bring this up in classes or presentations, I always get pushback. Always. Usually its not based on the situation, but to the word. It seems No is a word that nobody likes using in the workplace.

There’s a wonderful video by Henrik Kniberg where he explores the role of the Scrum Product Owner. In it he makes the point that the most important word that a Product Owner can use is No. That it’s incredibly easy to say – Yes to every request. To pretend that things are always feasible or easy. But that No is important. No implies that trade-off decisions need to be made on the part of the customer or the organizations leadership. That the word leads to thinking, discussion, and decision-making.

Comment

The Agile Project Manager—Engaging Your Customer!

The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’.

It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

The Agile Project Manager—The Clarity of Transparency

The Agile Project Manager—The Clarity of Transparency

I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the transparency fence—obfuscation. 

There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.

...If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.