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.

The Agile Project Manager—There Can Be Only One!

I hope I’m not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one.

I use the symbolism of the Highlander to remind myself of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking. The second reminder is the subject of what I want to explore in this article—the notion of investing in a single team to create a working model for your agile adoption efforts.

The Agile Project Manager—Traditional PM Triangle be Damned, Keep Quality First!

I can’t say how many times I have heard software practitioners talk about the Triple Constraints of Scope, Time/Schedule, and Cost as a triangle and suggest mental games of adjusting one and fixing the other two. Often you see Quality as a fourth constraint that is dependent on the other three, which is very true.

In my traditional project experience, stakeholders try to fix all three constraints—dictatorially fix them. This inevitably leaves quality as the only variable and, as teams flex on quality, the trade-off is hidden from the business until after the software is deployed.

Comment

The Agile Project Manager—Fostering Controlled Chaos

As you may or may not know, I’m an active agile coach. I often get asked to enter new teams and jump-start them or assess their overall level of agile-ness. One of the ‘smells’ that I look for in a strong and healthy agile team is what I’ll call controlled chaos or perhaps a better phrase would be guided chaos.

You see, the atmosphere in these teams isn’t safe nor predicted too far in advance. The teams don’t have a false sense of security. They’re working on a short list of features in close collaboration with their Product Owner. They know that challenges will rise up to meet them. Risks will fire. Team members will get sick or get married or tend to ill parents. And the design approaches and code won’t always work as advertised.

Comment

Comment

The Agile Project Manager—The Secret Sauce: Team Appreciation

I was attending a session at the Agile 2011 conference where Jean Tabaka from Rally Software was talking about some generic agile coaching tools & techniques. Jean happened to mention a few times that Rally had been internally focused on some organizational change models that happened to focus on strengths, positive recognition, and appreciations.

Focusing in on appreciations, she stated that it started in team retrospectives. That Scrum Masters would ask the teams to share their appreciations of each other as a start-up or entry ceremony for each retrospective. But then it caught onto other organizational meetings. She mentioned that many of their company-wide, all hands meetings began with appreciations.

Comment

1 Comment

The Agile Project Manager—There is no ‘I’ in Team

A couple of weeks ago I was teaching a group new to agile some of the basics surrounding Scrum and related agile practices. It was going well. And, as is sometimes the case, I was getting full of myself and feeling over confident. Things were going smoothly, the attendees were “getting agile”, and life was very good.

Then it happened—from left field and without warning.

We were talking about the nature of a self-directed agile team. I was trying to paint the picture of group-based accountability and responsibility. How empowering it was and how it led to the best results. How teamwork, well basically ‘Rocked’, and how agile teams truly collaborated around the customer to deliver creative and high-quality solutions.

1 Comment

Comment

The Agile Project Manager—Getting out of Jail Free

I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.

Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:

If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?

Comment