What is Agile HR?

Before reading any further, you may want to check out my post “great sources of Agile HR“. I will update that blogpost regularly, when coming across something useful on my quest to understand all this.

In this post, I have tried to summarize what Agile HR means for myself right now. I’ll keep the option open to revise my view anytime it seems flawed, insufficient or non-valuable. I would build any agile people practices on the following values:

  • Trust people to be able and willing.
  • Transparency; If you can’t be open about it, don’t create it.
  • Value adding for the customer (or value adding for the work employees are daily doing to create value for the customers).
  • Decision making with the customer, or as close to the customer as possible.
  • Continuous learning and adapting.
  • Blank – Fill in yourself with a couple of more after deep thinking

What is Agile HR, then?

Creating adaptive people practices, valuable for the customer

Tailored, adaptive and transparent people-related guidelines, methods and agreements that support the Agile organization to create value for its network, customers and colleagues. (I shy away from the words “HR-policies” and “HR-processes”, because their main function is to control and/or standardize people issues).

Creating the people practices with the people, through using Agile methodologies and modern tools

Agile HR is about using agile development methodologies yourself to create the Agile people practices. This means incremental planning, experimentation, verification and adaptation loops with the employees. The HR Tech scene is bustling with new HR tech to support creation of people practices. It is like a candyshop…!

Removing silos between support functions

Seeing all development as business support/business development. If it does not bring value to the end-customers, don’t establish it. Using cross-functional teams to create great service where it makes sense (HR, Finance, IT, Comms…). At least always cross-check with the other functions to get their view on the emerging people practices.

Constantly reviewing and updating of the emerged people practices.

Ongoing maintenance of the people system is necessary. With this pace of change, we can’t expect that something we created together in 2014 will be valid in 2020, or that something created in a company with 50 employees could be useful when if company has grown to hundreds of employees.

 … Let’s get to work, then!

…Agile HR network in Finland is starting on Friday 4th April 2014 with a core team workshop around what we’d like to achieve. There are HR’s and Bz Dev people from front-row Finnish Agile organizations and associations. Excited!

Great Sources of Agile HR


This is a blogpost to share useful links and references directly linked with Agile HR. I will gather sources here, and update this blogpost now and then with more sources. Agile HR as a concept is very new. In the start of  2013 nothing much came up when googleing the term. The term and field is still a niche, but constantly growing. Now large, global consultancies are publishing relevant predictions about the future of HR. And surprise, surprise! Agile HR is popping up as the a grand development need for HR.










Here are some great links about Agile HR to get started with.

When googleing “Agile HR” a lot of other links cite the first two abovementioned sources, all kudos for Accenture and Bersin & Associates! I’d recommend doing your own reading and deep thinking. This is something you don’t learn through flipping through summaries. Agile HR  really can’t be summarized very briefly – since it turns both management and HR upside down compared with traditional thinking.

When you have a strong common understanding of the paradigm shift in agile thinking (compared with the traditional top-down, command-control, stick-carrot kind of people practices now present in most companies), you can start thinking about creating Agile HR practices.

HR, Welcome to planet Wanna-be-Agile!

Imagine you are in charge of the infrastructure of your city. There is a Mayor, some other important officials and managers, too. The higher the rank, the more decisions they make. Your job is to see that the infra is supporting those decisions. You see that the people have what they need to survive and to live a somewhat good life. Of course, there is some privileges for the decision makers to go first in line and/or be better off because they have such an important job. Also the decisions are made in committees, behind closed doors. Only the decision, not the reasoning behind it or the discussion around it are communicated to the people of this city, not to talk about giving the people a real possibility to have a say.

Most cities run this way, and you are comparing your infra to the other cities’ infra. You are also building the same kind of roads, same kind of services and measuring the same kind of things, as any other city. You know a lot of infra-people in other cities and pretty often people in your profession change jobs in between cities, but the work is not changing that much. You can create the infrastructure just a bit better, nicer and efficient than in the neighboring city. Decorations and nice slogans here and there. Services to the people, to keep them somewhat healthy, somewhat happy and somewhat productive. The rules of how to handle the infrastructure haven’t changed much in 30 years. In some cities your job is valued a lot, in some others you are seen to just take care of the necessities. You know that without a modern infrastructure and running processes the city would be a mess. That is why you want to call yourself a strategic partner, and sit in the decision making tables. In some cities you have the seat. Which is great! In some cities the mayor is such an old-school dinosaur, that what he needs and asks for is an infrastructure from the 70’s. This mayor usually finds another infra-dinosaur to run the infra for him.

Now imagine that you change jobs to planet Wanna-be-Agile. Your job (you think) is to create the infrastructure for that planet’s city, too.  The planet’s Mayor and his posse have moved to this planet from planet Earth. They know their job is to make all the important decisions. This planet is very different from planet Earth. Everything changes rapidly here. The people on planet Wanna-be-Agile are working closely with a group called customers. The customers are part of the system, keeping the city alive and pose requirements of the development of the city. Most of the customers are immigrants from Earth, or still living on Earth. The customers buy stuff from planet Wanna-be-agile and another planet, planet Agile. The mayor has never really experienced or traveled on planet Agile, but he heard it was a great place. The cities on planet Agile are doing pretty well. The cities on planet Agile constantly outdo cities on planet earth when it comes to serving the customers. To create a competitive city, the mayor wants to have the same infrastructure, same tools and same methods as planet Agile cities have.

Trainers chosen by the mayor and his posse train the people of Wanna-be-agile. The trainers come from planet Agile. The trainers from planet Agile tell the people at wanna-be-Agile,

  • “Hey, what is important is that you create competent teams, and decide most stuff yourself”.
  • “Yes, you have the freedom to change the infrastructure, and you are even urged to do that if it makes sense for you, your city and your customers.”
  • “The mayor will understand it takes time for you to develop your teamwork and productivity, and will help you succeed in any way the Mayor can”.
  • “Because customers are constantly changing their requirements and the world is changing so fast, you can’t really plan your long term work targets or performance.”
  • “You need to learn to live with the uncertainty and constantly review your estimates and priorities to keep on doing value adding work”
  • “Most important is to keep your workload on a healthy level and to deliver stuff to the customers in smaller batches so they participate in telling you if you are on the right path”
  • “Now here are also some tools and methods you can use to drive learning, working, collaboration and iterative decision making in your teams”.
  • “Because of this organic development no two cities or hubs are alike on planet Agile, they are all unique”.

The mayor or his posse are not participating in the training, nor dot they really communicate with the customers. They are busy with making decisions and plans. You as infra-manager are planning the infrastructure to mirror a top-notch Earth-infrastructure, and you want to call it “agile” and “high level service”. The mayor knows that the new tools and methods will drive performance up and service to customers will become quicker. He is planning in great excitement, asking people to estimate next year’s development. You copy a “best practice” performance evaluation system from Earth and start implementing that on top of these people-given estimates and plans. They gave the estimates themselves, right!? So they should know exactly what will happen during the next year. So let’s discuss individual bonuses on the basis of these estimates….

…OK, so you see where this is going?

Your people have just been taught self-directiveness, freedom and responsibility. Some people have been elected as coaches, just to keep the learning and collaboration on a good level in the teams. The people have been taught that “no plan holds” because that is a basic paradigm on planet Agile. The idea is to react to changes. It is a value-set, which the mayor, his posse and unfortunately you, too, are fully unaware of. You think you have some best practice solutions from planet Earth to serve the people in a great way. Using best practices from planet Earth or copying infra from planet Agile, but still keeping the decision making and infrastructure design on the management level, will create a collision of two sets of worlds.

Your well-meant control and planning block the people from creating a great Agile city.

What happens to the people on planet Wanna-be-agile? They probably first realize how fun, creative and effective working according to planet Agile paradigms are. Until they bump into the first possible bigger hurdle. The people are unsure if they really can solve the situation. So they go and ask the Mayor and his posse. The Mayor does what he is good at and what is quickest. He solves the problem or makes a decision. He drives the teams to realize the estimated schedule, because that is where his individual incentive is.  The people are not very satisfied with this, since the mayor really does not know the customers, who just came in with a lot of new requirements. The people have to work their butts off to get anything done by the deadline, with all the new requirements from the customers coming in. To keep the mayor happy they deliver something, which looks good on the outside but is full with flaws on the inside. This goes on for a while, until the people realize that the Agile values are not realizing at all and they are forced to deliver bad quality to keep up with the estimated deadlines. The Mayor thinks Agile tools and methods are not creating the value he was sure they would. The Mayor trust people less because they come to him with impediments, delays, bad quality, new infrastructure requirements.  What happened to following the great plans and performance objectives, which were working so well on planet Earth?! Why did the people give bad estimates, they were given the freedom to estimate and now nothing holds?

And you? You are baffled. You have tried to implement the best practices from planet Earth’s infrastructure, and maybe even copied some great infra tips from planet Agile.

What nobody has told you, is that planet Agile works upside down. There is no gravity on planet Agile. There are not even cities on planet Agile, but hubs and networks which dissolve and come together when necessary. The infrastructure on planet agile consists of dynamic rules and frameworks that are useful and necessary, until they are not anymore. The people are allowed to change the rules. Some hubs have different rules than others. There is no money incentives on planet agile, but people agree on what needs to be done to develop their hubs and networks. There is no point in setting incentives on the “what” and the “when”, because the customer folks are so unpredictable and want to change a lot on-the-go.  Social incentives and incentives on “how” things are done are used on planet Agile. The ones who really made it to planet Agile can’t imagine moving back to Earth or to planet Wanna-be-Agile.

It is not easy for HR on planet Agile. Luckily you don’t have to KNOW exactly how the infra should look like. You will find out, together with the people.

Personal note: I was born on planet Earth, worked there for 10 years. Because of my rebellious soul and due to understanding the sciences of biology, physiology and chemistry, my mind was always on planet Agile. Organic is a word which is at the core of planet Agile. That is a subject you as an HR professional need to look up carefully if you want to work as infrastructure manager on planet Agile.

PS. The young generation of people and customers are born on planet Agile. What does that mean for you?

Picture: http://www.freeimages.co.uk/galleries/space/planets/


A social neuroscience perspective on why replacing the management can be the best way to succeed in Agile transformations

The cliché “nothing is constant but change” does not hold any longer. Change in current business environment is not constant, but disruptive, massive, unexpected, and rapid. Many industries live through disruptive digitalization, requiring a whole new organizational paradigm to evolve.

Agile and lean thinking and methodologies have evolved in software development and industrial production (1).  The underlying principles in both agile (2) and lean are deeply philosophical and/or psychological, requiring a certain value-based re-evaluation of the most fundamental perceptions of human interaction and business, as we know it.

This human side of the agile and lean thinking is too often reduced to include only the tools and methodology available for agile and lean practitioners (e.g. scrum tools, kanban methods, charts, estimates etc.). The whole paradigm of agile thinking is distorted in many people’s minds, and many seem to be misusing these trendy words without really understanding the systemic changes necessary for agile to show real value and for the organization to become adaptive, agile and organic. At the core of these practices is the idea of self-organizing teams who work at a pace sustaining their creativity and productivity. (3)

In this essay I will try to explain through findings from social neuroscience why it is so hard, almost impossible, for a manager from the “old paradigm” to engage in an scalable agile transformation with a holistic, systems mentality. I will argue that the “old-school” manager’s or leader’s attempt to transform into an agile manager is socially really painful. To succeed the manager should reframe and redefine most of his unconscious habits spanning from what has been experienced and learned during his/her career so far.

Social Neuroscience findings

Recent social neuroscience findings shed light on the social aspects of agile transformations. First, it has been shown that social pain induces the exact same reaction in our brain as physical pain does. (4). Second, there is a lot of unconscious processing involved to identify possible threats and mostly unconscious, automatic networks taking care of avoiding and reacting to any pain or threat (5). What is really striking is how much we work on emotional autopilot, and how little of what we think, act or learn is due to conscious processing with reasoning and weighing logical alternatives (6). The more stressed or under cognitive load you are, the less you exert pre-frontal reasoning, reflection and emotional control over yourself (7) and the more you go on your habitual autopilot and reactive, emotional behavior.

The SCARF Model

On the basis of recent social and cognitive neuroscience findings Dr Rock presents a useful motivational framework for successful human interaction, the SCARF model. SCARF represents status (how you relate to others), certainty (the brain is basically a prediction machine, and our reward mechanisms are a lot about predicting correctly), autonomy (sense of control, even a false sense of control will help), relatedness (“in”-group vs. “out”-group) or fairness (humans i.e. reciprocate fairness and will give up personal gain to punish unfair people). If some of these five domains are dismissed, it has been found to be very harmful for our brain’s performance and our motivation. (8)

Discussion: Old school SCARF is different from Agile SCARF

Comparing the old school system’s SCARF with the agile system’s SCARF reveals so many juicy insights.

If you are a manager in the old school system you have built your view of yourself during decades through the old-school paradigm: Your social wellbeing is flourishing through a higher rank and status in organizational charts, and your opinion is always attended for among your team. There is relatedness and decision-making behind closed doors with your fellow management members on “strategy hideaways”. Your autonomy is high and you can decide a lot yourself. Certainty might not be high, but you tend to create a false sense of it with creating budgets, long term plans and action plans for your teams to follow. You “implement” changes top-down. You know sooner than your team of any upcoming changes. So, your social brain is not violated that much in a traditional hierarchic setting when in a leading position. You are in the center.

What is striking is that according to personal experience the traditional SCARF domains are different in a pure agile system. In the agile system status is earned by competence and open collaboration, great communication skills, helpfulness, service-mindedness, transparency and ability to learn quickly. Status does not equal a position or a title. Certainty is low by default in an agile system, because it builds on constant uncertainty and adapts to value adding changes through the PO’s and team’s decisions. Autonomy is extremely high in a “pure” agile system, with team members defining their level of load, and with transparency steering incremental planning and prioritization. Relatedness is certainly on a higher level in the autonomous cross-functional agile teams, who have a coach facilitating their work, compared to manager-driven teams relying on their manager to plan and direct work. Due to the transparency and clear common social rules, fairness could (in my opinion) be perceived higher in agile teams compared to traditional teams, where manager’s likings may direct freedom and tasks. So, the team’s SCARF domains are definitely heightened compared with a traditional setting! From the social neuroscience perspective the agile culture is definitely very brain-friendly for the team.

Team’s gain & Manager’s pain

Let’s go with the fact that most of the managers’ behavior is directed by unconscious processing. Thus, the manager uses the old “frames” he has created through his learning and experience, as we all do. Many aspects of the agile transformation will feel like pure social pain in the traditional manager’s brain. His status is clearly lowered, he cannot direct work, and he shouldn’t plan in detail (less certainty). He possibly is not on top of the project’s progress because understanding several teams’ visualized backlogs is too hard (less certainty, again). Frequent changes lead to transparent decision making situations with requirements to i.e. re-schedule releases, add resources or even cut sales if management wants to keep the agile system healthy. Instead of keeping senior management happy with high-fly promises, and pushing teams to ridiculous amounts of work to finish on time because your own status in on the line the management needs to decide on helpful actions real time and with full transparency. This probably lessens the relatedness within management teams, since they need to, instead of having consensus of nice-looking power point plans and letting the team’s deal with how to get it together, really take decisions on even contradictory resourcing or investments on the run.

Applying social neuroscience for leadership in agile transformations

What could be done differently to ease the pain managers feel in agile transformations?

I’d say, they would need help with recoding their whole “SCARF” and creating new unconscious frameworks through hard re-design of habits. Management would need some serious help in getting their own insights of  deep lying paradigm differences between the system they have been living in for the last X years and the new, agile system. Managers could certainly benefit from stating out loud how status is earned in the new system, not to feel disempowered when not able to direct and drive work. Management would need some up front real-play experience in how they might feel when they first encounter the social pain the agile system causes them. The emotional brain guides a lot of the unconscious processing and reactions, so learning to recognize the unhelpful emotions on the run, and having emotional control mechanisms is crucial for success (becoming aware, and using conscious processing to overrun the automatic, old reactions). Managers could learn to derive social pleasure from the autonomy, fairness and constant learning their team exerts, and realize that any impediments, failures or wrong judgments are growing the team’s competence and making them more proficient in the long run. They could feel relatedness from remodeling the incentive systems in agile organizations to share success evenly, to incorporate social incentivizing, to share their knowledge and learning in social media, and by networking with other new thinking leaders outside their own organization.

Now that was hilarious, wasn’t it?

Do you really believe the old-paradigm managers would do any of the above mentioned? Neither do I. The majority of status-aware senior managers who fought their way up the traditional ladder are clearly not able to change most of their unconscious emotional framework anytime soon. The biggest paradox is that the senior management is usually initiating the agile transformations. They know their business will die without agile approaches. I find it a bit cynical, actually. After decades of running top-down programs in “change management”, “break resistance”, “create a sense of urgency”, “implement”, the pace of this world and the quick, small disruptive competitors turn the pressure of change back on the management. Unfortunately, they are fully unaware of themselves being the biggest impediment for succeeding in scalable agile.

Management thinks they are “implementing” a new set of tools and methods to make the organization adaptive, but this ignorance backfires in an agile transformation built on the wrong, old paradigm. It is easier for management to think about agile as a set of tools, than sit down and re-evaluate the whole systemic thinking, including their thoughts on how they view a human being and their own capacity of trusting others. When the new system runs into problems, the manager’s brain is under stress, and he acts even less on reflection and more on the old autopilot he has built up during his career. It is easier to sit there in pain, saying: “I’m not really convinced of this agile methodology” when the newly exerted transparency presents some clear flaws of the organization and confronts the lack of important, real time, high level decision making. Sorry guys, I would not bet my cash on you changing!

After studying neuroscience for only some months, I am quite convinced that traditional managers cannot see this through. It is too a big turnaround, requiring recoding most of their unconscious and emotional processing.  Thus, my harsh and clear recommendation is to recruit leaders who already express, think and live according to the new value set. Leaders, who clearly and publicly understand and share the whole underlying paradigm of agile and lean thinking.

Your old-school hotshots are not future stars in the agile system, but impediments. And you don’t have the time to wait for them to recode their innermost selves.


  1. Lean Manufacturing System, Toytota Production System, Wikipedia
  2. www.agilemanifesto.org
  3. Dingsöyr et al, A decade of agile methodologies: Towards explaining agile software development, J. of Systems and Software 85 (2012), 1213-1221
  4. Eisenberger et al, Does rejection hurt? An fMRI study of social exclusion, Science302, 290 (2003). Eisebnerger et al, Why rejection hurts, a common neural alarm system for physical and social pain, Trends in Cognitive Sciences 8 (7), 2004. See also more recent Eisenberg groundbreaking research and articles.
  5. Spunt, R. P. & Lieberman, M. D. (in press). Automaticity, control, and the social brain. In J. Sherman, B. Gawronski, & Y. Trope (Eds.) Dual process theories of the social mind. New York: Guilford
  6. Lieberman, M. D., Gaunt, R., Gilbert, D. T., & Trope, Y. (2002). Reflection and reflexion: A social cognitive neuroscience approach to attributional inference. Advances in Experimental Social Psychology, 34, 199-249.
  7. Arnsten et al. Stress signalling pathways that impair prefrontal cortex structure and function. Nat Rev Neurosci. 2009 Jun;10(6):410-22.
  8. Rock et al, SCARF ® in 2012: updating the social neuroscience of collaborating with others, NeuroLeadership J., 2012.