I have heard a lot of discussion lately about the use of the "#region" directive in C#. There are various camps (some religious) on this topic, so let me throw in my twopence.

Many developers like to use regions to collapse sections of the code because it makes it easier for them to focus on a particular section. That's nice.

If there is that much code in a single file (which *should* be only ONE class), then there is probably too much code in that class. Class design should be focused on one specific thing. According to good OO principles, classes should be autonomous, and do one specific thing. Classes should be intelligent groupings for functionality relating to a specific, focused purpose. The use of the region to group code bits together in a file is a good indication that there is probably too much code.

Simplicity is a highly desired principle in software development. It's the simplest thing that gets the kudos, not the most complicated. Developers who try to write complex, convoluted code so that they can look good to their peers are really doing the opposite. Added complexity is very costly, in time for other people to understand it, debug it, and maintain it.

Here are some ways to determine some code smells in this area.

• Do methods have more than 25 lines of code? If so they are probably too big - this is a code smell.
• Do classes have more than 12 methods? If so, this may be another code smell. Classes that have lots of methods probably are doing too much. See if they can be broken out into more focused pieces.
• Are there more than 3 constructors? Sometimes a lot of constructors could be a code smell indicating using a class for different things in different places.

Anyone else have any metrics that they use? Please respond with comments below.

These kinds of things should be completely discussed on a team, and woven into working agreements, and coding standards guidelines. Teams that work within these are the most productive because everyone is on the same page and playing by the same set of rules. If your team doesn't have a guideline for these kinds of things, I would encourage you to write one up today and get input from your team.

How to Fix Problems on an Agile team - Examining the Evidence
In this article, I discuss how we can look at the artifacts produced by an agile team, to assess the fundamental health of the team and the business value the team can produce. Then, I offer a means to fix the underlying issues that we discover as symptoms of the problem. Here is one example of a practical approach at looking at some specific assets and artifacts, tracing back to a possible root cause, and an idea on how to fix it.

Artifact                       Cause                                  Fix

Engineering Debt                   Not refactoring design iteratively        Train developers in refactoring
Developers need to understand what it means to refactor a piece of code. It isn't enough to explain what refactoring means without giving some good examples. Many times I have seen what I call "superficial refactoring" where only a few things are touched, so as to minimize changing the code that's already there. I have heard developers say "well, I don't want to touch that code because [it is currently working | I don't have time to fix it | I don't understand how it works]" so, they leave it alone and just add their blob of new code, which now sticks out like a wart. It was not part of the initial design, and now that the initial design is obsolete (in some form), we now have engineering debt in that the design of the old code was not updated to reflect the now new "whole" image including the new functionality. Watch out for superficial refactoring, and if it happens - be sure to train on how to do a complete refactoring. Note: this might cause developers to estimate stories higher, since they will be thinking more of the actual work needed to be done...

Lots of Bugs                           Not enough tests                                 Unit test, use TDD, train developers in testing techniques (use QA to help)
Test Driven Development is a good mechanism for reducing bug count. But, sometimes it is a hard-sell to developers who have been "traditionally" trained. Also, sometimes it is a hard-sell to management who will only see that it is taking longer (at first) to get main line code written. Over a few weeks, lights will come on for developers, and they will begin to see the benefits of testing the code first, and letting the code evolve as a response to the tests. Bugs will be much fewer, because the developers will need to consider more things when they write tests. Having a QA person assist the developers in writing these tests can be very beneficial as well, as they will be able to give guidance in testing appropriate areas of the code such that bugs will not be written into the software in the first place.

Failure to Complete Stories      Stories Too Big / Too vague               Focus on DONE criteria, swarm on stories, better task breakdown in planning
I see not completing stories is a process smell. There are a variety of reasons this might be the case. Perhaps the team does not have enough clarity on what actually needs to be accomplished in the story. This is usually evident if the planning for a story goes very quickly and no/few tasks are broken out. Also if stories are too large ("epic" stories) we should break them out into separate smaller stories that are easier to estimate. Many times during a sprint, I have to add tasks to a story because I hadn't thought enough through the component pieces that needed to be modified until I actually got into the work of the story. Sometimes this is unavoidable, but mostly I consider that I should have spent a bit more time in planning for the story so that I had a better grasp of the work involved. If I get my team to help me work on tasks on a story rather than starting a new story ("swarming"), this can be an effective means to get stories done. This is not always practical, as some stories have tasks that are very interdependent, and it's difficult to get a lot of people to be able to work these effectively. However, if the team has enough discipline, focusing on stories that aren't completed before starting new ones is a great way to have stories finished at the end of the sprint.

Customer Dissatisfaction          Customer is not the Priority                PO focus on customer value, get customer in the room
The customer (or stakeholder) doesn't like what the team produced. It can be a variety of issues that causes this problem. Perhaps the PO didn't get the right idea from the customer. Perhaps the ideas did not get properly communicated to the team. Perhaps the team is more interested in some technology than giving the customer working software... Sometimes relevant stakeholders (Operations or Management, for example) were not involved or represented by the PO adequately. The team needs to make sure they understand what the customer's priorities are, and why. Satisfying the customer also must be the primary focus of the team. This information should be given to the team during planning, by the PO. The team then has the opportunity to ask all the questions they need, to be able to understand the customer's needs fully. The PO and the customer should be accessible by the team during the sprint, so that if there are questions that come up during the work, they can have answers in very short order.

Use these strategies as a starting point for assessing issues. These aren't the only things that can be analyzed, but in my experience I have seen all of these come to light on one team or another. These are only starting points, ideas to get an analysis moving. Please respond with comments if you have some different specific experiences that could help other readers as well.

First off, let's get something out in the open. As an agile software developer, I have a couple of strongly held beliefs.

Design isn't optional.
Architecture isn't optional.

DTSTTCPW doesn't mean "no up-front design, we'll just wing it." [That's DO THE SIMPLEST THING THAT COULD POSSIBLY WORK for all y'all who don't speak acronym.]

When we fail to refactor our new code into the existing code, we get odd bits of functionality that stick out from the existing design like warts on a bowling ball. The idea behind refactoring is that we intend to make sure that we *always* have a round ball. Refactor doesn't mean just change a signature or two. Sometimes it means we need to go back to the design white board and figure out what we need to have *now* given the current functionality requirements. We almost always need to change the existing code's design and integrate the new code so that all appears cohesive, each and every time we write new code. Iterative development doesn't intend that we make a bunch of atomic changes and just glue them together.

Code design at each check-in should be able to withstand scrutiny of any outside reviewer, and the design should be up to engineering standards. We still call it software *engineering* not software *art*. Many teams I see are missing this point completely and are producing code that should have been re-designed rather than just having new code glued on. With each check-in we should be able to look over our classes and functionality and say, "yes, this is something that would withstand the scrutiny of a code reviewer not on my team, without excuses or explanation." If I have to couch it and say "well, we will be fixing that in the next release" or "we'll revise that in a later check-in" this is technical debt, and therefore a process smell. Developers that are stuck in this rut need to be re-trained that they aren't "done" with the code until it is production-quality.

If there are warts on your software, this is a very loud process smell, and it should be addressed directly. Make sure that the team understands that this is not an acceptable way to work on an agile team. Re-design in refactoring and adding new code should be common, and discussed among the team after the stand-up meeting daily. "Yesterday I re-factored and re-engineered the Widget classes, so that they now have the new functionality we need in story XXX and are more streamlined to what we are delivering this sprint. Today I plan to have a half-hour review with the team so everyone is on the same page with the re-design. Then I will incorporate all the feedback, get the final code reviewed and coordinate the check-in with the rest of the team to make sure I don't block anyone. I'll make the appointment for the review with everyone after the stand-up."

Make sure that everyone understands that the code as a whole should be well-designed at each commit point, and that this isn't optional. It needs to be expected behavior on the team. This also means that estimation of effort may (and should) go up, for complexity on tasks in both story points and hours. We don't look at revising design as "additional work" just like we don't view unit tests as "additional work." These things are both fundamental parts of the iterative process. Without adhering to these principles, iterative development just won't work, and we might as well go back to waterfall.

If your team has the process smell of needing to budget additional work for refactoring the design, perhaps it's time to go to the team and discuss what Agile software development really means, and that it doesn't mean lower-engineering quality software.

What's your team's truck count? No, not how many SUV's do your people drive... Truck Count refers to how many key team members would need to be hit by a truck before your project fails. Not a very nice thought, but it gets the point across. It means, if a key team member leaves your team (and presumably the company) how would this adversely affect the project? Lower numbers are BAD.

About the best you can do is one less than the team size. The worst you can do is "1." Think about your project, and think about who is keeping the brain-share of knowledge. Are they passing it around the team, or does the knowledge sit under one person's cap? If so, that person makes your truck count lower and your project riskier.

Team knowledge sharing is a fine idea, but it's not always easily accomplished. We use tools discussed below for information sharing and actual knowledge transfer.

Tools
    First of all, let me just start out with: EMAIL IS NOT A TOOL FOR TEAM KNOWLEDGE TRANSFER. "Well, I sent you an email about that last week..." it's just not an effective mechanism. Don't be tempted to use it. Email should be for temporary and archival type information communicaton - NOT knowledge transfer. Here are some things that DO work.

• Wiki
• A Wiki is a good tool for a central information repository, allowing team members to add and update information easily and frequently. There are many wiki tools available, but mediaWiki currently is the leader. The ideal wiki site would allow team members to use it without having to "log in" as this is a barrier to getting the information into the site. Even more ideal would be the ability to have remote access to the site from home (with the proper security of course).
• Online team services like Rally, Scrumworks, and others
• Online team service sites allow individuals to have access to the stories, backlog, burndown, and other communication tools from anywhere. This removes a hurdle to information sharing by not requiring physical access or the hassle of having to fire up a VPN client.
  
• Pair programming, and promiscuous pairing
• Pair programming is probably the most effective way for knowledge sharing and information transfer in a team. Pair programming is an XP concept, but unlike Scrum, tenets of XP can be adopted individually on a team, rather than buying the whole program. Each tenet ads value on its own, even if others aren't adopted. Concepts like test-driven development, continuous integration, shared workspace are all good tools for development, but each ads its own value, and all are good for increasing truck count.
• Arlo Belshee calls it "promiscuous pairing" when a team doing pair programming switches pairing partners regularly, and frequently. He advocates pairing different team members together rather than the same set day after day. I have experimented with this on a highly performing team, and with the size of the team at 5 and the dynamic there, we decided that half-days were a good mix. After lunch we would switch pair partners, and information flow among the team increased without a large adverse affect on performance.
  
• Shared workspace
• Simply co-locating team members is a fine way for information sharing to occur organically. Just simply removing cubicle walls allows sounds and communication to flow freely. Removing physical barriers is an effective way to increase information flow and increase truck count.
  
• TDD game
• The pairing game is where one person writes a test, then the other person writes the code. Then, they switch. This is a very effective way to have both parties fully engaged.
  
• Code Review
• Reviewing code from other team members is a marginally effective way to get information spread across the team. I am not a big fan of code reviews, but I recognize that they are a necessary evil for those teams not actually doing pair programming. The review must be willing to put aside distractions and interruptions to concentrate on not only what changed, but also the whole of the code - making sure to understand it and verifying that it's doing the right thing.

These are just some of the things I have used for information sharing and helped my teams in distributing the brain share for a project. There are probably others as well, feel free to collaborate by adding your comments below.

Our scrum master on the team I am working with has advocated a mid-sprint checkpoint meeting, to see how things are going, and take a progress pulse. I said this sounded a bit like  to me, but that didn't go over very well. I left it at that, but was just thinking about it some more. Why would we need a mid-sprint checkpoint meeting? The burn down chart clearly shows our progress on the sprint, trend lines are good, and everyone is reporting progress and no impediments in stand-up every day. Another meeting? Sounds counter-productive to me, just to see where we are - when we should all know where we are. There are now even have a couple new wide screen monitors displaying 4 rotating web pages, used as information radiators for the team. Everything seems to be good, and going by the book for scrum, so just little things like this that remind me of my Microsoft days cause me to take pause and say hmmm.....

Perhaps a 3 week sprint is too long if we need a mid-sprint review. See the prior article for more information on sprint lengths...

Ask a question like this, and you're likely to get a numberline as an answer...

"two weeks"
"three weeks"
"four weeks"
"one week"
"15 calendar days"
or, in general, n+1 answers for every n people asked.

Which is the correct answer for my team?

Turns out that it's all. Or none. Or one of these. Or sometimes two.. There are a variety of factors that can help determine what the "right" length of a sprint is for your team. And, it does vary by team. Some organizations have one team on a two-week cycle, and another team on a 4-week cycle. They coincide, so deliverables can be coordinated, and intra-team dependencies can be predicted. Other teams swear that the original proposed Scrum cycle should be 4 weeks, and that's that. Most teams are open to doing what works. However I have seen organizations prescribe to the team how long their delivery cycle should be, for one reason or another. This dictated timeframe seems to be a bit less effective than getting the team to decide. Also, larger teams tend to have more problems with estimation, as do very small teams. More than 7 or less than 4 on a Scrum team seem to be the limits for most effective delivery, in my experience.

Now then, there are certainly pro's and con's for each of the cycle lengths. A longer cycle means more stories can be included, but that the feedback cycle of estimation vs. delivery is longer and thus not as able to hone in on velocity. Too short a cycle sometimes feels like thrashing, and that not enough complete, thin slices of end-to-end functionality can be accomplished. Remember at all times, that a completed "done done done" story is "potentially shippable."

The truly completed "done done done" story is rare in my experience as an actual shippable unit, but that's an article of its own on how to pick and adhere to DONE criteria.

Let me discuss the merits and drawbacks of each of the cycle lengths above. For the sake of discussion, I will assume a Scrum team of 7, 4 developers, 2 testers, and a project manager. I personally have tried each and every one of these iteration lengths, so I do have the perspective of experience (on a small team). Your mileage of course may vary...

Two Week Cycle
This cycle length has been in my experience the sweet spot for a small, experienced Scrum team. It is just big enough to get "real work" done each iteration, and small enough that the feedback on estimation is frequent enough to get closer on story estimation and velocity determination. I have also found that this relatively short cycle is good for preventing "hijacking" of a sprint by one or more stakeholders, management, or others that work outside the Scrum framework. Almost always, a sprint in progress can be completed even in the face of changing requirements, or stakeholder directions. "We can start that the end of this week" or at the latest "the end of next week" is almost always a fine response to these winds of change. The time spent planning and demonstrating (meetings in general) is a good middle ground, and payback for this time spent is usually pretty good. The typical planning meeting is 4 hours, first thing Monday, and the demo is 1 hour, and the retrospective 1 hour, at the end of the day the second Friday. I am a big fan of sprints that start on Monday and end on Friday, rather than the middle of the week. Mid-week sprint endings sometimes allow for "between sprints" time which I don't tend to like, as the things getting done aren't accounted for in the velocity of either the prior or following sprint.

Three Week Cycle
Three weeks is a good compromise between those who want faster, and those who want bigger chunks of work done. However, I am still of the opinion that for most teams, there is too much wiggle room in 15 business days. Sometimes estimates are padded. Sometimes people end up working on things not on the backlog. Estimates tend to be farther off, because there is a perception that there is more time available to get things done. For a disciplined, experienced Scrum team that has worked at least 4 sprints together, this might be a very workable option. Provided that the organization plays by the Scrum rules, that the team keeps estimates to realistic values, and that the team is truly able to break down stories into small tasks.

Four Week Cycle
Most of the 4-week teams I have seen have ended up going back to a mini-waterfall approach. The first week tends to be design and investigation stories and tasks, a couple weeks of cranking out code, and the last week of testing, finding and fixing bugs. Not that it has to be that way, but that has been what I have most commonly seen. I think the reasoning was that the teams perhaps were not as experienced with Scrum, and the number of days left a perception that there was a lot of time to do things "the old way." Also, I have seen sprints hijacked by various issues and people, and totally taken sideways due to the length of the time. Feedback loop is much more difficult to perceive for most of the team, and as such, estimation may not just stay the same, it may get worse. Tasks tend to be lumped into large blocks of 15 hours, 20 hours, or more. A typical task on an experienced team with good estimation is not often over 4 hours, and never over 10 hours. These teams tend to be able to peg the stories for story points more accurately, and are able to deliver the stories as complete. This iteration length doesn't seem to work well, in my experience.

One Week Cycle
"How can you expect us to get anything of business value done in just one week? Especially given the Done criteria for potentially shippable?"
I think that's what I said anyway. My team was on a 2 week cycle, but we didn't have much experience with Scrum at the time. We were having lots of issues trying to break stories down into tasks. I recall several 40, 30, and other double-digit task estimates. They were just too big. We couldn't figure out how to break them down further. Planning sessions were a nightmare, lots of arguments about task breakdowns, and estimates. Fortunately we had an agile coach who suggested that we ratchet the iteration down to a 1-week period. At first, this seemed totally counter-intuitive to us. Shorter iterations? Wouldn't that make it even harder to break down tasks? As it turned out, that wasn't the case. We had to break our stories up from the epic stories we were using to actual user stories that delivered an increment of functionality that had business value. That was just the thing we needed to figure out what we couldn't do in the 2 week cycle. We tried one-week iterations for several weeks, and got a lot better at breaking stories and tasks down into smaller pieces. We as a team decided then that it was too much overhead to have a planning meeting, a retrospective, and a demo every single week. The stakeholders didn't really understand, and what we were demonstrating was such a small increment that they were starting to think that the project was just dragging out in delivering small pieces. The two week cycle was a good return on the time spent planning and demonstrating, vs. the time spent actually delivering work.

In the end, it should be up to the team to figure out what works best for them - given some input from the corporate culture and stakeholders. New teams just starting out with Scrum should perhaps plan to try first two sprints each of 2 weeks, then two for 3 weeks, and compare results. By the end of the 4th sprint, the team should have some reasonable idea of what would yield the greatest velocity. If there isn't a choice for iteration length and it's prescribed, you'll probably have to just make it work. In any case, try to avoid the con's above and see if you can get your scrum master to push back a bit on the powers that be and let the team have a bit of freedom to see what works best for all. Scrum should be a collaboration, so if at all possible, do the best you can at making sure everyone has their input represented and just hold the team accountable and let the team manage their own delivery.

Everyone keeps asking me about it, so here it is...
So you want to know about threat modeling? Congratulations, you have taken the first step toward software security. Software security should be the first thing we think about when we write software, but somehow it ends up being the last thing in a lot of cases. We should really be designing software with security as Feature 0. A Threat model is a nice element of an overall security plan, which really should be figured out before code line 1 gets written. This article gives a basic overview of how to create a Threat Model document, which can be used as a basis for a security plan for the system.

What is a Threat Model?
A Threat Model is a Document. The document describes a system in more or less a standardized way, so people can easily understand the system's overall architecture and design, and how it functions - from a security perspective.
A typical Threat Model Includes:

• Architectural Components
• Data flows
• Points of Entry
• Possible Attack Vectors or Scenarios
• Remedies or Counters to the Threats

How-to create a Threat Model
We can work backward from the goal: Ship secure software. To do this, we need to eliminate or mitigate security threats. To find these threats, we need to identify what's important to us, and how it can be used (for us and against us). We need to be specific about what we have that needs protection. Only then can we be clear about how to protect. We can use a Dataflow Diagram to help us identify these things in our system. Here is the suggested process:

1. Create a Dataflow Diagram
   1. See my separate post here: How to create a Dataflow Diagram
2. Identify the protected resources (Assets) that are of value to us.
   1. Everything on the DFD is an asset. Every dataflow, every process, interactor, and data store.
   2. Servers may be assets, as well as their operating systems, and other software on them.
   3. There may be intangible assets as well, such as bandwidth, or industry reputation. Imagine the damage if a security company's web server got owned by a hacker.
   4. What other specific things for the organization might be of value?
      
3. Identify the Entry Points - all places where data can enter the system.
   1. Entry points are more than just services listening on ports.
   2. Input or data files
   3. RSS feeds or external data feeds
      
   4. Configuration files or business rules engines
   5. Unintended services left running on the server
      
4. Locate the Trust-Level boundaries.
   1. Where are there components that communicate with each other at different levels of trust?
   2. Server and client are definitely different trust levels...
   3. Consider server boundaries
   4. process boundaries
   5. application boundaries
      
5. Brainstorm Threats
   1. Get the whole team together (developers, testers, program managers, and even management) and discuss each of the things on the dataflow diagram, to see what if anything there is that is possible, or potentially a threat. Don't exclude any ideas at this point, just write it all down. We can eliminate and prioritize later.
   2. Keep in mind that each of the asset types has a set list of potential threat vectors for it, these can be used to examine each asset for a thorough evaluation.
      1. Threat types are [STRIDE] Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Escalation of privilege.
         
   3. No threat is to big, to small, or too outlandish to record. "Someone could bribe our sysadmin for the root password" is still a valid threat...
   4. It’s sometimes difficult to identify the threats. We can use a trick to find threats by identifying them from mitigations:
      “We use SSL to protect the data flow between the server and the user.”
      That’s a Mitigation… but what’s the Threat? Man-in-the-middle, data disclosure, etc.
      How about “SSL authenticates the server.” => Threat: “Hacker could impersonate our server”
      
6. Refactor, revise, amend, prioritize, categorize Threat list.
   1. Go through the list, and evaluate each of the suggestions, giving each a priority. If there are non-valuable suggestions, discard them at this time.
   2. Threats need to be linked to a asset(s), and entry point(s)
      
7. Brainstorm mitigations to threats, starting with the highest priority
   1. Mitigations include firewalls, SSL encryption, PKI security, certificates, and the like.
   2. Sometimes a mitigation for a denial of service threat is to increase the performance of the application, such that the expensive issue is no longer expensive. Other times we can mitigate by throttling, or something akin.
   3. Mitigation Examples:
      1. Code Reviews - #1 most effective means to prevent security defects
      2. SSL protects in-transit data and authenticates the server (does NOT authenticate the client…)
      3. Input validation for user input
      4. XSD validation for XML documents
      5. Use Stored Procedures to access all data
      6. Access Control Lists prevent unintended access
      7. Firewalls prevent unintended access
      8. Least-Privilege accounts lower the amount of potential damage a compromise can effect
      9. Bandwidth Throttling can help prevent DOS attacks.
         
8. Document all of these things in a "standardized template"
   1. Different organizations use different templates, I don't have a good example yet but when I do I will post it.
      
9. Present and Review the threat model with the team producing the software.
   1. Everyone should be on the same page. The threat model is a great way for everyone to come to a common understanding of the architecture and focus on the things that can keep it secure.
      
10. Keep the document secured, and release it only on a need-to-know basis.
    1. This document tells everyone what we know are potential shortcomings of our system. Keep it under wraps!
    2. Only allow access to specific personnel, and make it a short list.
       
11. Review and Revise this document EACH SPRINT.
    1. Even if no new features are shipped in a sprint, it is worth reviewing the model document, just to make sure it is still accurate and relevant.
    2. If there ever is a security incident, the information most definitely should be added to the Threat Model document. One would wonder at this point what in the process of security and system design let this flaw in. This would be an opportunity to evaluate the design process and make some changes.
12. Use the Threat Model as a guide to designing and developing software
    1. Now that you have a basis to start, use it as a springboard to design and implement better software!
       

Using this method, we should be able to produce a document that gives us a base starting point to talk about security of our system, and help even non-technical people get on the same page to understand what any potential issues are. With this understanding of the system, we can then move forward and focus on the areas that are most important.

There are some tools available, here is one from Microsoft. It has some pro's and con's. There isn't much else out there that I know of at the moment in terms of tools that help with Threat Modeling.

Here is also a nice article on MSDN about Threat Modeling that is similar to this method I describe.

PS - some terms used in Threat Modeling
Terminology

• Asset        (Protected Resource) Something we have that someone might want to get
• DREAD        Ranking system – how serious is it
  • Damage, Reproducibility, Exploitability, Affected users, Discoverability
• Entry Point        Interface between the system and the world
• Exploit        Using a vulnerability to compromise something
• External Interactor    an entity not in scope for this threat model
• Mitigation        lessening impact of or elimination of a threat
• Penetration Test    third party is hired to find a way to hack in
• Vulnerability        a security flaw that could be exploited
• Vector        the mechanism of entry
• STRIDE        Classification system – what kind of threat is it
  • Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
• Threat        an adversary’s goal
  
  

Definition: Technical Debt is a term that we in the Agile world use to describe things in the code that perhaps aren't engineered as well as they could (should) be. It can refer to many things, like areas in the code that we should probably refactor to make them more readable, poorly performing code, obsolete or clunky architecture, encapsulation abstraction, or other class problems, or the like. It's debt because we know about it, we "owe" it to be done, but are focusing on other things instead.

Technical debt is the avoidance of doing work that we would otherwise do in the course of doing our best practices in engineering. It's a fact of life that most every Agile team has to deal with, in my experience. I find that there are various means of "dealing with" technical debt, some of which I will discuss below as a matter of practicality. However, I see it really as a symptom of a deeper problem. The team isn't finding good engineering as valuable as completing stories could be the underlying problem.

Teams can be pressured to deliver more than they should (this is common), and as such, could be focused on delivering the current sprint's stories rather than fixing things they find that are not as they should be. The team also could be creating more technical debt for itself by not focusing on good engineering in the first place. When junior people design things, sometimes they don't address all the points of performance and code maintainability. Trade-offs are made that can end up causing lots of rework later.

The concept of Agile software development, is heavily based on refactoring. Sometimes I find that teams use refactoring with a little "r" when they should be Refactoring. They make small internal changes, but are reluctant to change overall design, even when it is truly warranted. When we add a new feature, sometimes the design needs to change to accommodate it. THIS IS EXPECTED behavior in an Agile development process. Yet, time after time I hear developers say "well, I don't want to change all that NOW..." when that's really exactly what they should be doing. The concept of iterative development should be allowing us to ship software at the end of every cycle, and we really can't consider the software shippable if it has these poor designs still left over from earlier days.

Refactoring the design shouldn't be catastrophic though. But, there is always some impact that is almost always fundamentally left out when planning. Imagine we have an apple, and we need to add some cherries to it in this sprint. We might just smash the cherries on the outside of it, and call it good. But that would leave us a lumpy ugly mess... Rather, we might take another approach, and put the apple and the cherries all in a blender, and pour the mix into a new shape mold and freeze it. The new shape will be smooth and round, yet it will encompass the new features of having both apple and cherry flavors. It's a dumb example, but you get the idea. Refactoring can take many forms.

Handling Technical Debt
Now, I have been on a few Agile teams and I am a realist. Technical debt is most certainly here to stay. We just aren't in an ideal world, and we can't always take the time we really need to make sure that the iteration's deliverable is as pristine as it should be. So, now how can we handle this debt in a practical way?

Here are some ways I have seen teams deal with Technical Debt:

1. Ignore it.
   1. This don't work so good, in my opinion, but yes I have actually seen it done. It works, so we'll use it as-is.
2. TODO it.
   1. //TODO in the code is a flag that there is something more that needs attention. Also, //FIXFIX and //BUGBUG are others I have seen. Some of the tools give us mechanisms to flag these as work items, but in my practical experience this is just about the same as #1. Nobody ever gets back to these things to fix them. They just lose visibility and get buried. Not very effective in my book.
      
3. Backlog it.
   1. Create a backlog item called Technical Debt. Each instance where something needs attention is recorded as a task for this story. They can be estimated, and prioritized. Backlog items have visibility, so they don't get lost. Here is the problem - Technical debt now CAN be prioritized. And, it usually is - right to the bottom of the list. This really doesn't solve the issue either, unless you have a product owner who is savvy enough to know that good engineering means happier customers, developer, and management in the long run.
      
4. Bug it.
   1. Log a bug for each Technical Debt item discovered. This is probably the most effective means I have yet seen for the actual reduction or elimination of technical debt. In reality, I think this is the most appropriate. The new story requires changes that just haven't been made. It's not really "done" until this is taken care of. Ongoing maintenance of code should have an appropriate stakeholder with a voice in the Product Owner's scope of attention.
      
5. Job-Jar it.
   1. Put it into the bucket of things that need to be done but aren't on either the sprint or product backlogs. I think this is marginally effective, because nobody should technically ever have time to get to this stuff, they really should be pulling things off the product backlog onto the sprint backlog. But, I thought I'd mention this concept since someone brought it up.

Are there other ways to deal with Technical Debt? What ways have you had success? Please leave me a comment and let me know.