Isn’t it obvious?

I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.

What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past.  My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.

deadly-assumptions

And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.

There is nothing more deceptive than an obvious fact. 
― Arthur Conan Doyle

c770ba6b2c578be3db267493229de2dc

Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.

And it is this simple:

All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.

Work on the thing that adds the most value and stop working on things that don’t add value.

So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.

What is Value?

The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.

We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.

opportunity cost

  • the loss of potential gain from other alternatives when one alternative is chosen.

Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly.  But worst of all it delays delivering value.

Two Problems

So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.

In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.

  • Discover what our goal is – how do we deliver value? What outcome are we trying to achieve? 
  • Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.

 

Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered.  So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.

Example

victoriaspongecomet

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

But the funniest part of this story for me was that she was so frustrated,  she thought it was obvious, and he thought he was being efficient.  Those opposing view points are so common in this line of work.

When you see it, it is obvious but until you do it remains an enigma.

Why be a coach?

doc

Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on.  Then this loony guy comes in and says that you might actually contribute more by being less efficient.  – I’m the loony guy and I love it.

Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.

Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.

—————————————

There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’

The Advantage by Patrick Lencioni 

This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

The 5-Dysfunctions of a Team by Patrick Lencioni

I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.

 

Advertisements

The 3 Elusive Qualities of a Product Owner

It may sound overly simplistic but in my experience products generally succeed or fail in correlation to the effectiveness of Product Ownership on the team. Mainly because we under-appreciate the importance and the difficulty of the Product Ownership aspects in the product creation process. In my opinion the choice of this role is far more important than the coach or other team members. The role is full spectrum, they go all the way from discovery to delivery and more.

Ironically, we tend to think of software applications as being primarily technical objectives, our focus is too often on the quality and ability of the engineers, the architecture and design. We will spend time on process and optimization and efficiency.  All the while forgetting that the most common and most consistent failure of all software products is that no matter how good the quality, how optimized or efficient it is, or how good the engineers are that built it – if you build the wrong thing it is a failure.  A perfectly designed but unused product is worthless.

History if full of great products that missed the mark, how many apps have you downloaded to your phone that are no longer used or were never used after the first 30 seconds.  There are many many more products that fail to ever get in the hands of customers at all. Internal IT products are often culprits of this, the assumption seems to be that because the users are forced to use the product we don’t have to actually ask them what they want or how they will use it, we build great products that don’t fulfill the actual user need.

1410209080-dont-let-these-3-myths-stop-you-from-launching-cause-marketing-campaign-stop-sign

I think probably my favorite and most over used quote is:

There is surely nothing quite so useless as doing with great efficiency what should not be done at all.

Peter Drucker

I use the quote far too frequently but in 25 years developing software this remains the most frequent sight I see, more products fail for not meeting the most basic customer needs than for any other reason. And yet when I say this, it generally gets scoffed at, until you start asking how many people have worked on products that have been abandoned or shelved mid development. Teams rarely believe their product is at risk of being cancelled, or are too far removed from the customer to appreciate that the user liking and using the product is infinitely more important than whether they are efficiently re-using a section of code. We have created a mindset that ‘done’ is delivering code.  A product/feature/story is only really done when the customer is using it.

Product Ownership does not need to be a single person in that role, but it should be a mindset within the team.  Ideally I’d love for this to be a shared responsibility. Unfortunately in my experience a true appreciation of Product Ownership is as scarce as Hen’s Teeth, and generally unappreciated and vastly underpaid, those that do it well make it look easy and doing it badly or being indecisive can really destroy a product so it can be a risk to spread the responsibility beyond one person.   I have heard people talk of teams where the teams do it well and they don’t need a PO, but I have yet to see this for myself.  Because of this experience I think of the Product Owner as the most important ‘hire’ for the team, getting the right person in this role can be crucial to the success of the product.

A good PO these days is hard to find…

So why is a good Product Owner so hard to find and what makes the role so difficult?

1: Differentiating what is needed from what is wanted

A significant part of the role is identifying what is needed to solve your users problems or to fulfill their needs, to enable them to be better at their job, or to maximize their fun or relaxation.   The role is about understanding the problem and creating a vision of how that could be solved – not the technical solution but discerning the true need or true problem.

Henry Ford With 1921 Model T
Henry Ford stood next to his ‘Faster Horse’

 If I had asked people what they wantedthey would have said faster horses.

Henry Ford

The reason this skill is so tough is that users rarely know what they need, typically a user’s vision is constrained by what they currently do. As a result many products become re-works of a paper system or re-engineering an old system.  A poor product owner gives a customer what they want or what they ask for, a good product owner listens and watches and blends wants and needs to solve the customer’s problem and give them what they need.

tree_swing_development_requirements-scaled1000

I often seen backlogs that are full of stories that are unfiltered customer requests, it is lazy and it is easier to do what is asked. But to find what is needed typically requires experimentation, feedback, conversations and observation. It is far harder to build what is needed than it is to build what is asked for.   Similarly this can manifest itself when department managers decide what their team needs or wants without involving them in the discussion, a good Product Owner will spend time with the users of the product and ideally see how they use it.

A Product Owner with the creativity, the initiative and the Vision to create a great Product is worth their weight in gold,

2: Understanding what is required to create a successful application

A second aspect of the role is the one I see most frequently overlooked. Perhaps because of the emphasis on 1, the need to understand the business, I see people choosing someone from the business to become the Product Owner, their knowledge of the business is seen as their primary qualification and in many cases their only qualification for the role.  And worse they are often asked to do the role in addition to their normal job.

However, a great Product Owner understands not only what to build but is familiar with the development process, they understand the ebbs and flows, they understand the implications of technical debt, automation and testing. The understand how crucial it is to have working software in the hands of users as soon as possible. I am sorry to say that business POs often lack this knowledge and experience, they will mistakenly perceive a desire for a fully working product rather than appreciate the value of early feedback. Many are plagued with the last bus syndrome, trying to include every imaginable feature rather than working towards a minimum feature set to get feedback and derive value early.

rocket-flat-design-concept-for-project-start-up-and-development-process_1561-39

Personally I’d invariably trade an experienced Product Owner with zero business knowledge for an expert in the business with zero software delivery experience.  Business knowledge can be gleaned from effective conversation, observation and feedback. The understanding of a good Agile Software Development lifecycle is far harder to learn and there is no substitute for experience.

Typically the best products result from experiments, reviews and feedback, a willingness to be flexible and respond. The other disagreeable quality of a Product Owner taken from the business is that their knowledge is about how the work is done now, and they are often blinkered to the possibilities.

Remember that the Product Owner sets priorities and interprets the Vision, they have more influence on the product creation than anyone.  Their choice of priorities can profoundly impact the value, and the quality of the product. If they lack the understanding of the importance of testing, feedback and good software principles it can lead to conflict and disharmony in a team.

3: Communicating effectively with both technical and business stakeholders

Finally there is a need for effective communication.  We always talk about effective communication to the point that it becomes background noise.  But the importance cannot be overstated.

A great Product Owner, listens, they observe, they probe and they reflect.  The ask for feedback and they read between the lines, they watch body language, they see and hear what isn’t said as much as what is said.   When it comes to understanding the user they have great attention to detail and they look intently for pain points and points of pleasure, they are looking for a way to serve their users in the best way they can. Most of us think of communication as speaking, but for a Product Owner watching and listening are so very important.  Empathy with the user, the customer and the ability to communicate using their terms and understanding their domain and conversing with them in a meaningful way is crucial, and if you don’t understand the terms develop an attitude of attentive student ask questions and show you are interested and are learning.

A great Product Owner learns to say ‘No’ powerfully respectfully and does so in a way that conveys they understanding to the person asking, a great Product Owner should not be seen as an obstacle or a hurdle but a steward of good decisions. The word ‘No’ should be delivered in a way that leaves me feeling confident that the Product Owner will deliver the best product within the parameters and leaving me confident that this decision is right even if it is not what I initially wanted.  The Product Owner should be able to convey the implications of saying ‘Yes’ so that I understand why I am being told No.  A great Product Owner has any number of tools that can help people see this and yet we regularly see backlogs full of feature requests that will never see the light of day because the PO doesn’t feel capable or sufficiently empowered to say NO!

no

But the PO must also communicate with the development team, they must understand technical development terms, to have a grasp of the technical implementation, even if they do not have authority over the ‘How’ I’d expect them to have a vested interest in understanding it.  They also need to be able to communicate the business needs and the business terms in a meaningful way to the development team, This requires a versatility in speech and communication that is unusual to say the least.  Being respected and understood by both the business and the technical team is a major feat, and as we all know any cloistered group speaks in three letter acronyms that only they understand and the audible sign when they have to explain to an unlearned outsider can demoralize the best of us.  Do not underestimate this ability.

But there is more, they need the creativity to communicate design ideas or if the ideas come from others the scope to understand that creativity, to imagine what could be and express that to the business and to the technical team.  And then we get into the really tricky realm of the stakeholders as opposed to the users, this generally is the group that funds the product, they want to see progress, they want to see good stewardship of their investment, they may ask for forecasts and may even press for commitments.

We have now loaded our Product Owner with the need to communicate with senior people that make financial decisions, to express Risk and Forecasts in a manner that it concise but meaningful, we want to be transparent and informative, but confident.  If we are using forecasts especially mathematical forecasts we had better understand them and be able to back them up with explanation and confidence.  A Product Owner my stand their ground in the face of authority and speak truth to power. A Product Owner that makes unrealistic commitments or promises, will lose the confidence of her team and her stakeholders in a flash.

If a Product is to be sold it is likely that you will need to be involved in Sales and Marketing, which brings a whole host of other skills and communication issues to bear, understanding the implication to the market, and how you measure that and how you engage with that is a new realm of understanding and confusion.

A great Product Owner is a master communicator, they have an insatiable desire for knowledge, to understand and be understood.

Summary

As you can see the skill set of a great Product Owner is monumental, and yet the good ones make it look easy.  If you have a mindset suited to Product Ownership it is likely you already have good communication skills and enjoy learning more domains.

It is likely you are the sort of person that thrives on the delivery of a product and revels in the feedback, enjoying the flexibility and change, is unmoved at the thought of redoing something twice or even more to get it right.

Solving problem is a thrill and being able to see beyond the obvious and draw out information from users and then present something back is a joy.

That doesn’t mean it isn’t incredibly difficult, overwhelming at times and sadly unappreciated, and very often underpaid.

At some point the industry dismissed all these skills as unimportant and we see a flurry of Product Owners that write stories exactly as dictated by users, that input data into forecasting tools without the vaguest notion of what the forecasts mean or how they are calculated.

As I said at the start a great Product Owner is the lynchpin of a great Product, we should be seeking them out and rewarding them appropriately, you will be amazed at what can be achieved with the right person in that role.

 

 

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.

 

 

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?

 

 

 

 

 

The 4 steps to successful software delivery

After [reading / posting] a recent article on waste, (read it here), someone asked me why we shouldn’t do work that we will need later if it is more efficient to do it now?  You have already dug the hole—doesn’t it make sense to do all the work in that area together?

This is very similar to the argument for splitting stories horizontally along business layers: “We can be more efficient if we optimize and specialize.”

Yes, you might achieve local efficiencies by taking these steps. But local efficiency is not the most important factor in your decisions. Efficiencies and optimizations need to be considered in the context of the whole system.

The primary goal is to Maximize Value Early

For both project and support work, our goal is to maximize value for our organization, and to realize this value as early as possible.  In a consultancy firm, there is a slight abstraction, as work is paid based on time and materials, and these steps are distributed between client and team. Regardless of who owns the following steps, success depends on shared awareness of these priorities.

The 4 Steps

The four steps are designed to focus our energy where it will have the most impact first, and then building upon the previous step by shrinking the focus area through each subsequent step. Hence they are in descending order of impact.

1 – Prioritization
(Selecting Which Project/Product to Build Next?)

The most important decision your organization needs to make is which work will bring the most value NEXT. This has the most impact on your company’s bottom line, so should get the lion’s share of effort and focus.

Program Management

 

Describing the value a project will bring is far and away the most important aspect of software delivery. If possible, create a formula for calculating business value to help with these decisions. If you are unable to quantify or qualify the value to the organization of the work being undertaken (at a high level), then you are likely working on the wrong thing and all other actions you take could be waste.

Some projects/products will obviously bring in huge amounts of revenue. Others may save huge costs in manual entry and work-hours. Some may support business-critical systems that, if not supported, create extensive risk and potential cost. A project might also fulfill a safety or regulatory concern, or business objective.

Naturally this is complicated and can be difficult. Priorities change. Time factors and organizational politics come into play. A lot of the time you will be making informed guesses about value and costs. But this decision dwarfs all of the others in the impact to the bottom line, so is critical to put the right amount of effort here.

I would consider this to be the responsibility of the Program Manager or Project Management Office, but I see the responsibility to be to identify the projects that will bring most value to the organization as the end of their role. “Day-to-day Project Management” responsibility lies elsewhere.

I would however strongly encourage this decision-making process to be transparent and inclusive.  Hold a regular Project review board and invite the stakeholders. Make the process clear and help everyone understand how the decisions are made. I would also suggest a visible roadmap of work planned.

Finally, I would encourage you to not plan beyond your company’s horizon. If new work is likely to emerge in the next 3 months that may significantly change priorities, then only plan for 3 months.  Only start a product or project at a point you feel committed and certain it will be completed. Starting something with the expectation of pausing or pivoting suggests it wasn’t the most important thing to work on next.

2 – Direction
(Product Ownership – Building the right Product)

Whether this a new product or supporting an existing product, it is important to ensure that you build the right product,  Product Ownership is covered in lots of detail in other places so I won’t go in to details but I suggest watching this video:

po nutshell

Like prioritization in Step 1, the most important responsibility in Product Ownership is Maximizing value–Are you working on the most valuable thing next?  You do this through experience and through feedback from users and stakeholders.

Feedback is crucial. To get frequent user feedback, you should be thinking about how you intend to deploy your software and then update it regularly. You should be thinking of this before or with your first story.

Deployment and ongoing updates should not be an after-thought.

Product Ownership is also about maximizing the work not done. The product should meet the needs and goals but only do what is necessary. There will be a point when the returns diminish. All work carries an opportunity cost, and at some point your time is more valuably spent elsewhere. Understanding this is vital.

Finally, I want to stress the importance of getting value to the customer quickly. Value is only realized when the software is used. We should be striving to getting the software in use as soon as possible. This may be in an unfinished state. It may be only a partial solution, but it should be adding value. e.g. it can be used alongside an existing product, or it could be used for this workflow but for another you use another tool etc.

Feedback from people actually using your software is the most valuable feedback you can get.

Just like prioritizing projects, prioritizing stories has far more impact on the success of the project than the following steps.

3 – Quality
(Build the Product Right)

Building the right product is more important than building it right. Building the wrong product is just a waste. But that doesn’t mean that quality is not important.

Quality means doing it right when no one is looking.

Henry Ford

When assessing cost of software, it is easy to focus on the initial development cost alone. But support maintenance and future enhancements all fall into the total lifetime cost of a product. The cost of defects magnifies over time, and the cost of supporting poor quality code is significantly higher and more risky. Re-learning and knowledge transfer are painful and costly to an organization and I can think of numerous examples where companies have been forced to abandon projects or replace software because they lost a key employee who had the knowledge locked in his head–or software so fragile no one dares touch it.

Good practices such as Test Driven Development, Pair Programming, Behaviour Driven Development and Automated Regression Testing may seem costly at first. But when considered in the context of lifetime cost, they are a sound investment. More importantly, they enable the right business decisions to be made because there is a confidence in the software.

Quality code with a solid set of tests enables refactoring and new features to be added with the knowledge you are not causing unintended consequences elsewhere by breaking older functionality. This reduction in risk is a considerable advantage, especially when supporting older applications.

This is not a carte blanche to gold plate or over-engineer. Quality Code is the right code for the story and No More. We write just enough to satisfy the story and we write it well. Over-engineering applies to the GUI too–we don’t add features or over-engineer.

4 – Efficiency and Improvement
(Building it Better and Faster)

By this point we should be working on the most valuable product to our company. With that taken care of, our next focus is to work on the most valuable feature or story for our users/customers. We should be doing it in a manner that enables us to be confident in the work and able to expand it later.

But guess what? You can do it better.  We should reflect on the decisions we made and how we make them. Are we making the right decisions?  What helped us make those decisions?  Are we making the wrong decisions? If so what could we change to avoid repeating those mistakes.

The reflection and improvement should be done at all steps and should incorporate the learning from all stages.  If we continually look for ways to improve we will get better and better.

If you always do what you always did, you’ll always get what you always got

Henry Ford

 

What about efficiency of developer effort?

So what of the original question about being more efficient with horizontal splitting of stories, or the perceived inefficiency of re-working the same area of code later?

It is a question of impact and perspective. In both cases the question is founded on ‘efficiency’ being a measure of the developer’s efforts.  What I would like you to consider is that in terms of delivering value to your users and ultimately your company efficiency should not be measured in terms of developer effort, but should be measured in terms of delivered value.

Efficiency should not be measured in terms of expended effort, but should be measured in terms of delivered value.

The most valuable decision is to work on the right project – this dwarfs all other decisions by an order of magnitude. But it is at a different level of scope than this question.

The next most valuable decision is what to work on. This generally best considered from the perspective of delivering value to the customer quickly and of being able to respond to their changing and emerging needs.

When we split horizontally or when we do extra work, we know we will need later we may give the appearance of making more efficient use of developer effort, but in doing so we reduce our ability to adapt to changing needs and more significantly we delay the time to deliver the next most valuable feature.

This is an example of working with a waterfall mindset. The measure is that while it delays us this week, we will make back the time next month or next year. So if we are not planning to deliver this to our customer until next month or next year, it might appear to make sense. But you may not have considered two factors.

If we are deploying frequently, we are realizing value with every release and in the value of our software isn’t massively more than the cost of developer time to create it, then it is likely we shouldn’t be working this project at all. So ultimately the cost of developer effort for having to rework the same code later for a new feature is insignificant to the value gained by delivering sooner. We should measure ourselves based on value delivered not the effort to deliver it.

The second consideration is that the work you are doing on the assumption of needing it for a future feature may not actually be needed. That feature is by definition lower value and less important as it has been prioritized lower.  There is a pretty reasonable chance that the customer may change their needs or there is the possibility of the project being cancelled or considered good enough as it is.  That work may never actually be needed and you would have delayed the project for work that had no value. The efficiency you are trying to achieve may just be an illusion.

This is the business equivalent of spending $10 today to save $1 next year.

When considering efficiency and improvement, remember your goal is to maximize value to your customer and to realize that value as quickly as possible.  Ask yourself if the efficiency improvement you are proposing fulfills those goals? If not it may be just be an illusion.

 

 

 

 

 

 

Weeks of coding can save hours of planning 

In the context of Lean manufacturing there have been numerous studies that estimate that the proportion of value adding time in a production cycle is around 5%. The other 95% is deemed to be waste.  These studies also conclude that by far the biggest waste is overproduction.

Anecdotally I think it is a very similar story in Software development although my fear is that the proportion of value adding time is even lower.

Waste takes many forms but broadly speaking effort as a team/company fall in to three areas:

1 .   Valuable Effort – Value adding activities, these activities cost time and money, and there is a consequential opportunity cost but they add some value.   However, the value may be able to be realized more effectively.

2.  Obvious Waste – Non-value adding activities that are evident. These activities cost time and money (and opportunity cost) but add no value to the product being created. Examples are vacation, breaks, sickness.

3. Valueless Effort – Non-value adding activities masquerading as Valuable Effort, they cost time, money and have an opportunity cost but add no value to the product being delivered.

Waste Reduction is Not Your Goal

I will be covering the wastes in more detail but it is very important that waste reduction is NOT the focus of your efforts,  Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself.  But identifying waste can aid in your efforts to improve your bottleneck so is a great tool to support your other activities.

 

The 7 deadly sins

Lean identifies 7 wastes  (recently adding an 8th Waste)

  1. Overproduction
  2. Inventory
  3. Tranportation
  4. Over-Processing
  5. Waiting
  6. Motion
  7. Defects
  8. Wasted Potential of People

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Overproduction

Overproduction is considered the worst of the wastes and ultimately it is this particular waste that is the basis of much of the Agile Manifesto for Software Development.  Which is why systems thinking is a topic I keep coming back to.

Agile is founded on the premise that at the start of the product we know the least and lack of flexibility is the biggest constraint in the success of software development. Traditional methods plan, create, test and support endless features that were unnecessary, the cost of this waste is unfathomable and big enough to trigger the Agile movement and challenge the way we work.

Overproduction was also the primary waste identified in the book “The Goal” by Eli Goldratt, and if you haven’t read that book I would heartily recommend it. The book is . great primer for the Theory of Constraints and for understanding Lean thinking. 

Planning is Waste?

But Agile has not completely fixed this problem, and in my experience development teams regular and persistently develop unnecessary features.  With many teams choosing to work without sufficient time spent planning; story writing; prioritizing; and without consideration for whether the work they are doing adds any value now or more significantly adds the most value next.

Road mapping, planning and even story writing are often incorrectly perceived as ‘waste’ and the avoidance of waste is used as a justification to get back to coding on something that is likely not valuable and almost certainly not the most valuable activity to be worked on next, which is a far more insidious waste than the planning ever could be .

Features “not needed yet” are implemented on the basis that it will save time later, or features are added because “We know we will need it later” – (7 words I dread to hear.)

We work to look or feel busy, in our minds we translate activity as being productivity when there is little correlation between the two in the context of software development. In software, creativity; problem solving and planning are far more valuable efforts than unfocused coding.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln

In most cases features have no value until they are in the hands of a user and being used for productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.

Writing extra features that are not used or rarely used extends the production time but brings little or no value, it also compounds all of the other wastes because by it’s nature production of something of little value needs to go through the system thus exposing an unnecessary feature to all the other wastes.

When you next start work on something ask yourself: “Is this the next most valuable activity for our customer?” If you cannot confidently answer that question then maybe you need to spend more time planning so you can spend less time coding something that is not needed.

The worst case scenario

In software the biggest risk to any project is that it will be cancelled or obsolete prior to being used by your customers.  This may sound obvious but if a project is cancelled ALL of the features are/were waste. All that effort produced no value for anyone.  That time, effort and money could have been spent elsewhere.  So getting your product right is only any good if you get your product delivered.

Delivering value to your customer quickly is the best way to mitigate the risk of your efforts being wasted, and Done is not really done unless it is in the hands of a customer and actually being used for a productive purpose.

 

Overproduction is a big topic and deserves a little extra focus so I’ll delve deeper into the other wastes another time.

 

 

 

 

Is culture observation or aspiration?

There has been a lot of talk recently about culture and it’s importance when creating organisational identity,  but there are two ways I see for an organisation to create a culture.

A short story…

I was once told a story of how the British and US army engineers take two different approaches to footpath planning when creating their bases.

Flag_-_Union_Flag

The British planned in advance and they laid the footpaths to a defined route and the soldiers were required to follow the specified paths, and were corrected if they didn’t.

71X+wfQBpKL._UX385_

The US engineers on the otherhand would delay laying the footpaths until the base was in use, they would observe the routes taken and where the soldiers walked and would lay the paths when the preferred routes were clear.

The belief (or so I was told) was that people will find the most efficient route on their own.

Each has it’s own merits, and is itself likely a reflection of the culture of those two organisations.

A deliberate culture or a reflective culture

I see this as being very similar to a company’s culture. You have two main choices: either you decide the culture you want, you lay it out and then make decisions that reinforce the path you set. This means hiring practices, rewards, punishments, recognition, and everything in between, you continue to do this until the normal behaviour is to follow the path set.  Your culture is by your design. But to get the culture you want requires a lot of correcting of behaviour until it happens.

Or the alternative is to wait and see, behave the way you behave naturally and the same for the others around you, soon enough a culture will form and it will be a culture that reflects the way you behave. The good news is this is your real culture, the bad news is – this is your real culture.

There are problems with both of these, choosing a deliberate culture that goes against some of your natural tendencies or is unrealistic can lead to it not being followed and the result is that you claim one culture but actually have another, this can be very damaging especially to those that believe in the defined culture.  If you follow the rules but others get ahead by other means it can be corrosive.  A lack of defined culture can also bad as there is no safety check on poor behaviour, left unchecked it quickly becomes the norm and then it becomes your culture, which is the case for women in IT.

Women in Tech

One great example could be seen with Women in Tech, where most companies would say their culture does not set out to exclude or marginalise women, but without a deliberate culture to seek out diversity we have allowed the lack of diversity to become the normal state and for the culture to be one that unintentionally discouraged or excluded women. Often evolving from small companies that have grown by surounding themselves with like minded individuals. Unconsciously biased towards those similar to them.  It will take time and effort and a deliberate culture to break through some of those barriers we have created over the years.

But this is seen in all aspects of an organisation, if your culture tolerates something for long enough, maybe because it is easy to ignore when small, it can become a much larger issue when you grow.  If you are not explicit about the culture you want then you may not be able to shape the culture you have. In larger organisations sub-cultures can form in different areas and this can be even more damaging, without a clear global culture factions develop and the inconsistencies undermine the larger whole.

Agile Transformation

One of the reasons that Agile Transformation is so hard is because it is a culture change rather than a process change, you are defining a new culture and that will not happen overnight. All the previous actions that were normal, the rewards, the metrics the measurements are very hard to undo.  Empowering people to be self-organising when they have only known command and control will take a while to adjust.  I believe this is why so many agile transformations are unsuccessful, some processes are changed but there is no desire or will to change the culture, there is a general wish to change to Agile without actually changing.

The solution

The solution in my opinion is to do a little of both.  Be aware of the culture you want and be explicit about it, shout it from the rooftops, and repeat it and repeat it and repeat it, until everyone in your organisation knows you mean it and you believe in it, be clear where you aspire to be. This will still take a very long time to have impact.

But also be aware of where you are now, the unwritten culture you have now is just as strong and just as real. Be especially aware of the behaviours that your culture currently has that you are not happy about.  If you are honest about your weaknesses and failings you have a far better chance of changing. Seek out and coach those that are not behaving the way you aspire to be, remember they behave that way because it is your culture.

Culture change wont happen overnight but that doesn’t mean you shouldn’t be intollerent of any behaviours that don’t reflect the culture you want.