Anyone living and breathing software development heard about agile way of working, agile processes, and the key believes of the agile community Manifesto for Agile Software Development. It is just a couple of sentences that 17 likeminded software professionals signed in 2001 and that had a huge impact on the way modern software is being developed. In short, agile software development is a way of thinking that puts big emphasis on close collaboration between a developer and a customer, face to face interaction, frequent releases of software features that brings business value, small teams, and easy to understandable and maintainable codebase as opposed to long written specification, contracts, huge teams with many different specialists and occasional release of software.
When you start developing software using these key principles you are also starting to wonder how to apply the same when building teams and what culture you need to create so people truly embrace the agile way of working. If you are an HR professional who is being asked the organization to be more “agile” you need to understand what it even means.
Let me give you my perspective at these key principles and how they translate to people management and to HR professionals out there:
1. Individuals and interactions over processes and tools
This one doesn’t need a translation. It is a core of what leads to agile way of working and critical to have the right mindset. Software development is an art (with a bit of science) and it requires rather creative individuals who are able to come up with ways how to solve business problems using technology. When you need creativity you need to give people the freedom to think “out of the box” (to use a cliché) and not to be unnecessarily inhibited by processes and clumsy tools. It is all about individual people and being able to easily interact with each other. It is about them being able to explore their own potential rather than acting like robots blindly follow an outdated processes.
If you are an HR person you should never try to create an HR policy for everything. Let’s keep couple of regulations (only as required by law) and for the rest let’s just talk to people, lead by example and use a common sense.
2. Working software over comprehensive documentation
In the realm of people management you could translate this into a statement like “Culture of trust over Culture of regulations”. The original statement is talking about the need to build software that brings business value and ideally do it in a way that the end user (or other developers working on the project) can use the output without the need of extensive documentation.
When it comes to people management this means a culture of accountability, transparency, clarity and trust. You don’t need tons of rules and regulations. These would go against your ability to build creative teams. What you need is to communicate clearly what the goals are, what the potential roadblocks and constrains might be, who is responsible for making things happen and ensure continuous flow of information so everyone is constantly aligned and understands what’s going on. If you have these then it is relatively easy to build a culture of trust that will go hand in hand with the creativity we talked about in the first point.
For HR professionals the key will be to provide help in the areas of organizational development (how do we align our organization to the needs of our customers) and in information management (how do we ensure that our employees understand why are we here and how to get things done in our company).
3. Customer collaboration over contract negotiation
Purely from position of people management I would rephrase it this way “People development over People management”. It sort of extends the previous point. The original meaning of this point is based on the assumption that things are changing and no one really knows what they want. Instead of trying to compile a comprehensive list of features and set every single detail of how the software should work and how the outcome should look like in the contract the agile teams work on daily basis with customers and essentially build the software together by short iterations and frequent feedback loops.
In the people management world this means rather than trying to manage the teams (you could even say micromanage) it is better to give the team the ability to do what needs to be done. How? By getting the right people on board, providing them the tools needed, and ensure they have the skills and competences.
This means investing in growing your team. In line with the agile world you should focus less on theoretical knowledge and certifications and put much bigger emphasis on skills that bring immediate business value. It is nice to have a knowledge of how something works but if you cannot take that knowledge and apply it to a particular business problem it is meaningless.
You should also consider how focus on people development aligns with any performance management processes you might have in place and how you award good performance. Your focus shouldn’t be punishing past mistakes but rather coaching the team to understand what to do better the next time. In fact, most of the agile processes are very strong on so called retrospectives that ensure frequent feedback followed by immediate corrective actions. Mistakes are allowed as long as you learn from them and ensure they don’t repeat again.
4. Responding to change over following a plan
Another one that is widely applicable without any change. Flexibility is the king. It is great to have a multiple year long career plans for every single person in the organization and talk about how to get from junior developer, through intermediate to senior developer, then to manager and a director, but realistically that gives you and the team member very little room to maneuver. Isn’t it much better to talk about competencies and skills rather than about titles? The discussion should be about how your team keeps their skills up to date, how they become better and better at what they do (“It is not just about getting things done but getting things done while learning something new”), how do they embrace the changing needs of the business (“I really love writing backend code in visual basic” versus “I love building products using whatever technology makes sense”).
You need to work with the teams to be ready to reorganize every now and then to align with the business needs, you and the teams need to be ready to go above and beyond their job description. Just imagine going to your team and having a conversation along the lines of “I know you are a developer who writes code, but maybe you would write build better product if you also tested it, if you supported customers who have troubles using the product, or if you sit on a sales call with prospects. These things may give you very different perspective on your work, shift your priorities, and give you additional ideas how to build better products”.
Put it all together and you’ve got a clear understanding of what does it mean to move to agile software development and to agile organization. It is not just about starting to use a new process. It is about changing your organization, culture and mindset of people. If you want to be truly successful it is not just about software developers but about every single department and person in the company. Only then you can truly harness the power behind the agile movement.
What are your thoughts on agile movement? Do you work for organization that fully adopted agile as a lifestyle? What are the things you struggled with?
Originally posted at LinkedIn.