Imagine for a moment that software development iterations or sprints are like using a team of people rowing a boat, each with an individual paddle. If everyone on the team pulls their paddle through the water in the same direction and in the same cadence and the team has someone steering, then the boat will move swiftly in the intended direction. If, on the other hand, the team is not pulling in the same direction, then boat will slow down dramatically, or if the team members are not in sync as to the paddling cadence, then the boat will not move forward as quickly as it otherwise would and finally if the boat has no one steering then the boat may move quickly but will veer of coarse and lose speed to costly coarse correction efforts.
In an iteration or sprint, the user stories are agreed upon, documented, prioritized and estimated. The stories are chosen or assigned, so theoretically speaking everyone should know what they need to be working on and yet, without a daily stand up meeting, you will find that some of the team will veer of coarse and work on items they should not be working on. The time must be spent to take corrective measures and get the iteration or sprint back on target, but by this time the deadline will be blown.
A daily stand up will allow for the exposure of discovered issues that could derail the team if not handled properly and will also allow for the senior level team members to help unblock the other team members so that everyone is pushing forward and is in sync with the project and technology goals.
Discovery is expected and can be managed when it is expected, but it should never be a surprise. It is only a surprise if you are not having daily communication with the team regarding their stories and individual progress. If the communication is limited to a frequency of once a week, you will get surprised by how off track the team wanders over the coarse of five days.
Sunday, June 28, 2009
Friday, June 19, 2009
The $2 Billion Dollar Dilemma
What is the time and place for interrupting an iteration?
To answer that I will take an out-of-context quote from the most interesting man in the world, "The time is never and I will let you figure out the place."
Some would argue that this stance is too conservative and doesn't allow for any flexibility when real emergencies arise. This argument is founded on two things; first, that the definition that real emergencies are those things that are so dangerous that they have already or soon will prevent the normal course of business unless they are resolved and two, a fundamental misunderstanding of agile principles when planning iterations.
This is a valid definition of a real emergency but invalid in that proper iteration planning takes into account the overhead of resolving defects in production and therefore in that context the iteration plan is built with the expectation of "real emergencies" and is therefore not interrupted when they occur. In other words, the established average velocity of the team takes into account the natural frequency of real emergencies and the overhead needed to address them.
The other use of the "real emergencies" clause is when business development and sales people claim there are real business/sales scenarios that because of the perceived value of the potential client/customer, represent a valid excuse to interrupt the iteration or a real emergency.
To further illustrate this point I will describe a common real world example:
The development team is three weeks into a four-week iteration when the development manager gets called into an urgent meeting with the business development team. In the meeting the development manager is informed that in two weeks, his team needs to deliver a working demo product to be used by the sales team for a meeting with industry CEO's for a deal that could be worth two gazillion dollars. What does the development manager do?
The problem with countering this argument is the dollar amount of the potential deal, the business people will use that like a Quake stud with a BFG on quad damage to demolish any counter claim about the productivity losses and procedural misconduct the development team may offer up. They would argue that this is a situation in which the team is justified in breaking the iteration, and building the demo product for the sales team, but this argument and its seemingly weighty justification are just common camouflage hiding a much larger problem within the organization.
This justification is really just an excuse to all for all the factors that lead to a scenario like this, such as a lack of planning by the business development team and sales team, a lack of communication about what the needs of the sales and business development teams will be in the coming weeks and months, lack coordination between the product managers prioritizing the backlog and the business development/sales teams, and a destructive attitude that it's acceptable to push the consequences of disorganization down to the development teams.
Sadly, it becomes the duty of the development teams to stand firm against this hurricane of incompetence and hold the iteration together. Correcting the organizational misconduct will undoubtedly be very painful and in some cases slow going, but the end result completely justifies the means.
To answer that I will take an out-of-context quote from the most interesting man in the world, "The time is never and I will let you figure out the place."
Some would argue that this stance is too conservative and doesn't allow for any flexibility when real emergencies arise. This argument is founded on two things; first, that the definition that real emergencies are those things that are so dangerous that they have already or soon will prevent the normal course of business unless they are resolved and two, a fundamental misunderstanding of agile principles when planning iterations.
This is a valid definition of a real emergency but invalid in that proper iteration planning takes into account the overhead of resolving defects in production and therefore in that context the iteration plan is built with the expectation of "real emergencies" and is therefore not interrupted when they occur. In other words, the established average velocity of the team takes into account the natural frequency of real emergencies and the overhead needed to address them.
The other use of the "real emergencies" clause is when business development and sales people claim there are real business/sales scenarios that because of the perceived value of the potential client/customer, represent a valid excuse to interrupt the iteration or a real emergency.
To further illustrate this point I will describe a common real world example:
The development team is three weeks into a four-week iteration when the development manager gets called into an urgent meeting with the business development team. In the meeting the development manager is informed that in two weeks, his team needs to deliver a working demo product to be used by the sales team for a meeting with industry CEO's for a deal that could be worth two gazillion dollars. What does the development manager do?
The problem with countering this argument is the dollar amount of the potential deal, the business people will use that like a Quake stud with a BFG on quad damage to demolish any counter claim about the productivity losses and procedural misconduct the development team may offer up. They would argue that this is a situation in which the team is justified in breaking the iteration, and building the demo product for the sales team, but this argument and its seemingly weighty justification are just common camouflage hiding a much larger problem within the organization.
This justification is really just an excuse to all for all the factors that lead to a scenario like this, such as a lack of planning by the business development team and sales team, a lack of communication about what the needs of the sales and business development teams will be in the coming weeks and months, lack coordination between the product managers prioritizing the backlog and the business development/sales teams, and a destructive attitude that it's acceptable to push the consequences of disorganization down to the development teams.
Sadly, it becomes the duty of the development teams to stand firm against this hurricane of incompetence and hold the iteration together. Correcting the organizational misconduct will undoubtedly be very painful and in some cases slow going, but the end result completely justifies the means.
Saturday, June 13, 2009
Discussion vs. Productivity
At random intervals during the day the senior engineers will often get into a discussion over the correct implementation of some technology with regard to a particular problem we are attemping to solve. These discussions seem to have no discernible pattern in terms of the duration and therefore they can last anywhere from 5 minutes to upwards of 5 hours with the occasional discussion spanning a few days. When the discussion lasts days, we always break to do research and other tasks and then rejoin the discussion later.
These discussions are very disruptive in terms of interrupting the flow of the nearby engineers as well as halting progress on any non-related tasks the senior engineers were involved in before the break out of the discussion. The work area is such that almost all discussions are heard by all the engineers which often leads to a cascade of involvement.
My manager gut always cringes at the onset of each discussion because the gut reaction is to protect the short term productivity of the team. However, despite all the short term cons, there is a mountain of medium and long term benefits to these discussions in terms of implementing technology in an optimal pattern that is optimized for maintainability and horizontal scalability.
Even with all of the benefits, a discussion has to be managed. An uncontrolled discussion is like a wild fire propelled by a Santa Ana wind storm, it will consume all in its path with the direction dictated by the whichever way the wind happens to blow.
Here are some tips on managing the discussion to balance both productivity and innovation:
- Limit Emotional Arguments: As soon as the discussion becomes emotional and has morphed into an argument, its time to table the discussion to allow the participants time to cool off and gather their thoughts. If the matter at hand is more pressing, then have a cool off period of 10 minutes or so and move the discussion into a conference room. I don't recommend eliminating emotional arguments completely because often times there is a deeper concern that will get expressed in the heat of the discussion. Heated discussions shouldn't be the goal or the norm, but can be useful in exposing deeper problems.
- No Personal Attacks: Any discussion point that includes a personal attack is weak and useless. These should be strongly discouraged with the prompting to express a critique in a way that doesn't attack the other individual.
- Encourage Involvement: Try to include more junior level engineers in the discussion when possible as a training exercise. The sooner an engineer feels comfortable expressing an opinion on a technical topic in front of his/her peers the better off the project will be. If the subject matter is not conducive to this type of exercise, take the discussion to another room where it won't interrupt the flow of the engineers not involved with the discussion.
- Reach a Consensus: The point of the discussion is to make a decision on the best way to proceed with some implementation of technology for a given problem with stated objectives. If you don't reach a conclusion then you are spinning your wheels and truly hurting productivity.
- Avoid the Weeds: Don't allow the discussion to follow rabbit hole offshoots. Keep the discussion focused so as to reach the conclusion as quickly as possible while still determining the optimal solution path.
- Allow Time to Process: Sometimes the participants need to time to process what has been said and to do additional research. The manager or lead engineer will need to play the moderator role in determining when to table the discussion for later.
- Have a Flow Day: Make sure your team has an entire day dedicated to being in the flow, at a minimum. This will make up for any short term productivity loss caused by discussions. Additionally, you can dedicate a few hours of each day to flow as well.
Subscribe to:
Posts (Atom)
