Measuring Performance for Teams

If you've ever been in an organization that had performance reviews, you may have found yourself wondering whether the measurement process used to evaluate your (and your team's) performance made sense, and if there was a better way. Even if you have goals that can be evaluated quantitatively, rather than some metric that feels arbitrary, you may feel that your personal goals may run counter to the success of the your team. For example, you may wonder whether it makes sense to help your colleague on her high priority project and risk missing a deadline for your (lower) priority one. Sometimes the problems with measurement systems are because people just don't measure well. In other cases, it's because it's impossible to measure all of the things that matter.

Rob Austin's book Measuring and Managing Performance in Organizations gives you a model to understand why measurement systems become dysfunctional, and an approach to avoid dysfunction when you are measuring.

Austin addresses some core issues that agile (and other) teams face:

• How to evaluate and reward individual knowledge workers doing complicated things in teams
• How to motivate the individuals on the team to do what helps the team meet their goals, and
• What performance measurements are helpful, and which just add noise.

Austin explains why individual measures and goals may be counter-productive unless you can measure all of the aspects of a person's work, why most people want the team to succeed, and how that desire for team success is a key motivator, and why a staple of agile project management: visible and frequent feedback on team progress can improve your chances of success. While this book was written before agile became a popular term, anyone familiar with agile methods will find the ideas in this book in tune with agile methods.

Much of what I learned from reading this book seemed obvious in retrospect, but Austin explains the problem with clarity and precision, making observations that only seemed obvious once I read them. Early in the book, for example he points out:

Employees true output (such as value to the  organization) is intangible and difficult to measure; in its place organizations choose to measure inputs (such as the amount of effort devoted to a task...)

Which seems to be such an obvious problem with many evaluation systems that you wonder why so many organizations still do it.

Reading this book won't give you a cookbook for designing a motivation and performance evaluation system.  This is a difficult problem, especially for those working in an industry where there is a strong desire to quantify and measure. But this book will help you to understand the problem and enable to evaluate and improve your current practices.

While Austin's book will help you understand the model behind effective performance measurement, there are also more day-to-day practices you need to help your team be successful. For these  consider reading Johanna Rothman and Esther Derby's book Behind Closed Doors: Secrets of Great Management, which is an excellent guide to the day to day process of people management.

Managing people can be intuitive, but it is also more difficult than many people realize. A desire to measure is useful, but it can be counter productive when you measure without understanding. Software development is a collaborative, human activity, and as such we need to understand that management and measurement and difficult, and doing either without without an understanding of the challenges can lead to unexpected results.

Things about Release Management Every Programmer Should Know

As I mentioned earlier I was privileged to contribute to the book 97 Things Every Programmer Should Know: Collective Wisdom from the Experts. In addition to the contributions about coding and design, I was pleasantly surprised to see the number of items that relate to release management. While I've long been interested in how to build architectures and processes that make deploying and releasing software easy, I sometimes get the impression that these items were often though of necessary evils that could be done at the end, often by the someone who isn't doing "more valuable work." Much like awareness of agile software development made it obvious that testing and quality assurance activities work best when they are integrated throughout the development lifecycle, agile has also made it more obvious why build and release engineering is something to work on as you go. This makes a lot of sense, as ease of release is closely tied to the physical architecture of the system, and your build process defines the physical architecture.

Some of the posts of interest are the following, though I could have added others than related to testing as well.

1. Deploy Early and Often by Steve Berczuk
2. Install Me by Marcus Baker 
3. Keep the Build Clean by Johannes Brodwall
4. One Binary by Steve Freeman
5. Own (and Refactor) the Build by Steve Berczuk
6. Put Everything Under Version Control by Diomidis Spinellis
7. Step Back and Automate, Automate, Automate by Cay Horstmann

Aside from being excited that programming experts understand the importance of build, release, and installation mechanisms, I was also excited to see that one topic that people associate with SCM wasn't mentioned: Branching.

Branching is a useful tool when used in the right context, but more often than not, branching is used as a way to avoid issue rather than to address them. Rather than branching because there is a true divergence in the code, we branch to avoid breaking existing code. The problem is that doing so simply defers a cost. Sometimes deferring the cost makes sense. Often it's better to invest in the techniques you need to enable incremental change while keeping the codeline working.

97 Things Every Programmer Should Know is about much more than just coding, or just release management. And that's the point: programming is a multi-faceted skill and to write good code, you need to know about more than just writing code.

Planning is a Gerund

One of the things teams adopting agile struggle with is deciding how much to define a plan before you start executing. Have a plan that's too well developed and you end up risking that your team may not be responsive enough to change. Too little of a plan and you may end up changing course excessively, and have no way to measure your progress towards any sort of deliverable. 

At the core of this confusion over how much to plan is the reality that plans change, and spending too much time and energy creating a plan that ends up being wrong seems wasteful. But the lack of a plan means that you have nothing to measure progress against. One way to reconcile this is to keep in mind the following quote, attributed to Dwight Eisenhower (and a variant attributed to Churchill):

Plans are nothing; Planning is everything.

If we assume that as a project progresses, that things will change, we can still benefit from talking through the options as a team. Capturing the things that we don't know, but would like too, is useful information, and gives the team a good measure of risk.

The time you spend planning is an important consideration. Constrain the amount of planning time based on the duration of your sprint. If you can't come to an understanding of what the problem is or how to approach it, you have a clue that you're trying to do too much. But rather than throw up your hands, you can aim to have some sort of plan. It might be wrong, but even building the wrong thing can increase your understanding.

For the planning activity to be useful it is important that it not be top-down but that it involve the implementation team, as they are the ones who can speak to the the implementation risks, and can propose creative solutions given the ability to probe about real goals.

One thing that may concern people with the approach of involving the team and stakeholders at the same time is that a planning which raises more questions that providing answers can make some people uncomfortable. Senior managers may be uncomfortable with acknowledging ignorance. Team members may be put off by seeing that there are legitimate disagreements among the product ownership team about some issues. And some people are just uncomfortable when you can't just tell them what to do.

This is a cultural issue that may not be easy to overcome, but agile projects work well because the team can pull together to solve problems when given all of the information, and structure their code and their work to  mitigate risk. And if the uncertainty exists it's better to identify it up front.

Regardless of the level of uncertainty about goals and dependencies it is important to exit a planning session with a common vision for the goals and target for when you will re-evaluate the goals. A well run  planning activity can helps to focus the team towards a common goal.

Book Review: Modular Java

I recently read  Craig Walls' book Modular Java: Creating Flexible Applications with Osgi and Spring (Pragmatic Programmers). This book is a very detailed tutorial that walks you through setting up an application using OSGI and Spring with the help of Maven as a build tool. If you aren't familiar with any of these technologies, this book will get you started, and quickly have you feeling like you have a basic grasp of the concepts and technologies.

You'll finish the book with a desire to learn more about the technologies, and understand the power of modular applications.  As a tutorial, this is an excellent book. This is not an general guide to how to design with OSGI.  There is some background on the frameworks, and some explanation of technologies, and also pointers to sources for more information, but this book is all about learning by building. If you pick up the book hoping to learn any details about the how and why of OSGI and Spring, two useful technologies, you might be disappointed.  But if you like learning by doing, and working with running code, you'll enjoy and value this book.