These are the questions we hear the most.
Where and how should we start with Agile HR?
We had a lovely and active panel discussion with Agile HR practitioners about this theme. The panellists are from Lockheed Martin, who have recently invested plenty of effort in redesigning their way of working, delivering value and developing products, both in the business and in the support functions.
Lisa Richards, Jon McDonald, Jeff Mallory and Sommer Terry were discussing their own experiences bringing Agile HR alive in their teams and organisation with Riina Hellström, the founder of Agile HR Community.
Without further ado, here are some of the tips the wonderful panel shared with what’s happening where and how to get started:
Meet people where they are and keep it simple. Some people are keen and willing to dive into Agile and try out new ways of thinking and working eagerly. Other are more careful, or even dismissing the idea of incremental, stepwise delivery. We have to be mindful of what practices or conversations we start with, or if we even need to use the agile jargon at all. Instead of “let’s have a retrospective” we might say “let’s get together and discuss what went really well, and maybe find one or two things we can improve over the next two weeks.” If you can’t flex your approach of adopting and supporting Agile according to your user’s need, you aren’t really agile in the adoption of Agile.
Start where you CAN and drink your own champagne. When some HR professionals get properly trained in Agile HR, you can together identify areas of expertise or projects, where you can decide to use the Agile approach yourself. Lisa said it felt like “being a baby on a wiggly horse,” when starting to adopt the practices and the mindset in her team. This experience of being your own guinea pig, of the novelty of changing practically your whole way of working, of the tickling insecurity shared by a team, is something that will carry you a long way when you are supporting others through the change. “Being comfortable with being uncomfortable” was a nice phrase used, as was “creating a safe space to share and learn, fail and discuss this together.” We shouldn’t scare people off with this new way of working, we should inspire and engage teams to try. Great projects or environments to use Agile are, for example, projects where the team needs a lot of interaction with people (for example developing the HR service function), projects where the end product is ‘ambiguous’ and involves change for or with people (for example a culture change), or a product development where you expect the external requirements to change a lot during the project itself (for example talent and workforce planning in the midst of the pandemic resignation wave).
Offer a way out. If Agile doesn’t help teams do smarter things and do them smarter, there’s always a way back to how you worked before. This will reassure people to give Agile a go, when they know they are not breaking anything, the experiment or test is not irreversible. As Jon said, “having the blueprint for the previous way of working available was needed for some teams to try Agile out, but none of the teams have wanted to go back.”
Prepare to be challenged by people outside your team (from people who are not onboarded to Agile). It will feel and seem unusual for the people who are not accustomed to Agile to see a team involve them into the earlier stages of product development or to see low fidelity mock-ups or models. Some stakeholders aren’t used to giving constructive and clear feedback or, as Jeff put it, are confused about “why teams are bothering them to prioritise giving feedback of an unfinished product.” We have to onboard and include the stakeholders in not just how to participate, but also explain to them how we work and why we work this way.
Start with something, anything that makes sense. Bring in a Kanban board to visualise work together (but don’t call it Kanban), have a retrospective where you discuss improvements and acknowledge successes, try out prototyping and testing different ideas quickly and with low effort. Lisa shared that they are doing `Scrummychats` (instead of coffee chats) in her team, bringing in an Agile theme and discussing it, playing an agile game or learning about some Agile theme. This keeps the learning fresh and the conversations going on. A very nice way of embracing continuous learning and inviting people to improve their Agile practice together.
Remove the need for change management by involving the users in the development stage. Sommer shared a lovely success case, where they worked cross functionally, involving leaders into developing an annual cycle process, giving feedback early and often. The team reconnected with users and stakeholders to evaluate prototypes and validated the solution, step by step. When reaching the point of implementation or adoption, 100% of the stakeholders were aligned with the solution – 100%. That’s just unseen in HR with the traditional waterfallish way of developing people products and services.
