Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!

Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
Forum Moderator
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt Green check
expand Ranch Hand Scavenger Hunt Green check
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

Doc Norton wrote:Team Joy

I forget what conference it was that I heard you talk about this and I've often repeated it since. I think one example you gave of measuring it was including some kind of special notation on each git commit message. I also remember you mentioning that Team Joy is a leading indicator. This was many years ago, maybe 2008 if you were at the Agile conference in Toronto.
It's the Iron Triangle, right? Cost, Scope, Time. You can fix two of them, but you have to flex on the third one. If you fix time and cost, then you have to be flexible on scope.
I have to be honest and admit that I don't have much experience with negotiating contracts. That being said, in terms of budgeting, we ask that the budget be allocated to pay for the team, then bring the work to the team. If you know how much the team will cost per month and you know how much money you can allocate to the team, then you can figure out how much runway you have before you run out of money. With people and time/money fixed, you can then negotiate the scope based on what you learn over several iterations. This is where iterative development helps because if you prioritize the work according to the value you get from completing it, then you can be assured that you're getting the most valuable work done first even if you don't end up finishing everything you wanted to in the first place.

Geoff McKay wrote:
(where the scope of work is not well defined, as can be the case with Agile or iterative projects)

Does that imply that non-Agile or non-iterative projects have well-defined scope of work? That's not my experience. I spent almost two years on a project in analysis and design phases. We generated literally tons of documentation (it was a 100+-person project so imagine all of those people creating analysis and design specs). In the end, $36M down the drain, no running software except for a few prototypes, and the project got shut down. That definitely wasn't Agile, nor was it iterative and even with 100+ people trying to lock down the scope of work, it still failed.
Thanks, Doc. These will help tremendously in discussions about value and how we define it so it's measurable/quantifiable.
I just saw this today where someone in authority told the team to just close the stories and create a defect to carry over to the next sprint.

What's your approach to dealing with this, Doc, and changing behaviors? I'm asking questions right now to see what the motivations are but I'm going to bet it's all about making the velocity numbers look better.

Doc Norton wrote:Measuring individual velocity won’t tell you who is actually contributing to the team, who is improving process, or even who actually delivers the most stories, but it will encourage your team to make collaboration a secondary concern at best.

This also resonates with my experience although in our case, it was actually our focus on collaborating, doing pairing and mobbing, that helped us realize that measuring individual velocity was of no value, so we stopped doing it (measuring individual velocity).

Seems like this means we shouldn't be asking each individual team member "How many points do you think you can do this sprint?" during sprint planning.

At the same time, I know for sure there are teams out there that are doing this exact thing.

Doc Norton wrote:...most of what impedes the work is queues and system level impediments that are generally unrelated to the work. For organizations where issues exist such as extensive infrastructure lead times, limited stakeholder availability, or crossteam dependencies, there is almost no correlation of duration to the size of the work.

"Effort and duration are rarely correlated, much less equivalent."

This resonates strongly with my experience. I don't know if people will take this with anything other than nonchalance though. How do you have an effective conversation around this that results in a change for the better? I guess I'm asking (again) what you say when they ask, "If we don't equate effort with duration, how do we know when we'll be done?"

you wrote:Velocity isn’t about measuring the team. It is about having a coarse-grained forecast.

I really like this. Too often, velocity gets weaponized against teams. What would you say to managers when they do this? Is there an alternative way to measure teams or should they not measure teams at all and focus on something else instead? If the latter, what is that something else they should focus on? (I think I know the answer but want to know what you think).

Paul Clapham wrote:I'm pretty sure that Fortran had (has?) real multidimensional arrays.

Pascal also supports multidimensional arrays.
1 day ago

Doc Norton wrote:Or drinking your own Champaign, eating your own cake, driving your own car, ...

Drinking your own brew, eating your own tomatoes, beating your own drums, ... ?

But what's wrong with "eating your own dog food"? Is it too gross? I can see how "many ways to skin a cat" has fallen out of favor but there are things more gross than eating dog food. <shrug>
Hi Doc,

you wrote:Velocity is the rate at which a team delivers value to the customer. A team that completes many tasks, but delivers no value to the customer should have a zero velocity.

I'm currently working at a place where leaders are having the conversation about shifting from focusing on velocity to focusing on value delivered instead. What advice can you give for having that conversation?

I think people latch on to velocity because it gives them something that looks like a quantitative measure even though it's usually based on something intentionally nebulous like story points. It seems like in their minds, some number is better than no number.

I think it's great that the conversation has now shifted to value but how are we able to scratch that need to have something quantifiable?

I often cite the example of one place that quietly released a simple address change feature to production. They had built in a way to gather data on how many users discovered the feature on their own and completed the address change through the new self-service flow rather than call customer service for help. With that data, they were able to quantify their savings based on reduced number on customer service calls. And because enough people discovered and successfully used the new feature within a few months of its release, they were able to declare success with concrete evidence to back up their claim.

Do you discuss ways to measure value in your book? If so, what kind of examples do you give?
Welcome, Doc Norton! Hope you have good week here at the Ranch.
Maybe a long-overdue FAQ?
2 days ago
One more person I want to mention: Jack Reeves and his three essays on Code as Design

Reading these articles was how I formed the opinion that coding is a design activity and writing tests before writing production code is a design technique.
3 days ago