Blog

What Product Owners should not do

Noproductowners-2018-04-18-11-27.jpg

Last time I set out some of the things a Product Owner should be doing – or at least considering doing. Even a quick look at that list will tell you the Product Owner is going to be a busy person.

So in this post I’d like to suggest some thinigs Product Owners should NOT be doing.

Product Owners Cutting code should NOT be cutting code

Having a former coder in the Product Owner role can be a great boom. Not only do they know how to talk with the technical team and (hopefully) can command their respect but they can also see how technology can apply.

But to be an effective Product Owner they need to step away from the keyboard and stop writing code.

Two reasons.

One: time.
Product Owners add value by ensuring that the code which is written addresses the most valuable opportunities with the smallest, most elegant, delightful way possible.

Every minute spent coding is a minute not doing that.

Second: Product Owners need to empathise with the customer, with the business users, they need to eat-sleep-and-breath customers.

Being a good coder – let alone someone called an architect – is to empathise with code, the system, the mechanics of how a system works.

Importantly both requirements and code need to be able to come together and discuss what they see and find a way to bring the two – sometimes opposing – views together. It is a lot easier to have that discussion if the two sides are represented by different people.

Asking one person to divide their brain in two and discuss opposing views with themselves is unlikely to bring about the best result and is probably a recipe for confusion and stress.

Thats not to say both sides shouldn’t appreciate the other. I said before, former coders have a great advantage in being a Product Owner. And I want the technical team to meet customers. But I want discussions to be between two (or more) people.

(I might allow an exception here for Minimally Viable Teams but once the team moves beyond the MVT stage the PO should stop coding.)

Product Owners should NOT be line managers

OK, senior Product Owners should might line manage junior product owners but they certainly should not be line managing anyone else. Most certainly they should not be line managing the technical team.

Product Owner authority comes not from a line on an organization chart, or the ability to award (or deny) a pay rise or bonus. Product Owner authority stems from their specialist knowledge of what customers want from a product and what the organization considers valuable.

If the Product Owner cannot demonstrate their specialist knowledge in this way then either they should learn fast or they should consider if they are in the right role.

Product Owners need to trust the technical team and the technical team need to trust the Product Owner. Authority complicates this relationship because one side is allowed to issue orders when trust is absent and the other side has to obey.

And again, Product Owner simply don’t have the time to line manage anyone.

Being a good line manager requires empathy with employees and time to spend observing and talking to employees, helping them develop themselves, helping them with problems and so on.

Product Owners should not Make Promises for Other People to keep

Specifically that means they should not issue “Roadmaps” which list features with delivery dates based on effort estimates. The whole issue of estimation is a minefield, very few teams are in a position to estimate accurately and most humans are atrocious at time estimation anyway. So any plans based on effort estimation are a fantasy anyway. But even putting that to one side…

Issuing such plans commits other people to keep promises. That is just unfair.

Product Owners can create and share scenario plans about how the product – and world – might unfold in the future.

Product Owners can co-create and share capacity plans which should how an organization intends (strategically) to allocate resources. And Product Owners can work with teams in executing against those capacity plans in order to deliver functionality the Product Owner thinks should be delivered by a date the Product Owner thinks is necessary.

In other words: provided a Product Owner is making the promise that they intend to keep themselves (i.e. they have skin in the game) then they might issue some kind of forward plan.

Product Owners should dump outbound marketing at the first opportunity

Outbound marketing, e.g. advertising, press releases, public relations and product evangelism, often ends up on the Product Owner plate – particularly when the Product Owner is a Product Manager. And in a small company (think early stage start-up) this just needs to be accepted.

However, in a larger organization, or a growing start-up, Product Owners should seek to pass this work to a dedicated Product Marketing specialist as soon as possible. Both roles deserve enough time to do the job properly.

The Marketing Specialist and Product Owner will work closely together – they are after all two sides of the same coin, the Marketing coin. The Marketing Specialist handles outbound marketing (telling people about the product) and the Product Owner handles inbound marketing (what do people want from the product?). (Again, in organizations with established Product Management this is usually easier to see.)

Product Owners should dump pre-sales at the first opportunity

As with outbound marketing Product Owners often get dragged in as pre-sales support to account managers. And again this is more common in small companies and early stage start-ups.

There are some advantages to playing second fiddle to a sales person. The Product Owner might get actual customer contact (sales people too often block Product people from meeting customers.) And Product Owners should be exposed to some of the commercial pressures that sales people – and customers – encounter.

But doing pre-sales is very time consuming. And being wheeled in to help deliver a sales will distort the Product Owner’s view of the market – just ‘cos this customer wants the product in Orange doesn’t mean other customers want Orange.

And again, pre-sales is more effectively done by specialist staff as soon as the company can afford them.

Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development

Busy busy busy: What Product Owners do

HeadacheiStock_000014496990Small-2018-04-10-10-18.jpg

If you hadn’t noticed I’m building a blog mini-series on the Product Owner role. Its a role I’ve long felt didn’t get the attention it should have. Frankly, in a Scrum setting, I think the Scrum Master gets too much attention and the Product Owner not enough.

One aspect in particular of the Product Owner role really annoys me: they have so much work to do.

Or rather, a Product Owners who is doing their job properly – as opposed to simply administering the backlog – has so many things they should potentially be doing.

So a few days ago I started to make a list…

Backlog administration: writing stories, reviewing and discussing suggested stories, splitting stories, weeding the backlog (throwing stories away), improving stories, putting value on stories, writing acceptance criteria

Working with the team: talking to the stories, reviewing work in progress, reviewing “completed” work, potentially signing-off or formally accepting stories, participating in 3-Amigos meetings with testers and developers, helping to improve the development processes

UXD: working even more closely with an UXD specialists because the two roles overlap, and possibly substituting for UXD specialists where they are absent.

Meetings: prioritisation pre-planning meeting, planning meeting themselves, stand-up meetings, retrospectives, show & tell demonstrations (potentially delivering them the show & tell themselves)

Interfacing to the wider organization: reporting and listening to internal stakeholders in authority, attending Governance and/or Portfolio review meetings, aligning product strategy and plans with company strategy and plans, plus feeding back to company strategy about their own product strategy and plans.

Planning: participating in Sprint planning with the team, planning for upcoming iterations (the rolling quarter plan as I like to call it), longer term planning which might take the form of a roadmap, a capacity plan, a scenario plan or all three

Customers 1: identifying customers and potential customer, segmenting the customer base, creating customer profiles and personas.

Customers 2: visiting customers, observing customers, talking to customers about stories and potential future work, reflecting on customer comments and feeding back to the team and other stakeholders.

Customers 3: similar activities to #2 for people and organizations who are not currently customer but who are potential customers (because potential customers who have unmet needs represent growth.)

I’m sure some of you are saying: “But we don’t have external customers, we have internal (captive) users”. And your right, if you have such “customers” then you have a subset of these activities. But then again, shouldn’t you be thinking about how our product is used by internal users to service the needs of external customers? And how you could improve that experience (for the customers) and improve the process (for the users?)

Marketing: inbound marketing the items just mentioned under customers plus market scanning (checking out the competitors) and potentially outbound marketing (advertising, PR, trade shows, etc.)

Sharing expert knowledge: providing knowledge about the domain and subject of development to the development team, supporting sales calls, demonstrating the product at shows. (And when the company is small helping the training and support teams.)

The offering: using the information gained in all these activities to refine the product/service offering to satisfy customers or improve business processes; Is it the right offering? Are you targeting the right customer segment? Should you be offering something else?

Close the loop: evaluating the effect on customers and/or process: Are the features bing used? Are non-feature improvements making a difference? What shouldn’t have been done? What arises form the changes that have been made? More software changes? Process changes?

Money: is all this making money? if the continued existence of the team positive to ROI?

Coincidentally, while I was preparing this blog Marty Cagan published a blog entitled “CEO of the Product Revisited” in which he discussed offered a list of all the discussions a Product Manager can expect to be involved with. That is no short list either. And as anyone who follows my writing already knows I see the Product Owner role as a kind-of Product Manager – more on that in a future blog.

This is not to say that all Product Owners should be doing all of these things. Asking one person to take all this on is probably setting them up to fail. Every product owner should recognise every item on this list. If they aren’t doing any of these items themselves then I expect they can either cross it off (doesn’t need doing where they work), or name the person who is doing it.

And I also expect every product owner can add some things to this list which I have overlooked.

In future blog posts I intend to discuss (again) the Product Owner as a Product Manager and how Product Owners can reduce their work load.

Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development

Product Owner or Backlog Administrator?

3337233_thumbnail-2018-03-20-18-08.jpg

In the official guides all Product Owners are equal. One size fits all.

In the world I live in some Product Owners are more equal than others and one size does not fit all.

The key variable here is the amount of Authority a Product Owner has. In my last post I said that Authority is one of the four things every product owner needs – the others being legitimacy, skills and time. However there is a class of Product Owner who largely lack authority and who I have taken to calling Backlog Administrators.

About the only thing a Backlog Administrator owns is their Jira login. They are at the beck and call of one or more people who tell them what should be in the backlog. Prioritisation is little more than an exercise in decibel management – he who shouts loudest gets what they want.

A Backlog Administrator rarely throws anything out of the backlog, they don’t feel they have the authority to do so. As a result their backlogs are constipated – lots of stories, many of little value. Fortunately Jira knows no limits, it is a bottomless pit – just don’t draw a CfD or Burn-Up chart!

If the team are lucky the Backlog Administrator can operate as a Tester, they can review work which is in progress or possibly “done.” They may be able to add acceptance criteria. If the team are unlucky the Backlog Administrator doesn’t know enough about the domain to do testing.

I would be the first to say that the Product Owner role can be vary a great deal: different individuals working with different teams in different domains for different types of company mean there that apart from backlog administration there is inherently a lot of variability in the role.

The Product Owner role should be capable of deciding what to build and/or change.

So Product Owners need to know what the most valuable thing to do is. Part of the job means finding out what is valuable. While Backlog Administration is part of the job the question one should ask is:

How does the Product Owner know what they need to know to do that?

Backlog Administrators are little more than gophers for more senior people.

True Product Owners take after full Product Managers and Senior Business Analysts – or a special version of Business Analysts sometimes called Business Partners.

Product Owners should be out meeting customers and observing users. They should be talking about technology options with the technical team and interface design options with UXD.

Product Owners should understand commercial pressures, how the product makes (or saves) money for the company. Product Owners are responsible for Product Strategy so they should both understand company strategy and input into company strategy. Product Strategy both supports company strategy and feeds into company strategy.

Product Owners may need to observe the competitor landscape and keep an eye on competitors and understand relevant technology trends. That probably means attending trade shows and even supporting sales people if asked.

Frequently Product Owners will require knowledge of the domain, i.e. the field in which your product is used. Sometimes – like in telecoms or surveying that may require actual hands on experience.

And apart from backlog administration there is a lot of work to do to deliver the things they want delivered: they need to work with the technical team to explain stories, to have the conversations behind the story, write acceptance criteria, attend planning meetings, perhaps help with interviewing new staff and sharing all the things they learn from meeting customers, analysing competitors, debating strategy, attending shows, etc. etc.

I sure there are many who would rush to call the Backlog Administrator an “anti-pattern” but since I don’t believe in anti-patterns I don’t. I just think Product Owners should be more than a Backlog Administrator.

Product Owners need 4 things

iStock_000008515543Small-2018-03-5-16-09.jpg

To be an effective Product Owner – and that includes product managers and business analysts who are nominating work for teams to do – you need at least four things. You may well need more than these four but these are common across all teams and domains.

  1. 1. Skills and experience

There is more to being a Product Owner than simply writing user stories and prioritising a backlog. Yes, you need to know how to work with a development team and how to work in an Agile-style process. Yes you need to be able to write user stories and acceptance criteria, perhaps BDD style cucumbers too; yes you need to be able to manage a backlog and prioritises and partake in planning meetings.

But how do you know what should be a priority?
How do you know what will deliver value? And please customers? Satisfy stakeholders?

Importantly Product Owners need to be able to do the work behind the backlog.

Product Owners need to meet people, have the conversations, do the analysis and thinking behind those things. Any idiot can pick random items form a backlog but it takes skills and experience to maximise value.

Product Owners need to be able to identify users, segment customers, interview people, understand their needs and jobs to be done. They need to know when to run experiments and when to turn to research journals and market studies. And that might mean they need data analysis skills too.

If the product is going to sell as a commercial product you will need wider product management skills. While if your product is for internal use you need more business analysis skills. And product managers will benefit from knowing about business analysts and business analysts will benefit from knowing about product management.

You may also need specialist domain knowledge – you might need to be a subject matter expert in your own right, or you might become an SME in given time.

Some understanding of business strategy, finance, marketing, process analysis and design, user experience design and more.

Don’t underestimate the skills and experience you need to be an effective Product Owner.

  1. 2. Authority

At the very least a Product Owner needs the authority to nominate the work the team are going to do for the next two weeks. They need the authority to choose items form a backlog and ask the team to do them. They need the authority not to have their decisions overridden on a regular basis. (OK, it happens occasionally.)

As a general rule the more authority the Product Owner has the more effective they are going to be in their role.

The organization may confer that authority but the team need to recognise and accept it too.

I’ve seen many Product Owners who while they have the authority to nominate work for a team don’t have the authority to throw things out of the backlog. When the only way for a story to leave the backlog is for it to be developed it is very expensive. This leads to constipated backlogs that are stuffed full of worthless rubbish and where one can’t see the wood for the trees.

If the Product Owner doesn’t have sufficient authority then either they need to borrow some or there is going to be trouble.

  1. 3. Legitimacy

Legitimacy is different from authority. Legitimacy is about being seen as the right person, the bonafide person to exercise authority and do the background work to find out what they need to find out in order to make those decisions.

Legitimacy means the Product Owner can go and meet customers if they want. And it means that they will get their expenses paid.

Legitimacy means that nobody else is trying to fill the Product Owner role or undermine them. In particular it means the team respect the Product Owner and trust them to make the right calls. Most of all they accept that once in a while – hopefully not too often – the Product Owner will have to say “I accept technologically X is the right thing but commercially it must be Y; full ahead and damn the torpedoes.”

It can be hard for a Product Owner to fill their role if the team believe a senior developer – or anyone else – should be managing the backlog and prioritising work to do.

  1. 4. Time

Finally, and probably the most difficult… Product Owners need time to do their work.

They need time to meet customers and reflect on those encounters.

They need time to work-the-backlog, value stories, weed out expired or valueless stories, think about the product vision, talk to stakeholders and more senior people, and then ponder what happens next.

Time to evaluate what has been delivered and see if it is delivering the expected value. Time to understand whether that which has been delivered is generating more or less value than expected. Time to feedback those findings into future work: to recalibrate expected values and priorities, generate more work or invalidate other work.

Product Owners need time to look at competitor products and consider alternatives – if only to steal ideas!

They need time to work with the technical team: have conversations about stories, expand on acceptance criteria, review work in progress, perhaps test completed features and socialise with the team.

They also need time to enhance their own skills and learn more about the domain.

And if they don’t have the time to do this?

Without time they will rush into planning meetings and say “I’ve been so busy, I haven’t looked at the backlog this week, just bear with me while I choose some stories…”

More often than not they will wing-it, they substitute opinion and guesswork instead of solid analysis, facts and data. They overlook competition and fail to listen to the team and other managers.

And O yes, they need time for their own lives and family.

I sometimes think that only Super Human’s need apply for a Product Owner role, or perhaps many Product Owners are set up to fail from day-1. Yet the role is so important.

I plan to explore this topic some more in the next few posts.

Sprint Zero

SprintZero-2018-02-25-11-21.jpg

Starting a new project? A new product? Have a team transitioning to “Agile” (aka Scrum) and wanting to get ready?

Why not try a Sprint Zero? – Why not indeed.

Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc. etc.

Sprint Zero doesn’t need to happen in a time box, you can take all the time you need, after all, you haven’t become “agile” yet, Sprint Zero will make you Agile.

Good idea?

Please don’t.

Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further.

The truth is: there is work to do.

Just start “sprinting”. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.

Doing anything else delays the change and potentially reduces motivation.

If you want to call your first iteration Zero then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.

All those things I just listed – and more – that you need to do to “get started” are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?

If you haven’t worked out what those things are then No problem, try and schedule some real work. When you find you don’t have something (a database instance for example) simply write out a card, schedule it, do it. The things you need to do to “get ready” are actually things you need to do to build something you do want.

My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something – like install a database – when you could quite easily postpone that work for a few weeks or even skip it entirely.

Similarly some say “How can we start work until we know what we need to do? – we need to gather requirements, write some stories….”

But again: determining what needs doing, requirements gathering, is itself work to be done.

If it is not clear what needs to be done on day-1 then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.

Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things but once they are listed as part of the work to do – and especially if they have been promised to someone – then not doing them can be problematic.

Anyway, having written this blog I now wonder if I should have bothered. Now I look about a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.

Down with management!

ConversationiStock_000007409052XSmall-2018-02-14-10-44.jpg

Si: Welcome Peter, thank you for taking the time to attend this annual performance review

Peter: As long as you know I don’t want to be here, performance reviews are pointless, I told that to my manager Roger. I should be at my desk coding.

Si: Yes, I understand your position, in fact many of us sympathise with it, including Roger and myself

Peter: Well, good, does he also agree that management is a waste of time? If we were really following Agile the way we should then Roger wouldn’t be getting in the way all the time and I could write more code.

Si: Yes, well, we’ve had that feedback from other people and the company is committed to change. In fact, one of the things I wanted to speak to you about today was to tell you Roger is stepping aside.

Peter: What?

Si: Yes, Roger is undertaking retraining and will become a Product Specialist, he himself rejected the title Product Manager because he doesn’t see the need for Managers and even refused the title Product Owner because he doesn’t feel he can “own” something that is a community effort and is ultimately owned by the company shareholders.

Peter: Wow… he has been listening to me?

Si: Yes, in my long conversations with him he has spoken many times of the points you have been making. Of course as part of the management team it wouldn’t have been right for him to speak about his changing views too publicly lest people wonder what was happening.

One of the things I wanted to discuss with you today was how we go about distributing Roger’s other responsibilities. As one the longest serving employees Roger suggested you would have the best insights.

Peter: Right, erh, so what responsibilities are these? – apart from asking me “how long will it take?”

Si: Well some relate to the product. As Product Specialist he will continue to support sales staff making customer visits, he will continue administer the backlog, prioritise work in the planning meeting and draw-up the product roadmap – although he wants to involve more people and change the concept of a roadmap. He plans to increase the number of customer visits, competitor analysis and market scanning activities he has been doing already.

Peter: Good, we need a proper product owner, he was doing the role anyway but didn’t have enough time.

Si: Well yes, in fact he has also requested that you and the other engineers accompany him on customer visits in future.

Peter: What? – but our customers are everywhere but here!!! Saudi Arabia, Finland, Argentina, USA… it takes days to get to those places, I’m needed here, I need to be coding!

Si: Well I’ll let the two of you come to a decision on that. Right now we need to redistribute Roger’s work.

There are the administration matters, signing off holiday, arranging sabbaticals, maternity/paternity leave; the new monthly check-points replacing annual performance reviews need to be staffed. There is a lot of work around contractors, time-sheets, extensions and terminations, to be honest there are constant political battles over the number of contractors and whether we should be using them at all. Personally, I believe these changes will abolish office politics but some people think I’m being naive.

Anyway, a lot of this work could be for someone like myself in HR…

Peter: But that will slow everything down! HR is never responsive and most of them – unlike yourself – don’t know one end of a code stack from another

Si: Yes, quite right, HR is atrociously understaffed so we take forever to do anything, and many of my colleagues just aren’t close enough to the teams – frankly they don’t understand technology.

For those reasons the company is also closing the HR department. The work will be distributed to the teams. So my colleagues and I are all being made redundant. Some larger teams, such as yours, will be allowed to hire “Talent specialists” to help with recruitment matters and I hope to secure a such a job myself. But that also means members of your team will need to interview and select their own Talent Specialist. I expect you’ll be on the interview panel, I hope you will see the depth of my experience.

Peter: O, but we are all so busy coding, that will slow us down! And we don’t know anything about recruiting HR people. Can’t Roger arrange that before he leaves?

Si: Roger’s re-assignment is immediate, he insisted on it. I suggest you and your colleagues get started on selecting your Talent Specialist as quickly as possible.

Still, many of the things I just listed will not fall under the Talent Specialists remit. A self-managing team really should manage a lot of those things itself. The Talent Specialist will be there for staffing issues, CV filtering, negotiating with recruitment agents, diversity monitoring, visa applications, university recruitment fairs, exit interviews, legal issues, and so on.

Peter: Right, well I’m sure out team can dispense with a lot of the administration, we can trust one another to take holiday responsibly.

Si: Quite so, I’m sure you can organise away a lot of the admin work but there will be a rump.

Peter: Could we bring back the Scrum Masters?

Si: Well the Scrum Masters we had were always at pains to point out they were not managers or administrators – I know they are in some other places. Plus, they said they “did themselves out of a job” in the end and recommended their own removal.

Peter: Arh… I remember, I guess we will share the administration around the team. We can work out a process for that – the same as we do in planning meetings.

Si: Remember as you do that some of your team may need management training

Peter: What?

Si: Management, even administration, has its own on standards, rules, jargon, if members of your team are going to do administration and management work, let alone talk to others doing it then they need to know their CapEx from their OpEx, their 4 Ps from their 5 Forces, front-of-house from back-of-house, what you can and can’t say in an exit interview, a SWOT analysis from a …

Peter: Yes, yes I get it, a lot of mumbo jumbo if you ask me…

Si: All the same, is it fair to throw people in at the deep-end? Shouldn’t we help them learn if they want to?

Moving on next we come to Roger’s role in the hierarchy. Sharing company information down to the team and team information up the chain. Plus annual strategy meetings, quarterly reviews, product portfolio boards, key customer engagement.

Peter: We have Slack and Wiki’s so I’m sure we can manage the information alright.

Si: Arh… well, when we rolled this program out in Norway some of the teams tried just that. In a couple of months most of the team members were complaining about information overload. I believe the quote was “How can you expect me to do any coding when Slack keeps interrupting me?”

Peter: Arhhh.

Si: And the Norwegian executives felt they never got a consistent message from the teams because different people would turn up to quarterly reviews each time while strategy sessions started to resemble a Stackover flow argument. Some customers complained that they no longer had a point of contact or got conflicting messages. And lets not even talk about the auditors.

Peter: Well the thing is, none of us have been trained in Strategy or, what did you call it? Portfolio review?

Si: Good thinking, I guess one of Roger’s strengths was the time he spent studying that on his American MBA. Do you want to arrange a coupe of days training in strategy and portfolio review for your team?

Peter: Erh, I’m not sure I know enough to book a training course, and isn’t that going to take people away from coding?

I mean the whole team, all 10 of us, out for 2 days training? And the people going to attend meetings with other departments and teams?

Si: Yes of course it is, but you will be self-managing. The team won’t have anyone else.

And mentioning the team, there is also another issue you’ve raised yourself in the past. Here we are, two very similar males discussing this. In fact your whole team is quite like the two of us. The team are going to have to challenge themselves to improve their diversity.

Peter: Right…

Look, we’ve been here half-an-hour and haven’t started even reviewing my performance, will this take much longer? I’ve got code to write.

Si: Well, there is quite a bit more of Roger’s work to discuss, plus his boss, Jane, is also stepping aside so we need to reconvene with people from the other teams to allocate her remaining work.

Peter: If we are self-managing, could we decide to employ a specialist to pick up a lot of this work?

Si: I expect you could, you’d need to put some costings together.

Peter: Right, I’ll talk it through with the team and see if we can hire a secretary.

Si: Good idea, although the secretary is going to need more than just typing skills.

Peter: Sure, secretary might be the wrong job title. We need someone with skills who we can trust to make these decisions, someone with experience.

Si: Although, you know, such a person may become a bit of a gate-keeper to the team

Peter: Certainly, thats what we need, we don’t want interruptions!

Si: Well, the problem with a gate keeper is that they decide what goes through the gate and what does not. That gives them a degree of power.

And if someone is picking up all the left over work, making decisions for the team, and controlling access to the team, and information flows into and out of the team…

Peter: Yes, is there a problem? That all sounds good to me, this gate keeper will have the power to defend the team

Si: Well… what I was about to say is such a person might be seen by some as having authority… and how will the team members feel about someone else deciding what is told to others?

Peter: Well, we could review their decisions and tell them what to do

Si: Yes… well, that might be seen as a lacking trust or even micro-manegement…

Xanpan – free eBook now!

Hypothesis: If I offer people a free copy of my Xanpan eBook (suggested price $17.50) then people will sign up to my newsletter list – which carries my blog posts, event lists and other news.

Test: Blog it, Tweet it, etc., wait a month and count the subscribers.

Use the form below and check your mailbox for confirmation and links.

Subscribe to our mailing list

* indicates required



Email Format


Outsourcing banana skins: Warning signs that your supplier isn’t as good as they claim

iStock-500539718m-2018-02-1-11-06.jpg

So you think you want to contract out some development work? – yes, you know this area is full of banana skins to slip on, and you know others have problems but you still want to do it.

And you want to contract it out to an “Agile” development shop?

There are no laws against opening a development shop – a digital agency, an outsourcer, a consultancy, call it what you like. That is the beauty of capitalism, it allows pluralism. The hard part is choosing one that is competent, some outsourcers are pretty awful.

Everyone who can spell “Agile” can claim to be Agile, and most hire a copywriter to give them an online spin so they all end up making the same claims.

Those who are half good can coach their staff in what to say. And in truth, most of them genuinely want to do the best possible job for you – and be agile too. But how can you really tell?

Well… when I’m being cynical I think you can’t. The only way to really tell is to give them some work and see what happens. Of course once you’ve engaged someone you need to be both legally and mentally prepared to walk away.

So to help you here are some warning signs that you have stepped on a banana skin and your supplier isn’t as good as you – and they – want to be. You might even say these are warning signs that they aren’t really Agile.

1) Customer involvement

They don’t want customer involvement. They don’t want your people on site. They claim that your people get in the way. They want to be left alone to do things.

Obviously I’m thinking primarily of actual Customers, Users, Product Owners, Business Analysts and so on. These people should be working closely with the suppliers people. They should have direct contact, they should be discussing stories.

If your supplier isn’t embracing your people and treating them as their own team members something is probably wrong.

The supplier should be challenging your people – after all the suppliers are the experts, if they are simply accepting everything you ask for then something is wrong.

The same is true of other people you might want involved: a consultant or Agile coach should be welcome too. And if you decide to ask a third party to inspect their development then they should be open to this too.

Naturally they should also be open about the code too. After all the code will be yours one day.

2) Regular demonstrations

The supplier should be providing regular demonstrations – “show and tell” – as a very minimum. Every couple of weeks I expect the supplier to show the latest work. You – and your people – should be able to see working software offering more than the previous demo.

If the supplier is NOT providing regular demonstrations then you should be worried. Likewise, if the demonstrations don’t show progress get worried. Most of all, if the supplier doesn’t want to talk about why demonstrations aren’t happening, or how they can show progress then something is wrong.

3) Release, release, release

Show and tell demonstrations are good but the real test is to release to live. Releasing all the way to your live system. You might hide it on an obscure URL that nobody knows, or call it a beta release or something, I don’t care, the closer they can get to real live the better.

You supplier should be releasing to a live environment – or an exact copy – very very regularly.

The longer the supplier goes without an actual release the more nervous you should be. Sure, once in a while things go wrong and nobody is perfect. They may go two weeks with nothing to show for it. I don’t like it – and neither should you – but an occasional gap is OK.

Going four weeks without a release… I suppose it might happen in the early stages of the work. But it is in the early stages that you most need reassurance that they can deliver something – anything!

Six weeks with no release… well here we are into “3 Strikes and you are out.” Sure they will be able to give technical reasons why things messed up three times in a row. But take it from me, something is wrong.

The longer they go without an actual release to more concerned you should be and the more you should offer to work with them to address the issue.

Eight weeks? – eject, eject, eject.

4) Show me the tests

Maybe this should be warning sign #1 but for this you need someone technical, someone who knows what a test looks like. In the show-and-tells your supplier should be able to show you automated tests executing. Not very exciting perhaps and certainly not meaningful to the business but if they can’t show you then how do you know they even exist?

And if your supplier doesn’t have an automated test suite then it is certainly time to get out.

Ultimately the system they are building is yours. Your people will need to maintain it, or you will need to pay someone else to maintain it. Without automated tests that is going to be hard. Skipping tests now might make it look like you are saving money but you are not, even in the short term the lack of tests will bite you hard, it will push up costs and destroy schedules.

5) “Feature complete”

The phrase alone should be a warning sign. Equally the words “75% feature complete” (or any other percentage) is a big red flag.

If the supplier doesn’t have a test suite, if they can’t show working (preferably releasable) code then its probable they are feature stuffing. They will say they are making progress because “60% of features are done”. They may even start to claim they are feature complete but remember: a feature without a test isn’t done.

A feature without a test is pure risk. At any time a defect can put a hand up and say “Fix me!”

An automated test isn’t a guarantee of bug free code but without automated tests then I guarantee you have defects waiting to appear.

If you are in a relationship exhibiting any of these five sign then it is certainly time to talk. It may be time to end. But how do you avoid getting into that position?

Let me be as clear as I can: both you and your supplier should prioritise working, usable, functionality over more functionality. As the old saying goes “A bird in the hand is worth two in the bush”, working, deliverable (even better released) features are the priority, there should be less work in progress, fewer incomplete features, fewer “almost done” and as few as possible defects.

While cynical me thinks you might not be able to avoid it that doesn’t mean you shouldn’t try, so here are four warning signs that you are about to step on a banana skin:

1) “Agile is not that different”

Don’t let them tell you Agile isn’t different. In many ways it isn’t but if a supplier is trying to persuade you that you don’t need to change the way you work then it is a sign that either a) they don’t appreciate the magnitude of the change or b) they will tell you anything to get the contract signed.

Since you want a supplier who will challenge you it might not be a good idea to hire one who doesn’t like challenging you or doesn’t prepare you for difficulties.

2) “We are certified”

An extension of warning sign #1 is that the supplier is proud of how certified they are: ISO-9001, PMI, PRINCE-2, CMMI – some in the Agile world would regard these certifications as warning signs in their own right.

Scrum Master Certified, Agile Project Manager Certified, Scrum Product Owner Certified: these are slightly better but anyone who can’t tell you the flaws in all these certifications has myopia.

Question any organization that offers up badges rather than working products.

(Disclosure: for better or worse I hold a couple of Kanban certifications, while I think Lean Kanban University have done a better job than many in making their certifications meaningful I don’t think they are a panacea either. Anyway, Kanban certifications aren’t as recognised as those I just mentioned.)

3) Fixed or long term contract

IT suppliers have a long history of locking clients into “fixed contracts” – fixed scope, cost and time. These contracts are utterly flawed. Anyone claiming they can fix everything is a charlatan. Give them a copy of “Dear Customer: The Truth about IT” (the Xanpan prologue) and say goodbye.

Similarly locking yourself into a long term contract with a supplier before you have done some work with them is a bad sign. Do a small piece of work, for a small fee, with your potential supplier and see if they are as good as they say.

In my experience the best – most “agile” – digital suppliers can pick and choose their customers. If your supplier needs you more than you need them then it is a bad sign.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Minimally Viable Team in a nutshell

Workers_000011166993XSmall-2018-01-26-11-03.jpg

Last week I was in Holland helping a client with their agile adoption and digital transformation. When the subject of teams came up I started talking about Minimally Viable Teams. Yesterday I found myself writing an e-mail to the client expanding on the idea. And it seemed to me that the e-mail – or an edited version – was worth sharing here…

The idea of an Minimally Viable Team (MVT) is based on the observation that if a team is overstaffed then team members will find work for themselves – Parkinson’s Law.

Mix in Conway’s Law: the recognised phenomenon where team copy the organization structure they are in. So for example, if you have a database expert on the team the final design will use a database whether one is needed or not.

If one is aiming for a self-organizing, goal-directed, value-seeking team then making any decisions about the team, the software design, or even the problem before work begins is questionable. The more decisions that are made the more the team is constrained, the more the team is constrained the less it is master of its own destiny.

Further, those decisions made before work begins: one expects them to be rational, which means some pre-work is needed to understand what decisions are needed and make the decisions. That pre-work costs time and money. The more money that is committed then the more difficult (i.e. more career threatening) it becomes to reverse those decisions if things go wrong.

Some companies spend an awfully long time thinking and planning to do something: longer than it takes to actually do the thing. I once visited a company which had spent five years planning a particular project and not building anything.

Add two more things to this.

We know from experience that planning has rapidly diminishing returns. A little bit of planning creates great learning, but after a little while the rate of learning drops off. Very soon learning by doing becomes more effective, i.e. switch from thinking about what might be done to trying to do it.

This has never been truer than today – 2018: with the computing power and tools it is faster and cheaper than ever to build a prototype, a concept, an MVP, version 1, alpha version or whatever else you want to call it.

However, going to the other extreme and doing no pre-work doesn’t make a lot of sense either.

Enter the Minimally Viable Team: the team jumps to doing, all that pre-work is given to the team. They get to decide what is needed.

To traditionalists the team/project/product is launched prematurely but actually all we are doing is extending the start date backwards so that the pre-work is now part of the thing. By tasking the initial team with all the traditional pre-work the team becomes master of their own destiny again. And they can choose to approach the mission with a traditional approach (market research, architecture design, resource planning) or in an agile/digital fashion (build a small product and test it) – that is their choice.

The MVT idea is to “starve” the team and make them pull only the necessary resources as and when they need them. When organizations decide who (which roles) will be on the team in advance they are in effect designing the software.

And since agile approaches and modern tools allow us to make progress that much faster why not move more quickly to a working product? Minimise the design, postpone the architecture.

This approach also means the initial team can be kept small which means they are cheap. So if they conclude the project shouldn’t be done the organizational inertial is less and the project can be cancelled. Which hopefully means the organization will take more chances on more ideas.

Try this thought experiment.

On Day-Zero there is nothing.

Someone decided there should be Product X. How did this happen? They may have had the idea days ago and have spent the intervening time researching the market, the competition, the problem and so on. (During which time their normal job has been disrupted, the sooner they can dedicate themselves to the new idea the faster things will happen.)

On Day-Zero they talk to an architect who considers a design.

This takes a few days at the end of which there is an outline design and the architect suggests the team needs four programmers, two testers, a UXD and a DBA. Plus a project manager and product owner. 10 in all.

It now takes time to make the business case and gather those resources.

At that point work can officially begin, call that D-Day.

Then the team need to learn to work together, build something and launch it into a market.
They also need to understand what the architect had in mind.

Officially the project began on D-Day, or perhaps the day the business case was approved.

How much time has been spent so far? Without testing the market? Allowing competitors to do something? – all this time cost of delay has been at work changing the business case.

How has all that “getting ready” time been accounted for? How has this work been managed?

The MVT approach says: Time is of the essence the team should decide all these things.

So, as quickly as you can, spend a little venture money on an MVT.

That team has to investigate the market, competition, problem, etc. The team can think about architecture but their primary aim is to build something, and MVP, a prototype, a proof of concept, whatever – build it, show it to customers, launch it, put it in the market.

By keeping it small the team can quickly invalidate ideas which don’t work. Ideas that do work can be built on. They are free to learn.

The initial MVT will do all the same things that a “pre project” phase would do but in a much more agile/digital way. The MVT also allows for continuity, when the team find success the team that can be expanded and grown – applying Gall’s Law.

This also looks a lot more like a start-up than a normal corporate project.

If the idea of a Minimally Viable Team is new to you then check out the discussion in Continuous Digital or some of my earlier blog posts on MVTs.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Nature abhors an information void

142px-PennyFarthing-2018-01-20-13-28.png

No. 6: What do you want?
Voice: Information
No. 6:You won’t get it
Voice: By hook or by crook we will

Information… we all want information… Facebook updates, Tweets, 24-hour rolling news, the Donald Trump Big Brother House… the opening scenes and words of The Prisoner continue to echo, Patrick McGoohan and the other writers got it right, they were just 50 years early.

Human beings have insatiable thirst for information – even when we know rationally that information is useless is pointless we still want it. We persuade ourselves that something might be happening that we need to know about.

Just today I was driving when my mobile phone started to ring. It was highly unlikely to be anything but still my mind started to think of important things it could be. I had to stop the car and try to answer it. Of course, it was spam, a junk call, caller-ID told me that so I didn’t answer.

Every one of us has information weaknesses. In part it is dopamine addiction. We may look down on those who watch “vanity metrics” but we all information fetishes whether they be, metrics, scores, “facts” or celebrity gossip.

Whether e-mail, Twitter, Facebook, WhatsApp, SMS, Slack, some other medium or social media we all need information and a dopamine fi. Has only replied to my tweet? Has anyone retweeted my last tweet? Has anyone followed me today?

Sometimes it is impossible to believe that nobody has retweeted my fantastic tweet, or that a potential client hasn’t immediately replied to an e-mail, or that… I’ve even on occasions found myself picking up my phone and going to the mail app when I’ve only just walked away from answering e-mail on my PC – as if the e-mail on my phone is better than the e-mail on my PC!

The only thing worse than having a mailbox full of unanswered e-mails is an empty mailbox – mailbox zero – which stays empty.

Sometimes one demands information when there just isn’t any. I think that is what number 6 really meant when number 2 repeatedly asked him for information: there wasn’t anything more than he had said. He had given his information, if others demanded more then it was simply because they couldn’t accept what they had been told.

I’m sure all parents have experienced children in the back of the car who ask: “Are we there yet?”. To which you reply “No – it will be at least an hour”. And then, five minutes later you hear “Are we there yet?”

And who hasn’t felt the same way about project managers? Or technical leads? Or product managers? product owners? business analysts?

Children don’t stop asking because… well, maybe because they don’t understand the answer, they have a poor concept of time. Or maybe because they really want the answer to be “Yes we are there.” As small people children also want information.

Isn’t that the same when other people ask you the “Have you finished foo yet?” and even “When will it be ready?” While one hopes they have a better concept of time they don’t necessarily take in the answer, and they hope and hope and hope that the answer will soon be the answer they want it to be. People are very bad at handling information voids.

Manager types might dress the question up in terms of “The business needs to know” how often does that disguises the real truth: somebody didn’t like the last answer and is hoping that if the question is posed again the answer might be the one they want.

The project manager who checks in every few hours is no different than the developer who leaves their e-mail open on a second screen, or the tester keeps Twitter in the background. Each of them wants to know information!

Our difficult in dealing with information voids means we constantly search for information. And if we can’t find it we create pseudo-information: time based project plans which purport to show when something will be done or system architecture documents which claim to show how everything will work. Are the project managers and architects who create these documents are just seeking information? Dopamine?

Long time readers may remember my review of time-estimation research. Some of the research I read showed that people in positions of authority, or who claimed expert knowledge, underestimates how long work will take more than the people who do the work. Researchers were not clear as to whether this effect was because those in authority and experts let their desire for the end state influence their time estimation or whether it was because these people lacked an understanding of the work in detail and so ignored complications.

And it is not just time based information. Requirements documents are often an attempt to discern how a system may be used in future. System architecture designs are an attempt to second guess how the future may unfold. Unfortunately, as Peter Drucker said “We have no facts about the future”.

Faced with an information void we fill it with conjecture.

Sadly I also see occasions where the search for answers disables people. Sometimes people search for information and answers which are within their own power to give. Consider the product owner inundated with work requests for their product. They search for someone to tell them what they should do and what they should not do. Faced with an information void they look for answer from others. But sometimes – often? always? – the answer is within: as product owner they have the authority to decide what comes first and what is left undone.

I have become convinced over the years that often people ask for information that simply doesn’t exist. When the information isn’t presented they fill in the blanks themselves, they assume the information does exist and isn’t being shared. In some cases they create conspiracy theories or they accuse others of being secretive. But because of doubt they they don’t act on the information.

It is easy to think of examples in the public eye but I think it also happens inside organizations. Often times managers really don’t know what the future will hold but if they don’t tell people then they are seen as hiding something. If they deny information exists they may be seen as stupid or misleading.

The same happens the other way around, the self same managers – who really don’t know as much as people think they do – ask programmers, testers, analysts, etc. for information which doesn’t exist and which maybe unknowable. Telling your manager “you don’t know” might not be something you feel safe doing, and if you do then they may go and ask someone else.

In almost every organization I visit people tell me “We are not very good at communicating around here.” Again and again people tell me they are not told information they “should” be told. I’ve never visited an organization where people tell me “Communication is great around here” and while I’ve visited places where people say “We have lots of pointless meetings” nobody tells me “We are told too much.”

My working assumption in these cases is simply: The information doesn’t exist.

This is Occam’s razor logic, it is conspiracy free, it doesn’t assume the worst of people. I don’t assume people are keeping information secret – either deliberately or through naive understandings of what other people want.

So, the real answer for No. 6 should be “I’ve told you the truth, maybe you can’t accept it.”

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.