I have been very fond of Scrum and a strong advocate for it since my first introduction to it about 12 years ago. But in recent years I have not been exposed to it so much, my current organization favors more of a Kanban approach to software delivery.
However, this last few months I have been working with a new client who is using Scrum. I was invited to join their Scrum training this last week. And Oh my! As I was listening this quote sprang to mind.
“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair.”
Charles Dickens
This is where I get confused. I would appreciate comments from my friends in the Scrum community to help me rationalize whether I have drifted from the Scrum mindset or if I simply got exposed to an example of a dogmatic interpretation of Scrum.
The Daily Scrum
The trainer was talking about the Daily Scrum and how to keep it short. She suggested that – paraphrasing a little “the product owner being there was not only optional, but undesirable. The Product Owner being there encourages questions and conversation. Conversation and questions are bad, and a reflection that the Sprint planning was not comprehensive enough. If there is ambiguity in a story or the need for a question we should learn to get better at our planning.”
I was a little in shock. My advice is generally the complete opposite, that conversation is good, it is desirable and should be encouraged. I encourage the PO to be with the team all the time for questions. I will often encourage teams which have good interactions with the Product Owner to reduce the detail in stories and rely on the conversation more, for me it is the outcome that matters and not perfect planning. Over the years I have correlated the amount of text on the story card to inversely be a measure of the maturity of the team. (assuming they are producing value)
I was dying to jump in and disagree, but this was someone else’s training and I was there as a guest. But I did begin to question whether what was being said was a misinterpretation or have I misinterpreted and my move away from Scrum has resulted in practices which conflict with the Scrum philosophy.
The agile mindset
On the flip side and the other side of that quote I began with… I was on the training with the Product Owner from the team I am currently working with and I was astonished at how quickly he has grasped an agile mindset and how comfortably he has taken to thinking in an agile way. It took me a lot of time and effort to achieve the comfort level he is at. We have been planning an MVP and he has been simply brilliant, the conversation is about balancing value and necessity and it is impressive how easy it has been to navigate the usual pitfalls. Sometimes you get really lucky with your team, and the job is so much easier when there is an agile mindset at play.
I’d love to hear your thoughts on the Scrum question, let me know…
I am a very lucky person, I have my dream job. I work for a huge Solutions Provider as a member of their software consultancy group. The consultancy group has multiple physical offices in the St Louis area, and offices in Denver, New York and London. we have now decided to expand into the virtual space and launch a Virtual Office dedicated to collaborative software delivery. My role is to create this office, define the tools, practices, processes and then to build the team: hiring and supporting the staff and managing and growing the office. It is an incredible opportunity and it is not overstating to say that I wake up excited (and daunted) about it every day.
I wrote a while ago about the new role and about the challenge of remaining true to an Agile mindset. My goal was not to lose our agility as we became separated by technology and tools. https://yorkesoftware.com/2018/10/11/a-3-pipe-problem/
It was a surprise to discover that with the right attitudes and the right tools we are actually able to enhance our agility. We are actually more agile in a virtual space than we were in the physical space.
What is Agility?
To many this will sound like an exaggeration, but as a consultancy firm we sometimes operate in a less than optimal situation, there are challenges when you are working in a slightly abstracted situation. To be truly ‘Agile’ the goal is generally to get the team and business working together and to shorten feedback loops, deliver software quickly. But the reality is that ‘the business’ is a client. They are removed often physically which is bad enough but often they have other priorities and so are removed in an availability sense too. So whilst our teams are together, it is rare that we get the business (SMEs and Product Owners) on site and embedded with our team, when we can this is the ideal situation.
More often we get together for project kick-offs and planning and regularly for demos and retros. But stand-ups are often conducted via web conferencing tools, as are story writing and weekly planning/prioritization meetings. This puts a barrier between the team and the business, we do our best to break down these barriers but the reality is that they exist.
I call out being a consultancy as it is an extreme case but it also happens in most businesses, the PO and SMEs generally have another job and other priorities and the development team gets a slice of time and attention, so this is not unique to consultancy.
Brave New World
So understandably I went into this new venture with the expectation of doing my best to mitigate an already existing problem and to strive to not let it be worse in a Virtual Team.
In the early stages we found a tool called Sococo which is very hard to describe as technically it offers the same as many other remote communication tools, but it uses the metaphor of a physical office to make it easy for us to relate to the situation. When we used this tool something quite amazing happened, suddenly we were in the same metaphoric space as ‘the business’, we were truly working together. If I had a question for the PO I can drop by their office. If we need clarification from a SME we can invite them to join an Ad-hoc meeting.
We were no longer waiting for scheduled meetings to ask questions, we were chatting immediately. Feedback loops became immediate conversations, if someone was busy they would drop in between calls or other meetings rather than scheduling something formal. The casual nature of the metaphor brought us all together. This is how I imagined agile teams should behave in an office, but all too often logistics (read lack of meeting rooms) meant this was rarely a reality.
As a little tangent I worked with a delivery team a few years ago where the PO was available to the team all day but was in an office maybe a 60 second walk away. She made it clear the team could drop by or call her. But they never did. As an experiment I asked her to sit at a desk in the team area, immediately the team was a buzz of questions and conversation, we worked faster and discussions were spontaneous and relevant to the work at hand. This is how Sococo feels now. I can’t express how excited I am about it.
Daily Demos
An interesting thing has happened too, the team had an aspirational goal of daily demos, demonstrating completed stories and getting feedback on direction each day at stand-up. The aim was to challenge the team to keep stories small and to focus on shortening the feedback loop.
What happened instead was the realization that you don’t need to wait for stand-up. When a story was done the team would pull everyone together immediately get feedback and then discuss and plan what was next.
We realized that scheduled meetings for everything from story writing to stand-ups were primarily about availability of people and especially meeting rooms, they had little to do with the product or agility. When not restricted by availability of meeting rooms you can simply talk about what is needed when you need to. It is so liberating. Naturally such a change requires a great deal of discipline to be effective but you have the potential to be focused on the shortest feedback loop, and reacting immediately.
By moving to a virtual environment we are becoming more agile than we were even together in the office, and having fun doing it. These may not sound like ground breaking discoveries but I can assure you they are having a profound impact on our work.
For those interested in joining future meet-ups, we are open to all. The group is aimed at those interested in Agile and in particular the Product Ownership aspects of it.
Agile Product Ownership St. Louis
Monday, Feb 11, 2019, 6:00 PM
World Wide Technology 701 Fee Fee Road Maryland Heights, MO
19 Members Went
Chase Clettenberg and Liz Gattra will be giving a talk on Story Writing, What makes a good user story. Lightning talk and then if we have time a general Q&A Please join us: 6:00-6:15 Meet and Greet 6:15-6:30 Lightning talk! 6:30-7:15 Q&A / Discussion
Topics are varied and not always limited to Agile as was the case this evening where we explored Lean thinking and how it applied to software delivery.
Remote attendance
For those unable to attend in person we are now offering remote attendance via Webex.
We meet on the second Monday of each month. We hope to see you at the next meetup.
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.
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 stood next to his ‘Faster Horse’
If I had asked people what they wanted, they 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.
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.
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!
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.
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.
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.
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.
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?
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.
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.
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.
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
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.
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.
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
For this blog post I’d like to make a change from my usual style and share a personal experience.
For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.
It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .
Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.
Jack Handey
It’ll be easy he said…
Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas; I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.
We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.
As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.
Delivery Pipeline
The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in. I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.
There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.
I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.
Challenges
The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.
Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.
This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.
Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.
DevOps
I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.
I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me. But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.
I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.
This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.
It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.
I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.
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.
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:
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.
The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on whatwe are doing both in our work and in our product, and far too little on why we are doing it.
Failing to understand the why
The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.
There is nothing so useless as doing efficiently that which should not be done at all.
Dr Peter F. Drucker
Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice
We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?
The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value. It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.
Refactoring gets sacrificed when throughput is the priority.
Stories focus on the what not the why.
We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’ rather than actually asking why or giving it proper thought and effort into understanding the real why.
Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods. We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.
It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.
Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.
Taking a little while to do it right could well pay dividends. Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.
Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery. Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.
The customer should be your focus
Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.
When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.
UX is an afterthought
When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX. The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.
The goal of a story is NOT to minimize development Effort, it is to maximize customer Value
A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.
A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer. If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome. Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.
Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.
Acceptance Criteria is a substitute for thinking and conversation
We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.
Being busy is not your goal
It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all. Keeping you busy is not the goal, delivering the best product to the customer is.
John Yorke 