Viewing entries tagged
team commitment

My Journey in Software Estimation - What a long strange trip...

Comment

My Journey in Software Estimation - What a long strange trip...

I’ve had a long career with estimates in software projects. While it’s been a rocky journey, I now feel that I’ve gotten to the point where I truly understand how to and the value of estimation.

But before I give you the great reveal, let me share some of my history…

Estimate Newbie

I first began my career as a newbie in estimation. I fell into the trap of being as honest as a could be and I found that my estimates were often used against me. For example:

  • My bosses would often forget the “fine print” around the estimates. Words like – “this is only a guess until I get more formal requirements. Or, I’ve never done this before, so I really don’t know how long it will take” were never remembered. Imagine that?

  • People who had not a clue would weigh in on my estimates. Bosses, who were under pressure to release quickly, would cut them. And project managers, who were trying to “defend” the project, would pad them. And my developer colleagues, who always had an optimistic spin on things, their estimates would always be lower than my own. Imagine that?

  • And I always felt that nobody wanted the “truth” in estimates. That they couldn’t handle it. So, it negatively influenced me to pad/cut depending on the situation. But the key point is the inherent dishonesty I felt around all estimate discussions. Early on, it felt like a game of sorts. Where the last one that weighed in on a number…won. And the development team…generally lost. Imagine that?

But as in all things, I grew in my experience and in my career. Soon, around the late 1980’s, I became a “manager”. Which meant that I not only had to estimate for myself but for my group(s) as well. This showed me both sides of the estimation continuum and frankly, I didn’t like it much.

Comment

A Dozen Ways a Product Owner can  Re-Energize! their Team

Comment

A Dozen Ways a Product Owner can Re-Energize! their Team

Often agile organizations take the position that the Managers, Leaders, or the Scrum Masters are responsible for keeping the team focused and energized towards their work. And yes, these roles can play a part in keeping the teams passion and energy focused towards doing great work.

But I’ve found that another role can really make a difference here as well. One that is rarely suggested for this sort of nuance. That role is the Product Owner.

To make my point, I’d like to share a dozen “opportunities” for a Scrum Product Owner to make a difference within their teams. Is the list exhaustive? Probably not. But that’s not the intent. The intent is to get Product Owners thinking outside the role of backlogs, user stories, and delivery. And instead thinking about ways where they can play a key role in the engagement, joy, energy, passion, focus, and results of their teams.

Yes, I just added another large responsibility to an already overwhelming role. Sorry about that.

Comment

Agile Leaders…Be a Yes Man!

Comment

Agile Leaders…Be a Yes Man!

Do you recall the … Jim Carrey movie called Yes Man? In it he was influenced by a ‘cult’ of sorts that recommended an approach, in order to change our lives, where we have to say YES to everything – every question, every opportunity, and every inquiry.

The point is somewhat captured in the agile posture of “Yes, and…” that many coaches subscribe to.

Lately I’ve been thinking about traditional software leaders who are moving towards agile methods. Typically they take a class or workshop to gain a cursory understanding of agility. Some even take more ‘advanced’ workshops, which are focused towards the leadership shift.

Comment

If you don’t ENGAGE your teams, don’t be SHOCKED if your estimates are WRONG

1 Comment

If you don’t ENGAGE your teams, don’t be SHOCKED if your estimates are WRONG

I watch my fair share of TV shows that surround real-world business and projects. I’ve noticed a theme that I want to share to see if you see it the way I do. So here are a few examples:

Gas Monkey – Fast ‘N Loud       

Fast ‘n Loud is a show on Discovery Channel here in the US. It’s about a garage that takes in “needy” cars and refurbishes them for resale.

The owner of Gas Monkey Garage is Richard Rawlings. In the episodes he generally is scouring the countryside for fixer upper cars that have up-side profit potential.

1 Comment

Forecasting: Is it EVIL in Agile Portfolio’s?

1 Comment

Forecasting: Is it EVIL in Agile Portfolio’s?

I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.

Is forecasting evil in agile portfolios?

YES!

The context for this conclusion and subsequent discussion is three-fold:

  1. Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
  2. And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
  3. And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting. 

1 Comment

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.

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