Viewing entries in
Agile PM

Pareto and You—Separating the Wheat from the Chaff

Comment

Pareto and You—Separating the Wheat from the Chaff

I can’t recall when I first came upon the Pareto Principle. I think it might have been when I was studying for my Six Sigma Green Belt. But I’m unsure. I know I was operating as a QA Director at the time, because most of my example uses for it surrounded testing and defects. Nonetheless, it’s probably been over 15 years.

 

That being said, I don’t think I hear people “considering” Pareto enough in their day-to-day activity, so I thought I’d bring it up and remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for software engineering in general and agile teams in particular.

 

Comment

1 Comment

Google 20% Time…Sadly it’s gone!

 

A few weeks ago I saw an article on LinkedIn that Google had decided to drop its 20% time for its teams. If you’ve been living under a rock, this is one of the most referenced (and admired practices) at Google. In essence, every engineer was allowed to spend/invest 20% of their work time on project(s) that interested them. It was a creativity and innovation incubator of sorts. Teams would surround the “best ideas” and work on this with 20% time. As experiments would show merit, they might make it into the core products or leveraged as a new tool, technique, or method. And no, 20% time did not mean that employees worked 120% of the requisite time. It was an 80/20 split and not intended as a project schedule accelerator.

Now they’ve changed policies. Innovation is being focused more on specific teams working in labs, so more centralized. And 20% time is now jokingly referred to as 120% time as Google’s official policy hasn’t been to “remove it”, just to move it to discretionary—in each employees “spare time”. It’s too bad really, because this policy was truly inspirational to many companies.

1 Comment

2 Comments

The Agile Project Manager - Can Agile Teams get “Burned Out”?

My My, Hey Hey (Out Of The Blue)
My my, hey hey
Rock and roll is here to stay
It's better to burn out
Than to fade away
My my, hey hey.
--Neil Young

One of the core principles of agility is the notion of “sustainable pace”. It originated in the Extreme Programming community. Initially, in v1 of the XP book, it was defined or framed by the principle of a 40 hour work week.

I vividly recall managers at the time railing (no ruby intended) against the notion as a clear example that these agile maniacs were out of touch with business reality, out of control, and looking for an easy road at work. What could possibly be next—working from home?

In the second edition of XP, Kent Beck softened the message a bit and dropped the (n) hours recommendation. Nonetheless and thankfully, the notion of sustainable pace has remained as one of the core agile principles. Although there does appear to be an increasing de-emphasis of it within today’s agile teams.

 

2 Comments

The Agile Project Manager - You Can't Handle the Truth

Comment

The Agile Project Manager - You Can't Handle the Truth

One of my favorite movies of all time is A Few Good Men with Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation at the end clearly in my mind. You know the one.

Tom Cruise says—I want the Truth…
And Jack Nicholson leans forward, with that classic look, and says—
You Can’t Handle the Truth!

What a climax to the film. I get chills every time I watch that scene.

I’ve been thinking more and more in my coaching about why leaders and managers often wait too long to ask for agile coaching help. I think it’s a general phenomenon in agile (and non-Agile) teams and organizations, but for the purposes of this article, I want to focus upward—on “them”.

 

Comment

The Agile PM: WIPping Things Into Shape

The Agile PM: WIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

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.