Performance evaluations and performance management are areas I disagree with many Agile coaches’ opinions on. “Popular opinion” is that you don’t evaluate individual team members at all. You only evaluate the team as a whole. They maintain that team members are self-motivated and will do their best to support their team. They also feel that evaluating individuals on the team could lead to stratification, and all team members should be treated equal and be at the same level. What I propose is to evaluate individuals, but to emphasize team support and commitment in the evaluation.
“Only the madman is absolutely sure.” ― Robert Anton Wilson, Masks of the Illuminati
Nothing in this world is completely black or white, good or bad. The human brain likes to categorize things. Put things in neat little buckets, so it can think of groups of things, and assume all things in that bucket have certain attributes. When that happens during a decision-making process, though, you’re throwing away information before assessing its value. As soon as you feel you’ve categorized it you let go of the information that went into that categorization. Incomplete information is the enemy of sound decision-making. Sometimes you need to make snap judgements when timing is of the essence, but even then it should be a first approximation, to be re-evaluated later.
In the business world, almost everything is a compromise, and when you’re lucky, an optimization. Neither are possible if you see everything as “all or nothing”. For instance, it’s easy to think that borrowing money is bad if you don’t really need the money right now, because of the interest payments and opportunity costs. But what if you could keep your operations going during lean times with that money? What if you were able to buy more of a resource at a time for a lower per unit price with that money? Then borrowing money can pay off in the long run.
This same principle holds true at the individual level. I had a conversation recently with a woman I was trying to work together with on a goal. She used “I can’t…” as a retort to every attempt at a path forward. I explained that when you start from “I can’t”, there’s nowhere to go; no room for progress, or at least change. If you start with “It’s really hard for me to…”, now you’ve accepted that it’s not impossible, and progress is possible. Let’s find ways of making it easier, or your ability to work towards that goal greater. And we did.
As an active participant in the Agile community, I often hear very hard-line stances, like “You’re not doing Scrum if you don’t follow these principles to the letter”. Such black and white thinking ignores the fact that every company is a bit different, and it’s perfectly functional to drop some practices and add others, as you might substitute ingredients in a recipe (but you better understand the ingredients well before doing it). It’s this kind of “check-mark thinking” that widens the gap between companies “doing Agile” and companies being agile. Continuous improvement is not possible if there is only one acceptable state.
Since I’m in Boston, we have a lot of snow to deal with this winter. The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down. I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much. After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side. That’s why the rake was pulling to the left. Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake. I fee we do the same thing with our software tools a lot.
Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them. There are times when this is appropriate. My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe. Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is. Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.
So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.
As a Software Engineer and as a geek, I face many tempations. One of them is “I can add this really cool feature while I’m in the code, and it will take hardly any extra time. It won’t impact any of my other work at all”. There are some very good reasons why you shouldn’t do it though, and why it’s an Agile anti-pattern.
- Most people are bad at timeboxing, no matter how good their intentions are. I know I find myself adding “just 15 more minutes” to timeboxes more often that I should. You may be spending more time on these extras than you think, or at least more than you intended.
- You are part of a team. The extra work you do may not create much burden on you, but it may create a burden on others.
- If you have extra capacity, there may be much more valuable work you could be doing. It might even be just as quick.
- Who is going to QA your work? Is extra documentation needed? Do you even think about the documentation needs? Are extra configuration options needed that Release Engineering needs to coordinate?
- Every line of code is the potential site of a bug, conflict, or incompatibility. Maybe it works now, but interacts with other code or data that it breaks. Maybe it breaks in the future. Maybe it has a performance impact (since this work didn’t come through normal channels, it probably wasn’t accounted for in performance testing).
- One of the Agile principles is that decisions are made at the last responsible moment. By doing work that did not result from a team decision, you make design and implementation decisions that may no longer be appropriate when that feature planned. Depending on how much work it _really_ was, you may be locking the team into a suboptimal path, or at least creating extra work to remove your implementation
- Most forms of Agile focus on the team functioning together, self managing and empowered, and acting as one. When someone takes it upon themselves to do work that wasn’t planned by the team, it can affect the team dynamics just as much as if someone said they would do something but didn’t do it. It breaks expectations about what is happening and the flow of work through the process.
When someone, especially new software developers or those still in college, asks me whether they should learn Java or C#/.NET, my normal answer is something like “They both do about the same thing, but Java will run on almost anything, and almost all the development tools are free. With C#/.NET you could pay hundreds for Visual Studio, and the programs will only run under Windows.
Microsoft has a long history seeing open source as the enemy, but has never had a problem stealing ideas from it. They even use marketing jargon that is directly opposite of reality. My favorite case of this is Microsoft Windows Services for UNIX, which is actually UNIX-like utilities you install on a Windows computer to give it UNIX-like functionality, not something you add to a UNIX box to help it communicate with Windows. In the past Microsoft has even called Linux a cancer. These days they’re singing a different tune, one that goes “We love open source“. We know what the motivation is. In the real world, business computing environments are of mixed architectures and operating systems. Everything needs to interoperate. They’re not going to dominate the server world like they do the desktop. But you know what? I don’t even mind that they don’t mean it as long as they act like they do. And they are.
Microsoft is opening up major parts of the .NET codebase to open source. They’re doing so under the MIT license, not a GNU license, and that makes sense. They’ve made major contributions to Linux in the past decade. There’s also now a community edition of Visual Studio so you can use it for learning and some projects for free, which is long overdue for them.
I’m a Linux lover, not a Microsoft hater. Any steps they take in the right direction are OK by me!
No matter what your process, and how good that process is, lack of accountability can limit its effectiveness, and the effectiveness of your organization as a whole. Any model will fail to be accurate when it does not represent reality close enough.
Let’s say your company is using Scrum to manage software development work. If you have people on your team that regularly do work that’s not on the scrum board, it hurts the effectiveness of the process because
- The unplanned work being done isn’t being tracked, so resource planning and allocation will be off
- Part of what makes Agile work is you’re doing the least work required to meet the objectives (when the unit tests pass, stop coding). Software Engineers often face the “Wouldn’t it be cool if it also did X? This will just take a minute to implement” temptation.
- The unplanned work being done may not even be desirable or valueable to the Product Owner.
- The unplanned work may actually hinder further planned work by taking the application in a different direction or prematurely locking the application into a design implementation that may become invalid in later sprints. This is in conflict with making decisions at the last responsible moment.
- The unplanned work may become a burden to others. Either QA finds out about it and has more testing work to do than planned, or they don’t find out about it and any bugs in it can escape into the wild.