The Agile PM: Agile Basic Training—What is an Acceptable Level?

The Agile PM: Agile Basic Training—What is an Acceptable Level?

The agile methods are deceptively simple and common sense oriented. In many ways, that’s one of their great strengths, but its also one of their fundamental weaknesses. I see so many teams convinced that they can “go Agile” just by reading a book or an article and then diving in and “sprinting” towards successful software delivery. The logic goes that agile is simple common sense practices, self-directed, and intuitive—so of course it will be simple to pick up and execute.

I typically categorize these teams as “bad agile” teams in that they adopt a small, superficial, and somewhat trivial set of the core agile practices and then think they’re agile. In almost every case they don’t understand the agile mindset nor how the core principles and practices complement one another to foster improvement. They’re “doing Agile”, but they’re not “being Agile”.

The Agile PM—Please Sir, May I have some help?

3 Comments

The Agile PM—Please Sir, May I have some help?

A Sad Story

A seasoned Director of Software Development was championing agile adoption at their company. It was a moderately scaled initiative, including perhaps 100 developers, testers, project managers, BA’s and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were “good to go” as they started sprinting.  

Six months later things were a shambles. Managers were micro-managing the sprints and adjusting team estimates and plans. The teams were distrustful, opaque and misleading their management. There was virtually no honest and open collaboration—nor trust. They’d (re)established a very dysfunctional dance.

Funny thing is…

3 Comments

The Agile Project Manager--How do you want your Software, Good or Fast?

Picture this…

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order—gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making.

Honey she says—

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good & fast food. 

It seems as if we’re always given certain choices in our software delivery challenges similar to what our waitress has given us. We have all heard of the “iron triangle” of Project Management—defining Scope, Cost, and Time as the three critical dimensions for a project. Usually Quality is placed within the triangle as a fourth variable—totally at the mercy of the other three.

The Agile Project Manager—The ‘Essence’ of Agile Metrics

I’ve been struggling for quite some time figuring out the “essence of” agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

One thing I have discovered is that metrics need to be “different” in an agile organization or culture. Traditional measures don’t seem to work within agile teams—as I’ve often seen them to cause dysfunction (more on that later).

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning should we measure the processes (at the beginning or leading edge) or should we more so focus on the results & learning (at the end or from the trailing edge)? I’ll explore this more next.

Leading vs. Trailing Indicators

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?

The Agile Project Manager—No Upfront Estimates!

The diagram represents the Cone of Uncertainty—coined by Steve McConnell of Construx. I’m sure he’s not the first or only one to reference the cone, but he famously has connected it with software development. The cone indicates the futility of estimating & committing to software projects at project initiation—not matter how well conceived the estimates are. There’s typically too much uncertainty to be accurate. Instead, an iterative or incremental approach will glean more information to improve the estimates over time. This is particularly true for projects that include new technologies, new teams, or trying to create novel or innovative products.

I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.

All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter neither how hard we tried nor how much effort we expended on estimation and planning, over 60% of our projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—accurate software project estimation is incredibly hard.

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.