Musings on Agile Performance Reviews and Goals

September 28, 2010

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.

5 comments

XebiaLabs said...

Interesting post, Dave. As more and more companies embrace Agile methodologies, we have begun to notice that it doesn’t just alter an IT team’s work style, it becomes a lifestyle! In order to fully embrace Agile practices, automation deployment is a key tool that will not only help development and operations teams increase their efficiency, but will also simplify managers’ jobs due to its self-sufficient nature. The emphasis on teamwork is an important element in Agile that, when combined with deployment automation, helps bridge the gap that often arises within an IT department between development and operations teams, making the entire process more streamlined. Have you found any other tools like deployment automation that aid the functionality of an Agile team?

October 4, 2010 at 10:38 AM
Dave Moran said...

@XebiaLabs,

Agreed! Agile does become a (work) lifestyle! I'd like to say that Agile simplifies a managers' job, but it does take time and effort for teams to become truly self-sufficient. It can actually complicate your life by managing at "arms-distance."

Automation is vital to improving results. As you point out, deployment automation is one means of improvement, and often overlooked. Automated testing in general is another big way to win: automated unit tests and regression tests in particular. You want to release often, and you want the ability to refactor with confidence -- test automation enables that, plus speeds up the entire development process.

TDD is something that I'd like us to experiment with; I've attended training and found this to be intriguing, as the instructor combined TDD and pair programming. The building unit tests and conducting a code review in one shot has appeal.

October 4, 2010 at 2:35 PM
XebiaLabs said...

Response:
Absolutely, tools like TDD and automated testing are important to improving results with agile. We agree with you that many people tend to overlook the benefits of automation in general, but it seems likely that as automation becomes more popular, so will the tools that aid its progress. Looking forward to reading more of your posts.

October 12, 2010 at 12:30 PM
Victoryperfect said...

Excellent sharing Thanks for share i am sure its must help me. thanks for doing this.

Scrum Process

April 7, 2011 at 2:27 AM

Post a Comment