Viewing entries in
Agile PM

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 TRIAD at the Heart of Agile Collaboration

I was employed a few years ago at a wonderful company. I first joined them as an agile coach and Scrum Master. I had been spending an inordinate amount of time on the road teaching, so this local opportunity to coach a set of agile teams was timely and incredibly welcome by my family and I.

After joining, I was soon promoted to a Director of Software Development role and became a member of the senior leadership team. That was my title and my primary role, but I continued to coach and champion agility across the organization.

I used to joke about arguing with myself because I had two halves. I had the dark-side responsibility of “management” (Darth Vader) and the light-side responsibility of coaching our self-directed agile teams (Luke Skywalker). Although I felt I achieved a reasonably good balance, it certainly was challenging at times to keep my heavy breathing to a minimum.

The Agile Project Manager—Don’t Throw out the PMBOK!

I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

  • be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
  • pay close attention to risks – planning, real-time surfacing and guiding team reactions
  • encourage the teams to improve at an accelerated rate; to set the bar high for improvement
  • become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress

The Agile Project Manager—Listen to your Spider Sense

I was working with an organization a few weeks ago on a coaching assignment. They’ve been experiencing quite a bit of attrition within their technology teams and the discussion inevitably went to root causes. Several leaders at the client were confused about the drivers behind it.

One of them said that they had sat down with several developers before they left and everything seemed fine. They talked about the developers concerns and tried to address every one. They felt that there were “tuned into” the team and were trusted. They just couldn’t understand why folks were leaving without giving them an earlier warning…and more importantly, a chance to address their concerns.

Here’s another interesting ‘twist’ to the plot.

The Agile Project Manager—Driving Value or Where’s the Beef?

The Agile Project Manager—Driving Value or Where’s the Beef?

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Quite often, when she was disappointed in her quest, she would shout “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—sort of throwing the software “over the wall” for feedback.

The Agile Project Manager—What’s the Big Deal about Commitment?

As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

The Agile Project Manager—Do You TRUST Your Team?

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

- If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

- If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

The Agile Project Manager—Viewing RISK Through a Different Lens

This post was originally made in PM Times in June 2010. However, I wanted to make it part of my “Agile Project Manager” series, so I’ve updated and extended it a bit…hope you enjoy v2.

 I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMP’s in the audience the more spirited the discussions become.

The Agile Project Manager—Voila: The Great Reveal

The Agile Project Manager—Voila: The Great Reveal

I remember the day as if it was yesterday. It was my first sprint review at a company I’d just joined as an agile coach. They’d been ‘doing’ Scrum for several years and I had gotten the general sense that they were well disciplined and mature agilists.

So when they scheduled a series of sprint reviews to expose the x-team efforts of their latest sprint cycle, I was understandably excited. So I got into the room early to get a good seat and was eager with anticipation.

Gradually, the room filled and it became quite noisy, which only drove my anticipation higher. Then the first team took “the stage” and began their review. They popped up some PowerPoint slides and away they went…

The Agile Project Manager—“Going Agile”...The Price of Admission

I often get asked to visit agile teams—delivering some ad-hoc training and taking a look about. Usually I’m asked to do an informal assessment and share improvement feedback—framing the visit as part get to know each other session and part agile assessment. A short while back I visited a team. They’d been doing agile (mostly Scrum) for quite a while and considered themselves relatively mature in their adoption.

Right away, when I got off the elevator, I noticed that their environment was open and airy; so very conducive to collaborative agile teams.  There were rolling whiteboards all about and small groups of people were talking and pairing all over the place. Even the managers were sitting out in open space.