The 10 things I have learnt about Agile Product Delivery

I have a confession. I share it in the belief I am in the company of my brethren; I am an accidental product manager. Two years ago, I did not know a user story from a bedtime one. A notification from an alert. And a gherkin was still just a tasty pickle.

But 24 months is a long time in agile product management and I have had to learn. Fast. One of the insights I have gained is that sharing experiences with the motive of betterment is one of the core tenets of agile philosophy. So, I humbly submit the 10 things I have learnt about managing agile product delivery, in the hope others will find value and enrich with their experiences.

1. The hook and the anchor

In any agile delivery there will be good times and there will be bad times. And when the bad times come, you will need something to keep the momentum going for your stakeholders and yourself. This requires preparation, data and a compelling reason for doing what you are doing. For us, this involved an initial business discovery project, which included meeting and surveying our clients. This enabled us to do two things – define a succinct value proposition for the problem we were trying to solve and survey data and client testimonials we could turn to when times got hard.

The other (not to be overlooked) benefit was that it enabled us to take reduce resistance from nay-sayers.

2. Love the job and get s**t done.

After university, I fell into a role in Financial Services and spent most of my career working at the intersection of strategy, technology and operations.  My move into product management whilst accidental, was then, perhaps inevitable – all good product managers operate at this confluence, as this is where ‘s**t gets done’. Do not misunderstand me – writing personas, defining true north value propositions, wireframing features and coming up with joyous user experiences are all critical facets of the product management function, but the ability to mobilise resources to deliver the right product at the right time is what sets one product manager apart from another.

I once commented to a friend that for an MBA grad like me, this was the ideal job. And in the right environment, it is. So, love it. There are far worse things to do and few better.

3. Be with your teams…

I have hired (and fired) project managers, business analysts and product owners and the one thing I have learnt is if you are the ‘product person’, you cannot hire your way out of day-to-day interaction with the people building product.  Be it start-up or at scale, when you try to convey vision from afar, you lose something fundamental. If you are not willing to make the trade-off, don’t try it.

4. Full-stack, fully dedicated and collocated teams…or bust.

For over a year I managed the interaction between an off-shore ‘front-end’ development team and an on-shore ’back-end’ team. It was a train-wreck. And the train was my product.

Putting aside cultural and logistical issues, if your objective is a unified focus on a single outcome – building great products, then managing teams with different objectives and agendas is not an option.

It is my belief that a product manager must do everything within his or her power to make team focus and collaboration towards a single vision a top priority. And a single team with a single focus is the most important thing to help make that happen.

5. Only create stories a user can understand.

One of the indicators of product leadership is the type of work that goes ‘on the board’ (NB: Always have physical boards for your teams, even if you also use a digital one).

Stories (or whatever medium you use to communicate requirements) that only a technologist can understand are almost always the result of ineffectual product leadership and will be to the detriment of your product, and therefore users.

Take responsibility for requirement creation and only create ones that an end-user could understand. The team may create more technology-orientated sub-tasks and that’s fine, but the only thing that should move along a board or be measured should be understood and valued by users (without the need for an interpreter).

6. Small stories.

A related insight is the value of small stories.

We have a rule that any story bigger than a specific size (in whatever currency you measure such things – points, days etc.) must be broken into smaller stories.

This serves two purposes – firstly, it helps velocity, and secondly, it helps to force product people to think about MVP in terms of feature sets.

7. Architect-in-time.

In my experience, architectural design and implementation should emerge in the context of delivering requirements. The promise that early architecting will address future problems (e.g. performance, maintainability etc.) is seldom delivered upon in a way that is more efficient than emergent design.

However, the risk of over-engineered solutions that address at best hypothetical, and at worst imagined requirements, severely impacting your budget, timeline is a clear and present danger. Guard against it with your life – technologists are responsible to the business for a reason, do not willfully give up this accountability.

8. Evolution, not iteration.

In line with ‘lean’/MVP thinking, build atomic features of value to your users and release these as quickly as possible with a mechanism to capture feedback. Use the feedback to evolve the feature. Release the improved version, and repeat.

Feedback from your user base is the lifeblood of any product management function. Do whatever you can to get it and get it early.

9. Manage a process improvement board.

Velocity is your friend and the people building the product generally know how to improve velocity. Do what you can to empower the team to deliver features quickly. If you think this is the responsibility of the ‘scrum-master’ or ‘programme-manager’, you need to rethink your objectives.

10. Carry your stakeholders through the journey

In many firms, product management is a relatively new function and in many more, agile is. Help your stakeholders – provide them with good updates, explain key jargon and avoid ‘fluff’.

Agile done well is an incredibly powerful way to deliver superior products and create competitive advantage for your firm, but there are risks; Agile provides speed and done badly or misunderstood by executives, will lead to failure quicker than you can say ‘waterfall’.

So there you have it – the 10 things I have learnt about agile product delivery.  By no means an exhaustive list, or faultless – but in the agile spirit, shared for growth and further improvement.

There are lots of things I have still not worked out – for example, how to get the best out of project managers, how to better align technology and business interests or how to best use JIRA(!), but hey, it’s a learning process!