I wanted to give some practical advice for those doing interviews for Delivery Management. Having spent years hiring & being hired for delivery management roles, designing interview processes & recruitment funnels, alongside working with Talent Acquisition Partners (internal recruiters) & external agencies, here are the questions I think you need to consider answering well.
These are also the questions I think many people get very wrong. So I wanted to cover some example answers.
What does Agile mean to you?
For me, Agile is both a historic approach to rapid software development, a behavioural mindset which takes from Lean manufacturing (a thing in its own right) & applies a set of principles & guard rails to help engineering teams & organisations deliver technical solutions & technical change efficiently. For me, Agile sometimes loses its potential impact as it gets constantly diluted & repackaged to be a silver bullet. Agile should often be used sympathetically & with context & not just for the sake of doing ‘it’.
If you were asked to explain the concept of DevOps, what would you say?
DevOps & its iterations & variations cover both a behavioural mindset & culture, along with technical best practice in software engineering. Both fundamentally help to fix the challenge of technical services & product being developed in a silo by technical folk & then passed to the operational side of the business to support & run. Taking from Lean manufacturing & the Agile manifesto, implementing DevOps can help organisations engineer better solutions which scale.
The technical side covers the notion of implementing a development environment which allows engineering teams to contribute to a software product using branch-based development. Everyone contributes to a master branch, using merge & version control tooling. Thus, allowing for continuous integration & continuous delivery (CI/CD).
How do you sell the notion of Agile to those who are resistant?
It’s not difficult to understand why folk are resistant to Agile. Constantly being pushed as a catch-all solution for pretty much every organisational problem, Agile is just another tool in the box to apply in bite size chunks where appropriate & needed. I wouldn’t sell Agile, I would sell the notion of fleshing out a empiric problem, understanding why that problem exists & what impact it causes & then applying a range of analysis & thought processes to prototype a potential solution which may or may not include Agile practices or techniques. I would ‘do’ and ‘be’ Agile rather than sell it.
How do you manage risk on a project?
Outside of the classic ‘Iron Triangle’ of project variables (time, cost, scope) which may or may not have the potential to be flexed, an approach to risk management is one of fully understanding the big picture view of the project, what its value is & what it (the project) is trying to achieve. Multi-direction dependencies should be identified & tracked as early as possible, key areas of complexity should be communicated & talked through & the right people involved, solving the right problems & be included & as early as possible. Risk should be quantified in terms of impact to quality, (and the Iron triangle components) & then prioritised accordingly.
How do you know what framework to use on any given project?
Understanding the project & the team(s) are key. For software engineering, where a single product & a single team are involved, Scrum can work well. For the same scenario but where multiple projects or teams are involved beyond nine or so, you would consider Nexus which scales Scrum but stays within broad simplicity. For large scale teams dealing with multiple products & multiple Product/Service owners which need to be released at different times with a heavy scaling requirement, you’d start to look at SAFe.
For change transformation projects, leveraging clear visualisation techniques such as Kanban help drive progress & implementing Agile behaviour in any self-organising project team often helps general pace. There are other frameworks & methodologies (especially for software projects) but these would be my broad go to’s.
Name a time where you’ve had to manage a difficult client where the project is not in a good state.
You have to very quickly synthesise & understand problems & be able to articulate them in an understandable manner to people who can help you. Clear communication is key & that includes when things are going wrong. Where client stakeholders are difficult, understanding their motives first helps to then build a path forwards. Where there are people there are politics. So, an empathetic ‘their shoes first’ approach & giving people time to express opinion is important. Good project leaders know how to temper that & the often laser focus needed to drive through completion. If stake holders are having an impact on the project or its completion, I’d investigate again motives first. It all starts with people.
If answering to that stakeholder & the project is not in a good place, then clearly presenting an action plan, way forward & why, helps pacify & builds confidence in action happening & a way forward exists. Avoiding or under-communicating at this stage can be a big problem.
What project collateral & assets would you use when managing a project?
Ala ‘Agile’ sufficient & necessary is my general approach. For projects which requirement heavy governance & safety guard rails a well-crafted RAIDD (including ‘D’ecisions) should be a central component of any project library. Along with an understandable plan on a page, a visualisation of a roadmap with key features, events or milestones & then frequent but lighter weekly reporting in the form of RAG (Red, Amber, Green) allows one to communicate key project messages to busy executive teams without burying them in detail.
With respect to Scrum team performance, leveraging dashboarding capability from tools like Jira & Azure DevOps helps to present velocity & burndown, & augment narrative with empiricism. DORA metrics from DevOps tools allows one to check in on Engineering team performance & capacity & packing this all up in a library of documents using tools like Confluence or SharePoint ensures the right people have access to the right information at the right time.
What’s the difference between Agile & Lean?
Whilst independent things in their own right, Lean comes from manufacturing back in post-war Japan. The notion of understanding value-streams & efficiency through waste minimisation was key in heavy manufacturing settings & some of this mindset & practical application of various events (Kaizen) can be applied to modern day organisational change management. Coupled with elements of Agile you can potentially deploy a strong set of tools & ways of working to help teams navigate change. Whether that’s implementation of Kanban, using Catchball for top-down consensus, five-whys & various other information gathering & problem-solving techniques now weaponised by management consulting firms Lean implementation can be a good way of ‘getting shit done’. Lean practises dovetail heavily into the business analysis area of a team & should be implemented with that in mind.
What does the Software Development Lifecycle consist of?
Fundamentally it covers ideation & prototyping, design & build, testing & subsequent deployment & then the running of the platform, product or service built. Automation of the steps is a core component across the lifecycle. The actual components are a set of six which are Discovery, Design, Development, Testing & QA, Release & Maintenance.
Within each stage there are various & sometimes complex sub-sets so ideation would rely on information gathering, user research for example, prototyping could include elements such as Lean MVP, design & build encompasses software engineering, Cloud technical architecture & cyber security, with testing & running involving automation, DevOps, IT security, etc. There are more to each of these but that is broadly the SDLC.
What considerations are there for a Cloud project?
For Cloud projects, project teams & organisations should consider a number of key elements. The migration to the cloud platform itself, data storage & management & the subsequent costs where cloud changes the expense model from CAPEX to OPEX. Due to this, observability platforms & effective monitoring is key. Other things to consider include cloud security, information management & Cloud architecture which will directly impact elements such as scalability potential & cost. Environmental impacts to cloud compute workloads can also be considered, leveraging containers & as-you-need-them workload deployment rather than always-on. Better for the planet & better for the companies bottom line.