One of my recent posts fictionalized how an organization that has adopted Agile development can work at cross-purposes. The moral of the story is simple: Agile development emphasizes teamwork in ways that are likely to challenge your existing management approach – ultimately demanding change.
The performance management process is one area that has been historically focused like a laser on the individual and will need to be adjusted as you adopt Agile development. Being a knowledgeable, capable individual contributor isn’t enough for Agile development. Individuals need to be good team players, an easy transition for some and not for others.
As a manager in an Agile organization, you won’t be assigning tasks to individuals, either. Agile development is about self-organizing teams that welcome and respond to change. This means that you cannot determine in advance what tasks individuals will be working on, nor should you. Teams will need to learn to self-organize, and their learning that means you cannot do the organizing for them. Period.
This is a good thing! This actually raises the bar on you as a manager and on those who are directly involved on an Agile team. People need to be technically competent and cooperative, collaborative team players. As a manager, you need to be able to grow your staff to operate in this new model – and do so from arm’s distance.
Abolishing performance reviews and focusing on previews is where I’d like to be. But we’re not there yet. Since we can’t predict what people will be working on because they’re a part of a self-organizing team, what do we do? Part of the answer lies in what is normal for any situation: It’s about what people know, how they apply that knowledge in actual practice, how they conduct themselves, and the contributions that they ultimately make:
Knowledge = what you understand
Skill = how that knowledge or understanding is implemented in actual practice
Behavior = how you conduct yourself in the performance of your job and how you interact with others
Contribution = the value that you provided through delivering something or helping others deliver on something
By using these ingredients, as a manager you can observe, solicit feedback, and discuss with each of the people that work for you where they are strong or weak, plus develop plans to leverage their strengths and shore up any glaring weaknesses. (I’m a believer in leveraging strengths as much as possible versus focusing on weaknesses, unless a weakness is strong enough to get in someone’s way or prevent them from advancing up the career ladder.)
In an Agile context, individuals require more than just technical abilities. They will need to expand their understanding of team dynamics and technical practices in order for the team to improve. I think the reason that Scrum/XP hybrids are taking hold is because this combination provides an excellent foundation for defining the rules and roles for team interaction (so the team doesn’t have to define them) along with technical practices that improve software development.
You can measure how much someone knows. Something like technical knowledge can be measured by testing – formally or through actual work where someone produces a design or working code that is peer reviewed. And in the technology industry, there is always new knowledge to acquire, and learning goals should be a part of the equation, including things like:
Technical: Learning a new technology or practice, such as a new programming language, test-driven-development, test automation, etc.
Process: Obtaining a deeper understanding of Scrum and/or some aspect of Scrum like planning, retrospectives, coaching Scrum teams, etc.
Professional Development: Written or presentation skills development, taking workshops on teamwork, etc.
In real life, there are those who acquire knowledge but fall short in implementing that knowledge. Sometimes they lack confidence or are afraid to fail. Other times, a little practice is required to develop the understanding into a skill that enables the knowledge to be used effectively.
For example, knowing how to give a good presentation and being able to deliver one requires a little stage time and constructive feedback. If you are a programmer, object-oriented design requires some real-world practice to cement your understanding or take you to another level. And your practice should be done under the watchful eye of someone with experience, so that you don’t adopt or reinforce bad habits.
Behavior, or how you conduct yourself, is obviously important if you are a member of a team. If you are a self-centered, arrogant, selfish person who can’t or won’t work with others – like sharing knowledge – you will have a problem being perceived as a good, Agile team member. While the former is an extreme example, small adjustments can make big differences in the context of teamwork, and sometimes individual preferences must take a back seat to align the actions of everyone on a team. In general, the best Agile team members have a blend of technical and interpersonal skills and the willingness to help others succeed that is unmistakable. I outlined some key behaviors in my post, Ten Behaviors Required for Effective Teamwork.
In the final analysis, we all must be contributing. If you want higher pay, your value proposition will be based on the above and the ultimate delivery that you make. Did you work on that really complex problem? Did you help someone else work through a complex problem? To contribute at higher levels, we all need to continually build on our knowledge and work at applying that knowledge, working in a virtuous cycle to deliver the goods.