Suits you?

Last night I went to a ‘Product Tank Birmingham’ workshop on ‘Empathy Mapping’. As an exercise, we looked at ‘a product meeting group’ and tried to identify its customers. There was a brief discussion about ‘Product Owners’ (from agile software development) and ‘Product Managers’ who often have a more marketing-led approach. Someone then commented on what ‘Product people’ think. I found I didn’t agree. I reflected on the difference between Product Owners (in this context: me), who care about giving people the product they want and Product Managers, who seem to care more about people’s relationship with the product.

I realised there is a half-way house and I have not, to date, worked in it. My experience in agile software development has been about “custom” development of software products for small teams with a shared view of what they want. I’ve realised for a while that my experience is very different to those Product Owners who have to develop a more generic product to ‘optimise’ across a set of potential or actual customers who have differing needs. There is an extra role there which is far more like my understanding of Product Management. I think the key difference is the need to correctly judge the closeness of fit needed to achieve mass market appeal vs the bespoke tailoring trade that I’ve worked in.

Early in my career, I worked as a programmer on a software package for pharmaceutical companies. We coded to specifications provided by 2 people, a salesman and our technical manager, who both travelled the world visiting customers’ sites. Looking back, I think the salesman was much better at identifying the features that would be valued by most customers. Is marketing USEFUL?

Advertisement

Popular Scrum tweaks

Contentious, I know, but the Scrum framework for agile software development may not be completely perfect yet. That’s fine because because we can improve on it, like science.
A few problems that often come to light are:

• Very few people agree what Agile is. I’m one of them.
• Few people agree exactly what Scrum is (despite it being defined by a very short document, The Scrum Guide.) “Like chess, Scrum is very simple.”
• There is a lot of common agile practice that is used by Scrummers and taught on courses but isn’t part of Scrum.
• Many people think they are ‘doing’ agile and/or Scrum but may not be. Who knows? The rules are: there are no rules.

In my last post I mentioned pragmatic changes to Scrum. Below are some that seem common and I’m not sure are always wrong. I think they come from the fact that Scrum makes assumptions about the mere humans who fill the Scrum roles that are, to be polite, idealistic:

• The use of Business Analysts to supplement the Product Owner’s knowledge and skills and the developers ability to listen and ask the right questions. Developers are not all good at dealing with people or at business analysis. The people who are, are not all good at development. Part-people who add up to a whole role may be the best a team can realistically achieve.
• The use of stakeholders who know areas of business better than the Product Owner (PO.) Product Owners need to be super-human: trusted by whoever is paying, knowledgeable, decisive, able to write good stories and constantly available. The PO is there to make dangerous business decisions, so the Team don’t have to. If they make bad decisions, it isn’t the Team’s fault. They are allowed to have help. By this logic, any BA who helps the BA should be outside the Development Team because business process is not “IT”. I have not yet seen any organisation with a business process department. I think we will soon. Process design is often considered a management responsibility but very few managers have appropriate experience.
• The use of technical/engineering/architecture specialists to supplement the skills of the Development Team. One small team is assumed to consist of generalising specialists with knowledge of everything that will be necessary to complete the project, though you don’t know what that is yet, so ‘be lucky’
• Network communicators/organisational specialists. Scrum assumes autonomous teams but at scale, organisational efficiency considerations start to apply pressure to centralise scarce and expensive skills. Co-ordination of networked teams becomes necessary. Traditionally, managers are likely to have filled similar roles but in future there may be more collaboration than typical managers have experienced while fighting for influence and resources inside a hierarchical organisation.