Never talk about politics!

I grew up in the UK but I have lived in the USA for a little over 6 years in total, which equates to around a quarter of my working life, so whilst I still feel very British there is an element of the mid-Atlantic creeping in. That is to say I feel like I have grown a level of understanding for some of the quirks of American culture and am a little more sympathetic to the perception of the UK culture from the American side of the pond.

us-uk-flags-union-english-18622380

However being so overtly British I get to hear the same questions repeatedly and some of the misinformation is a little troubling at times.  Especially when it can be fact checked so easily.  Since this is my soapbox I’ll indulge a little before I get on to the topic at hand.

First the USA did not win the war of 1812 please take 5 minutes to read wikipedia.  Second, the UK NHS: I have been in the USA for 6 years and in that time I have worked for two employers both of whom tell me that the health insurance they provide is the best there is. My colleagues tell me it is better than anywhere else they have ever worked. I have no reason to doubt that this is great Health Insurance, and apparently it costs around $27,000 per year – mostly paid by my employer and that is in addition to the social security deductions which are approximately 8% of my paycheque.

In my experience the quality of service offered by the ‘best‘ Health Insurance is approximately identical in quality of healthcare to that received from the NHS. Yep you heard me, I find no discernible difference in quality of care.  There are certainly differences, I have to pay a co-pay to see my Doctor here in the US which is free in the UK.  Doctors in the USA want to push you to take every test under the sun so they can bill the insurance, where in the UK they assess if there is a need first. In the USA if there is a referral it is on you, whereas in the UK your doctor would follow-up. The Doctors’ surgeries here seem to be a bit more lavish and they need an army of staff to administer the insurance bureaucracy but as far as wait times, quality of medical treatment and accessibility of treatment I see no difference.

So I do get a little upset when I say people describing the UK medical system as having poor treatment and long wait times and something to generally be afraid of.  Think of it as having the best medical insurance you can buy, and then imagine that it is free to you, I can see why that is so incomprehensible when you are used to spending nearly $30,000 per year on that service. I am sorry to say it so bluntly, but the USA spends on average 4 times as much for what is very much an inferior system for most people.

Okay I’m off-my NHS soap box now.

Capitalism or Socialism concept

But the third and most troubling perception that I am regularly confronted with is the notion that the UK is a ‘Socialist‘ country and the USA is a ‘Capitalist‘ country.  This notion troubled me a lot and got me thinking, but first let’s clarify the definitions:

Socialism:   political and economic theory of social organization that advocates that the means of production, distribution, and exchange should be owned or regulated by the community as a whole.     

Capitalism:  an economic and political system in which a country’s trade and industry are controlled by private owners for profit, rather than by the state.

Essentially the extent to which you are a capitalist or socialist country is determined by the extent to which the government interferes with the free market, either through spending or through legislation.

Measuring Capitalism

Spending is pretty easy to assess as we can see what proportion of GDP comes from government spending and how much from ‘the free market’  However, legislation is much harder to measure and by definition any intervention in the market is ‘socialist’.  E.g. Defence, immigration, policing, taxation, tariffs, subsidies, etc.

I think most people realize that pure socialism is fatally flawed and equally flawed is pure capitalism, so it is really a question of how little or how much government is needed and how much can the market provide on it’s own. We all have a reasonable expectation that infrastructure, defense, police, jails etc cannot be provided by the market and that the whole country benefits from education and healthcare for the poor as the benefits are far reaching to the economy but how much of the rest is open to debate.

Let’s take the USA, the US spends a staggering 35% of it’s GDP on socialist activities, that is more than a third, and is incredibly socialist in it’s government policies and legislation, just recently there have been some very high profile trade tariffs, a trade tariff is direct manipulation of the free market by the government – it is the very definition of socialism. Lobby groups regularly persuade the government to invest in particular parts of the country or legislate for the benefit of certain industries.  Both the UK and the USA bailed out banks and the USA bailed out the car industry and corn farmers.

By contrast the UK spends 41% of it’s GDP on socialist activities, and also heavily regulates the free-market with employment laws, they provide tax-breaks for entrepreneurs and subsidies for ‘green’ businesses to name a few, but notably didn’t bail out the car industry or steel industry or mining industry.

51c8d01b2deda.image

In my anecdotal experience and to be clear this is opinion based on only very limited education in Economics and Politics, neither the UK nor the USA has any claim on being capitalist countries,  both may claim to be slightly right of center but are both squarely ‘Mixed economies’ and have found a balance that is slightly further from Socialism than Capitalism but not by much. And whilst the UK spends more, my observance is that the USA regulates more and is far more interventionist in investing, bailing-out, propping up and otherwise supporting USA based industries.

TL:DR Summary: 

The UK and USA are broadly similar in terms of the degree to which they are Socialist or Capitalist in practical terms, but in my observation the UK is more willing to intervene for the benefit of the people – especially the poorer and the USA is more likely to intervene for the benefit of business.

What has this to do with Agile?

So what does that have to do with Agile?  Well it strikes me that there are a great many parallels.  If we equate Socialism – a planning heavy form of governance, where plans are made by a few experts:- with ‘Waterfall’  and  Capitalism – a responsive form of governance where the market leads and the many respond independently of governance:- with Agile,  then maybe you can see where I am headed.

download (2)

In small scale both Waterfall and Agile succeed, but as we scale both suffer in different ways.  In Waterfall as in Socialism the planners become further removed from the market they are serving and are less responsive to particular needs and more and more out of touch.  a great deal of overhead is needed to align the vision from the top and unsurprisingly they are often so far removed they get it wrong, corruption sets in and effectiveness (the true productivity) plummets.

By contrast in Agile as in Capitalism works very well in small scale but as we grow the decision makers are not able to see the big picture and whilst they are responsive to what they can see, they fail to see the larger system and optimize for themselves rather than the larger organization and problems set in with misalignment. There are some aspects of a business that simply don’t work by being responsive and need to be planned and organized.

Governance

So where does that leave us?  Well at heart I am both a capitalist and an Agilist so I am biased, but the way I see it as we scale with Agile and in business in general we discover that we need governance, some degree of consistency, infrastructure and support and most of all a clear direction.  But I believe we should keep that governance as small as practical and only govern that which we cannot govern ourselves.

In the case of big government I believe that includes socialised healthcare because normal market forces do not apply when it comes to our health and so the market cannot effectively provide what we need, I also believe that we should invest heavily in socialised education as better educated workers make everyone wealthier.

When it comes to Agile teams I don’t think the teams should do the hiring or decide pay and they don’t generally want or need to be bothered with administration or infrastructure, I feel that is governance that they should be spared, similarly I think ‘health care’ such as vacation, benefits, and support (HR) is governance. Start-ups will need to deal with all of this but at scale we shouldn’t have to.  Nothing controversial so far, but where we may start to see differences of opinion is the level of governance needed for teams.

In my opinion we achieve the best results from small teams, that are given clear direction and are empowered and enabled, that means direction not a director, so team leaders, project managers or any other similar role is bad for teams, it is unnecessary governance and is in my opinion fundamentally anti-agile.

Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done.

The best architectures, requirements, and designs 
emerge from self-organizing teams.

That doesn’t mean we don’t need managers or leaders, but we don’t need them involved in the work.  In Scrum we empower Product Owners to set direction and priorities but they stay out of the HOW, we empower Scrum Masters to coach us on process and guide us on improving flow, we even empower them to remove impediments on our behalf but we do not empower them to tell us HOW to do the job.  In my opinion Project Managers (when they are deemed necessary) should respond to information provided by the team and not the other way round, they are a consumer of information only! They should convey no authority.

12625104-no-managers

Where we need managers is NOT for doing the work, a suitably cross-functional team should be able to do that without an anointed leader.  What we need managers for is the ability to create those cross functional teams, and do this by listening to what is needed, hiring and enabling the forming of those teams.  We need leadership to provide clarity of direction, clarity of culture and clarity of values. We need managers to help us by enabling us grow as individuals in our individual careers in parallel to our goals for the team. We need managers for ensuring that we as an organisation are planning for the future so we can focus on delivering in the present.

If you feel you need a manager to manage the team doing the work then in my opinion you have failed elsewhere, it is a sticking plaster to a bigger problem, all you are doing by instilling team leaders/Project managers or team managers on a delivery team is masking a bigger problem elsewhere, possibly in hiring, training, education or communication.

The prime role of leadership is ensuring clarity, they have the big picture, making sure their employees see it too should be their number one goal, any other governance in the day to day job is an unnecessary overhead and a smell that there are problems elsewhere. The corruption inherent in larger systems needs to be cut out at the source not covered up with a layer of management. If you are hiring the wrong people then fix your hiring process, don’t hire people to manage problem staff. If you are struggling with consistency or maintaining values then it is an issue for education and clarity, putting a manager on as team is not the solution: enforcing values is not the same as instilling values.

90ee2b65615c3fda2b2c4190697c34d4

In Agile, like Capitalism, we want government to be as small as possible and only get involved in things that we either can’t do ourselves or are necessary but unrelated to our day to day work. Unnecessary bureaucracy and governance are well, unnecessary.

Give them the environment and support they need, and trust them to get the job done.

Hire the right people and let us do our job, educate don’t regulate, enable don’t enforce,  but most of all trust us, don’t try to control us. Set a direction, then get out of our way.

 

 

Advertisements

Estimation is waste?

There is an ongoing debate about whether or not to use Estimates in your software development process, largely fueled by #NoEstimates, but as is often the case the battle has been picked up by many that have become over zealous without fully understanding but with great certainty tell you that you should never estimate.

There are many good explanations as to why estimating may not help you and some great explanations of alternative ways to get the information you need, or to help you understand why the information was not needed. But I want to focus on one of my pet-peeves – Thou shalt not estimate because estimating is ‘waste’ Every time I see that I shudder, and quite often I am left with the feeling that the person writing doesn’t understand either Lean or #NoEstimates.

Thou shalt not estimate because estimating is ‘waste’

What is Waste?

First of all the statement makes it sound like waste is bad, in fact the word does seem to imply that waste is bad.  However, Lean is a lot less emotive with the term, Lean is often confused and simplified into simply the reduction/removal of waste.  But this is a very lazy and incorrect interpretation.

Lean is about productivity first and foremost, and is about reducing ‘waste’ ONLY when AND if doing so does not impact the system productivity. In other words, in Lean ‘waste reduction’ is far less important than system improvement, but for whatever reason we get hung up on waste – especially when bashing others. We reduce waste to improve the system – waste reduction is not our goal it is just a tool to help us.

Is Estimation waste?

Is Estimation waste?  The short answer is yes, but that is only part of the truth.  Lean considers waste to be activities that do not directly add value to your product and can be considered either ‘Necessary Waste’ or ‘Pure Waste’.

Waste covers a whole host of things, but waste includes: Planning, testing, reporting, breaks, vacation, sickness, and a great deal of other things far too many to mention.

So calling Estimation ‘waste’ is akin to calling Planning ‘waste’, if we were to eliminate say planning and testing in an effort to reduce waste, we would very likely cause more and worse waste by producing the wrong thing (over production waste), in the wrong order(over production), or poor quality (rework waste).

In other words not all waste is bad and not all waste should be removed – simply calling something ‘waste‘ does not help the conversation.

Sometimes a little waste now can save a lot of waste later.

8 wastes

Is it beneficial?

The real question is whether the activity helps the system? and as a follow-up, is there a better way of achieving the same thing?

Questions to ask when considering waste:

  1. Does this activity help the system to be productive now and in the future? (Would removing it impact our productivity)
  2. Is there a better was to achieve the same outcome?

I can’t answer the question of whether Estimation is beneficial in your system, because every system is unique, if you are using estimation for forecasting purposes then I’d suggest that there may be alternative solutions that are better and #NoEstimates may be a good place to start.  But forecasting is only one use of an estimate, your system may find that estimates are beneficial it is for you to decide.

Next time you see someone use blanket statements that eliminating ‘waste’ as an absolute and unqualified justification for not doing something, please challenge them to qualify their statement. Remember that waste is often necessary, our goal is more often to improve or understand the wasteful activity rather than eliminate it entirely.

1490696188622049861

Let’s consider a world without waste

If you are still unsure think what would happen to your system if you abolished all wasteful activities:

  • Vacations – typically 10% of your productivity lost.
  • Coffee breaks – 10 minutes every 2 hours = another 8% productivity lost
  • Toilet breaks
  • Stand-ups – yep they are waste too.
  • Demos, Retrospectives, Planning, all are ‘waste’

Just imagine how productive you would be with no direction, no feedback and no staff?

 

 

The Enemy of Agility is Ego

dunning-kruger-effect

Over the years I have discovered that the more I learn on any subject the more I come to realize that I know very little, it doesn’t seem to matter how much I study or how much I learn, the awareness of scope of my ignorance grows far faster.  Does that make me wise or just aware that I know very little?   I suspect that I’m slowly fighting my way out of the valley of despair.

No need to improve

One of the most challenging aspects of being an Agile Coach and working with teams is that to improve you first need to accept that there is room to improve. There are a some teams and team members that believe there is nothing more that they need to learn, they are so supremely confident in their own capability and knowledge that they refuse to consider that there could be a better way to do things than the way they have always done things.
On the other-hand I can’t be confident that there is a better way, only that we won’t find a better way unless we look. I don’t like the notion there is a ‘best practice’ as this limits our thinking. But this puts unwavering certainty that this is the ‘best practice’ against encouragement to explore the possibility of a better way, certainty is very powerful.

Sometimes this ‘certainty’ is founded in fear, especially when dealing with transformations where former roles are called into question, I find this an understandable reaction, but the situations I struggle with most are the team members that become blinkered to opportunities, they have found one way that works (even poorly) and simply are unwilling to try anything different. Their Ego, prevents them considering anything else.

As a coach I have no desire to force processes or ideas on people, only to open their minds that there could be opportunities and alternatives.  So it can be heartbreaking when people refuse to even consider alternatives, or worse impose their views on others through sheer force of will.

Perhaps I am mistaken and maybe the right answer is that if something isn’t broke don’t fix it, but that notion doesn’t sit well with me.

kruger calvin

So how do we persuade people to open themselves up to learning new things?

I recently had an experiences that I found tough, there was a QA who refused to ‘leave his column’ on the board, he would not do anything that was not ‘testing’ and resisted anyone working with him in ‘his column‘ thankfully it is not often I see that level of obstinance. But this situation was further compounded by the rest of the team enabling his behavior. The developers were all too happy not to be involved with the QA aspect and were seemingly unmoved by his unwillingness to cross boundaries.

The QA column was regularly a bottleneck but rather than addressing this the team wanted to mask the issue by pushing cards through and raising new cards for rework. What was tough was that the team saw no need to experiment with alternative ways of working: suggestions included either helping the QA, or even getting the QA involved earlier, and despite raising QA as a bottleneck repeatedly in retrospectives the team didn’t want to change behavior even in the form of an experiment.

As a coach you can shine a light but not force a change.  I felt the team was capable of far more but the team were getting things done and were seemingly content with the status quo. For me this is the dark side of coaching, where you must watch a team not reach their potential, out of respect for their independence.  Ultimately it is a trust issue as things so often are.

Ownership of Columns

In general I dislike explicit roles when there is a shared responsibility, and I dislike the notion that a column on a board is in anyway related to a person or a specific role, the board should reflect the progress of the work (stories) not ownership of the work and when the two become muddled people become defensive and territorial.

When there becomes an association between a column and a person the focus moves from getting a story done as a team, to moving a story on to the next column, we switch our context of efficiency to a narrower view.

This is often seen as a subtle and unimportant distinction. But when the team loses a cohesive sense of ownership for getting to done and can hand off responsibility to another sub section of the team, bad habits emerge. At it’s worst I have seen teams (thankfully not one I coached) where at stand-up one part of the team will brag about how many stories they are ahead of an other part (be it front and back end or Dev and QA). In one extreme case I saw a team decouple testing from development by splitting stories and I overheard one standup where the developers were gleeful that they were now 3 sprints ahead of testing (the sprints were 3-week sprints). It is 9 weeks before they will see value from their work or even know if their work had value, and yet they were so proud.

Dunning Kruger Effect

Adjusting your mindset to one of learning rather than certainty can be tough, especially for those that grew up in a culture that rewards confidence and certainty, but accepting that you don’t know everything and being aware that there is always the potential to improve can enable you to become far more capable, the only thing stopping you is your ego.

 

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell

 

Feedback: victim or beneficiary?

Feedback takes many forms, some is explicit and some can be inferred, even the absence of interaction is a form of feedback. Some if obviously well-intentioned, and some less so, some is invited and some is thrust upon us.

When you accidentally cut someone off in traffic, the feedback they give may be in the form of a horn and a hand gesture.  There is no question this is feedback, it may even be useful when you have stripped away the anger and your defensive response – I did after all miss something, they are helping me see something I didn’t see myself and now I will at least have the option of improving my behavior in similar situations in the future.

boston-road-rage-1024x683

Improvement is MY choice

Please note the word ‘option’,  the decision to change my behavior is mine, I can choose whether I respond or how I respond, giving a peer feedback does not compel them to change the way you want them to, regardless of how forcefully you may give the feedback.

Many times you will receive conflicting feedback, or sometimes you just disagree with it. When someone gives you feedback and they are asking you to change behavior remember it is you that needs to change and there is no one Youer than You.  It is up to you, you can choose what or whether to change.

you-have-brains-in-your-head-you-have-feet-in-your-shoes-you-can-steer-yourself-any-direction-you-choose

A Feedback Culture

I work in an organization where there is a very strong culture of self-improvement and professional development, but there is also a distinct absence of management, we therefore rely heavily on feedback from our peers. Our internal processes encourage formal and informal peer feedback.

In an Agile community we rely heavily on feedback loops for improving our processes, stand-ups, demos retrospectives, not to mention the metrics we encourage in our development practices. These are all opportunities to respond to the feedback as a team to help us improve.

Peer Feedback

However, individual feedback from peers is much less structured and much less objective so it becomes much harder for the giver or receiver to be objective in the way they give or receive the feedback. Peer feedback is by nature personal and when things get personal the stakes get higher. We give feedback in a subjective way, and we receive and we respond to feedback in a subjective way, both are cursed with perspective.

Ostensibly the goal of feedback from the perspective of the giver is to affirm behavior we approve of (e.g. clapping and cheering) and to discourage behavior we dislike or disapprove of (booing).  Context is also a factor we may be motivated personally or professionally.

For the receiver of feedback it is ostensibly to aid us in seeing things we are unable to see, to gain another person’s perspective on something. We may get to see things we can’t or don’t see for ourselves e.g. Am I speaking too quietly.

Whether the feedback is invited (“Can you hear me?”) or not (“Speak up!”) we are benefiting from another’s perspective on a situation.

Attitude

Sound’s great! But the attitude of the giver and receiver play a much more significant role in peer to peer feedback, and in how effective or valuable that feedback is, and what the consequences on the relationship are.

Let’s go back to the person I accidentally cut-off in traffic. Whilst there is benefit in being reminded that I need to pay more attention to my blind-spots I doubt very much the person cut-off and is giving me hand-gestures was overly concerned with my personal development or in helping me become a better driver.  The reality is that their goal was not to help me improve, it was to vent their frustration, to express anger and to feel better in themselves by ranting at me, my welfare was not even remotely the concern.

And so it is with peer feedback, there are times when I really want to express my opinion, I don’t care whether the person improves, what matters to me is that I get my say and I can express MY feelings.  This can come off as spiteful rather than supportive. and leave the person feeling a victim.

Victim or Beneficiary

The “feedback culture” has created an opportunity for some people to express a desire to ask to “give feedback” when really they are taking an opportunity to give someone a piece of their mind in a situation where the ‘victim’ feels they cannot respond. By calling it feedback we get a free punch and if they react badly or refuse to be verbally punched we can claim they are not acting in the spirit of feedback.  I worry this is damaging our culture and is a misappropriation of feedback, the result is the artificial harmony we were trying to get away from. Dressing an attack up as feedback does not change it.

bully

Before giving another person ‘feedback’ we need to reflect on it ourselves and consider whether our true desire is to help the person improve. Do we truly desire the subject to be the beneficiary of our feedback or is the act of giving feedback more about satisfying your own need for satisfaction and they are just the victim of your feedback.

Spirit of improvement

Please understand that I am not saying that the horn and the hand gesture are not feedback – clearly they are. Nor that I can’t respond to the feedback and improve. It is a question of the spirit of the feedback as much as the  message itself.  If I feel the feedback is given in the spirit of helping me I am far more likely to respond favorably, if I see the feedback as a veiled attack I am as likely to resent the message and in some extreme cases I may retaliate – I am less likely to see it as an opportunity for improvement.

Is your true desire is to help the person improve or do you want to make them feel bad? Do you want a good relationship in future? Then perhaps be more considerate of your approach.  We all make mistakes, and we can all improve so let’s make the effort to be kinder in our delivery of the message – not necessarily the subject. Feedback needs to be clear and should not shy from difficult issues but the delivery can make all the difference.

TRUNK Test

When we rely so heavily on relationships and on feedback it is important to apply the TRUNK test for offering feedback:

Is what you are about to say TRue, Useful, Necessary, and Kind?

 

 

 

Goldratt User Stories

As a product owner we should be building products to deliver on the Vision and a set of  defined objectives or success criteria. But often our plan is not closely mapped to those criteria or it can be difficult to measure whether we have achieved our Vision or delivered on our objective.

Let’s change the way we write stories

So I wondered if we could expand on a desire for delivering measurable value by changing the way we both plan projects/product and write our user stories?

 

Tell me how you measure me and I’ll tell you how I will behave.

Eli Goldratt

 

The notion of this is that rather than defining our User Stories in terms of behaviour, or actions or activities –  in which we primarily focus on the ‘What’ we should change, our start point should become us defining the “needle we want to move”  Let us start with the measurement of success. Understanding how we will be measured and identifying behaviour that impacts the measurement.

photo_of_the_day_ferrari_458_italia_dashboard

E.g. our goal is to increase the number of items per basket for online sales, our measurement is therefore the average number of items sold per transaction.

Equally it could be to increase the average value of the basket per transaction, or increase the number of units sold of high profit products

Hypothesis rather than Story

Our ‘story’ then would be to ask the Product Owner and Team to identify one or more hypothesis for ways that could impact that measurement. The notion being that a hypothesis must be tested before the story could be considered done.

This could take the form or a brainstorm session to identify the more traditional stories or it could simply be left for the team (in conjunction with the PO) to determine the best way (possibly two or three alternatives) to achieve the desired outcome after the story has been pulled.

This is building on the principle:

The best architectures, requirements, and designs
emerge from self-organizing teams.

Already happening?

You could argue that this is already the role of the Product Owner and that the Product already does this, and in identifying and prioritizing stories they have already considered the impact.  In some cases I would agree with you, in a few cases I have seen products or projects with clear objectives in terms of the goal of the product and even sometimes a measure of success in terms of measurable objectives.

I have yet to see the end goals mapped even at a high level to the stories and features, in most cases success criteria are wooly or undefined and more often than not the Product Owner and team will brainstorm stories (story mapping) without reference to the goals, and even Impact Mapping often will not extend to measurable goals.

That is not to say that the Product Owner is not considering this holistically, the measurements are generally part of the consideration but many stories creep in that have no material benefit or impact on the success criteria of the product.

From-the-book-User-Story-Mapping-by-Jeff-Patton

Measurements for Goals as the basis for Story Mapping

For reference I love Story Mapping, I consider it my favourite tool for Product Ownership and have been known to rave a little too much about it on occasion.

The start point in story mapping is typically to identify themes of user activities (you could call them epics but don’t get hung up on terminology they are essentially big rocks and then we will progressively break them down in to smaller rocks arranged underneath the big rocks.

We can then prioritise the work in the context of the whole rather than being constrained by a linear backlog which makes the context difficult to visualise.

It is also a fantastic tool for explaining the product for release planning and forecasting and so on. Like I say one of my favourite tools.

But what if instead of starting with activities or big stories, what if we started with our measurable goals or success criteria.   e.g. new subscribers per month, revenue per visit, time to achieve objective using application etc.  And we then identify stories that best enable us to achieve that goal.

There may very well be some overlap so there maybe the notion of tagging a secondary objective, but imagine if this helps us weed out stories that are not taking us to our goal or have limited value in the context of our goal.

We would ask which of these stories has the potential to move the needle the most? and prioritise accordingly.

download (9)

Make it measurable

Focusing our efforts on measurable impact to the product should implicitly be the goal of any Product Owner so why not make it our explicit goal?

 

 

 

 

 

How do I know I am delivering Value?

Many of us are relatively familiar with the notion that stories should be expressed in terms of value delivered (Why) and how important the “Why” is for being able to maximize the outcome for the customer–

 

Who: As a …

What: I want to :

Why: So that …

 

When we talk of good stories we refer to INVEST as a means of helping validate that our stories are well written, I think this is a great tool for helping write user stories, we may even include Acceptance Criteria to help the team identify that the story has been completed in such a way that the value is best able to be realized, but I’d like to propose going a step further.

success

Expected Vs Actual

Whichever way the story is written the assumption is that the PO has determined the value of the story and prioritized it accordingly, but value is a very nebulous term and encapsulates all sorts of things many of which are assumptions or just plain guesses or personal preferences. We are also making the assumption that the story will successfully deliver the value we intend.  Rather than accepting that it is a hypothesis that it will achieve our goal.

Up to this point we are assuming that the Product Owner is always making the right decisions, and their assumptions of the value delivered by a story are infallible. Speaking as a Product Owner, that is a rather hopeful assumption, often value judgements are little more than educated guesses, certainly they are very subjective opinions on value. Even market research is guesswork to some extent and particularly with new products or internal systems there is little opportunity for effective predictions of value.  I don’t want to take anything away from the PO and their authority on making these judgements that is after all their role.  But as a PO I would very much value a feedback loop which would enable me to validate that my decisions were right or wrong and give me the opportunity to course correct accordingly.

In other words it is necessary for us to make judgement calls but getting feedback on the accuracy or otherwise of those decisions would be hugely beneficial.

download (5)

So what can we do?

We could add to the Acceptance Criteria to include some additional validation. Our Acceptance Criteria helps us validate that a story is implemented the way we intend it to be implemented, it does not however always enable us to measure whether the value is fully realized.

For example:

Assumption: We believe that adding a picture to listings on a product website will increase sales by 10% (our market research says so).

As an online customer,

I want like to see pictures of products

So that I can make more informed buying decisions (and thus buy more products) –

(Business Value: Marketing estimates sales increase of 10%)

 

Our Acceptance Criteria may stipulate positioning of the picture, the size and what to display if a picture is not available. We may even add some performance Acceptance Criteria such as average page load time. But that is not enough to validate that the value was achieved.

missing3

How do we validate that a story delivers Value

But how do we validate that this story does actually deliver the value we expect – whilst we can be confident that having a picture fulfils some aspects of the value – the better informed decisions, it might be that we are missing out by not having the ability to zoom on the picture, or it may be that our users are not bothered by the picture at all and would prefer another feature such as the “lead time” or “quantity in stock”

Validation Criteria

What if as part of this story we not only implement the feature to show the picture but we also include analytic measurements on the page load times, and even a measurement for the number of sales of a product or products per day and then evaluate 50% of users with the new feature and 50% without the pictures and compared the results. Or we could conduct focus groups on this feature or usability studies to get more subjective but detailed feedback.

As part of the story we could add an additional layer of Validation Criteria, this would be similar to Acceptance Criteria but would be a way to measure the value actually realized by the user

download (6)

What do we gain?

Would including functionality or activities that enable us to measure that we have delivered the value we are expecting make the stories better? Would that information help shape our product and build a better product? Would it help us prioritize our backlog as we get a better understanding of value actually delivered vs value expected to be delivered?

We could either add stories for these measurements or consider these to be encapsulated in the delivery of this story.

Essentially we are asking whether feedback is valuable and if it is – how valuable is it to us.

download (7)

Return on Investment:

When discussing this with a colleague the first response was that this is putting more upfront work and that is a challenge for the ‘lazy’. In Agile ‘Lazy’ is a virtue so this is important feedback.

Naturally there is an overhead in this but as with all feedback loops the information is valuable, knowledge is power and we just need to tune our efforts – our feedback volume to the right level to get valuable information with the minimum necessary effort. Another example of an Andon Cord where if the effort is too much and producing either too much information or nothing of value then we need to retune our feedback loops to give us enough valuable feedback to act.

Also many of these measurements will be applicable to multiple stories so the investment may end up being very limited but the feedback may be far reaching, and once automated the ongoing feedback can be tweaked to add extra sensors to give us more and more valuable information.

Some examples of value assessing measurements:

  • Website analytics: hit rates, click through rates, hot spots etc.  The cost of these is minimal and is often something that can be applied even after development.
  • We could write stories to build into our application measurement for how our product is used, or the performance of our product,
  • We could add usability testing or focus groups, surveys of users
  • By using feature flags we could set up effective A-B testing to get feedback on structured hypothesis validation.

Please note that not all measurements need to be software driven – increased subscribers say may be measured entirely independently of your application.

Navigation

Vision

But ultimately the biggest change would be in your initial vision creation, do you know your product goals and do you have a way to measure success.

Is your goal increased sales, or time saved, or efficiency improvements, or increased users or cost saving and regardless of your goals do you have a plan for measuring whether your product is achieving your goals.

This may seem like stating the obvious but I cannot count the number of projects I have been on where the stated aims were cost-saving or revenue generating and numbers were stated and yet after the project was authorized no one ever went back and assessed whether the project was a success or achieved any of it’s aims. Having an aim was enough to get the project started.  Claiming a 10% increase in sales or reduction in costs should be something you can measure so measure it.

Ironically being able to map a story to one of your stated goals for the product could be another way to filter unnecessary stories if the expected impact is not one of your product goals.

Summary

This is a very simple change to your story writing process – an extra little consideration that could have significant implications to the success of your product, the addition of a very valuable feedback loop on value delivered (rather than value expected)

As a …

I want to …

So that …

And I can verify this by …

 

Post Script:

I presented this notion to a Product Ownership Meetup and the response was amazing the conversation was full of so many great ideas, and examples of how some of the product owners are already putting this in to practice – not explicitly but have made usability and measuring usage a key part of their Product Ownership methodology. I love the conversations this group has each month, but this month I came away with so many new things to think about.

The highlight of which was Goldratt Users stories – which will be the subject of my next blog.

Tell me how you measure me and I’ll tell you how I will behave – Eli Goldratt

Practically Agile

As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.

Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.

  • Systems Thinking
  • Community Context
  • Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.

At the very heart the manifesto is about getting better at delivering software.

We are uncovering better ways” – it is a journey of discovery, we do not have all the answers.  “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.

Systems Thinking = YOU are not the center of the universe

The goal is effective Agile Software Development, solving a problem for a user, with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .

Transformation failures

In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed.  The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.

An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster.  High performing teams arise when we learn that we are more that the sum of our parts.

The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally and this is the pillar that binds it together and makes it so strong.  We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.

As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.

We challenge our thinking, we question our beliefs and we look for ways to grow.

We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.

If you always do what you’ve always done, you’ll always get what you always got

Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.

5-focusing-steps-113297

Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.

Summary

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.