Agile needs front-end planning model to move away from the current back-end reactionary model...

Here is an (edited) conversation I had over chat with a friend today.

The point of this conversation is that I'm exploring the idea that what Agile is missing is front loaded change feedback.  Something along the lines of, "Ok, we can do that but it'll cost you $5."  The current model works like this, "OK, we did the work, that was days/weeks ago, and it cost you $5."

This is not about controlling change or costs.  It's about visibility.   

Right now, to make the impact of change visible, takes days or weeks (and in really shitty Agile environments - months).   It's my feeling that, if the tools modeled outcomes in real time and the effects of changes could be guessed at or estimated, then the impacts could be modeled in real time.

This would make the potential impact of any changes highly visible.

I really feel this is on the leading edge of Agile and would love to discuss this more.

Here's the concept (don't worry, the conversation below is short):

Faceless friend: And on the same sh*t different project front, tech and UX can't agree on stories.

scottahurlbert: Who is this?

Faceless friend: Your mother.

scottahurlbert: You need to attach one of these to each user story or feature:

scottahurlbert: http://www.shockwatch.com/products/impact-indicators/shockwatch-label/

scottahurlbert: Actually, that's something I've been thinking about a lot lately.

scottahurlbert: I'm just teasing with the impact indicators but ...

Faceless friend: That is a wicked cool thing, though.

scottahurlbert: My idea is this...

scottahurlbert: The trouble with agile is that it measures everything after the fact.

scottahurlbert: But what you need are KPIs that change when you modify any of the attributes of a story.  This would keep everyone playing fair.

scottahurlbert: Now it would all be guesses, but if you could capture the guesses the way you capture points it could be "best we know at the time" all the time.

scottahurlbert: So, for example, you would establish a base setting by scoring a story.  Then as you modify a story from it's base you would be automagically modifying it's point total with ALL input, in real time.   Schedules would adjust - in real time - and the effects of any changes could be seen on the speculative timeline.

Faceless friend: How do you measure, though?

scottahurlbert: This "speculative timeline" would be treated as real until more information came to light - this new information would simply adjust the trajectory of the "speculative data" the way that getting points adjust the burn down.

Faceless friend: A point system ?  What if the UX effort is small, but the tech effort large?  Or vice versa.

scottahurlbert: You don't - you pro-rate forecast EVERYTHING.

scottahurlbert: It's what's missing from agile.

scottahurlbert: Front-end feedback.   The entire Agile system is based on backend feedback and a feedback cycle from the backend based on weeks and months (multiple days at a minimum).  This allows for wiggling.

scottahurlbert: If instead, when you modified something, the dates all changed in real time, the resource requirements got changed in real time, etc etc. it would be more impactful and would allow you to actually manage an agile project.

scottahurlbert: It's what's missing.

scottahurlbert: Sorry it took me this long to figure that out.  It seems so obvious when you say it.

Faceless friend: But how do you quantify the change?

scottahurlbert: Does not matter - at LEAST you would be arguing over that.

Faceless friend: Hm.  Interesting.  

scottahurlbert: For example, you could say, "this change makes this story 10% more complicated."

scottahurlbert: This change cuts the scope by 50%

scottahurlbert: This change adds 16 hours of fixed time.

scottahurlbert: This change adds a hard dependency to story ABC.

scottahurlbert: Do you see what I'm getting at?

Faceless friend: Yes.

scottahurlbert: You would be changing the model as you go by quantifying the changes so let the changes fly.  But you are also still tracking velocity and so at the end of each sprint/iteration/story the rubber still meets the road.

Faceless friend: You would (of course) need to get a consensus, but then you could calc a whole new set of metrics.

scottahurlbert: In a hard fashion and all your forecasting gets made real again by each new velocity measurement.

scottahurlbert: You wouldn't even need consencus because it would all be kept in check by the velocity.

Faceless friend: Then when you're velocity sucks, you can point to the stats.

scottahurlbert: yes

Faceless friend: Stakeholder Ahole A added X scope, pushed Y story N stories down the backlog, etc.

scottahurlbert: And in your scenario, the change made by A-Hole-A would be immediately noticable.

scottahurlbert: Now it's only noticed during sprint planning - days later.

Faceless friend: Yes.

scottahurlbert: Maybe weeks later.

scottahurlbert: Becasue in Agile there is no real time forecasting.

scottahurlbert: So, to put this in to practice today where none of the tools support front facing metrics, what we need are tools that allow us to do these mods in near-real-time.

scottahurlbert: You could do it the way you would use a spreadsheet to track extras.

scottahurlbert: Or you could start with a set of numonics that capture meta data around the changes that can be output as a report to be cycled back into the stories at regular intervals.

Faceless friend: Well, realistically, you're mirroring the Change Request process.

scottahurlbert: This feature REALLY needs to be real time, but a page based calculator would be a start - or a working man's spreadsheet.

scottahurlbert: Yes, the change request process but with Agile lingo.  I love it.

scottahurlbert: And in fact, that's a way to sell it.

Faceless friend: Let's build it.  Make millions.

Faceless friend: We split 90-10.

Faceless friend: You can live off of 10.  

Faceless friend: Yes.  If you view Agile as an attempt to get stakeholders involved in the process, this would be arming the peasants with torches and pitchforks.

scottahurlbert: Agreed, but in a good way and not so much a "burn her, she's a witch" kind of way.

scottahurlbert: More like, "stop her before she becomes a witch" kind a way.

scottahurlbert: I need to take this notion, make it an idea, then craft it into a concept, mold it into a metaphore, twist it into a design, bend it to a model, and build it into a product.

Faceless friend: I really think there's something here.

Faceless friend: It's an entropy measurement.  That can't be bad.

scottahurlbert: Yes, great way to put it.  Entropy and Change Request.  Brilliant.