Project management and development notes from 2020
Based on my experiences in last 12 months of finding the right agencies for clients, as well as work done for an online product business
I’ve broken these notes into two main sections, with some random notes at the end. These notes cover what I’ve seen in terms of project management as part of running my supplier selection process, as well as the consultancy work I’ve done in-house for clients.
Clients and agencies
By the time I’ve helped a client get down to the last 2–3 agencies to chose as a supplier, we’re most often in a situation where there’s little doubt about each agency’s technical capabilities.
What then differentiates beyond this point often comes down to how comfortable the client feels that each agency will make best use of the budget, within the time available.
A key point to look for here is a clear and unambiguous process of how feature priorities are actually evaluated by the client and agency partner.
- This might be based on assessing the need for each feature against KPIs established at the outset.
- Or it could be that each feature is measured against a one-line mission statement, which then has a range of associated objectives and tactics.
This likely gives confidence that prioritised calls will made and assessed in a clear way, providing reassurance that the opportunity afforded by the budget, in terms of what the outcomes are, is best managed within the time available.
Agencies need to go further than just saying:-
Features are ranked in a backlog, with high value elements being worked on first.
This is because this doesn’t show how value is assessed.
It’s also essential that agencies provide clarity in meaning. Lean, Agile, Waterfall, Scrum, Sprints are words from which people client-side derive different meanings, based on (sometimes limited) experience of the various ways they’ve seen these methodologies, processes or artifacts applied before. Take for example, the agency that says:-
We run a blended approach to project management, pulling the best from agile and waterfall methodologies.
We’re Agile, but with a little ‘a’
Primarily, this tells me that the agency aims to set the rules of engagement, because a standard approach has been adapted to suit them. On the basis that this is then bespoke, governance of the process might not be clear, or even established. Instead, it might be preferable to put methodology and governance in the hands of an independent external process that both client and agency have equal access to.
Further, blended approaches really depend on how much is drawn from each methodology. x% Agile and y% waterfall can vary, and, if as a client you have little experience in one, or the other, or both, how do you know what’s optimum?
Online product businesses
Within the last year I also worked as a consultant for a business that had an online product operation to support its core business, which was 80% + B2B, with the remaining B2C.
- Having grown rapidly, its customer database, and the associated tools around it had been built at speed, often to meet a succession of isolated business cases.
- B2B application development, B2C application development, integration and database development teams acted in silos.
- The integration team needed to function better as a central service, in an environment where it was given the resource to provide solutions for its two main internal customers, the B2B and B2C application teams. Under-resourced central services teams cannot mandate a consistency of approach if they are not adequately resourced. I’ve seen this over and over. The outcome often is, under pressure to deliver, that application teams (or other dependent business units) go off in their own direction and either build their own thing (often re-inventing the wheel), and, under-the-hood, cut out central services all together. The result is often poorly built products, where the functional overlap creates feature bloat. This leads to confusion as to how best to achieve any new task (as there are often multiple, incomplete ways, on which there is very little shared knowledge). It also creates internal myths more widely in organisations, as detailed understanding naturally dissipates, as to what solutions or features do, why, and what approach is best. The wrong opinion, in the mind of those who can shout the loudest, often becomes gospel.
In this sort of environment things have to change, along the lines below. I’ll summarise at the end where Scrumban might be a lightweight resolution to some of these challenges.
Better internal and external stakeholder management is needed. The external process, if based around a solid understanding of customers/audiences/users/personas/competitors can be as robust as you like, and make best use of all sorts of research techniques. But it can quickly count for nothing if internal stakeholder management is all at sea.
Any internal stakeholder engagement process should start with establishing the level of engagement required by each stakeholder and the roles and responsibilities they have. An exercise should run, as part of a workshop, where stakeholders self-identify their levels, with project staff helping to validate and normalise this across the organisation. There are several methods for doing this, but one which works well asks people to state their level of engagement as either:-
- Vital to engage
- Necessary to engage
- Good to have engaged
- Courtesy to inform
Then next you need to establish their role or responsibility as PRAI (which is similar to a more common system known as RACI):-
- Producer — Those responsible for creating or initiating an outcome
- Reviewer — Those who review outcomes
- Approver — Those who approve decisions, enabling the project to progress
- Informed — Those who need to be informed, or express and interest in being informed
Bottlenecks can often appear within central service teams, or any place where too much load is put on too few people.
Blockers might exist because of bottlenecks, but they can also exist as a result of competing priorities within different teams, especially where one team’s need consistently usurps the other’s. Lack of knowledge, tools, skills or resource can also cause blockers. As can dependencies.
Estimates, spikes and dev input to backlog refinement
If optimum routes to solutions fall foul of bottlenecks or blockers, then estimates can quickly become flawed. Estimates in themselves take time. (So they could be considered waste, as thus not particularly lean.)
Spikes (i.e. a unit of work where the potential solutions to a problem are explored or researched) can be pointless if not done by the person who will end up doing the work, as it is they who need to understand it. Sometimes the best way to understand the work might be to start to do it. Spikes, in of themselves, could be seen as waste also.
A request for estimates or spikes, or uncovering a need for spikes, might often come up at product backlog refinement sessions. These may then need dev input, but arguably product backlog refinement sessions might be best of not including devs.
Overload — and caring for your team
A team, in which members become bottlenecks, hit blockers, who are already up against it in terms of (potentially) flawed estimates, who get pulled into spikes or planning where that time is not adequately accounted for, or deducted from what remains in a sprint, can quickly become overloaded.
Product Owners and Product Managers, and most likely Project Managers won’t have direct line management responsibility for the devs they are dependent on. Even if they do, the chances are they have limited real world experience of having done the work of a dev. Regardless, whether you have line responsibility for your devs or not, you should foster a responsibility of care, and aim to generate the best possible working environment for them. Think about life in their shoes.
- Don’t ask for, or describe solutions. Set goals, objectives and challenges instead. In terms of setting objectives, think about OKRs, which tier down from the organisational, through to departmental, through to individual level.
- Give your devs ownership of achieving these objectives. Make it unambiguous what calls they are allowed to make.
- As much as is possible, give them the choice of what hardware and software they need to achieve these objectives.
- Understand their professional and personal ambitions. Ensure their personal objectives are focussed on achieving these and commit yourself to helping them succeed in the fulfillment of these.
- Accept that you cannot give them all they need. So, give them the freedom to invest a self-directed development budget. Allow them the time to seek out those that can mentor, guide or inspire them, and give them the opportunity to provide the same for others.
- Ensure that the remuneration package they are on adequately reflects their value. Having this in your budget acts as an insurance policy should they choose to move on.
- Ensure packages are well-rounded. That they have a realistic approach to time off, to learning, to work/life balance. Ensure that notice periods provide individuals a level of job security, and some assurance that they will not be left exposed if other key staff are allowed to disappear too quickly.
- Make your time available to them as soon as is practical, when they make it clear that they need it. (There is a balance here to make sure that requirement is not over-serviced).
- Have a clear sense of how much process is required to engage with your development teams, and regularly consider if that’s too much, or not enough.
Scrumban and/or Kanban as a resolution to some of these challenges
Finding yourself in the situation I described above, the four core practices of Kanban can be useful:-
- Start With What You Do Now. (There will be some good. And your initial role is to observe and spot what is good, not upset the apple cart)
- Agree to Pursue Incremental, Evolutionary Change. (Providing and encouraging leadership as per point 4 helps here)
- Respect the Current Process, Roles & Responsibilities. (They can be incremented over time. See point 2)
- Encourage Acts of Leadership at All Levels. (Essential for buy in to point 2. Helps understand point 1 quicker. Highlights the lined items that focus on ownership in point 3)
To me, these practices seem indivisible, as each supports the other (as shown in italics).
Moving into Scrumban, think about what Lean, Kanban additions to Scrum augment Scrum, and understand where they divert from it too. Think also how Extreme Programming (XP) and/or DSDM techniques can help here. The former, by providing a robust approach to development, the latter by enabling strategic priorities to be adequately formed and ordered before development starts. (Disclaimer: based on what I said earlier, this hybrid approach is probably not one for agencies)
- Limiting work in progress, should reduce bottlenecks
- Assigning the full team’s focus to blockers, especially if using XP techniques, resolves key priority issues quicker in an environment where understanding is widened and longevity (by virtue of better TDD and BDD) is built in.
- Estimates and spikes disappear as they are wasteful.
- An engaged and available product management function can plan as required and/or on near demand, as opposed to during standard scrum events. (This is where Scrumban starts to diverge from Scrum). Also, this approach ensures product teams are focussed on priortitised objectives, leaving self-organised development teams to own the solution as they should. Scrumban (and DSDM can help here too) provides a better opportunity for Stakeholder engagement (the external part of which can help inform some elements within XP.)
(What I think acts as a potential risk is a function that is implicitly or unknowingly moving towards Scrumban, where a Scrum master (or Product Onwer) is not picking up on this. In this scenario devs may be trying to leverage the benefits of Scrumban, but locked too rigidly into Scrum (and estimates, and over-exposure to too many Scrum events) are risking a level of burn out. I’m sure there are follow on disadvantages to Scrumban, but it’s not an approach I’ve personally used enough to be aware of what these might be.)
Where to start
If you’ve not done anything along the lines of Agile before, look first at how you can perhaps use it to overhaul how you provide on-going support to customers. Work towards a place where your support function becomes a fully resourced customer success team.
Agile approaches I’ve taken in the past
When I was running miggle as an agency, the following approach was outlined in our last published ‘miggle process overview’, which was updated in June 2017.
We manage our projects as close to an Agile DSDM as is practical given what might be competing ‘business as usual’ (BAU) demands within a client’s business. What we like about DSDM is that it has a focus on delivering a quality solution within set time and budget constraints, where the variability would be the extensiveness of the features delivered. It recognises that there’s a set of key ‘must-haves’ which represent a minimum viable product (MVP) and that these should be focussed on first. This allows us to work on a time and materials basis, rather than deliver fixed cost for fixed scope and time, while still allowing end clients to manage scope to fit to budgets and timescales.
That focus is delivered through collaborative workshops and meetings (which works well if there are multiple stakeholders client side) and by using MoSCoW prioritisation. DSDM also allows us to plug and play what works for project management for both client and supplier, meaning if certain elements require a more traditional waterfall approach we can incorporate them.
Digital decisions are never a walk in the park, so please get in touch and let me help you find the right way through the technical landscape.