What's wrong with this picture?

This chart is the task hours estimate remaining for the sprint for the team I am working on. This has been a consistent trend, despite attempts to curb adding stories to the sprint backlog.

There are several factors that contribute to charts like this. If you begin to notice these kinds of trends, here are some things to look for.

• Outside Influences / Randomizations
• Team members are working on things that are not on the backlog
• Unplanned things (fire-drills, ad-hoc customer support, management asking for "emergency" things)

These kinds of things can be mitigated with a strong scrum master, who is empowered to negotiate with outside influences. Sometimes issues come up that require team resources to complete them, this is just the nature of the business in some cases. However, for unplanned work, we do two things. First, we plan a buffer of time in sprint planning that we assign to these kinds of things. It is encouraged to limit this buffer to a specific period of time, and should be treated as a spike. Second, we ADD all tasks that were actually worked on, so that we have visibility to the actual work that got done.

• Under-estimation

Many times, there is simply no interest in digging into the nitty-gritty of the tasks during sprint planning. If each story is clearly understood by the team, the entire team should spend some time tasking out each story in sprint planning. I have seen teams that don't put in enough effort to the planning session. When tasks are better understood in planning, they allow for much better estimation. The "we'll figure it out later" attitude simply doesn't work in this kind of environment. It works much better to spend the time in sprint planning to understand fully what all the tasks are for each story. At least task breakdown should be done in sprint planning, and estimation as well if possible.

• Lack of testing

Un-tested (speaking of unit-testing now) code typically takes longer to get working. Code that is developed within a unit-testing framework (whether or not TDD is used) tends to function better, and requires less "try-it and fix-it" cycles. Unit testing the code does take more time than just writing the code alone, however there are so many benefits and reductions in the amount of time spent on rework and accuracy assurance, that it is usually an easy sell even in an organization that has a heavy work load.


If you see this kind of chart appear in your organization, take it as a yellow flag warning sign, and try to employ these tactics above to improve the estimation process. Don't let your burn-down BURN UP your team!

Sprint planning is the exercise of sizing up the work we think we can get done in an iteration. The recommended practice is to size the high-priority stories on the backlog in story points. Story points aren’t exactly well understood by most organizations, but those that do, more power to you.

We take stories off the backlog to package into a sprint not by how long we think they will take (we estimate that after we break down the tasks) but by the number of story points which indicate the complexity. On a team with at least two sprints completed, I always recommend not taking any more story points than were completely delivered in the last sprint – no matter what, even if they were really low due to some odd circumstance. We can always pull in another story if we finish early.

Now, there are teams out there that have a bit of a different mechanism. Stories are estimated in “ideal days” rather than story points. Then, each team member calculates the number of actual work days in the sprint for them (accounting for vacation and known absences etc). Then a more or less arbitrary “load factor” is applied to this number of days, a percentage of 100 (usually 66%) to find out how many “ideal days” worth of work time we have available each sprint.

There are a number of problems with this method as I see it. First, we have an issue of the remaining time – one third. A third of each day goes where? It gets spent doing what? Not counting for meetings (which almost always can be foreseen) there is a lot of time that is unaccounted. The spirit of scrum isn’t to account for each hour and track who does what when. However, there is almost certainly a lot of actual work that people are doing during this time that has no visibility in the iteration. Agile and Scrum DO require as much transparency and vision into the process of the organization, and this practice of “load factor” I think tends to hide some actual work that the team should be getting credit for doing.

My proposal was to use the ideal days estimates, but add sprint backlog tasks for the things that were being done “on the side” to make them visible, and get “credit” for the real work that was being done but not planned and estimated.

The flip side is that things like meetings, applying operating system patches, and answering email don’t have any real value they deliver. So in that sense, they should NOT be on the backlog. These things are accounted for in the number of available hours for “work” – actually developing the new software.

Leave the status reports and department meetings out of the backlog, but definitely put in that “extra report” for the boss or that batch script for the IT guy. Those are at the very least tasks, and they have customer value (to the customer who got them, not necessarily the end user). Estimate them with story points (even if it’s after the fact), and by all means include those points in the delivered stories at the end of the sprint.

This way there is complete transparency. Everyone can see the actual work that got done, nothing falls through the cracks. And later, when stories aren’t being delivered fast enough (according usually to the boss who got the extra report) then everyone can see that the extra half day spent on that report could have been used to deliver a story. The whole team can then really prioritize what the real features are.

Also – there are a couple of inherent problems in the scenario described above… a good scrum master would have blocked the addition of an “extra report” making the boss decide if he wanted to wait until next sprint or abnormally terminate this one… A second problem that is evident here is that perhaps the Product Owner isn’t perhaps taking into account the internal stakeholders and prioritizing accordingly. Either way, we still shouldn’t be randomizing the team by inserting unplanned work in the middle of a sprint. If it’s that important, stop and re-plan the sprint with the new priorities.

Scrum really does work, but only if we have a set of rules that keep everyone accountable for their contributions and the organizational structure in place to keep the team focused on completing and delivering the highest priority work first.

Lean is one of the three legs of the Agile stool (Scrum, XP being the other two). Lean is a concept originally used by Toyota in manufacturing, and it has been adapted to software development. Lean, Scrum, and XP have some overlap, but they dovetail nicely together, and complement each other's practices to build a strong foundation for software production.

The main tenets of Lean are as follows:

• Eliminate waste.
• Build integrity into the product.
• Enhance and promote learning
• Deliver as fast as possible.
• Decide as late as is responsibly practical.
• Empower the team.
• See the overall big picture

The elimination of waste is a critical point in streamlining processes. Waste in this context is anything that does not deliver value (from the CUSTOMER'S perspective). Writing a status report does not add value for the customer, so it would be considered waste, even though it may have legitimate business value.

Waste in software development is most easily recognized as one of the following.

• Undelivered or incomplete work
• Excessive Process
• Extra features
• Randomization (switching tasks or projects)
• Movement (physically moving from one position to another)
• Bugs

Incomplete work isn't shippable, so it is of no value to the customer. It most likely contains bugs also which are lurking below the surface, as it isn't completed yet (fully tested). This concept is applicable on scrum teams directly, by having the team focus on the topmost few stories in a sprint, and complete them (to a shippable and demonstrable state) before opening the next story. This guarantees complete units of functionality that the customer can value.

Some process is necessary in software development, this is computer SCIENCE after all, an ENGINEERING - not art or the wild west. However, process that doesn't directly add value (in the customer's view) are waste. Performance reviews, status reports, departmental request forms, etc. are all waste in this view. Having a checklist to satisfy and having a code review before check-in are NOT waste, they directly add value that a customer can appreciate.

Extra features are complete waste. It has been long known (and widely and variously quoted) that the majority of features are not used in most software products today. It's basically been the 80/20 rule - 80% of the people use only 20% of the features, and that's enough for them to make use of the product and be effective. The other 80% of the features are probably waste, because of the tremendous time and effort that had to go into building, testing, and maintaining them for a minority (sometimes a very lonely few) users. This time and effort should probably have been better spent.

Switching tasks, contexts, randomizations, and interruptions are another source of waste. This includes meetings, phone calls, IM's, etc. Anything that causes members of the team to have to stop thinking about the software and focus on something else. There is a time cost not only for the interruption, but for re-adopting the context and thought processes again when they return to development. Ideas and real progress can be lost this way. Schedule meetings for the last half of the day only, turn off the phone (YES your CELL TOO), email, and IM when working - this will help streamline the focus and eliminate waste.

Movement or motion is a great cause of waste. Not only does it take time, but it can be physically tiring too. If that developer has to walk down the hall 6 offices to ask someone a question and talk face to face, that takes a minute each way. Also, it's the opportunity to be distracted by other things going on, colleagues, a new cup of coffee, etc. Not that these are bad things - they aren't. However, it blocks the focus on development. Starbucks recently applied this concept to its stores, when it studied how much motion it took a barista to make a latte. They discovered that there were extra motions each barista had to make in reaching for the beans, getting out the milk, etc. They moved the beans up from the cupboard to the counter, and some other minor movement-lessening optimizations and saved a few seconds for each cup of coffee made. Overall, they saved several man-hours of labor each day at each store, got the customers coffee even faster, and saved some work for the baristas. This really is a powerful concept.

Bugs and rework are entirely waste. It wasn't done correctly the first time, so it now has to be done again. Study the reasons why your bugs happen, and make sure to track down the root causes and catch the trends. Make fixes around the holes in the processes that allowed the bugs to fall through. It is far more expensive to the customer and to the software producer to fix things early (like when a test fails) rather than after shipping. Think about Windows XP patches, there have been hundreds. If only 10% of them could have been prevented by more extensive testing, the product might have shipped only a few months later, but how many billions of dollars of IT time, download bandwidth, reboot time, and lost progress with the millions and millions of installed users. Not to mention the growing mistrust of the user community for the company.

Elimination of waste may seem like a simple thought, but in a software development process it can be rather complex and sometimes a bit hidden as to where waste may lie, and how to eliminate it. However, once we get this efficiency, we can lower the cost and time it takes to deliver better quality software to our customers.

This is a pair programming workstation at an undisclosed office near me... it has never been used. Note that there are no chairs... <sigh>

The mere fact that it exists at all does give me hope however. Agile here is not dead, only frozen in carbonite...

This station also sits in a shared workspace that is always empty. It's so sad when there really is a better way but nobody wants to use it.

If there were only two chairs here, with two programmers working together, then, "yer doin it RIGHT." If there were three more of these workstations with six other team members in this shared space, perhaps working with a couple of whiteboards and a cork board with story cards on it, then THAT'S where I want to be.

This station with its dual monitors, keyboards, and mice is the ideal pairing workstation. Both monitors have the same image (clone mode), and both keyboards and mice are active at the same time. The only complaint I would lodge here is that the workstation is so underpowered it really couldn't be used for development. The pair would have to use remote desktop to get to a development machine. Perhaps that is the actual design, however having the local machine there I think is much better.

On an agile team, there are differences and dynamics at work that can help either make the team more successful or less successful. A good coach and/or scrum master should be able to see signs and patterns on the team where differences exist, and use dynamics as leverage to get the team moving in the right direction.

Differences
There are differences on all teams. Difference shows up in many forms and factors in an agile team. There are differences of opinion, differences in roles, even differences in genders. There are differences in seniority levels, differences in skill levels, and differences of understanding how best to serve the customer. Each of these and other differences can either drive a wedge between team members, or be used as a lever to help guide the focus.

Once we recognize that there are always inherent differences from many perspectives, we can choose to either amplify or dampen the effects of these differences. When teams have both introverts and extroverts, the behaviors of these team members can be quite different. These differences in behaviors for these two types of personalities can be quite disruptive. This is a difference we need to dampen. We can dampen this difference by choosing consciously to recognize the traits of these personality types as a team, understand how they operate and recognize behaviors. When the team understands what behaviors to expect, the behaviors become normal or expected, and people on the team can deal with them effectively. Dealing effectively with the behaviors can dampen the effect of this difference, and help guide the team towards better synergy.

There are other differences that also might be dampened. Level or seniority differences can be a big part of behaviors on a team. Because a person is a higher level in the organization than others, some people may tend to behave differently either consciously or subconsciously towards these people. These differences can and should be dampened by discussing the issue as a team, and everyone knowing what the role is and why they are there, in the context of that team. A working agreement can be struck such that within the team, everyone knows what to expect of everyone else there. The expectations and roles being agreed upon in advance can help dampen this difference.

There are other differences that perhaps should be amplified instead of dampened. Differences of opinion can be a hot topic in a team, but these differences in the end make a product and a team better. Differences of opinion should not be dampened, but encouraged. Not everyone should think alike. Different perspectives generate new ideas, and that drives innovation and discovery. Differences of opinion sometimes generate heated discussions, however the passion can be partly diffused or at least deferred. Team members may be passionate about a particular opinion, but if differences are encouraged, team members will grow to respect others with a different opinion, as they see these differences at times paying off with higher quality software. The difference in opinion can be not only healthy, but essential to the growth and well-being of a high-performance team.

Differences can be used as a tool to help guide a team, or can be its undoing as well, if left to chance. Great team leaders, coaches, and scrum masters can recognize where there are differences and use them as a lever to guide the team in the right direction.

Here is an article in the Agile Developer series, about Continuous Integration or CI. Why is Continuous Integration is important? Here is some of the philosophy of how we think of CI and some discussion of practical applications. It is a short slide deck presentation in both PowerPoint and PDF formats.

http://testdrivendeveloper.com/2009/02/10/AgileDeveloperSeriesContinuousIntegration.aspx

Here is an article I posted a while back on what makes a successful agile developer. What makes a successful Agile developer? How are Agile developers different from regular developers? Here is the article with a short presentation and video on the topic.

http://testdrivendeveloper.com/2009/02/01/WhatMakesASuccessfulAgileDeveloper.aspx

One of the large benefits of agile teams should be the transparency to see how things are going at any given time. A team typically has a burn-down chart that shows daily (or more frequent) updates to tasks and stories. This chart is a key to seeing if the team is on-target for delivering what it committed to at the beginning of the sprint. Sometimes the estimated time remaining actually goes up, indicating that delivery will be delayed. This information is critical in trying to manage a project. Problems with delivery are part of the software development game, and should be visible so they can be mitigated.

If we see a trend either flat or upward in the burn-down chart (burn-up as it's called), we should be able to react to this information by talking with team members about what is preventing progress from being made. We can take a variety of actions to address impediments - cut stories, re-focus other team members to swarm on tasks, and other things to try to get back on track making progress toward delivery. However, if we don't have the rapid feedback of the burn-down chart, it's hard to see what the current status of the project is. This chart is the heartbeat of the project.

Team members should do their best to estimate stories and tasks, but as we all know, estimation is usually less accurate at the beginning of a task. When we know more, we should be updating the task estimates for time remaining. Using tools like Rally, Scrumworks, or other products, the work and time it takes each team member to add new tasks and change the time remaining estimates should be minimal and manageable. Make sure to remind team members how important it is to keep the tasks up to date on at least a daily basis.

As an agile team, we should be able to see where we are at all times. This information ideally should even be radiated real-time in the team space so everyone can see how things are going - even the casual passer-by. Problems should never be hidden. Problems always come up, and they get solved not by secrecy, but by publicity. The more minds we have on solution, the faster problems can be resolved. We should never look at problems or impediments as either personal or team failures, quite the opposite in fact.

The team should always be able to see how it is doing, and a good self-directing team will notice its own burn-down impediments and re-focus itself on solving the issue without outside help. Newer teams may need the assistance of a scrum master to call out impediments, but the team should still be responsible for addressing its own issues. Only in personnel or political issues should "management" be brought in to assist with solution. If there are roadblocks, the team should be able to call on the scrum master to assist in bringing in anything needed from outside the team.

Once a team really understands the real power of task breakdown and continuous update of time remaining, they can gauge themselves on their own progress and what needs to be done to address anomalies, avert crisis, and succeed at delivering their commitments.