Agile Digital Product Management

Building a complex digital product comes with significant risk.

According to the Standish Group’s CHAOS report, the success rate of digital projects has not changed since the ’90s, and actually declined during the period 2012-2015, as the popularity of Scrum reached its peak. Six years later, in 2021, The Project Management Institute reported that more than 50% of digital projects fail to meet their original goals, with 35% of projects cancelled outright, delivering nothing.

Projects don’t succeed because you’re using Scrum, they succeed because they’re well-designed, well-managed, and well-executed, with priority given to agile principles and success drivers instead of actually-rigid “agile” practices and rules.

Product builds are a marathon, not a sprint. I can help your team build better digital projects with higher quality and less stress.

Success Drivers

Unfortunately, there is no silver bullet that ensures a digital project will succeed. All successful digital projects require hard work, and a deep understanding of the product, business, domain, technology - and the unique success drivers of a digital project.

In my experience, these driversinclude:

Clarity

Clear Vision: You need a concise, understandable explanation of the business goals for any project. This factor is critical to success. Everyone involved in the project should know exactly what they are trying to build, and why. The vision should remain largely intact for the life of the project.

Limited Scope: Report after industry report - including CHAOS and the PMI - correlates project success with small, cohesive projects; incremental delivery; small, motivated and empowered teams; and effective collaboration, feedback and engagement between stakeholders.

Evolving Strategy: You need a clear, transparent strategy that describes, at a high level, how you anticipate the project to launch and mature into the vision over time, so that everyone understands, shares, and can work towards the project’s priorities. Your strategy can - and should - evolve over time as the team receives feedback from developers, users, the business, and observation - but changes to the strategy should be an occasional, overt decision that’s widely shared.

Active Management

Skilled Leadership: You can’t delegate digital project management to generalist project managers or non-engineering business managers. Digital project leaders need to be skilled, hands-on engineers with deep knowledge of the product, business, subject matter and technology, and who have a peer relationship with the non-engineering business stakeholders in the project.

Feature Management: Feature (aka story) management takes significant effort, and new features are often discovered at unexpected and inconvenient times. A database of features - requirements, ideas and discoveries - that you can easily curate, sort, search, prioritise and review is a key success driver. Ideally, features should be arranged hierarchically to make feature decomposition and simplification easier. The feature database could be considered a sophisticated version of Scrum’s backlog. Something like ProductBoard is great for this.

Prioritisation: Deciding what to build next can be surprisingly difficult; if you have hundreds of features in the pipeline, you need a way to prioritise them. The priority of a feature depends on not just your strategy, and the complexity, impact, and relative importance of each feature. Prioritisation frameworks like RICE can help to score features, but ultimately you need a way to make, record and update the priority of each feature.

Skilled Engineering

Design: Before work begins on a non-trivial feature, a draft design should be sketched out by a senior engineer. This enables the team to anticipate important details about the feature - how it’s expected to work, key data structures, wireframes, database tables, messages, API stubs, etc. The draft design is an essential element of feature simplification and decomposition, as well as being a reliable aid to planning, and it acts as a starting point when implementation begins. Importantly, this design is disposable scaffolding (because The Code is The Design) - so the design documents are non-normative, subject to change, and should be discarded after use. What we’re trying to do at this point is understand and reduce scope, not dictate implementation. Unfortunately, up-front design is strongly discouraged in Scrum practices - but this is often misinterpreted as no design at all. But in my experience, a lack of experienced engineering design is a key failure driver.

Avoid Estimation: I could write a book on this. Inaccurate, artificial deadlines such as those produced by planning poker put downward pressure on quality - resulting in the perverse outcome of increased project risk. I recommend replacing planning poker with actual planning by an experienced engineer - the design step - and using that design to understand the risks. This isn’t to say that you shouldn’t keep tabs on progress - but velocity, a lagging indicator, is much more accurate than using a gambling metaphor to guess how many stories you can squeeze into the next sprint.

Implementation: designs need to be ready before a developer becomes available. This lets the developer get to work very quickly - but the developer, not the design, is in charge now. They may change the draft design, rewrite it, or even discard it as new information is discovered and implemented. In all cases, the developer, designer and users should be encouraged to work together via frequent ad-hoc meetings to discuss progress and problems.

Commitment: Be prepared to give your developers enough time to complete each feature, even if it takes longer than you’d like. Prioritisation means that every feature you start working on is the most important one - so let the developer build it properly, or don’t bother starting. In the rare case that a feature is found to be infeasible or much more difficult after work starts, don’t hesitate to move onto another one; recalibrate, and try again later.

Continuous Deployment: Testing and deployment should be continuous (CI/CD). Building an effective CI/CD pipeline can take a lot of up-front effort - but, done right, the benefits to productivity, risk, and developer satisfaction are profound.

Tangible Progress

Velocity: I define “velocity” as “productivity despite change”. One way to measure this is to make it easy and natural for developers to provide status updates on feature development - for example via Kanban boards and/or shared to-do lists - which let us measure how the developer believes they are progressing. Trello is a great tool for this, especially if it’s integrated into a bigger picture. Ideally, progress reporting should feed back into a project dashboard, so we can track overall project progress at a glance. Real-time measurement of velocity gives actual progress at all times, and makes estimation redundant in most cases.

Feedback: All stakeholders should be able to provide feedback about the product and its features, before, during and after development. This can include bugs, feature requests, and other feedback. Feedback channels should include all meetings, email, and (maybe) a dedicated feedback system. Formal feedback should be triaged by a senior engineer and entered into the features database. I like to keep minor issues (bugs) separate from the feature database, and to have regular hackathon days where customer-facing and operations teams hang out together to choose what gets fixed. This is also a great way to identify when little problems are actually big problems in disguise.

Stand-ups: You should have daily “stand-up” meetings, where all developers get a chance to talk about what they’re working on, ask for help, and share news. Stand-ups provide the perfect opportunity to start collaborations between engineers - but strict rules are critical to success. Stand-ups should never run for more than 10 minutes, they must always start on time, and you must have a way to take substantive conversations offline. When everyone is in the meeting, it’s easy to waste everyone’s time.

Showcases: Developers should be encouraged to present their finished work to the business on a regular (one or two times per month) basis. This critical, regular presentation gives everyone an opportunity to discuss new features within the greater product context, and to suggest changes where appropriate. It’s also the perfect opportunity to give engineers positive feedback about their work.

Clear Communication

Collaboration: Team members should be encouraged to have lots of informal and ad-hoc conversations - but keep them small; 2 or 3 people is perfect. Create opportunities for discussions, such as in-office lunch catering. Make sure there are always plenty of chairs, chat rooms, meeting spaces and whiteboards (virtual or real). Avoid larger meetings (5-10 people) where possible - when you can’t avoid them, have a formal agenda. Very large meetings (>10) should be rare, structured, with a tight agenda, and well-prepared speakers.

Reflection: Be blameless. Encourage constant, constructive discussions about process, problems, mistakes, things we did well, and things we could do better. Take care to criticise the process, not the people. Focus on how we avoid problems next time. Solve the important problems first. Don’t try to solve every problem - take care to consider which problems are important, and which are not. Sometimes, not fixing a problem is the right thing to do.

Agility

Agility means that if a practice isn’t working - if it’s making it harder to achieve your vision - then you should change it. Make an exception. Throw it out. The core of agility is to be flexible, to allow the rules to be relaxed sometimes - to let engineers do engineering that results in a great product.

The goal of these practices is to deliver a project that is strongly aligned with the original vision.

Contact Me

Hi, I’m Mark. I’m a software engineering consultant based on the Sunshine Coast, near Brisbane, Australia. I can help you understand and implement the success drivers for a digital project.

I’m available for contract/permanent consulting and leadership roles in Agile Product Leadership and other technical roles.

Get in touch! Let’s discuss how I can help your project get started, or get back on track, or just go faster.