Managing the Customer
Part of your job is managing the development team, but you must also manage the customer. Customer satisfaction depends so much on managing expectations. Customers don't like surprises, so you shouldn't deliver them. The customer should know what to expect in the iteration demo. If you deliver less than your team committed to, the customer gets an unpleasant surprise. If, for example, a team member must be out for paternity leave, inform the customer that it will affect the output of the next iteration.
A great way to keep the customer informed and to avoid surprises is by inviting them to the daily stand-up meeting. Every morning, have the team go over three items:
- What I accomplished yesterday.
- What I hope to accomplish today.
- What barriers are impeding progress.
Armed with this daily knowledge, the customer will start to feel like part of the team instead of an outsider. The customer will have up-to-date knowledge and won't be greeted with any surprises. The daily stand-up meeting, weekly iteration demos, and constant communication will keep the customer happy and involved. It's important to pull the customer into the process; otherwise, there will be an "us vs. them" environment, and that is dysfunctional. When your team is in competition with the customer, neither will win.
Bugs vs. Defects
Defects are gaps between what your team committed to and what they delivered. If the team commits to a story and they find a problem with the functionality of that story, you have a defect on your hands, and the story isn't finished. You should only count stories as "done" when your customer accepts them without defects. It does no one any good if you merely log a defect and take credit for the story anyhow.
A bug is anything that bothers users. I'm not sure we'll ever get away from bugs, but constant communication sure helps. In managing the software process, it's important to understand the difference between a bug and a defect. Bugs are not negotiable. If the behavior of the software bugs a user, you have a bug, end of story. If your team and your customer agreed upon the behavior beforehand, then you have a defect, not a bug, and your team should correct defects immediately.
A defect is a gap in the story contract and acceptance criteria. A bug is not a defect since it's an annoyance that has yet to be discussed. Bugs pop up all the time, and if the customer is motivated enough, he'll craft a story to get rid of the bug and put that story on the backlog. A customer shouldn't have to think about defects, however. When someone finds a defect, the team should drop everything and fix the defect right away. A defect signifies that a story which the team has already labeled "done" is, in fact, not finished. Finish the story and move on. Institute a zero-defect policy. Don't count a story as done until it meets all acceptance criteria. You can't get away from bugs, but you sure can eliminate defects.
At the end of every iteration, have a short time where the team can reflect and craft ways to improve even more. A fun way to do this is to list feedback under three headings:
- Good (what you would like to continue).
- Bad (what you would like to stop).
- Ugly (a fun category if an issue was particularly messy).
Consider all items as action items. Your team should continue and enhance "good" items. Your team should stop, change, or overhaul bad and ugly items. A good manager will try to remedy the items listed under "bad" and "ugly." Most of the time, you are the only one who can change these items. The team will remedy the items under their control, and the items that remain are more organizational problems. Don't just ignore these organizational problems. It may be difficult, but as management, it's your job to handle issues such as poor facilities, equipment, software licenses, etc. Who said management was easy?
Keep retrospectives short. Thirty minutes is a good cap on a retrospective meeting. You don't want it to linger on into a discussion on agile theory. After all, you're in charge, so if your team starts a long discussion on how to move forward, you may have to make the call.
Software system design can enable or cripple your team. Let pain and developer annoyance be your guide. If an aspect of the software is painful or annoying, invest the time to fix it. Treat that time as an investment. That investment should yield returns. For instance, a shared development database often causes pain because one developer who alters the schema for a new feature will often break the system temporarily for the rest of the team. Having a database instance on each developer machine quickly solves that particular problem. Be sensitive to pain and don't take "we can't do anything about that" as an answer.
Determining Iteration Length
An iteration is the length of time a team works before demonstrating the new state of the system to the product owner. Scrum advocates one month. XP advocates one or two weeks. I strongly advocate one week. Iterations are different than releases. Iterations represent a cycle in software delivery. Lean stresses the reduction of cycle time as a means to improve throughput. Shortening cycle time to one week will help keep the team focused on exactly what they need to deliver. It's hard to get distracted from essential stories when there is only one week to deliver them. Some folks might think that you can't get anything done in only a week. If that is true, then you have some serious other problems that you need to tackle. If you are just beginning to embrace agile values, then you might be working with systems where even fixing a typo and releasing to production is a two-month ordeal. If that is the case, then you need to improve your build and deployment process so that it can be done in an hour, not two months. If you have some monumental issues you are battling, you need to invest effort into fixing those problems. As the manager, everything right or wrong in your organization is your fault. Take the initiative to mitigate the problems.
One-week iterations squeeze your process and force dysfunctions to surface. With short cycle times, anything slowing down your organization will become very obvious. Problems can't hide when you employ short cycle times. Use one-week iterations as a tool to discover existing problems. Tackle them one by one until you have a smooth-running team. You'll then be able to deliver significant value in a single one-week iteration.
Hiring and Firing
As a manager you want to do more hiring than firing. Staffing is your responsibility. I'll now discuss what I call a "net-negative developer." This developer does not have low productivity. These are developers no one misses when they're out sick. These developers might have good intentions, but team velocity is slower because of them. In fact, the team could move faster if these people went on vacation. Have the courage to make the staffing changes necessary to improve your team. Hold high standards for your team members. I understand that large corporate environments might have policies against firing without egregious performance. As a manager, it is your responsibility to navigate the political landscape to remove things that hinder your team's performance. A net-negative developer is a constant tax on your team's productivity. Have the courage to do what is right not only for your team but your customer or product owner.
In contrast, recognize when you have a "multiplier." In performance reviews, you might not be able to list specific items directly attributable to this person, but it seems that whatever project the multiplier is on goes very well. This developer multiplies the efforts of the rest of the team. Perhaps this person removes roadblocks or works to streamline your process. Either way, this person might double the productivity of the entire team just by doing what they do. Recognize and reward this person. They are a valuable asset to your organization. Work to identify this type of person in your hiring process as well.