Viewing entries tagged
agile planning

Agile Planning – Getting Punched Every Day

1 Comment

Agile Planning – Getting Punched Every Day

There’s a famous Mike Tyson quote:

Everyone has a Plan
until they get Punched in the Mouth

It reminds me of the ultimate futility of estimating and planning. Or investing too much in both of those endeavors. Particularly in the area of software product development.

Another related quote is from Eisenhower. It surrounds the value of plans (artifact) vs. planning (activity):

I have always found that in preparing for battle that
Plans are Useless,
but Planning is Invaluable

That is:

  • The activity of exploring requirements via user stories and acceptance criteria;
  • The activity of minimizing (MVP) the results so as to learn;
  • The activity of making estimates as a vehicle to explore size, scope, risk, and design approaches;
  • The activity of discussing construction and deployment strategy;
  • The activity of delivering work to stakeholders and gaining their feedback.

Are all more valuable than fixed or static plans, which are intolerant of the punches that are inherent in software development - learning and discovery.

Wrapping Up

The next time you find yourself getting “stuck in” your plans or thinking that planning is more important than doing and adjusting, then please remember these two quotes. Also remembering, that Tyson and Eisenhower weren’t practicing agile software development. But they were indeed…agile.

Stay agile my friends,

Bob.

1 Comment

Individual vs. Team Arithmetic - The choice is yours…

Comment

Individual vs. Team Arithmetic - The choice is yours…

Introduction

This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams?  And finally, when planning and forecasting, should we plan at the individual level?

The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.

The Dinosaur Age

Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?

Comment

Agile Capacity, Revisited:  Stop biting off more than you can chew!

Comment

Agile Capacity, Revisited: Stop biting off more than you can chew!

More than a year ago I wrote an article about how important “capacity management” was in agile teams. To be clearer the point was really…realistic capacity management.

At the time, I’d just come off a coaching roll where I’d encountered quite a few organizations that were pushing their teams too hard. Not slightly over their capacity, but two, three, four or more times their healthy capacity. And this created some distinct side effects:

  • Employee satisfaction and morale was down and attrition was up. And they didn’t just loose their average people, they were losing their best people;
  • Product quality was usually in a crisis mode and customer trust was continuously eroding;

Comment

When it’s No Longer Relative

1 Comment

When it’s No Longer Relative

This is a guest blog post by my colleague: Chris Waggoner. Enjoy!

Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.

1 Comment

Agile Release Planning - Redux

2 Comments

Agile Release Planning - Redux

If you've attended any of my Product Owner workshops or many of my conference sessions, you know that I often talk about release planning as a necessary extension to any of the agile methods.

From my perspective, it almost doesn't matter if you're leveraging Extreme Programming, Scrum, Kanban or some variation. If you're working in a context where you need to communicate release plans and make some sort of commitment to your stakeholders, then I think you should be doing release planning.

Now clearly it's not a silver bullet and you sure can't guarantee fixed scope & date commitments. But it certainly helps your teams align what's feasible within your release train tempo.

Here's a link to an article / 3-part post series I've written on the topic. I hope you find some value in it.

Stay agile my friends,

Bob.

2 Comments