Product Owner role, tweets selection

This is a selection from 6000+ tweets and retweets posted here in 6 years.

Product Owner role
Confessions of a serial #ProductOwner, based on a true story by Anna Forss link
RT @RonJeffries: We don't want a Product Owner. We want a Product Champion. link
#ProductOwner  Embrace Uncertainty by Jeff Patton link
Many key success factors for IT projects I worked with,very well explained in "Agile Product Ownership in a nutshell" link
5) Don’t know what I want, but I know how to get it: link

RT ‏@lgoncalves 20 Product Owner Anti Patterns link #scrum #coaching #agile #productowner
An example of expected skills set for a Product Owner about Product Development: link
Obliquity, another key skill for Product Owners :  link

User Stories
Patterns for Splitting User Stories link

RT @giusdesimone: @ralfhh: @rslawrence: Just published a new story splitting resource, "How to Split a User Story" flowchart:  link
#ProductOwner How to split a user story link

#xpitlondon Elephant Capaccio exercise facilitated by @xpmatteo link

Payroll is all or nothing right ? A forgot lesson about incremental releases: link

RT @StefanRoock: User Stories are about conversations. link

#ProductDevelopment. In solitude/isolation. Or as an interactive/iterative live performance act w/ an audience of real users/stakeholders

We are not limited by what we don't know. We are limited by what we incorrectly think to know and what we don't even imagine we do not know

The principles and laws and lemmas of sw requirements from sw engineering : #requirements

RT @Keinze: @lukadotnet Everyone should read your collection of requirements principles link

RT @sigsoft: "Walking on water and developing software from a spec are easy if both are frozen", Ed Berard. Agile & Requirements Engineering

Every project initially is based on unvalidated assumptions that are presented as requirements: link and link

Gradual discovery and motivated confidence over the illusion of power and control 
The faster the target is moving,the more increasing inspect-adapt frequency is beneficial/advantageous/profitable over perfecting the plan link link
Are we creating better products? Are we executing vision faster? Are we spotting and exploiting opportunities sooner? If not, why?
Good software design decisions lead to more future-proof,easy-to-maintain systems & are well aligned w/ business requirements -@siebertlubbe
#Lean recognize both unknowns, uncertainties & what cannot be measured i.e. in the principles:Deliver as fast as possible,Amplify learning

2nd red pill: sensing unknowns uncertainties and the unexpected over what is known, and explore them

3rd red pill:be aware of inherent ambiguities,incomplete info,fragmented realities,multiplicity of pnt of views.And strive for understanding

RT @drunkcod: "If you have more than 3 priorities then you don't have any." -Jim Collins

You literally ought to be asking yourself all the time what's the most important thing in the world I could be working on right now
... and if you are not working on that why aren't you? -- Aaron Swartz
"It requires more experience, discipline and skill to forgo a quick win today in favour of being in a better place tomorrow" - @patforna

(Low) costs of generating alternatives, experimenting & iterating enable a new product development approach & new management style #Agility

Patience to conduct routine business routinely, talent to respond exceptionally to exceptional circumstances, wisdom to know the difference

Former tweet an excerpt from Business stripped bare by Richard Branson, link

Good software design decisions lead to more future-proof,easy-to-maintain systems & are well aligned w/ business requirements -

Estimations and deadlines
RT @tastapod: The wonderful Allan Kelly: "We start with a ritual called estimation" link /via @qedtherese

An explorer is not defined by the kilometres he travels, but by the places he discovers. SW development is about exploring new possibilities

RT @fabioarmani: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.  — Douglas Hofstadter

It is not possible to estimate what ... ?  link

How to assess, communicate and manage uncertainty and risk with Agility? link
RT @cyetain:
@lukadotnet The important estimates are the ones that point out where the uncertainty lies (2/2) @kjscotland
RT @henrikkniberg: When developing, I have only 3 feature sizes. Small (< 1 day). Medium (1-2 days). Large (too big, must be broken down).

A tight deadline is just a simple reassuring problem.The real&complex one is 'are we building the right product,will users/market like it?'

“making promises to deliver sw by December, when engineers had said it wouldn’t be ready until April" sound familiar? link
1) Promise something you can't honor 2) Finalize the sell 3) Delegate someone else to keep your promise. Mmmh  link

Estimation is Evil link & The #NoEstimates Movement link by


Truth & Reality: in general, in IT, and in Computer Science

This is a selection of tweets about truth & reality, ideology, cult, orthodoxy and prejudices -
in general, in IT and in CS, from 6000+ tweets posted in 6 years. With minor edits to increase readability.

Suggests additional tweets and comments, here and on twitter. I'll add them to the list.

What's art, what's not? What's good, what's not? What's right, what's not? What's true, what's not?  And who decides?
Philosophy is a handbook of life, Andrea Camilleri -
Social constructionism study the ways in which individuals and groups participate in the construction of their perceived social reality
Consensus theory holds that #truth is whatever is agreed upon by some specified group
Consensus reality is that which is generally agreed to be reality, based on a consensus view.
W.James's Pragmatic theory of truth:a quality the value of  is confirmed by its effectiveness when applying concepts to actual practice
Knowledge between truth and belief: image
Superstition: the belief on imaginary cause-effect relations
Various theories and views of truth continue to be debated among scholars and philosophers - link
@giulio_vian have read that for most of the religions "truth" is transcendent; and each religion have a different representation of that
Lying is a cooperative act,a lie has no power until someone else agrees to believe the lie. Pamela Meyer video


Value pluralism:the idea that there are several values which may be equally correct and fundamental, and yet in conflict with each other
Realized value system: contains exceptions to resolve contradictions b/w values in practical circumstances,Is what ppl tend to use in daily life
Idealized value system:a listing of values that lacks exceptions,absolute.Absolutists:who hold to idealized value sys & claim no exceptions
Every value system, like the Agile one,  inevitably is incomplete, has some inconsistencies, contradictions and ambiguities
On Value systems pluralism and Realized value system Vs #Lean or #Agile cult/ideology: link

When validity of a concept is based on faith on the Master,who prove Master's correctness? When 2 Masters disagree, who decide who's right?
Validity of a theory can't be proved by consensus except for cults & superstitions.While magic & any suffic adv technology are on their own league
RT @demingSoS: "Do not believe anything because I have told you so. Only believe it when you have tested it for yourself." Buddha
RT @TheBuddhaNature: "Believe nothing, no matter where you read it or who said it, no matter if I said it." ~Buddha
RT @MarkGraban: When somebody says "I am a professor" and therefore can't be argued with... they aren't a very good professor.
@giulio_vian The difficult one, choosing Masters that encourage to develop personal insights rather than to subscribe to one given truth
Can you imagine a scientific field where validity of an hypothesis is decided by the proposing scientist's popularity & the current trend?
While your opinion, belief,intuition,feeling can be right you need facts,evidences,arguments to share it,discuss it,improve it with others


The beginning of wisdom is found in doubting; by doubting we come to the question,and by seeking we may come upon the truth - Pierre Abelard
RT @cyetain: "Doubt is not a pleasant condition, but certainty is absurd."- Voltaire
RT @TheBuddhaNature: "The truth you believe and cling to, makes you unavailable to hear anything new." ~ Pema Chodron
All models, frameworks & well established knowledge may blind us when facing raw talent, unconventional approaches, creativity & innovation
"There always are 2 options:A)Disagree B)Learn something new. Smart people usually try option B multiple times first. It's called Listening"
Explore the unknown,learn a new thing,try something different,cross a border,build a bridge,connect the dots in unprecedent ways,be a pioneer
What we know, what we believe to know, what we know and is wrong, what we don't know, what is uncertain, what change, what we'll never know
Self-transcendence, Openness to change, Self-enhancement, Conservation image
RT @DerailleurAgile The six blind men and the elephant link // This is also known as cognitive bias. via @lukadotnet HT @YannPdeM
RT @migueldeicaza: "opinion without experience is called prejudice" by @natfriedman
"Prejudice has 2 characteristics: 1)Everyone has prejudices 2)Nobody realizes that they are prejudiced"-@RisingLinda: link
When intuition is to put an experience into a known sys of thought/theory instead of expanding the boundaries of understanding, is prejudice
When dealing with unknowns with a limited time to decide, a #belief is called #intuition. Over a long period is called #superstition
When dealing with principles at some point you will most likely face the choice of being pragmatic/contextual vs ideological/maximalist
@giulio_vian A principle imply judgement of situation,evaluation of context,dealing w/ exceptions. Ideology is absolutist, totalitarian
To be cynical is to submit fully to an ideological structure despite knowing better - Slavoj Zizek.  What ideology are you submitting to?
RT @LeanVoices: The arrogant man thinks he is entirely right and never wrong, the wise man knows he is often wrong and never entirely right.
"Arrogance: believing you know the *right* answers better than any other. Confidence: knowing that you can cope with what will be."
"Confidence of knowing the right answer is arrogance in disguise. Real confidence is knowing to be able to cope with what will be."
Arrogance often indicates loss of contact w/ reality,affect learning,was considered the greatest crime of ancient Greek link
IMHO good consultants are those who can be confident without being arrogant, who have initiative without lacking empathy & ability to listen
When arrogance meet lack of empathy, groupthink is just one step away. Add a dash of violent communication & bullying is just one step away.
Mastering the art of being humble toward unknowns and experts, and at the same time seamlessly being courageous with plenty of initiative


How discipline, community, action and vision can lead to a disaster link
False statements that support the power structure of the hierarchy get precedence over true statements that put the power struct in question
 ... from S. Denning about struggle between power and truth
Facing an inconvenient truth can be harder than reveling an inconvenient truth #transparency
There is no tech argument that can be decided by authority except in religion, in politic, in sects, in authoritarian & totalitarian regimes
having the authority to decide does not imply bening authoritative
@ZJemptv what you call critique could be moralism: judging someonelse behaviour based on own subjective values & morality  @coreyhaines
Moralist is someone who judges others according to his/her own values & beliefs & doesn't recognize to others the right to choose their own
What if #Agile #Orthodoxy is used as a weapon to oppose disagreement and dissent in support of some1 authoritativeness? link
Critical thinking and independent judgment over the cult of personality and cult leaders: The 5th value of the #Agile Manifesto
@ImaginaryTime that move the focus from the cult of personality (of the master) to the scientific method to objectively demonstrate a theory
@ramtop yep forgot self-appointed high priests of agile methodologies & their churches.After all IT too deserve its Scientology... or not?
RT @RonJeffries: @agilemanager do you imagine, somehow, that dragging agile down with misstatements will somehow make your ideas taller?

RT @LeanVoices: You might be entitled to your own opinion but you are not entitled to your own facts. R Dawkins
Distinction between exact sciences & humanities, demarcation problem b/w science & pseudoscience: good to know for software production pros
Exact science link Humanities link Demarcation problem link
@jchyip @marick and at the same time science progress also with help by unproven conjectures and intuitions link
RT @LeanVoices: There is a world of difference between those who seek the truth and those who want to win a debate at the expense of truth.
@tobiasmayer Can we say is Dogma-free when each rule have a purpose and when the beliefs are supported by facts? @OlafLewitz @waynerpalmer
proven facts/data, subjective perspectives, personal opinions & preferences, science/engineering,politic,religion/cult, superstition,trend
In pub talks belief and opinions suffice. (SW) Engineers instead should use facts, evidences and good arguments
Science uses external reviews & experiment replication. What about  methodologists that use only data from their own projects, is it enough?
Case-based reasoning, Retrieve-Reuse-Revise-Retain: turning anecdotal evidence into science? link
Professional software development between science, sound experience and beliefs: link
Many ways of looking at Software development, from software religions to computers programming: link
Free yourself from cargo cult software development, recognize the unknowns in professional software production link
#SoftwareAdvertising is tools vendors & consultants advertising themselves w/ smoke&mirrors as opposed to sharing valuable content/insights
#SoftwareFashion is about following new trends as opposed to developing mastery in one area and develop useful evolution
#SoftwarePolitic is about collecting consensus & search for supporters as opposed to searching for solutions that actually works well enough
#SoftwareSuperstition is about counting on unproven cause-effect relationships as opposed to empirical evidences, proven facts,real data
#SoftwareReligion is about believing something as opposed to having experienced it hands-on directly
IT magic: where people love superstitions, illusions, silver bullets, magic tricks over professionally expertise competence and perseverance
IT religion: where people love opinions beliefs rituals sermons tribal belonging over facts, evidences, good arguments, hands-on experience
IT fashion: where people love the newest and the trendy! Yesterday science/progress/discoveries are outmoded
@migueldeicaza @natfriedman opinion not based of facts/evidence is called superstition or arrogance
@migueldeicaza @natfriedman opinion based only on own idea and point of view is called conservative narrow minded
@migueldeicaza @natfriedman opinion based only on previous experiences is called preconceived idea

Learning & teaching

This is a selection of tweets about
learning & teaching, from 6000+ tweets posted in 6 years. With minor edits to increase readability.

Post your comments here and on twitter.
Don't forget the book: Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn.

Learning often begin with acknowledging we don't know enough about something

@tottinge @philip_schwarz "when you think you know it all, you realize that you're just fooling yourself... " from Jiro Dreams of Sushi
RT @AncientProverbs: True knowledge exists in knowing that you know nothing. -Socrates
Learning is twofold: acquiring new skills and increasing awareness of ignorance
RT @TheBuddhaNature: Unless you try to do something beyond what you have already mastered, you will never grow. ~ Ralph Waldo Emerson
RT @TheBuddhaNature: Doubt everything. Find your own light. - Gautama Buddha
RT @tmaurizio: An investment in knowledge always pays the best interest  (Benjamin Franklin)
RT @TheBuddhaNature: "In the beginners' mind there are many possibilities, but in the expert's there are few." ~Shunryu Suzuki
All models, frameworks & well established knowledge may blind us when facing raw talent, unconventional approaches, creativity & innovations
We cannot learn to see until we admit we are blind - TED Alan Kay shares a powerful idea about ideas
Long feedback loops bring cause and effects far away outside the learning horizon. Even the simple become complex.No chances to learn from experience
Learning by Experience from Others:
@ArturoHerrero Tomorrow's illiterate will not be the man who can't read; he will be the man who has not learned how to learn ― Herbert Gerjuoy
'I've X years of professional _experience_' become 'my mindset & approach to work is X years _old_' without periodic regenerations/reborns
I can accept to fail (and learn) when trying something new.Don't ask me to repeat again and again the same mistake. It's a 'no'

Lean-Agile learning
Improve your Lean-Agile Coaching abilities: link #Lean #Agile #Coaching #ContinuousImprovement #PersonalDevelopment
Microsoft Education Competencies: Dealing with ambiguity link Humor link
Microsoft Education Competencies: Organizational agility link , Strategical agility link
How much is it Agile/Lean to learn Lean/Agile from narratives/rhetoric instead of early/frequent observations of outcome of ppl actions?


RT @skmurphy: "To teach is to learn twice." Joseph Joubert
1/2 #Teaching The Swedish principle is that every answer is precious and students are encouraged to participate.
2/2 #Teaching Isn't this the purpose of education? To value each and every idea? link
"Since people make things, work must begin with developing people", Eiji Toyoda: link
Entertain,provoke,inspire,challenge,empower to critically think,to form own opinions,to connect & act & impact. Is the purpose of education

Those who tell you what to do. Those who sell you truths and recipes for success. Those who ask questions and let you find your answers.
I never teach my pupils; I only attempt to provide the conditions in which they can learn - Albert Einstein. From @lyssaadkins book
No matter how good an idea is, you cannot force it into people because freedom come 1st: is it #Lean values/principles or any #agile frmwrk
"productive discomfort" the outcome of a successful application of the Socratic questioning method

Better teaching
RT @cyetain: The Socratic Method: You know it is working when they start trying to poison you :)
Becoming a better teacher means also striving to find better metaphors, rhetorical figures & stories to share with others what really matter
A (lean-agile) #Coach is like a mountain guide: someone you can really trust when you need it!
Noticed that during a speech the moment you stay silent can be the most powerful moment
A little more experience & I'll be able to replace PowerPoint w/ a flip-chart & some drawing & a speech w/ perfect silent moments to reflect
Facilitator's tip: don't underestimate the power of silence

Education science
Let's use video to reinvent education: link
Education is a self organizing system where learning is an emergent phenomenon... link
RT @torbennr: How Kids Teach Themselves link Interesting experiment, thank you.
Speculations about education as a self organizing system where learning is an emergent phenomenon: link
More on speculations about education as a self organizing system where learning is an emergent phenomenon: link
Self Organized Learning Environments (SOLE) link
Sphere College is a project that seeks to apply self-organization to adult education: link
Flow model and Psychological safety model: link Temperature model: link
This research in cognitive psychology"The Effects of Interleaved Practice"suggest 1 underestimated advantage of #Agile link
@torbennr @axmagno The paper "The effects of interleaved practice" & the one linked here link that's an experience report

The 3 inspiring principles of microservices

The three inspiring principles of #microservices originate from:

1) Alan Kay definition of OO, 1967
2) Conway’s law, 1968
3) Unix design philosophy, 1969

1) Alan Kay definition of OO
The big idea of OO for its inventor is “messaging”. OOP to Alan Kay means only messaging, local retention, protection and hiding of state-process, and extreme late-binding of all things. Internet, for OO inventor, is possibly the only real object-oriented system in working order, in which the basic unit of computation was a whole computer.

A microservice runs in an isolated independent process, it's highly decoupled from other services, communicates only through a lightweight mechanism like a HTTP resource API, and it functions and can be deployed independently.

2) Conway’s law
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

A microservice is built around a business capability that has a clear value proposition.
Each team is multi-disciplinary, cross-functional, autonomous and it's built around one or more microservices with a common value proposition.

3) Unix design philosophy
One of the principles around Unix design philosophy is this: Make each program do one thing well.

This is where the 'micro' in microservices comes from.
Unix was built from the ground up and was grown slowly over time. When building a big application in a short period of time, it's difficult to get the boundaries of a microservice right from the beginning. So it’s okay to start with a larger non-micro service and break it down later, while the boundaries emerge.

How to assess, communicate and manage uncertainty and risk with Agility?

The thought that disaster is impossible often leads to an unthinkable disaster.

Gerald M. Weinberg

Doubt is not a pleasant condition, but certainty is absurd.

Every time there’s a good business opportunity to develop a new product or evolve an existing one, executives want to know required investment amount, expected ROI and probability, and risk involved.

Therefore product and development teams are asked to figure out if the new product or product evolution is technically feasible, how long it will take to implement, how much it will cost, when will be finished, and how much risk and uncertainty is involved.
Then Project/Release/Iteration manager will present a release plan where time, effort and costs estimation are expressed with ranges. The degree of uncertainty and the level of risk determines amplitude of the estimations range.

As result, the degree of uncertainty and the level of risk will impact the investment decision, budgeting, governance of products portfolio, release plan, and external customer where one is involved.


How to assess and communicate risk and uncertainty

Visualising and communicating risk and uncertainty with agility it means to do that in a lightweight form that’s quick and simple to understand, easy to constantly and frequently update, and straightforward to iteratively enact.
This is very different from heavyweight approaches for documenting risks with long documents that quickly become outdated, often remain unread and very seldom if ever lead to timely action.

The lightweight assessment is
constantly and frequently updated
as new learnings and new information emerge

The assessment of risk and uncertainty is typically done after initial high-level identification of features and user stories and after initial high-level effort estimation. The assessment is then updated periodically as new learnings and new information emerge.
A high-level way to assess and visualise the overall degree of uncertainty and the level of risk consists in categorising the implementation of the new product or the evolution of the product as an Exploration type of work or as a Production type of work.

Investing more time detailing upfront requirements,
specifications and design wont reduce risk or uncertainty

- Production type of work is characterised by known problems and known solutions. It occurs when implementation work is similar to previous implementations. As a result it has very low degree of uncertainty and very low level of risk. Estimation ranges can be narrow because of low estimation errors expected.

- Exploration type of work is characterised by high level of uncertainties and unknowns in the problem and/or in the solution, and in the product/market fit. In addition to this, there could be plenty of things outside the area of control or influence that can change anytime impacting the success of the implementation and of the product. For this type of work, investing more time detailing upfront requirements, specifications and design wont reduce risk or uncertainty.

There’s a continuum between the very low risk and uncertainty production type of work and the high risk and uncertainty exploration type of work.

Different opinions and different points of view
are invaluable sources of information,
therefore are encouraged and explored

Product and development teams’ members that will do the actual work, should collectively vote where they think the current implementation work stands, placing each one a dot between the two extremes, discussing whenever they see differences among their votes and revoting after the discussion. In case of persistent differences in opinion among team members, it’s advisable to raise the level of risk & uncertainty. This evaluation can alternatively be done by team's Product Owner together with the Tech-Lead and the Project/Release/Iteration Manager.

Actual effort or scope can be up to 4 times the initial estimate

For an implementation work estimated to be on the extreme left-end, a pure exploration type of work, the estimation error can be up to 300% of the initial estimate. In other words the actual effort or scope can be 4 times the initial estimate. For a pure production type of work the estimation error can be 5-10%. While for an implementation work that stands in the middle, the estimation error can be up to the 50%. For examples see the Cone of uncertainty, based on research in the software industry and validated by NASA's Software Engineering Lab.

How to detail and explain risk and uncertainty

When executives and managers want to know reasons behind estimated overall risk and uncertainty level, when product and development teams want to improve the assessment accuracy, when they want to verify their assessment or present it in more detail, it’s useful to drill down into these three main risk and uncertainty components:

1) people and market
2) domain and requirements
3) technology and architecture

For each component the level of risk and uncertainty can be rated Low (green), Medium (amber) or High (red) and presented, for example, like this:

The following lists break down each of the three main risk and uncertainty components into multiple elements. While discussing the elements, new elements specific to teams’ and product context and circumstances could emerge and should be added to the list.

The elements in the lists below are placeholders
to provoke discussions and provide basic guidance

Note that the elements in the lists are placeholders to provoke discussions and provide basic guidance. A team experienced in dealing with risk, uncertainty and complexity would probably start with empty lists and populate them throughout discussions.

1) People and market

2) Domain and requirements

3) Technology and Architecture

Each element of the lists should be discussed one at time by the product and development teams to rate the level of risk and uncertainty.

The rating of each element should be given for example considering historical data, or absence of historical data, listening to professional judgment of team members, and considering the weight of each element in the current context and circumstances.  Whenever there are differences among team members' estimate, there should be a discussion to learn from each other point of view, and after that a re-estimation. In case of persistent differences in opinion among team members, it’s advisable to raise the level of risk & uncertainty.

This approach should help to rate the overall level of risk and uncertainty for each of the three components and explain reasons behind each rating.

Every new information, findings and learnings
are used to verify, validate, update and enhance
results and decisions from previous stages

From those estimations and from the conversations that lead to the estimations, product and development teams should be able to re-vote where the current implementation work stands in the continuum between the production type of work and the exploration type of work, considering possible interactions among the components, and producing a more accurate assessment.

Tip: Keep it simple! Update the assessment frequently using new info and new learnings available over time.

How to manage high risk and high uncertainty

When work required to deliver a new product, or a product evolution, is expected to be mostly of Exploration type, estimation of costs, effort and time are expressed with extremely wide ranges and with estimation errors up to 300% of the initial estimate (for examples, see the Cone of uncertainty mentioned before). Therefore a linear upfront investment based on initial estimate for Exploration type of work is hazardous.

Small experiments and prototypes
are designed, built, deployed and tried out

with real users, early adopters and customers
in hours, days, or few weeks

In these cases it’s more convenient an initial exploration phase with the goal to identify and reduce main risks and uncertainties by exploring the problem space, testing assumptions, validating the solution, verifying product/market fit, clarifying the scope, and learning new info.

During the exploration phase an experimental approach is adopted: shortest possible experiments are designed and executed to gather data with minimum effort, and smallest possible prototypes are built, deployed and tried out involving as much as possible real users, early adopters and customers. Each is done in the space of hours, days, or few weeks. One of these experiments is the minimum viable product or MVP.

Investment decision and estimates
are finalized only after the end of the
exploration phase

An exploration phase ends only when risk and uncertainty are reduced enough so that a good, informed investment decision become possible. For an overall effort of one year, the exploration phase could last, for example, 2 months.

After exploration phase, sometimes estimates still have a wide range and estimation errors are up to 30-50%. I.e. the development time could be estimated in the range of 6 to 12 months.

Low priority requirements can be used as a safety net
to deal with residual risk and uncertainty

When this happens it’s particularly convenient to prioritise the requirements in the backlog using the MoSCoW prioritisation method in order to use the requirements classified Should as a safety net.

Here the best case scenario forecast, that assumes the highest velocity of the team, will include in the scope requirements classified as Must together with requirements classified as Should.
The worst case scenario forecast, that assumes the lowest velocity of the team, will include in the scope only requirements classified as Must.
As a result, in this example, the initial estimation range of 6 to 12 months, that is 6 months wide, is turned into a range of 6 to 8 months, only 2 months wide.

After a short period of time
from the beginning of the implementation work,
the investment decision and estimates
are verified against real progress

After about two months of work implementing the solution, it’s worth to observe the trend of team’s velocity:
  • When the velocity is stable or converging and is inside the ballpark, a new more accurate estimation can be done and plans can be updated accordingly.
  • When the velocity is stable outside the ballpark, this is a sign that investment decision should be re-evaluated.
  • When the velocity is diverging outside the ballpark, this is a sign that there could be still risks and uncertainties that need to be explored extending the exploration phase.


This lightweight, gradual, iterative approach to assess, communicate and manage uncertainty and risk is a simple and effective way to monitor and react timely to a variety of circumstances that impact investment decisions, budgeting, governance of products portfolio, and release planing. It also encourages and supports conversations on risk and uncertainty between executives, managers, product and development teams, and customers.

It is based on current lean/agile literature and on personal experience.

The mechanic of this approach is simple. In addition to it, few organisation cultural traits and leadership mindset characteristics are useful to make it work: transparency, trust, teamwork, and tolerance for experimentation.

If you are interested into the topics discussed in this post, those four suggested readings are for you:
  • Book: Lean Enterprise: How High Performance Organizations Innovate at Scale. Jez Humble, Joanne Molesky, and Barry O’Reilly. 2015
  • Article: 4 Significant Ways to Improve Your Ability to Innovate. Joanne Molesky. 2015
  • Book: Agile Project Management: Creating Innovative Products (2nd Edition).  Jim Highsmith. 2009
  • Article: A Leader’s Framework for Decision Making. David J. Snowden, Mary E. Boone. 2007
  • Article: How to prioritize risks on your business model, Ash Maurya


Thanks to Maurizio Pedriale and Carlo Bottiglieri for their help in the review of the draft of this post.

Overcoming the one weakness of OOP

OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships between objects or structure of objects in a relationship can change, without affecting the rest of the program. 

The work of Professor Karl Lieberherr on Adaptive Object-Oriented software programming, based on the Law of Demeter, is the first to highlight this weakness of OOP, to explain its relevance and to introduce a solution based on a specific design, high-level specifications and automatic code-generation tools.

This post describes the work and the solution introduced by 
Karl Lieberherr and other well-known authors such as Steve Freeman, Nat Pryce, Tim Mackinnon and Sandi Metz. The presented solutions are based on designs that use composition, dependency injection pattern, visitor-like pattern, composite pattern and duck typing.

Glossary of ambiguous terms, as used here
Object graph: the web of relationships among a group of interrelated objects.
Object relationship
: association such as composition and aggregation, and dependency.
Object structure
: the definition of the publicly accessible object’s state and behaviour, its data and functions, its fields and methods.

Which is the one weakness of OOP?

A key advantage of object-oriented programming is certainly the kind of flexibility that object encapsulation provides.
Thanks to that flexibility, the representation of an object (the inside of the object, the internal implementation details, the internals) can be changed without affecting the rest of the program.
As a consequence, it is easy to locally understand an object in isolation, change it, extend it, evolve it, and reuse it.

When talking about encapsulation, the focus often goes to encapsulating the object’s state, the information, the data, the internal object structure.
What about relationships among objects?
OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships can change without affecting the rest of the program.

The one weakness of OO code is that it is brittle in the face of changes to the relationship between objects and to the structure of objects that are part of an object graph.
Two common examples follow:
  1. When an object’s unstable dependency changes, it can trigger changes into the object itself and this can start a chain reaction of changes in dependent objects.
  2. When an object graph changes or some responsibilities or state is moved from one object to another, code traversing the objects and making computations on the traversed objects needs to be changed too, to adapt to the new object graph and the new structure of the objects.

Examples with source code are also available here [1] and here [2].

Overcoming the one weakness of OOP is a common design challenge for many software developers building systems with OO languages.
What solutions have been found so far? How do they relate to encapsulation?

How to overcome the one weakness of OOP?

How to make OO code less brittle in the face of changes to the relationship between objects and to the structure of objects that are part of an object graph?

This post introduces solutions from three well-known sources.
The three solutions follow below.

1. Professor Karl Lieberherr work on Adaptive programming and the Law of Demeter

In 1987 Ian Holland at Northeastern University formulated a style rule for designing object-oriented systems called The Law of Demeter [3].

The Law of Demeter is best known in its formulation at the method level that pertains to how methods are written for a set of class definitions. Typical examples of violation for this formulation include method call chains such as  dog.getBody().getTail().wag() that is colloquially known as a train wreck [4]. Conformance to this formulation of The Law of Demeter supports object encapsulation.

The formulation of the The Law of Demeter that applies to the structure of the classes, is less known. This formulation makes the notion of unnecessary coupling very explicit. Conformance to this formulation supports modularity and low coupling in object relationships, and it makes code less brittle in the face of changes in the relationships and in the related objects [4]. In other words, conformance to this formulation helps to overcome the one weakness of OO code. But how to achieve this conformance?

Between 1991 and 1996 Professor Karl Lieberherr [5] developed Adaptive Object-Oriented software programming and the Demeter Method [0], a concept that takes encapsulation to a new level. This work clearly identifies and describes the one weakness of OOP and provides a working solution.

The solution as shown here [1] conforms to the Law of Demeter and uses programming by composition so that each composite object shields other objects from changes in the composed objects and in their relationships. The solution also replaces hard-coded navigation paths used to traverse the object graph with higher-level navigation specifications. Automatic tools called Demeter Tools use the navigation specifications to regenerate and adapt the code that traverse the object graph and invoke the functions, whenever the object graph or an object structure changes.

Here I name this solution as: “Programming by Composition + Demeter Tools”.

2. Mock Objects and Growing object-oriented software, guided by tests

Thanks to Steve Freeman, Nat Pryce and Tim Mackinnon for reviewing the draft of this post!

Between 1999 and 2010 a group of people from Connextra team first and then from Extreme Tuesday Club (Connextra team members: Tim Mackinnon, Tung Mac, Matthew Cooke, Iva More, Peter Marks, John Nolan; Extreme Tuesday Club members: Steve Freeman, Philip Craig, Oli Bye, Paul Simmons; Joe Walnes from ThoughtWorks and Nat Pryce) explored, experimented and developed a new way of writing object-oriented software that revolves around the practice of test-driven development (TDD), tests automation and a new technique called Mock Objects.

The full story is documented here too [10]. The initial work between 1999 and 2004 has been documented into two papers [6][7], and in 2010 in a new book [8] that summarised the whole experience produced by all the people involved.

The trigger for the discovery of the technique was when John Nolan set the challenge of writing code without getters and then favouring void methods over non-void ones. Later Peter Marks helped coin the name ‘Mock'.

The driver for the technique was literally a pragmatic way to practice TDD and write good tests without going against what was felt were good design principles, for example without exposing object internals for the sake of testing, or shying away from composition. The work was then inspired and influenced also by the Law of Demeter and Lieberherr’s work and also by [12][13].

Probably the most important effects on coding style were the development of the Mock Objects, and favouring composition over inheritance that led toward programming by composition. Programming by composition led to decouple object behaviour from the structure of the object graph. In addition to that, each composite object shields, to some degree, other objects from changes in the composed objects.

Programming by composition also led toward a design pattern that nowadays is called dependency injection [9] not to be confused with the dependency injection frameworks (a.k.a. IoC frameworks or IoC containers) that were never needed in the large Connextra code base. In turn dependency injection led to minimising objects’ dependencies and to decoupling dependencies.

Unlike the solution of Lieberherr, this solution does not use automatic tools for code generation.

Here I name this solution as: “Programming by Composition + Dependency Injection”.

A secondary effect on coding style was the tendency to push behaviour towards Visitor-like objects, objects resembling the Internal Iterator pattern [11] that have similarities with the Visitor pattern. A team member from Connextra remember using the Visitor-like pattern together with the Composite pattern used among other things to abstract away differences between the traversed objects.

The abstraction introduced with the Composite protects the code, to some degree, from changes in the object graph and in the structure of the object.
The Visitor-like design reverses the direction of an unstable dependency relationship (from a stable object to an unstable one), turning it into a stable relationship (from the unstable object acting as the "visitor" to the unstable one acting as the"element").

While the focus on this solution diminishes after the first paper, it is documented here because of a similarity with the solution presented by Sandi Metz.

Here I name this solution as: “Visitor-like + Composites”.

An interesting after thought about the technique of TDD with mocks from Tim Mackinnon: I can’t stress enough how most people have missed, and still do, that connection with CRC cards, mocks and role play. Mocks and the technique really came from the idea of working with a partner to act out what you expected the design/objects to do - and then “asserting” those interactions. That was the number one design point. For us, this was the aha moment.

On the same line Nat Pryce comments: There was quite a change in emphasis between the Endo-Testing paper and the Mock Roles, Not Objects paper and GOOS book. For example, the former recommended using mock objects to fake third-party APIs that are difficult or slow to use for real in tests, such as JDBC. The latter recommended *not* mocking third-party APIs, but rather discovering the appropriate interfaces for mocking from the need of client objects. Also the Mock Roles, Not Objects and GOOS style focused more on messages and protocols between objects.

3. Less, The path to better design

Sandi Metz in her speech 'Less, The path to better design' [2] takes on the challenge of the one weakness of OOP and presents design solutions that deal with changes in unstable object’s dependencies, both in the object structure and in the object graph.

The approach she presents is based on the idea that designers cannot predict the future but they can guard against it choosing carefully object dependencies, identifying those that are less stable and surrounded by more uncertainty and then aggressively decoupling them.

This approach is in tune with the second formulation of the The Law of Demeter that applies to the structure of the classes.

The solution that Sandi Metz presents, employs a design similar to the visitor pattern to decouple from unstable dependencies.

In the problem presented there are two objects that needs to interact to execute a task. The first object is known, under control and more stable, the second object is less stable because surrounded by more uncertainty. In order to reduce the coupling of the first one to the second, the second object acts like a Visitor in the Visitor pattern while the first object plays the role of the visited element. This design reverses the direction of the dependency, doing so it turns the unstable dependency relationship into a stable one.

Unlike the previous solution, this one does not make use of the Composite pattern to guard the code against changes in the object graph, because the language she uses is Ruby that supports duck typing, which serves the same purpose.

Here I name this solution as: “Visitor-like + Duck Typing”.

Comparing solutions

These are some similarities about the solutions suggested by the authors:

  • One solution uses tools and higher-level navigation specifications to regenerate code whenever there are changes to the relationship between objects and to the structure of objects.

  • Two solutions include the use of Programming by Composition: to decouple object behaviour from the structure of the object graph, and to shield, to some degree, other objects from changes in the composed objects.

  • One solution include the use of the dependency injection pattern: to minimize objects’ dependencies and to decouple dependencies.

  • Two solutions include the use of a Visitor-like pattern, used essentially to reverse the direction of an unstable dependency and so turning the dependency relationship into stable.

  • Two solutions abstract away differences between objects traversed in an object graph to protects the code, to some degree, from changes in the object graph and in the structure of objects:
    • One solution for statically typed languages does this with the Composite pattern,
    • The other solution for dynamically typed languages does this with Duck Typing.

  • All the solutions explicitly tell how to carefully choose and limit dependencies, with different but substantially equivalent means.


Beauty & Dignity

Beauty: what pleases the senses, what enlightens the mind, what is righteous, what is just, what is truthful, what is good.

Dignity: the idea that each and every human being without distinction of any kind, by the mere fact of being born into this world, has innate equal rights such as the right to freedom and to the pursuit of happiness, and is worthy of honour, esteem, consideration and respect.


Lean-Agile Coach self-assessment radars

These slides show 3 self-assessment radars for Lean-Agile Coaches.

The first slide is based on the Agile-Coach Competency Framework by Michael K. Spayd and Lyssa Adkins.
The second and third slide come from a blog post by Esther Derby.

Feels free to comment and to question the skills, the traits, and the levels.

“Don't bring me problems,bring me solutions." Really?!?!

“The thought that disaster is impossible often leads to an unthinkable disaster.”
Gerald M. Weinberg

Modern leadership is servant, modern managers are like hosts that receive and entertain guests.
Team members have ownership and autonomy in the way, in the ‘how’, they pursue the value they are asked to create.

When team members face difficulties, they raise obstacles to management attention. And managers act on the obstacles that bubble up from the team. This follows the principle of transparency and feedback.

Are managers ready to hear about all these problems?   Continue...

Planning ÷ reacting: finding the balance

Life is what happens to you while you're busy making other plans - John Lennon, Beautiful Boy

The are things that can be planned and others that cannot be. The conundrum is, which is which?

What happens when someone

This is why it is important to find out in every moment the balance between the two, to know

Someone says that Agile is the art of finding the balance between anticipation (as e.g. panning) and adaptation (as e.g. reacting).  

An interesting final reflection: what values, principle and practices help to find a good balance, and how ?