Baccarat is an interesting card game that you’ll find at many casinos. The objective of the game is to correctly predict whether the bank or player will win a hand.
In Baccarat the scoring for a hand is very simple, add up all the cards at their face value with face cards being worth 10 and only count the total in the ones column.
6 + 7 + J = 23 = 3
A + 4 = 5
The highest possible hand is 9 and whoever has the highest hand wins. If the player and banker have the same hand, it is a tie.
I won’t go into the details of how the number of cards are drawn is determined, but if you are interested you can find that information on Wikipedia. Basically, you end up having pretty close to a 50 / 50 chance of either the player or banker winning a hand. (Of course the house edge still is about 1.06% in the best case.)
The interesting thing about Baccarat though, is that despite the odds, despite common sense, despite the understanding that the game is completely random, people will still sit there and record every single hand and score trying to use it to look for patterns to predict future results.
These poor deluded souls actually think they are measuring something on these score cards, as if what happened in the last hand will in any way affect what will happen in the next hand.
After many years of trying to find the secret formula for measuring software development activities, I’ve come to the conclusion that trying to measure just about any aspect of software development is like trying to measure the odds of a future Baccarat hands based previous Baccarat hands.
Why we want to measure software development
It’s understandable why we want to measure software development—we want to improve. We want to find out what is wrong and fix it and we want to know when things go wrong.
After all, who hasn’t heard the famous quote:
“What gets measured gets improved.”
Don’t we all want to improve?
Somehow we get stuck with this awful feeling that the opposite is true—that what doesn’t get measured doesn’t get improved.
And of course we feel guilty about it, because we are not doing a good job of measuring our software development practices.
Just like the avid Baccarat gambler, we want to believe there is some quantifiable thing we can track, which will give us information that can give us the edge.
Sometimes the reason for wanting to measure is more
sinister practical, we want to evaluate the individuals on our team to see who is the best and who is the worst.
If we could figure out how to measure different aspects of software development, a whole world of opportunities open for us:
- We can accurately give customers estimates
- We can choose the best programming language and technology
- We can figure out exactly what kind of person to hire
- We can determine what kind of coffee produces the best code
How we try
I’ve been asked by many managers to come up with good metrics to evaluate a software development team.
I’ve tried just about everything you can think of:
- Lines of code written
- Bugs per developer
- Bugs per line of code
- Defect turn around time
- Average velocity
- Unit test code coverage percentage
- Static analysis warnings introduced
- Build break frequency
I’ve built systems and devised all kinds of clever ways to measure all of these things.
I’ve spent countless hours breaking down backlogs to the smallest level of detail so that I could accurately estimate how long it would take to develop.
I’m sure you’ve probably tried to measure certain aspects of software development, or even tried to figure out what is the best thing to measure.
It’s just too hard
No matter what I measure or how I try to measure it, I find that the actual data is just about as meaningless as notebook full of Baccarat hands.
One of the biggest issues with measuring something is that as soon as you start measuring it, it does start improving.
What I mean by this is that if I tell you that I am going to start looking at some metric, you are going to try and improve that metric. You won’t necessarily improve your overall productivity or quality, but you’ll probably find some way—intentional or not—to “game the system.”
Some managers try to get around this issue by just not telling the team what they are being measured on. But, in my opinion, this is not a good idea. Holding someone accountable to some realistically arbitrary standard without telling them what, is just not very nice at all, to put it mildly.
But really the biggest reason why it is too hard to measure aspects of software development, is that there are just way too many variables.
- Each software development project is different
- Each feature in a project is different
- Software developers and other team members are different
- From day to day even the same software developer is different. Did Jack’s wife just tell him she was cheating on him? Did Joe just become obsessed with an online game? Is Mary just sick of writing code this week?
- As you add more unit tests the build time increases
- Different team members go on PTO
- Bob and Jim become better friends and chat more instead of work
The point is everything is changing every day. Just about every aspect of software development is fluid and changing.
There is not one metric or even a set of metrics you can pick out that will accurately tell you anything useful about a software development project. (At least I have never seen one at any software development shop I’ve ever been at on consulted at.)
If you were building widgets in a factory, you could measure many qualities about that widget making process, because much of it would be the same from day to day, but with software development, you are always exploring new territory and a 1000 different variables concerning how you are developing the software changing at the same time.
Measuring without measuring
So am I basically saying that metrics in software development are completely worthless and we shouldn’t bother to track anything?
No, not exactly.
What I am saying is that trying to use metrics int the same way that we measure the average rainfall in a city, or running pace improvement by looking at its average over time, doesn’t really work in software development.
We can track the numbers, but we can’t draw any good conclusions from them.
For example, say you track defects per lines of code and that number goes up one week, what does it mean? Any number of things could have caused that to happen or it could just be a totally random fluke. You can’t really know because there isn’t a knob you can turn and say “ah, I see we turned up the coffee bitterness factor to 3 and it resulted in more bugs.” Instead there are 500 knobs and they all changed in random directions.
So, I am saying don’t look at how the numbers of any particular metric are moving from day to day or week to week and expect that it means anything at all, instead look for huge deviations, especially if they are sustained.
If all of a sudden your average team velocity dropped down to almost nothing from some very high number, you won’t know what caused it, but you’ll know that it is much more likely that there was one single knob that got cranked in some direction and you’ll at least have some idea what to look for.
You really have to treat the software development process more like a relationship than like a factory.
I don’t have a series of metrics I use to evaluate my relationship with my wife or my friends. I don’t secretly count how many times my wife sighs at me in a day and track it on a calendar to determine our relationship quality factor.
Instead what I do is talk to her and ask her how things are going, or I get a more general idea of the health of the relationship by being involved in it more.
Team retrospectives are a great way to gauge the temperature of the team. Ask the team members how things are going. They will have a pretty good idea if things are improving or slowing down and what the effectiveness level is.
Measure not, but continuously improve, yes
So kick back, don’t worry so much. I promise I won’t tell Six Sigma that you aren’t using metrics.
Instead focus on continuously improving by learning and applying what you learn. If you can’t notice enough of a difference without metrics, metrics wouldn’t have helped you anyway, because the difference would just be lost in variance anyway.
What slows down the development of software?
Think about this question for a bit. Why is it that as most software evolves it gets harder and harder to add features and improve its structure?
Why is it that tasks that would have at one point been simple are now difficult and complex?
Why is it that teams that should be doing better over time seem to get worse?
Don’t feel bad if you don’t have an immediate answer to those questions. Most software practitioners don’t. They are hard questions after all.
If we knew all the answers, we wouldn’t really have these problems to begin with.
Regardless though, you’ll find many managers, business owners, customers and even software developers themselves looking for the answers to these questions, but often looking in the wrong place.
Process is almost always the first to be blamed. It stands to reason that a degradation of process or problems with the software development process are slowing things down.
Often there is some merit to this proposition, but I’ve found that it is often not the root cause. If your team is not sitting idle and the work that is important is being prioritized, chances are your process is not slowing you down.
Now don’t get me wrong here. I am not saying that these are the only two important aspects to judge a software development process, but I am saying that if generally your team is working hard on important stuff most of the time, you can’t magically improve process to the point of increasing productivity to any considerable order of magnitude. (In most cases.)
Often questions are asked like:
- Should we pair program or not pair program?
- Should we be using Scrum instead of Kanban?
- Should we be changing the way we define a backlog?
- Should we use t-shirt sizes or story points or make all backlogs the same size?
- Do we need more developers or more business analysts?
- Do we need to organize the team differently?
Now these are all great questions that every software project should constantly evaluate and ask themselves, but I’ve found over and over again that there is often a bigger problem staring us in the face that often gets ignored.
Let’s do a little experiment.
Forget about process. Forget about Scrum and backlogs and story points and everything else for a moment.
You are a developer. You have a task to implement some feature in the code base. No one else is around, there is no process, you just need to get this work done.
It might help to think about a feature you recently implemented or one that you are working on now. The important thing with this experiment is that I want to take away all the other “stuff” that isn’t related directly to designing and implementing that feature in the code base.
You will likely come to one of these conclusions:
1. The feature is easy to implement, you can do it quickly and know where to go and what to modify.
Good! That means you don’t really have a problem.
2. It is unclear what to do. You aren’t sure exactly what you are supposed to implement and how it fits into the way the system will be used.
In this case, you may actually have somewhat of a process problem. Your work needs to be more clearly defined before you begin on it. It may be that you just need to ask more questions. It may be that half baked ideas are ending up in your pipeline and someone needs to do a bit more thinking and legwork, before asking a developer to work on them.
3. Its hard to change the code. You’ve got to really dig into multiple areas and ask many questions about how things are working or are intended to work before you can make any changes.
This is the most likely case. Actually usually a combination of 2 and 3. And they both share a common problem—the code and system do not have a design or have departed from that design.
I find time and time again with most software systems experiencing a slow down in feature development turnaround that the problem is the code itself and the system has lost touch with its original design.
You only find this problem in successful companies though, because…
Sometimes you need to run with your shoelaces untied
I’ve consulted for several startups that eventually failed. There was one thing in common with those startups and many other startups in general—they had a well maintained and cared for codebase.
I’ve seen the best designs and best code in failed startups.
This seems a bit contradictory, I know, but let me explain.
The problem is that often these startups with pristine and well maintained code don’t make it to market fast enough. They are basically making sure their shoes laces are nicely tied as they stroll down the block carefully judging each step before it is taken.
What happens is they have the best designed and most maintainable product, but it either doesn’t get out there fast enough and the competition comes in with some VB6 app that two caffeine fueled not-really-programmers-but-I-learned-a-bit-of-code developers wrote overnight or they don’t actually build what the customer wants, because they don’t iterate quick enough.
Now am I saying that you need to write crap code with no design and ship it or you will fail?
Am I saying that you can’t start a company with good software development practices and a clean well maintainable codebase and succeed?
No, but what I am saying is that a majority of companies that are successful are the ones that put the focus on customers and getting the product out there first and software second.
In other words if you look at 10 successful companies over 5 years old and look at their codebase, 9 of them might have some pretty crappy or non-existent architecture and a system that departed pretty far from the original design.
Didn’t you say something about pulling up your pants?
Ok, so where am I driving at with all this?
Time for an analogy.
So these companies that are winning and surviving past year 5, they are usually running. They are running fast, but in the process of running their shoelaces come untied.
They might not even notice the shoelaces are untied until the first few times they step on one and trip. Regardless they keep running. And to some degree, this is good, this is what makes them succeed when some of their failed competitors do take the time to tie their shoelaces, but those competitors end up getting far behind in the race.
The problem comes pretty close to after that 5 year mark, when they want to take things to the next level. All this time they have been running with those shoelaces untied and they have learned to do this kind of wobble run where they occasionally trip on a shoe lace, but they try to keep their legs far enough apart to not actually step on a shoelace.
It slows them down a bit, but they are still running. Still adding those features fast and furious.
After some time though, their pants start to fall down. They don’t really have time to stop running and pull up those pants, so as they are running those pants slip further down.
Now they are really running funny. At this point they are putting forth the effort of running, but the shoelaces and pants are just too much, they are moving quite slow. An old woman with ankle weights power walks past them, but they can’t stop now to tie the shoelaces and pull up those pants, because they have to make up for the time they lost earlier when the pants first fell down.
At this point they start looking for ways to fix the problem without slowing down and pulling up the pants. At this point they try running different ways. They try skipping. Someone gets the idea that they need more legs.
I think you get the idea.
What they really need to do at this point though is…
Stop running, tie your shoes and pull up your pants!
Hopefully you’ve figured out that this analogy is what happens to a mature system’s code base and overall architecture.
Over time when you are running so fast, your system ends up getting its shoelaces undone, which slows you down a little. Soon, your system’s pants start to fall down and then you really start to slow down.
It gets worse and worse until you are moving so slow you are actually moving backwards.
Unfortunately, I don’t have a magic answer. If you’ve gotten the artificial speed boost you can gain from neglecting overall system design and architecture, you have to pay the piper and redesign that system and refactor it back into an architecture.
This might be a complete rewrite, it might be a concerted effort to get things back on track. But, regardless it is going to require you to stop running. (Have you ever tried to tie your shoelaces while running?)
Don’t feel bad, you didn’t do anything wrong. You survived where others who were too careful failed. Just don’t ignore the fact that your pants are at your ankles and you are tripping over every step, do something about it!
Pay attention young programmers, this is the most important piece of programming advice you will ever hear.
Well perhaps not, but it might be the most important piece of programming advice you hear today.
“Switching gears is grinding gears.”
I’ve been doing this programming thing for quite a while now, and I have come to realize that the biggest thing that saps my productivity is switching gears.
What do I mean by switching gears?
Many different contexts
Switching gears can apply to a variety of different contexts, but it is basically whenever you are working on some task or technology and have to stop what you are doing and either do something else or change the type of thing you are doing.
This is really a bit different than multi-tasking. Multi-tasking is really trying to do more than one thing at once. It usually involves a large amount of rapid context switches, but for this post I am more concerned about the general idea of breaking rhythm.
I think it is easier to speak about this subject if we talk about some specific applications of the idea and why they are harmful.
In the Agile world of software development today, we often are required to switch from problem domain to problem domain as many of our iterations contain mixes of different features on different parts of the system and bugs to be fixed.
Have you ever been in the situation where you were just beginning to understand how some area of the code base worked, or how to work with a particular customer on a particular problem space and then had to switch to something else and start all over again?
Even when you switch back to the original context you were working with, if enough time goes by, it becomes new again. You have to relearn much of what you had learned the last time and just when you begin to hit your groove, the cycle begins again.
This form of switching gears is at the very least frustrating, and at the most a complete demotivator and productivity sapper.
Unfortunately for most developers, this problem is out of your immediate control. But, take note product owners and project managers, there is a reason why iterations should have a goal.
If you are in the precarious position of being a developer pinned against the ropes, try to make some noise and let your management and product owners know that your team will be much more efficient when you aren’t switching gears all the time.
In my experience, the results of replacing this constant context switching with the synergy of a common goal and related features in a segment of time has an astounding effect on productivity that is hard for any serious businessperson to ignore. So speak up!
Switching technology is painful!
It really isn’t worth trying to fight this because you are going to be going against the technology grain to do so. Although, I do suppose this may be one of the reasons for the recent popularity of Node.js.
I’m not saying to not learn new things. It is very important to always be learning.
What I am saying, is to try to find some kind of rhythm with the technology stack you are working with and try not to switch that up.
Technology specific training can really help here as well. I for one, need to learn JQuery better. The problem is that when I am working on a web based feature, I am not forced to learn JQuery because I am not in that context long enough.
So what do I do instead?
I waste time Googling for answers. I know that I have a short coming here and I need to just bite the bullet and spend some dedicated time to really thoroughly learn JQuery, because by Googling for little pieces of it at a time, I am not really making much headway and the context switch ends up stealing what I do learn from my memory.
One more aspect of this is the idea of focused teams. Many software development groups do not like to specialize their developers onto one focus area. I agree whole-heartily with the idea of non-specialization.
But! There is huge benefit to be gained by keeping the same group of developers working on a specific set of technology or part of the code base for a set period of time. I’ll talk about this a bit more, towards the end of this post, but the basic idea is that it takes time for people to find their groove.
I think it is optimal to break any large team up into smaller technology area focused teams that regularly rotate every 3 months or so. The idea here is that you give those teams enough time to get good at what they are doing and actually commit what they have learned to memory, but you rotate them often enough that they don’t end up becoming specialists which are unable to see the whole picture.
This one typically isn’t an issue, but it can be depending on the environment that you are working in.
Teams need enough time to go through that forming, storming, and norming set of phases. If you are constantly interrupting this process by switching around team members, you are never going to get the team to act as an entity of its own.
Teams are generally more efficient than individuals, because they benefit from synergy, when 1 + 1 = more than 2.
But just like a big truck taking some time to get up speed, a team takes time to get going. Also like a big truck, a team can gain momentum that individual developers seldom can achieve.
A smaller aspect of this is pair programming. I suppose that many have been successful switching up programming pairs once a day or so, but I suppose that more teams have been successful switching up pairs at longer intervals.
For me, this interval varies. Sometimes, I feel like I need to stay paired with a teammate for longer than 2 weeks, which is our regular interval, sometimes 2 weeks is fine. It depends on what you are working on and how much momentum you have.
They key here is to make sure that you are giving teams enough time to take up their own flag and stake their territory. Teams can take some time to find their common goal. Self-direction can really help with this.
Ever tried to turn a flat head screw with a screwdriver, but it doesn’t quite turn, because you can’t seem to get the head of the screwdriver into the groove of the screw?
You twist that screwdriver around a bit until finally it slips into the groove. Then when you turn the screwdriver the screw turns with it.
As humans, we tend to be like screwdrivers, we have to find our groove. We all have this adjustment period where we are fumbling through things.
It is very important to make sure that we aren’t switching gears so often that we are not actually turning any screws once we are in the groove.
Regardless of what kind of context switching you are doing—whether it is problem domain, technology or teams—it is important to make sure that you are not spending 90% of your time finding the groove and only 10% of your time “in the groove.”
Depending on what you are doing and what the context switch is, the proper amount of time before switching contexts is going to vary, but I think it is very important be aware of this phenomenon and plan around it. If you don’t you are going to end up spinning your wheels, which is unfulfilling to say the least.
Imagine this common scenario if you will.
One of your friends calls you up and says:
“Hey, would you mind helping me move on Saturday, I am getting 4 or 5 people together and we are going to move my stuff to my new house?”
You of course reply:
“Sure I can help, what time do you want me to be there?”
“We are starting at 10:00 AM sharp!”
You might have guessed what is going to happen next. You show up at your friends house expecting that everything is nicely packed in boxes and that you are just going to move some boxes and furniture into a U-Haul, but instead what you see is this:
He couldn’t have cleaned up the house and at least put the stuff in boxes before having 5 people show up at his house to move stuff?
So what should have been a 2 hour jobs turns into a 2 day ordeal as you and 4 other friends sit around waiting for moving friend to pack up his stuff so that you can put it in the truck.
All 5 of you can’t actually help with the packing of stuff and the throwing out of garbage because there is only one person who knows what is trash and what things need to go in what boxes.
If your friend would have cleaned up the trash and packed up everything in boxes before he had the 5 of you come over and help, things would have gone much much faster!
Your backlog list is your apartment
The same kind of thing happens when you call up 5 of your developer and QA
”buddies” and ask them to get some work done for a sprint.
If the team is trying to sort out what needs to be done, what is trash, and what things need to go in what boxes, they are going to be much slower at actually getting the work done.
You see, your list of un-groomed backlogs is not unlike a hobo. Often times it could use a good wash and a proper shave.
When I am talking about backlog grooming here, I am not even talking about having a planning meeting, where you plan what you will do next.
Angela Druckman has a good description of a Grooming Session.
The idea is that periodically you groom the top x% of your backlogs so that they are in nice clean boxes ready to be worked on when the team picks them up.
The important thing here is that this is a team activity, everyone should be involved with backlog grooming. The business really owns the backlogs in most cases though, so they should be directing the team as to which things go in which boxes so to speak.
What about just in time backlog grooming?
Why work on a backlog until the very last responsible minute?
For the answer I point you back to the moving scenario I started this post with.
The reason why it is so inefficient for your friend to have everyone come over and try to move him before he has packed up everything and gotten rid of the trash is that you end up having a large amount of idle time waiting on one person.
Think about when happens when a team of 8 developers starts working on backlogs for an iteration at the same time.
If all of the backlogs are not “groomed”, but instead are a scattered mess of mismatched sizes and parts, each developer is going to have to talk to perhaps the same business person about the backlog that developer is working on.
What happens when this business person is out of the office?
What happens when this business person is trying to field questions from 8 developers?
What happens when there is a turn around time to get back to the developers on questions about the backlog?
Now contrast this with the scenario where all the backlogs that are going to be worked on in an iteration are nicely packaged in neat little boxes.
The backlogs may not contain all the technical details of what is going to be implemented, but they are broken down to small bite size pieces that are fairly well understood by the team.
In this scenario the team is going to be able to pick up the backlogs and start going to work. Sure they will still have to ask the business questions about the backlog, but the kind of questions being asked change fundamentally.
Contrast this kind of question:
So what exactly is this backlog about? What kind of things do we want to build to report on this data?
To this kind of question:
As we discussed previously and I see in the backlog, we are creating a custom report for this customer. I also see that we had defined what this column A should do. Should I be using calculation X or calculation Y to compute this column?
The first kind of question is better answered in a bigger meeting with all the right people. To answer the first kind of question might require some research. The first kind of question would hold up the completion of a backlog because it is not easily answered. It requires thought and perhaps asking other people, talking to the customer, etc.
The 2nd kind of question is specific. This is something that can be figured out usually by a single person. Most importantly it does not hold up the work. Developers can continue implementing parts of a solution and put in the algorithm for computing some value later.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
This seems like a very basic question, but I have found myself asking it again and again. Seems like so many teams never really question what exactly it is that makes up a team.
In an Agile environment this question has even more relevance as the focus on teamwork is greatly emphasized.
Teams have a common objective
The most important component of a team is shooting for the same target. The smaller and more defined the target the more tightly bound the team.
Consider the famous TV team “The A Team.” Each episode of this television series the team is tasked with a common goal of some sort. This pursuit of a common goal is one of the main components that binds them together as a team.
Sports teams provide an even better example. In all team sports the entire team has the objective of winning. More specifically though, there is always some other sub-objective that the team is involved in. The more “team-like” the sport, the more the entire team is involved in that objective.
I have found that it is exactly the same in software development. It is important to try to find small goals that focus the entire team. When differing members of the team have different objectives, you may be operating on a team, but you might not be operating as a team.
This difference is critical because teamwork often produces synergy. Synergy is when 1 + 1 = more than 2. It is when skills are combined together to produce a greater result than the sum.
If you want to increase the feeling of “team” over individual, reduce the breadth of work going on at any given time and focus everyone on the same small goals.
In Agile this looks like having more team members working on a single backlog or story and reducing the number of stories that are put into progress at any given time. Try putting a strict WIP (Work in Progress) limit on your team to force the team to work together and have a common objective.
Teams fates are bound together
Teams fail or succeed together. I’m not much of a follower of professional sports, but I know from TV dramas produced about them that when different team members fates are not intertwined, teamwork breaks down and all hell breaks loose.
This seems obvious, but it is worth taking the time to consider whether your team members fates are truly bound together or not.
Want to find out quickly? Here is a mental test you can do. Pretend that one team member completely fails to do the work that he or she is responsible for. Does the entire team fail at that point? Do some team members get accolades and others get scolding?
If you honestly ask that question, you might find that indeed your team members fates are not bound together.
It is absolutely critical for a team to equally reward members at the failure or achievement of a particular goal!
Call out the over achievers and you will destroy teamwork to create developer heroes who step outside of the team’s workload to do special tasks and take on herculean efforts in order to gain recognition.
Call out the under achievers and you will also destroy the team, creating an environment conducive to backstabbing and snitching. One in which no one wants to be at the bottom of the totem pole, so everyone steps on everyone else’s heads and fingers to climb over them.
Don’t get me wrong here. I am not saying to never evaluate the individual and promote or reward them. I am just saying evaluate an individual in regards to their contribution to the team achieving the team’s goal.
Focusing on the team’s success or failures encourages team members to help each other, share knowledge and work together.
If I know that I am being evaluated based on what I get done versus what the team accomplishes, I am much less likely to spend my time helping other team members complete their work. This isn’t to say that I don’t like helping others and collaborating, it is just common sense to prioritize what you are being evaluated on first.
Bottom line is, if you want to make a successful team, make sure that successes and failures are shared. Sure, sometimes the whole team is going to be doing pushups for one team member’s mistakes, but it will force the team to deal with that weakness.
Teams deal with their own problems
Nothing demotivates a team more than bringing external influences into a team to control their fate.
Teams should control their own destiny. It is much better to give a team a problem and ask the team to deal with it than to task a particular team member with a special project or responsibility.
Teamwork is all about sharing the burden. This is closely tied to the idea of fates being bound together.
Imagine this scenario. You have a team that has a common objective. They have their fate bound together. But, you come in and give one team member a special responsibility or assignment.
How does this team member view the world?
Differently than the rest of the team. Now they have to competing goals. The team’s current objective and their special objective. Most people in this situation tend to ditch the team in favor of taking care of the responsibility that is squarely on their shoulders.
A better way to handle this situation is to give that “special task” to the team itself. Let the team figure out how to get it done. And let the completion of that objective fall squarely on the team and not on any individual.
If this is a little too scary, you might consider having a team lead. This is a bit contrary to most Agile preachers, but in reality most teams have captains and leaders. Take the extra step and let the team decide who the lead will be.
This brings us to another way team should deal with their own problems…
Teams should be responsible for both bringing new members into the team and kicking them off the team. Interpret this as you will. But teams have to deal with their own problems. If they need more resources, they need a way to get those resources and if someone isn’t pulling their weight, they need to either deal with it or vote that team member off the island.
Applying this to Agile
I covered a pretty large amount of ground in this post, so let’s wrangle it all together and see how to effectively apply this to an Agile development environment.
Here are a few of my tips to improve your Agile team:
- Most important! Set the team on a common objective by only allowing 1 or 2 backlogs or stories to be worked on at once, regardless of the size of the team. (Imagine what would happen if a sports team had different team members focusing on different objectives. All chaos would ensue.) It is alright to have individual members focusing on different tasks, but those tasks should belong to a common objective. Is this painful? Hell yes! Does it feel inefficient? You bet, but the team will find a way to work together to be efficient.
- If your team is too big to have a common objective, break them up into smaller teams. It is better to have smaller focused teams than big teams with split objectives.
- Don’t split the responsibility based on roles. If a team shares an objective, then that team should see it all the way through. You may have developer, QA people, and business people all on the same team, so it is difficult to break the mindset of “I do this, then this other person is responsible for the next step and so on.” Instead the mindset should be “as a team we need to get this feature defined, developed and tested.”
- Never reward individual heroics and never call out individual failures. This is hard, because it goes against one of my personal principles of always calling out both commendation and condemnation publically, but in a team setting it has to be the team that is called out, not the individual. Trust the team to deal with the individuals.
- On the flipside, reward the entire team for success, call out the entire team for failure.
- Always give a task to the team, preferably in the form of a backlog or story. Never give a task to an individual.
- Let them team decide how to handle any given responsibility. Teams tend to find fair ways to assign and distribute work.
- Never hire unless the team approves.
- Never fire unless the team approves.
- Don’t make team members evaluate each other. This will cause them to compete against each other and to think about merits as individual accomplishments versus team accomplishments.
- As much as possible let the team run itself. If a team is not performing, you might need to appoint someone as a leader or facilitator of that team and give them the responsibility of improving the team’s performance, but in most cases teams figure out how to operate best when left to themselves.