12 Principles Of Agile For HR Professionals

Are you a manager or an HR professional working for a software development organization that is moving towards agile way of developing software? Have you considered what you need to do not only to change your processes but also to change the minds and hearts of people on your team? Last week I talked about The Agile Manifesto and how does it translate to people management Agile Manifesto For HR Professionals. This week I will dig a bit deeper into practical details using The Twelve Principles of Agile Software as a guiding force:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software – for the purpose of people management you can translate “customer” into “employee”. So what are the needs your employees have that you should satisfy? It starts with fair salary and considerate treatment and leads to career opportunities and continuous development. When employee leaves your company she should be better than when she joined. More knowledgeable, with bigger value on the job market, and better equipped to deal with the world out there. This all means you need to lead by example, instill the right values and let (and encourage) people to grow. Consider what is written in Don’t Manage. Empower!, One Question You Should Never Ask and The Real Leadership Shows When You Are Not The Boss.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage – always be ready to challenge your team to do better and/or new work. At the same time be ready to adjust your HR practices in a way the business needs. This means that you cannot have too many heavyweight processes that are difficult to change and you cannot have everything documented. Just document the minimum required by law (keep in mind different labor laws in different countries) and then use (and encourage others to use) a common sense in dealing with daily problems.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale – what is the most critical work you as a manager or HR professional need to deliver to your team? Feedback! To enable your team to grow you need to continuously deliver feedback. Don’t wait for big yearly performance review but offer small pieces in a timely manner. This is the way you will help your employees growing. For some tips on how to deliver feedback check Now, How May I Help You?, and you can check what to do when you have to deal with underperformers The Art Of Giving Second Chances.
  4. Business people and developers must work together daily throughout the project – don’t pretend you know all the answers. If you want to introduce new policies or to change a strategy just talk to your team. Working together will ensure that you are not making rush decisions and will help you to introduce changes. By involving others and getting their buy-in you make any transition much smoother. There are many ways how to work with the team in such a way that at the end of the conversation you have a clarity and common understating of why something needs to be done, what is the ultimate goal and how to get there. Try to use tips described in What Problem Are You Trying To Solve?
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done – you need to get the right people. You can always train skills but you cannot really teach attitude and motivation. These need to come from within and your job is to ensure the right people are joining the team. Once you have these people on board, give them a vision and tools they need and then just be there to listen, provide feedback and help removing obstacles. You can get some tips on how to hire great people in these articles Hire For Strengths, Not Lack Of Weaknesses, Getting The Perfect Hire, and Effort And Attitude Beats Talent And Knowledge.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation – spent us much time with your team as possible. It is not that you want to micromanage, it is that you need to be around to help. Your role is to serve the team by providing means to create value and help dealing with problems. Regardless whether you are located in one location or have the team spread geographically your job is to over-communicate. You can check some tips and follow some of the practices described in Communication Shouldn’t Be Efficient and It Doesn’t Matter What You Say.
  7. Working software is the primary measure of progress – let’s translate this to people management speak as “working and motivated team is a primary measure of management/HR success”. The business goals will be delivered only by those who have a mission, understand the end goals, have the skills, are motivated and are able to work well together to reach these goals. If you are a manager who “manages processes” then you have no place in having any subordinates. The real managers and leaders don’t spend their time by managing processes but rather they spend majority of their time managing and helping the people they are responsible for. More on this in You Manage Things, You Lead People.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely – understand that even the most loyal and hardworking person will break eventually if not given chance to recuperate. You may ask your team to go above and beyond every now and then putting them under undue pressure every single day will just lead to their burn out, low morale and nonexistent productivity. Challenging the team to do a bit more than yesterday is fine since that is the way to grow but it needs to be done carefully and within reason. This goes to all aspects of managing teams. It is great to be flexible and change often but there is a threshold beyond which more changes and challenges are not sustainable and will just wear people down. Everyone needs time to recuperate by slowing down a bit and having some level of stability. You can find more thoughts on moving fast while maintaining your sanity in Want To Be Seen As A Leader? Be Fast!
  9. Continuous attention to technical excellence and good design enhances agility – leading by example and promoting the right values by refusing mediocrity is the key. Once you start tolerating or even worse doing a sloppy work others will see it and consider it acceptable. Mediocrity is the ultimate enemy of greatness. If you want your teams to be great you need to show them what great means (lead by example). You also need to constantly work with the team members and identify those who are not buying into the vision, who don’t want to collaborate with the team, who don’t have the skills or who decided to they don’t really want to contribute. Once identified you need to deal with them quickly. Help them up level their skills, help them to understand the goals, help them to connect with the right people or if these don’t work help them out of the company. Even one bad apple can spoil the rest and it is your role as a manager or HR professional to act swiftly. Consider some of the thoughts in Your Heart Is Not In It Anymore and How Can You Motivate Others? You Can’t!
  10. Simplicity–the art of maximizing the amount of work not done–is essential – as Albert Einstein said “Everything should be made as simple as possible, but not simpler”. When it comes to HR practices it teaches you to avoid micromanagement, to avoid unnecessary red tape and comprehensive regulations. Finding the minimum of things that should be documented to satisfy the law and the need of the organization is one of the most difficult tasks HR person can have. It is way too easy to succumb to the mindset “we should have a policy for this” every time a people problem comes up. Resist this and rather spend the effort of educating the teams on what fair treatment, open and honest communication, transparency, and collaboration actually means. If you spend all your time on writing and enforcing policies than you have no time to actually help others to learn, no time for providing feedback and helping to build the culture of getting things done. This is a very tricky proposition especially in distributed teams coming from various cultural backgrounds but everything is possible. You can check some tips in So You’ve Got A Remote Team. Tricky… part I., part II., and part III.
  11. The best architectures, requirements, and designs emerge from self-organizing teams – one of the most controversial (to some) and difficult aspects of the agile movement. Once you hire great people you need to let them do their job. Self-organizing teams are a way to prevent undue pressure from people who should have no say in what is being worked on. It doesn’t mean you need to introduce holacracy or similar concepts. It means you need to create a clarity around who is responsible for what and not mess with it every time a small issue comes up. To be able to let the teams run free and get the job done you need to have the right mix of people in the team. Building meshed organization where each cell contains all the skills necessary to get the work done is the key. Extensive reliance on collaboration across different departments who may have competing goals is not the way to go if you want to have highly agile environment. Some thoughts on how to build such a team are share in this article How To Build A Team And Not A Random Group Of People and How To Hire A Strong Software Development Team.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly – and we are back to feedback. One of the key services any manager or HR professional can provide to the organization is to provide or at least facilitate regular, frequent, and constructive feedback. This can mean helping to resolve any communication issues within the team, help people to grow or to help the team to act as a cohesive unit. For a healthy organization it is not only about feedback flowing from top to bottom but also about frequent feedback from the lower levels of the organization back to the top. Only by this you ensure that top management has good understanding of where the organization is and what to do to move it in the right direction. You can find some thoughts on dealing with communication issues and feedback in these articles How To Deal With Communication Issues, How To Deal With Broken Promises.

When you put it all together you will find that people management in agile environments is not about processes or a devote attention to a particular development and management ideology but rather about flexibility, trust, frequent feedback, transparency, and lots of communication between all the stakeholders.


Originally posted at LinkedIn.

For more read my blog about management, leadership, communication, coaching, software development and career TheGeekyLeader or follow me on Twitter: @GeekyLeader

Agile Manifesto For HR Professionals

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.

How To Hire A Strong Software Development Team

Building a strong team is a prerequisite to shipping successful, innovative and good quality products that customers love. But how do you build a software development team capable of doing it? You build it lean and mean. In How To Build A Team And Not A Random Group Of People I outlined the basics of building any team and today I will focus on building a small, agile, engineering team that will be resistant and able to execute. To recap the basics from the previous post. I would urge you to:

  • Hire for strengths
  • Hire for gaps
  • Hire for cultural fit
  • Hire the right, not the best, person
  • Hire by committee

It starts with technology

And now to our engineering team. It all starts with technology. Or does it? What technology stack will you be using? If you are hundred percent sure on programing language and technology stack it is an advantage to hire for these, but I would argue that ultimately it doesn’t matter. Unless you work on some legacy product where the technology is given by its environment or business constrains I believe that it is better to hire great, smart and talented engineers who will be able to flexibly shift between technologies as needed, than bunch of experts in one particular programming language.

Hire for smarts not knowledge

We are living in fast moving world and especially in technologies the world is moving even faster. Yes, you may be building your products in C++, Java, or .NET which could be considered stable and even old languages but if you are (un)lucky you may need to build applications (like SaaS) using whole bunch of relatively new technologies and what is worse there are constantly evolving, changing, and new are emerging. For a team that builds brand new product it may be required to learn new things as they go and as the particular needs demand.

With this in mind, hiring a great Java or .NET developer might be a good call but that is not a requirement. The most important is to hire a brilliant and talented engineer who is able to solve complex problems and pick a technology as needed to get the job done. You recruitment process needs to be aligned with this requirement. And yes, if your technology is set, then by no means, hire also for skill in a given language since it will save you time to get that person up to speed. I would suggest you check this article first Effort And Attitude Beats Talent And Knowledge.

Hire for flexibility not experience

You need some experts on your team but when developing modern software flexibility will be more desirable. When it comes to expertise you need someone with a domain knowledge. Bring a true expert who can mentor the rest of the team, but make sure the team can pushback otherwise you run into danger of the “old thinking” and any competitive advantage in the form of innovation will get out of the window.

When it comes to technology there are some circumstances when you need someone with a deep expertise in a given technology. For example, if your product needs to handle huge amount of data you may need someone who is really good at database performance, data optimization and similar topics that are difficult to study from a book and come only with experience with a particular database engine.

When hiring an expert who is focused on one technology make sure you balance the team with bunch of other people who will bring the smarts and flexibility in case the technology shifts.

You hire for cultural fit

Mindset is everything. For all this to work you need to build a sense of ownership and accountability. These things don’t come easily to everyone so your main concern should be to finding people who will identify with your goals, who will share the passion for building a great software, who will share the need to make a difference and to help solve problems for your customers. If you have these on board you keep the team together in good and bad times, you give them autonomy and they will build together something great.

So how could your perfect team look like?

As usually, it depends. It is always a question of what you are building, whether the team sits together in one time zone, what is the management structure in your company, what budget restrictions apply, what processes will be used and many other aspects. But assuming you want to build a solid product development team that will have the right skills, will be given the needed autonomy, will work within some agile processes like SCRUM, you will need these:

  • Product owner who owns a vision and requirements for the product and works closely with external stakeholders
  • Product designer who ensures the overall design of the product and that it solves the problem you set to solve
  • Architect who leads the technical direction of the product and have the final word on technologies used and any technical arguments and will be responsible for performance and scalability
  • UX designer who is responsible for designing workflows and usability
  • UX researcher who is able to gather data from customers or potential customers to ensure that feedback is gathered well in advance of the final shipping date
  • Graphics designer who is responsible for all the visual aspects
  • Writer who ensures all the textual descriptions are easy to understand for the target customers, and the right amount of text is presented
  • Backend developer, or two to build the core technology that does all the magic, deals with gathering, storing and manipulating data
  • Frontend developer, or two to build what the designers came up with and provide a great simple to use, scalable, and responsive interface to the user
  • QA dude to ensure end to end quality of the release, ensure that quality is built in through code reviews, unit tests, automation, and other means and is the last line of defense against shipping broken product
  • SCRUM master to have a servant leader who keeps the machine running and removes obstacles for the team

Lots of people, huh? The good news is that not all of them need to be actual full-time employees but many of the roles can be combined. You probably don’t need a full time UX researcher and can combine it with the Product designer or other role. You don’t need full time Writer and can combine him with another role. And you definitely don’t need full time SCRUM master. That is a virtual role that can be even regularly rotated across the team.

The bad news is that for this to work really well you need to build in redundancy. You may get one strong UX designer but you need someone else on the team who will have at least decent UX design skills. Why? To be able to deliver even if your main UX guy goes on vacations and to actually constantly challenge the main UX guy and to be able to challenge the expert and keep him at his best. And the same applies to any other role. What does it mean for the software developers? Well, it leads to the need of hiring a full-stack developers rather than experts focusing on niche. You get one strong frontend guy, but anyone on the team needs to be familiar with frontend technologies and step in. You may have one strong backend guy (most likely the architect) but even the frontend guys should be able to write backend and deal with databases.

So again, when you are building your next team think about expertise, smarts, flexibility, culture, and redundancy.


What is your recipe for building a great engineering team? What sort of people would you require to build a new successful product? Do you have a completely different approach to building software development teams?

Originally posted at LinkedIn.

Good And Bad Software Engineering Manager

What does it take to be a successful manager in a progressive software development company? What are the traits you need to have to build solid software development teams and ship great products? I have recently read a great book The Hard Thing About Hard Things by Ben Horowitz and in one of the chapters he is pointing out something he wrote years ago when building his product management team: Good Product Manager / Bad Product Manager. This made me think about what does it take to be successful as software development manager and this is what I came up with…

Good engineering managers understand the development process, constantly strive to improve it and make sure team follows what was agreed. They understand the key priorities for the team and are able to make difficult decisions when the team is being forced to handle more than possible. Good engineering managers take it on their shoulders to have the tough discussions with other stakeholders. They challenge the team’s estimates and push for as realistic view of the work as possible.

Bad engineering managers push the team to follow the process mindlessly without understanding that the process is just the means to some end and not the end by itself. They are afraid to make difficult decisions. They would rather push the team to provide unrealistic estimates than face the other stakeholders and tell them that the requirements are not doable.

Good engineering managers know the industry and what is the standard. They are constantly in touch with Product Managers, Sales and Technical Support to know what the market looks like, what the product strategy is and why there are certain priorities in the product. Bad engineering managers wait for product management to tell the team what to do and are not able to provide the engineering team the big picture.

Good engineering managers focus on creating value for customers. They drive the team to focus on reducing issues related to installation, upgrade, integration, supportability and maintainability. They negotiate hard with product management to limit the amount of technical debt. Bad engineering managers just stay away from any engineering related decisions on the product.

Good engineering managers understand the content of the release, what is behind every single feature and are able to explain the current status even when woken up in the middle of the night. Good engineering managers know what is the product team working on every single day, they are actively identifying issues and risks and drive them to resolution.

Bad engineering managers are just proxies. They rely on information fed them by the team leads. They bring no real values neither to the project, nor to the team. Bad engineering managers communicate poorly outside of engineering, and frequently hide the issues in the hopes that it will get somehow resolved. When being asked for the status, content of the release or biggest risks they have to go back to the team and ask.

Good engineering managers provide feedback, raise risks and issues and make sure these are discussed and resolved. Good engineering managers ensures that the teams follow the best engineering practices and that these are shared between the teams. Bad engineering managers don’t even know what their product does, they treat people as numbers and have no idea who the best and worst performers on their teams are. They take no interest in understanding the technologies and people. They are essentially just administrators who shuffle paperwork around.

Good engineering managers own the escalated issues from Sales and Support and ensure their prompt resolution. In urgent or sensitive cases they are willing to jump on a call with a customer to explain the situation and discuss the steps to resolution. Bad engineering managers hide from responsibility and hope that someone else will have the difficult conversations when dealing with customer issues. They always point to problems somewhere else rather than fixing real (or perceived) issues within their teams.

Good engineering managers regularly communicate with all stakeholders and build good relationship with them in the times of peace so when there is a hot issue to be resolved they can tap into the pool of goodwill and resolve it promptly and to everyone’s satisfaction. Bad engineering managers just sit back and talk to other stakeholders only when being triggered by them. They don’t care about relationship building and then they are unable to resolve issues without escalating to higher management.

Good engineering managers understand business priorities and are willing to shift resources around as needed. They leverage teams around the globe and are willing to help other products outside their own sphere of responsibility. Bad engineering managers are unwilling to release their people to other more important products being afraid of losing power. They are always looking for excuses why their product is more important and don’t keep the business needs in mind.

Good engineering managers are heavily involved in recruitment understanding that only by getting the right people on-board they can build first class products. They develop their people and provide opportunities. Good engineering managers understand that only by building a strong team under them they can get to the next level themselves. They take no short cuts and know that developing people takes time and effort. They know that one of the key tasks of successful leader is to inspire the team, set clear expectations and provide feedback. With this in mind they are actively participating in on-boarding of new team members and ensure that every person on the team know what is the expected behavior, what makes this company successful and what will make him successful as well.

Bad engineering managers focus so much on politics and numbers that they forget about the people who do the work. They don’t provide feedback, and don’t talk to their teams. Bad engineering managers spend the time only with team leads and delegate any interaction with the rest of the team to his team lead. Bad engineering managers are so busy dealing with current issues that they are not able to build scalable team that would eventually prevent the issues in the first place.

Good engineering managers are able to use money wisely and train the team to do the same. They understand that only because there is a budget for something it doesn’t need to be spent if there is more cost effective way to solve the problem. Bad engineering managers constantly complain that there is not enough budget for all the things they would like to do without trying to work around it and come up with less expensive options.


What is your recipe for a great manager responsible for software development? What are the skills and behaviors you are looking for?

Originally posted at LinkedIn.