Tag: Product Owner

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 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.

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.

 

 

Practicing what you preach

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.

roadmap

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.

user-story-mapping

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.

leap faith

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-cycle-Extended

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.

 

If I were a painter, I…

Recently I have spent a lot of time talking about story writing, but this week the focus has been on Acceptance Criteria and there have been a variety of comments that have caused me to reflect and have caused me some concern.
Some examples:

  • Unless stated otherwise a story is assumed to be happy path only. If it isn’t in the Acceptance Criteria we don’t have to do it.
    • Acceptance Criteria must contain all details including all edge cases that must be tested, anything not stated doesn’t have to be implemented.
  • If all acceptance criteria are met the PO/Customer MUST accept the story even if they are not satisfied.
  • If acceptance criteria change before the story is done, it should be completed as specified and a new story should be created for the changes. after all, late changes to Acceptance Criteria demoralize Developers.
  • If Acceptance Criteria are unclear we can choose what to do.
  • The Acceptance Criteria should never tell us how to do the job.

A metaphor

To respond to these questions I thought I would use a metaphor – A homeowner wanting to redecorate her house.

img_0374

The home owner hires a firm of decorators because they have a reputation for quality.

Her first request is that the painter decorate the sitting room,  She would like the walls painted blue, the ceiling an off-white, the windows also off-white but the paint needs to be wipe-able to avoid finger prints, and the doors and trim should match the window color.

A story is an expression of a need

Acceptance Criteria are the notes from the discussion to help clarify the need

In this case the homeowner has specified a number of acceptance criteria:

  • Walls – blue
  • Ceiling off-white
  • Windows off-white but wipe-able paint
  • Trim same as windows

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner – in this case the home owner.

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner

The job can and probably should be broken down into smaller tasks (stories). Having just the windows painted has value, just the ceiling does too, just the trim and potentially each wall independently may have value although that may be harder to qualify with the Product Owner, depending on their needs.

Detail in Acceptance Criteria

What you will note though is that the acceptance criteria did not state that the areas to be painted must be professionally prepared and sanded, that a primer coat be applied and two top coats are applied.  They do not state that the carpets should be protected and that spills should be cleaned up and that there should be no paint on the glass and no wall paint on the ceiling, no ceiling paint on the walls or that the paint should fully cover the walls and be an even drip free finish.  In fact the Acceptance criteria make no mention of how the work should be completed at all.

Who is the audience of your Acceptance Criteria?

The Acceptance Criteria come from a conversation with the Product Owner, but you may also want to take technical notes from conversations with those that will do the work. E.g. if the contractor has an apprentice, it may be necessary to spell out to him/her the technical details mentioned above, what seems common sense to you and the Product Owner may not be as obvious to someone less experienced. But notes on implementation are not acceptance criteria in the same sense. The product Owner should not be expected to understand all the technical details, what is acceptable is always determined by the Product Owner.

If quality is not specified in the acceptance criteria

But that means I only need to worry about the happy path right? So I need to do a good job with the specified work but I don’t need to care about drips or mess or if I am painting the walls I don’t need to care about the ceiling after all I am only doing the happy path. I can ignore walls that are hidden behind furniture, I can do the job quicker if I don’t put down dust sheets and we can worry about cleaning up the mess later right?

Put like that it sounds silly doesn’t it, but that  is what you are suggesting if you don’t consider anything other than the happy path, the minimal amount is done but you are leaving a mess to clean up later.  If this is clearly understood and acceptable to the customer or that you have split a story like this to get feedback sooner there may be an exception but if you think that you can declare a story ‘done’ with a mess left to clear up later it is a recipe for a disappointed customer or a misleading impression that you have achieved more than you really have. Giving a sense of artificial progress may lead to disappointment later.

img_0376

Acceptance Criteria are comprehensive and exhaustive

If all acceptance criteria are met the PO/homeowner MUST accept the story even if the homeowner is not satisfied.   There is some crown moulding between the walls and the ceiling, it was not mentioned in the Acceptance Criteria and the decorator has painted it the wall colour, but the Home owner wanted it the same as the ceiling and thought it was obvious so had not mentioned it.  The decorator insists the job is done because the Acceptance Criteria are met.

This is actually a very common issue, Acceptance Criteria are often not comprehensive and there are ambiguities and omissions, so how do you handle them?  Assuming you are paying for the work on a time an materials basis the customer is the one that suffers, they will have to pay for the rework(or extra work), but it is generally the workman that gets frustrated, they believed they did a good job and so it is frustrating to have to repeat good work.   But the customer is not satisfied, and that should be the only thing that matters. Your goal as a quality workman is to satisfy your customer.  The job is not done until they are satisfied (assuming the request is reasonable)

It might be that the customer is willing to accept the work as it stands and agree to the repainting later. But more likely they will want it fixed before you move on to the next piece of work.

What is not acceptable is to refuse to make the changes because they were not explicit in the Acceptance Criteria.  The story card is an invitation to a conversation, the Acceptance Criteria are reminders of what has been discussed. At no point do Acceptance Criteria or the card become a sealed contract.

img_0373

Changes during a story

The painter is half way through painting the window and the Customer comes to check on progress. She sees the paint colour of the windows and decides it is too white, too stark and clinical and would like the colour changed to an off-white.  She understands that the rework will cost and the new materials will cost and she accepts this, but she is unhappy with the colour.

The painter responds: “But the thing is the A/C were clear about the colour, the shade was specified, I have spent a long time getting through the first half of this job and it is only fair that I finish it according to the A/C”  Then we can have a separate job to repaint it a different colour.  Frankly my metrics will look bad if this job takes 50% longer, it will look like I am slow. Do you know how frustrating it is to do a job and have it rejected..”

I have heard frequently how when a PO changes A/C the story should be completed as it is and a new story created for the revisions.  But any continuation on work that is not wanted is waste. The notion of continuing to work on something that is unwanted, and even worse billing the customer for that time, is just wrong.  If metrics are driving bad behaviour then the metrics are failing. If someone is demoralized because a PO has clarified their needs then they need to evaluate their understanding of Agile.   A full half of the Manifesto is:

Customer collaboration over contract negotiation
Responding to change over following a plan

If you are unwilling to accept and adapt to changes in A/C even late into development, then you really need to go back to basics and ask if you genuinely support Agile software development.  I am sorry if that sounds harsh but the notion that keeping devs happy and metrics pretty is more important than delivering the right thing for your customer is very frustrating for me to hear.

 If Acceptance Criteria are unclear we can choose what to do.

The homeowner has been pretty vague in her choice of colours, blue and off-white. So presumably we can choose whatever we want?

Clearly that is unrealistic.  What might be more reasonable would be to talk to the homeowner and say “We prefer this brand and type of paint and these are the available colours within that range can you pick one”   The homeowner may say, No I want a very specific Blue only available in this brand that needs to be imported from New Zealand.  In which case you should explain that such a choice will increase the cost and duration of the job and adds to the risk – being an unfamiliar material, it may need more coats etc.  If the homeowner understands and accepts those risks then it should be done, but if the homeowner can be presented with a less costly and less risky alternative then they may be willing to modify their request.

Ambiguity should trigger conversation it should not be an excuse for making assumptions.

Ambiguity should trigger conversation it should not be an excuse for making assumptions. The goal is a finish that the homeowner is happy with, the specifics are likely open to negotiation. But whilst you may present alternatives it is for the homeowner to make the decision.

Anything not stated doesn’t have to be done

There are two types of things not stated in the Acceptance Criteria that apply here, how we do the job and some of the specifics.

How: The Acceptance Criteria doesn’t explicitly say that we need a primer coat, but we know that for a quality job it needs to be done. The Acceptance Criteria doesn’t tell us which brushes to use, or how to paint to get a good neat coverage. The contractor may need to specify those to an apprentice, but the homeowner should not need to specify the tools to be used or how to do the job (unless that forms a particular part of the need)  You as the contractor may need to spell out those details to your apprentice, consider those sub-tasks of the story.  Prepare and protect work area; Sand surface, apply primer, apply first coat,  apply 2nd coat, clean up area, clean brushes etc.  But these are NOT Acceptance Criteria to be supplied by the home owner. They are about how to do the job not about the job that needs to be done. Sometimes these do overlap but generally we try to keep the how out of the request.

There are also some specifics that may not be mentioned, for example there is a recess around the fireplace but only 4 walls were mentioned.  Can I ignore the other surfaces?  Likely not, details may have been assumed, if there is doubt clarify with the homeowner. There is something fixed to the wall which is too close to be painted behind, but if not painted it would look odd. The Acceptance Criteria shouldn’t need to specify that you need to remove it and paint behind to do a good job. But again if there is any doubt clarify it with the homeowner.  The Acceptance Criteria will rarely be comprehensive and conversation will be necessary.

Specifics: The Acceptance Criteria should not specify how the job must be done

Normally we try not to specify how the job must be done, but there will be exceptions to this. The homeowner may have a need to decorate using traditional materials, and so may specify that particular tools are used – e.g. No power tools, no lead based paint. No synthetic materials in paint or tools.  Sometimes those requirements are not necessarily clear to you. The Customer may insist on 2 primer coats and 3 top coats.  Two more coats than you feel is necessary for a quality finish, but they insist are how the job should be done.  In those instances you may make recommendations or suggestions, and try to understand why they feel this is a requirement. But ultimately it is for them to decide – so long as they understand the additional cost and risk.

But again there are exceptions to this, for example the customer my request that you skip a primer coat and only apply a single top coat, or insists that you use low quality materials to save on cost. If you believe that this will result in a substandard job, then again you should explain your reasons and try to find an alternative and if necessary refuse to accept the job if you feel that the result would reflect badly on you.  Ideally it should be clear from the start what the expectations around quality of service are, but it may be necessary to re-clarify periodically if there is doubt.

Summary

  • In story terms, the story should express the need, what your goal is. It is the start of the conversation(not the end) for assessing how to satisfy that need.
  • The Acceptance criteria are simply notes to help remember that conversation, they do not form a contract.
  • Acceptance Criteria should never be considered absolute, immutable or comprehensive.  Uncertainty should be clarified with the Product Owner early and often.
  • You should respond to changes in Acceptance Criteria quickly, the quicker you respond the less waste there will be.
  • Acceptance Criteria do not normally express how to do the job, although you may note how you intend to do the job to illustrate to the PO to help clarify any ambiguities.

What about Gherkin?

You can’t have a discussion on Acceptance Criteria without mentioning Gherkin, Gherkin is simply a tool for expressing Acceptance Criteria in a standardised and hopefully clearer format. However, Acceptance Criteria Gherkin and Test scenario Gherkin are very often confused, and the Gherkin constraint may result in the focus shifting from the conversation about the user’s need, to how to use Gherkin and the user’s need may get lost.

Story Acceptance Criteria is also not the place for identifying all of the test scenarios and edge cases, it is about understanding the need of the customer.

Another common issue with Gherkin is that the precise nature of the format and terms implies that the Acceptance Criteria are absolute and non-negotiable which is the exact opposite of how they should be considered.  If you start to fall in to the trap of seeing the Gherkin as a contract (rather than notes on a conversation) then stop using it until you get in the habit of regular conversation with the Product Owner.

By all means practice with Gherkin until you get better, but if you remember that it is about capturing notes from a conversation with the PO and most certainly NOT negotiating the terms of a contract then it is a useful tool.  But personally I prefer not to use Gherkin in the initial conversations about Acceptance Criteria simply because it is not a natural way of thinking for many POs so the format constrains thinking and conversation and the frequency in which it is treated as an explicit contract undermines it’s value.   Once you have discussed the Acceptance Criteria converting them to Gherkin may be beneficial.

However, I prefer to see Gherkin used for Acceptance Testing where those writing the tests are familiar with the syntax and where precision is more important.
If you take nothing else from this, please remember that Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

It’s my way or the highway…

The last few months have been pretty busy for me and so I have dropped out of the online community for a while. Over the Christmas break I had some free time and so I ventured back in, caught up on some reading and tried to get a feel for the common issues of the day.

What I found was post after post condemning just about all things ‘Agile’    

“Ban the use of Story points”

“Agile is dead”

“Scrum/KanBan should be sent to the scrap heap”

“We don’t need: Scrum Master/Product Owner/Agile Coach/QA” 

There were some even suggesting that Agile had run it’s course and we should go back to Waterfall.

I found all this very disheartening, on one hand most of these were from people presenting a new idea or new techniques, and it is sad to say but in our culture it seems the only way we seem to know how to sell something is by presenting everything else as bad or with Click Bait statements, we all want to get noticed.  But when did ‘Agile’ become so black and white?

For me Agile has always been first and foremost about inspecting and improving – finding better ways.  But that doesn’t automatically make anything that differs from your approach Bad.  And it certainly doesn’t make everything New to be Good.

There is not one Right Way.

In almost every case the examples/justifications were examples of poor implementations of Scrum/Kanban; incorrect use of Story Points; or a person being ineffective in a role, or in some cases there were teams that had matured to a point where they were no longer getting benefit from a tool or a role.

But not one of those examples makes the tool or the role Bad.   In each and every case the team should inspect and adapt, and identify improvements.  If one team decides that Story Points do not add value for them, that is great, that team has found a better way that they can deliver software.

But that doesn’t mean that other teams that find them effective are automatically doing it wrong. If you find you can use a tool effectively and it works for you, then use it. Just keep inspecting and improving.  If a tool doesn’t work for you or you find an alternative tool that works that is great too. But try to understand why you are using a tool, what is your desired outcome and is there a better way for you.

As an anecdote, I was using a drill to make holes to hang shelves, I carefully marked and measured and then drilled. A friend was with me and he picked up a cross-head screwdriver lined it up on the wall and hit it hard, punching a hole in the plasterboard wall, far quicker than I was doing with the drill.  The technique was great for him in that situation, but when faced with wood or brick it was not suitable, and in both cases I still needed to measure and mark.  

Tools are context AND user specific, what works for one user in one situation does not automatically work for all users in all situations.

The same goes for the roles argument, I agree that there are some teams that have the versatility, the right mix of people and the capability to work effectively without one or all of the roles, but that doesn’t mean they are an ideal we should all strive for. Many teams find they are far more effective with those roles, and I would consider that to be just as much an ideal state as the other. If your team is effective and improving then you are demonstrating an Agile mindset.  Our goal should be to improve how we deliver software, not strive for someone else’s idea of utopia. Concentrate on improving YOUR team rather than mimicking another team in a different situation.

Declaring your way the only way is not demonstrating an Agile Mindset.

Explain the benefits, do not attack the alternatives

If you find a way that you feel works well and you want to share it, then explain what problem it solved and why you felt it improved the way your team worked, share that example, but please don’t do so by declaring all other tools WRONG.  What is right for you may not be right for everyone. You will just sound like a Snake Oil salesman.

Don’t reinvent the wheel

Having said all that we don’t need to reinvent the wheel and discover everything ourselves. We can benefit from other people’s experience and advice.

Both Scrum and Kanban and any of the tools mentioned can be badly applied, but when implemented with the guidance of someone with a genuine Agile Mindset (rather than a blind by the book interpretation) they can be excellent foundations from which you can evolve, by inspecting and improving, they are not the end point but a safe and structured starting point.

The same applies to the named roles, having someone with an Agile Mindset that can help create a foundation of understanding of the roles and when and where they add value can provide a structure and consistency that allows you to grow from a starting point that has proven to be effective for many.

Do not stand still.

But most of all, whether it be Story Points or the need for a QA, inspect regularly, assess what problem you are trying to solve in terms of outcomes, if you feel a change will show improvement then experiment and review.  Small changes are generally preferred, it is easier to see the impact and easier to undo if the results are not what was expected. Understand what you are changing and why so that you can properly assess whether the change was beneficial.

I have seen teams conclude a Scrum Master/QA/Product Owner is not necessary after all they can cover the role themselves (usually as the result of cost saving measures or because they are presented with a false notion that good teams don’t need help). Sometimes this works, but more often the responsibilities are performed less effectively when distributed among the team and so the net result is a reduction in the effectiveness of the team.

There are certain expertise and mindsets that often come with a role that is not fully appreciated until it is gone. This generally and understandably gets neglected when it isn’t the core responsibility of the team members.

Let the team decide

If a team feels they need a change I’d have far more confidence than if the decision was made by someone with little or no exposure to the team, or on the back of reading a blog suggesting “good teams don’t use Scrum Masters/Story Points/Scrum/etc.”

Agile Transition Frustrations

On the back of my good day last week, I have run in to a somewhat frustrating day today.

I have taken it upon myself to challenge the adoption of Agile in the organisation, it has been over 18 months since they adopted Scrum, and there are currently 7 Scrum teams each with a Product owner and there are 3 Scrum Masters and an Agile Coach/Scrum Master.  Sounds great! except that not one of those 11 roles have a job title to match.

In every case someone is ‘acting …’ – they are seconded from another role.  In most organisations that wouldn’t be a problem, you could be pretty flexible, temporarily at least. But in the Civil Service a job description and responsibilities are a big deal, every 6 months there is an appraisal of your work where you are measured on objectives that are constructed based on your job description and designated roles and responsibilities of that job, so unfortunately those in the roles of PO and SM are struggling to meet any of their objectives, not to mention a lack of support and backup as those more senior in the organisation are not familiar enough to formally provide it.  So it is being provided informally by those that are enthusiastic about agile.

So I decided that the time had come and I wanted to press it with HR, I want to create formal roles to reflect the work being done, to allow those interested to be able to apply and those doing the roles to be recognised and rewarded. And then finally I wanted to ensure there was a support network in place. (I could be biting off more than I could chew)

But today I met with two people – one responsible for organising the support network and one from HR, the lady from HR was fantastic, all you could ask for from an HR rep, she seemed genuinely concerned about the people, about ensuring they got the support and had career options and had clarification of their roles and responsibilities. But the support network guy… Now I don’t know if he misunderstood my request, or whether he was irritated by agile or what the situation was, but I felt I was on the back foot, he suggested that ‘some agile advocates’ were so zealous in their agile application that they created a rigid process worse than the ‘traditional’ approach. He seemed to suggest that as agile had no process that formal support was unnecessary, and he then spoke for a while about how the process was not understood, followed or even liked by the organisation, and I must confess at this point I wasn’t sure if he was talking about agile or the professional support network he was responsible for.

I felt very deflated, I really thought I would be pushing on an open door, this was someone (me) wanting to utilise their expertise and help make the system work by making it relevant to those doing the job and I was being criticised for not being ‘agile’  I found myself questioning what I was doing. Was I being un-agile? Was I imposing structure and regulation?

In the end the HR rep concluded very diplomatically that we were not ready for him yet and we would re-convene again without him – phew. But it still made me stop and think, was I doing the right thing?

So I have spent this evening thinking a lot about it, and on reflection I put it down to a belief that agile means no formal process. This is clearly wrong on a number of levels, but in the Civil Service it would be an impossible situation, formal process is so ingrained that you need a very formal process to not have a process.

The agile principle is that we favour “Individuals and interactions” over “processes and tools”. But that is not the same as saying we don’t believe in processes. I believe that the people are crucial and that providing structure, support, training and opportunities is very much the agile way, and if I need a process to do that so be it.  What is un-agile is to not provide these vital people support because a process gets in the way – which is the current situation.

Sometimes being challenged in your thinking really helps clarify understanding, and whilst I left the meeting frustrated I am now very pleased I had that conversation, I feel more certain than ever that it is both right and necessary for me to challenge this situation, and keep the focus on the people. 

Agile in action

For the most part it was a pretty normal sprint, the team read and refined the stories, asked questions and clarified the requirements. One of the stories referred to a text editor where text would be cut and pasted. There were questions about formatting and content and the PO was sure that maintaining formatting was not required and that the text would be standard text.

The team worked through the story and completed all acceptance criteria and everyone was happy, except one of the development team who felt an urge to work closely with the users and get actual examples of the text they used and how they worked. It turned out that one of the source documents was non-standard in the sense that the text editor selected was not able to cope with the source data, when pasted critical characters were lost.  We investigated further, and it also turned out that formatting and layout were also very important to the users in some situations, something not fully understood at analysis.

The team, the PO and the BA worked together, they all got involved and came up with a solution, and we have written a new story to be included in the next sprint, which means a slight delay in functionality being released to the users but as an observer to this incident I was very proud of how agile the team behaved and how smoothly we adjusted to what was in effect a significant blow to the initial design.

That may not sound a big-deal but if you consider that had we not challenged the requirements, had we not had open and effective communication with the Product Owner and the users, had we implemented requirements as written we would have been able to sign-off the work and likely get all the way to release and delivery to the users – weeks if not months later before this problem was identified, by which time the cost to resolve would have been considerable and the disruption to all would have been significant.

This is a great example of where agile can be a great tool.  A situation where the team made customer collaboration a priority over contract negotiation, and responded to a change rather than adhering to a plan.   Sometimes I worry that the benefits of agile get lost, but on days like today I feel like agile really has made a difference.  I feel immensely pleased with the team.

Product Owner Role – Overview

I have been asked to give a summary introduction of the responsibilities of the product owner role to a budding Product Owner.  They are due to go on a training course in around six-weeks so this is much more of a high level introduction to the expectations of the role.

Product Owner Overview

I began by outlining some of the core expectation of the role, the delivery expectations and the importance of the role in the process.

But the crucial and generally time consuming aspect of the role is the co-ordination, interaction and management of the stakeholders.

Product Owner Stakeholders

The Product Owner is one of the hardest roles in Scrum, being lobbied by users, the business, the team and others.  Giving time to users to properly understand requirements, understanding the goal and vision of the project/product. Identifying priorities. Being available to the team. Making decisions and all the while knowing you are the single wring-able neck, the one person responsible for the success of the project.

The Product Owner is involved in writing stories, planning releases, setting the product vision, the sprint goals and constantly ensuring that the backlog is up to date and prioritised.

It is not for the feint of heart.