Not more info, but the right info

Here some dude says this: "This takes me back to Herbert Simon’s stupid idea that all we need is more information. What? Now, he’s dead we have all the information we could possibly get our hands on and the world is no better off! In fact, the more information we get the worse things become."

Fascinating...

The shortest distance

Is this totally Lean? You don't know what "you don't know" until you know it. So minimize your reliance on guess work. Use Occam's Razor and push forward. Do something, measure it, revise your model based on the new metrics, rinse and repeat. Keep speculation at a minimum.

Pragmatic Webinar

Steve Johnson presented a webinar on the Pragmatic Marketing site. It was worth the watch for quotes like:

"The real role of an Agile Project Manager is to force the project to leave the building despite the company's best efforts to prevent it."

And "I don't accept the premise of your question."

And this interesting formula: "Evidence * Impact = Priority"

More thoughts on valuation

Somewhere on the Tyner Blain blog it says this:
"Financial benefit is what we have to base our decisions on - both hard ROI and soft ROI data. We can measure cost data, and even forecast it - taking into account both fixed and variable costs. But if we use the wrong cost allocation strategy, we will make suboptimal decisions. The success of a requirement is based upon the ratio of value to costs."

Many streams of thought here...one conclusion is this; bad numbers are worse than no numbers. Maybe during the retro we should look back at the predictions and see how accurate we were, then apply that same percentage of correctness to future considerations.

Deep thoughts (better than Jack Handy)

This is very deep and might be cool (if it can be transliterated from "theoretical" to "actionable"). Read this link.

Contained is this quote; "Remember a rule of system thinking is to understand the whole in favour of the parts. So look at the situation and ask your self how are the different smaller level wholes related to make the bigger level whole."

BA's in the Agile process

This dude here is reasoning out the role of a BA in Agile development.

His main point are these;
Developers can't elicit requirements. I agree, not because they can't, but developers should be busy developing. I'm not advocating insulating the developers from the users, but provide them the opportunity to productively develop without the added burden of trying to elicit useful information from the requestor...unless they want to.

Stakeholders can't model and document their own requirements. This is true. If a requestor is not familiar with creating a "user story," or expressing "conditions of acceptance," etc. Then someone (in the BA role) needs to stand in the gap and complete these components of requirements gathering process.

You need analysis experts. I don't agree with this. The developers should be able to analyze the requirements to propose a technical solution. The key word being "should." But it seems as if they push-back, they just want to "know what to code." Not "figure out what to code." What am I missing? I'd like to have another perspectives.

Getting value faster

Here Tyner Blain blog says this "...no one is promoting that we maximize value - they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest"

I think this is the perspective we need to adopt for project valuation and why we should attempt to compare effort to value.

The rest of this article is excellent explanation of "velocity points." Better than the nebulous explanations that are dished out thru most Agile training