• Incremental Funding Approach (IFA)
  • Should we spend any more money?
• Minimum Marketable Features (MMF)
  • How much and what product do we need to win?
• Minimum Releasable Features (MRF)
  • What can we release so that we can satisfy demand now and get more feedback?
• Minimum Demonstrable Feature (MDF)
  • How can we show case the product and thereby get valuable feedback early & often?

These are all methods to be validation centric.  The constant challege in complex product development is to build the right product.

More to follow this thought is still baking

Download Scrum In A Nutshell

excerpt… “While the Stakeholders are the most important people for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is held accountable by them for the success of the Team. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.”

• How much is the PO truely seprate from the team?
• Is there a single wringlable neck?
• Is the team / PO a symbiotic ecosystem with a centralized model for detemining direction? thoughts?

This is free for you to consume. It is our hope that you will provide comments and feedback. Those that do can register on our community site and provide constructive comments. They will be acknowledged. We will use your comments to evolve the explanation of thought here or clarify ideas. As you read, hold on to your shoes because each sentence is loaded with deep layer focused meaning and if you skip around reading this will hurt your understanding. 

Product Development is a much better choice of words.

Here is one reason why… If I say software development the first word
that comes to mind for most people is code. That means if you write
code scrum/agile is for you and if you don’t it does not apply.
Repeatedly I have seen organizations become crippled in their
application of agile from that simple (seemingly small innocent ) turn
of words. XP, another agile practice got much of it’s bad rap simply
because it was code/software centric in it’s wording.

For much of the reasons I outlined above and for some others I have
not we don’t say software development. Instead we use the word product
development which broadens the context in an appropriate direction and
allows for better balance and understanding to occur in practice.

Sharing and communicating these concepts without causing people to lock
them down is very hard and requires extreme attention to practical
use. Concepts are not words but words are all we have so chose them
carefully and then watch for understanding.

Limiting focus to software development and that language will quickly
cause loss of balance in my experience.

* Coded – it works on the developer’s box
* Verified – Unit tested and they work on Integration box
* Validated – accepted by ProductOwner as being what was needed

Later on a fourth “Done” was added for “Production Ready”, which meant:

* Production Ready – all additional stuff was there, like
documentation, training for users, etc

Now, I still like the four “dones”, but have a slightly different focus.
Since Stories are now well-defined bits of work, with well-defined
definitions of done, there is no longer the subjective third “done” for
them. The Product Owner no longer gets to decide if it is what is
needed, the story is defined to be done once the acceptance criteria are
verified. So there is not a hierarchy of things we do:

* Stories get “Done/Done”
* Features get “Done/Done/Done”, and we don’t know how many stories
this will take
* Products get “Done/Done/Done/Done”, and we don’t know which
features this will take, or how many stories it will take

This new way of looking at things shows us what is really going on.
Within the team’s work there is only tactical agility, where the team is
being agile in figuring out how to meet its story’s acceptance criteria.
There is low-level strategic agility where the PO is deciding which
stories to deliver for each feature in order to provide the value (for
that feature) that is needed. And there is high-level agility where the
PO is deciding what is the “releasable feature set” necessary to
actually be able to put this thing into production. Three different
levels of agility, three different sets of stakeholders, three different
levels of abstraction and questions to ask.

Dan Rawsthorne
dan@danube.com

The twist…
These teams rely too much on memory, which fades dramatically after 3
months thereafter their observations and response when something is
wrong becomes increasingly blind. (in other words, the excel spreadsheet
of data in their heads runs out of buffer and becomes corrupt)

The fear….
Any metrics can be twisted and the word “discipline” can be used as a
way of getting tough. Which then defeats the purpose. Developing good
quantitative measure that do not get usurped by management (or other
force) becomes the challenge. The fear is that metrics will be used to
push the team when a downward interpretation is made and thus encourage
gaming the system.

The loss…
Scrum Teams fail to build and leverage informative history based on
metrics. They rely too much on memory. Their scrum implementation
initially looks good but lacks sustainability because the guidance is so
weak.

Response:
Good metrics are essential to helping teams improve long term and
organizations learn. However, all metrics can be abused and misused
which will defeat the purpose of the metrics collected. It takes
discipline to not be reactive but, instead use these numbers to help
teams and organizations get better.

So, when a new technology compresses a feedback loop’s time horizon.
Then it is not surprising that people are often unwilling to adapt and
leverage the new time horizon.Why? “It stresses me out”, “I don’t want
to change” and ” nothing is broken”… I see scrum as a framework (or
detection mechanism) that makes finding these habits easier and calls
them to attention in such a way that people feel safe to face the
change. That is why I like to say Scrum is a pathway that when applied
with CARE, leads to a well formed team (a group of people working well
together) who maximize their ability to adapt in the face of their
challenges. You can call the above soft skills or whatever. The science
behind these views is becoming very supportive.

We typically realize scrum’s promise in development domains that require
a rich set of blended metaphors to consider the problems. Software
products typically demand strong well structured expressions that exceed
the limit of one person’s head; it is often done better as a group
activity and often more successfully. Software development has some of
the most rapid feedback loops available in complex development domains,
good teams maximize these loops. Soccer would be faster but, it does not
allow for the complex abstract thinking that software does.

Products that are made up of software, hardware, chemical systems,
mechanical, numerous embedded components and human interaction are what
I would call about as hard as it gets; helicopter anyone. We do all
kinds of things to shorten the feedback loops and learn as rapidly as we
can about stuff we don’t know about yet. At the end of the day, after it
comes together, are we ever really clear on how it happened? or where
were we simply successful enough at dealing with stuff we didn’t
expect. I believe we have some clarity but, mostly not.

A question I like to ask is “For conceptually complex development
domains, how can we get better at being adaptable in the face of things
we don’t know about yet?” This question fascinates, humbles and energizes me

–
_______________________________________________
Douglas Shimp
Managing Partner and Senior Consultant, CST
www.3back.com

“Applied Scrum, where the rubber meets the road.”