When Developers Want To Get it Right the First Time

It’s not all that uncommon to be in the middle of rolling out agile practices to an organization and to have newly “self-managing” teams start asking questions about the effectiveness of going ahead with a feature (user story, product backlog item) when all of the details aren’t completely known. Generally you here one or both of the following questions:

  1. “It doesn’t make sense to write something one way today just to have to rewrite it tomorrow when the customer clarifies what they want or asks for something else. Isn’t it better to write it RIGHT the first time?”, and
  2. “Why should be start building something when the customer doesn’t yet completely know what they want?”

Both questions are really good ones to ask and NEED to be asked by an agile development team on it’s way to mature self-management. In this blog post, we’ll deal with the first one: “Isn’t it better to write our code RIGHT the first time?”

This question typically comes from the experience developers have when they find themselves re-writing code they just finished building one or two iterations (Sprints) ago.

As is often the case, I recommend looking at the problem from two perspectives: mitigation (how to reduce the impact) and financial (what’s a good business decision).

  1. Mitigation —
    • While it’s not advisable to slice and size more than 2 Sprints ahead (because things change and you could end up wasting your time), there’s nothing wrong with looking three or more Sprints ahead to get an understanding of what’s coming.
    • Pair Programming – definitely can help here. One coder driving and one coder navigating can open up the possibilities for unexpected improvements to code today that can be beneficial tomorrow.
    • Coding and Design standards — sometimes just attacking similar problems in similar manners with consistently well written code can make a big difference. It’s also possible that SPI and ESB are good patterns, but not the right patterns as being applied. Perhaps there are a few more. Also telling — how many other developers can you talk to about this that are knowledgable of patterns and how to use them? If the number is small, there’s probably a bigger problem that needs to be addressed.
  2. Financial —
    • It’s a lot harder to see when you’re stuck in the middle or rewriting code, but there also a cost factor to include. If we spend more time earlier in refinement or sprint planning, are we guaranteed to a) identify cases where we change what we are doing today to take into account what we need to do, b) discover an obvious solution that resolves both what we need to do and what we might have to do, c) be able to implement the “better” solution less expensively by knowing up front , and d) not have changes in the Product Backlog that reverses our decision because of a de-prioritization or rewriting of a backlog item.
    • The unfortunate thing about problems like this is that we have to approach all problems as if there might be a better way, even though only a small portion of them might actually yield savings by “doing it better the first time.”
I recommend the following steps:
  • Start identifying specific cases where something you did in one sprint had to be significantly rewritten two or three sprints later.
  • Start getting more developers thinking about this problem and also, specifically identifying cases.
  • With the other developers, begin researching and identifying patterns that are reasonably easy to implement and will solve the common cases.
  • When those common cases resurface, implement the agreed upon pattern and then discuss.
  • Create and implement coding standards, implement code review and enforce the standard (change it when necessary)
  • Increase internal learning on this topic.
  • Begin to implement pair programming as a rule (i.e. most coding is done as a pair).
  • Read “Clean Code” by Bob Martin and “The Art of Agile Development” by James Shore.


Why Sprint Planning is Often Ineffective and How To Fix It

I think one of the biggest mistakes in the creation of the Scrum framework is the part where “Sprint Planning” was called a meeting. It would have been better called a “workshop” or, as is now the case, an “event.”

Why? Well, let’s explore the current state of many Sprint Planning “meetings.” You walk into the conference room, and find your team mates sitting around the conference table. Somebody, likely the Scrum Master, has their laptop connected to the data projector hanging from the ceiling and is projecting on the screen a page from a popular backlog management tool. The meeting proceeds slowly with the Product Owner talking a little about what they want to do, the Scrum Master furiously typing everything he or she can, and the rest of the team alternating between slightly interested and doing their emails (in fact, one of the most RUDE behaviors I’ve witnessed in modern meeting etiquette these days is the acceptance of laptops and phones on the conference table and people using them while a discussion is on progress — but that’s another rant for another day).

Meetings like this drag on, are horribly ineffective, and leave the whole team walking away complaining about how they can’t get work done because of “all of these meetings.” Those complaints often lead to the shortening of Sprint Planning and other dysfunctional behaviors, like having one or two senior members of the team decide what the team is going to do, the Sprint Planning event reduced to merely a checkbox on the list of things to do.

If you truly want to run an effective and, most importantly, VALUABLE, Sprint Planning event, here’s a short list of things you need to consider:

  1. Drop “meeting” from your vocabulary. Meetings are held when a small number of people need to get together to review some information and make a decision. Sprint Planning is a workshop where the team is required to do a LOT more than just make a decision.
  2. Remove the distractions. No matter how your team feels about it, working on the product, answering emails, or texting family members during a meeting are NOT examples of improved productivity through multitasking. Team members that are distracted by outside factors are not putting their best into the planning of the next Sprint. If necessary, require that laptops be closed and phones be put away. If you have to, collect the phones on the way in the door. Leave them in a basked on the table and ask your team members to establish a policy with family members that only emergencies will be responded to during planning events.
  3. Hold your Sprint Planning events at the same time every single Sprint — this helps your team plan for the uninterrupted time and helps to ensure that no one forgets to show up. My favorite scheme is a two week Sprint with Sprint Planning held on alternate Wednesday mornings and backlog refinement events held on the other Wednesday mornings at the exact same time (that way, everyone knows that they will be busy in a team event every Wednesday morning).
  4. Remember the time boxes that the Scrum framework suggests — two hours of planning per week of the Sprint. So, a two-week Sprint should have a Sprint Planning event of something between 3 and 4 hours (but not more than 4 hours). On the other hand, if you’re planning a two week Sprint in less than 3 hours, I’d suggest that something important is being ignored or forgotten.
  5. Remember that Sprint Planning is supposed to be the time where the entire team works together to 1) clearly understand what the Product Owner wants them to build and 2) figures out how to build what the Product Owner wants. Doing this properly involves discussion, questions and, sometimes, arguments about solution or approach. If you’re Sprint Planning event doesn’t include reaching a clear understanding and then creating a solution, you’re doing it wrong.
  6. Shut off the data projector. Close all of the laptops. You probably don’t need them (or, if you do, it’ll only be for minor questions that need resolution during the conversation — for example, “what does that screen look like today?”). White boards, flip charts, and digital cameras are your best friends here.
  7. Don’t forget to consider all aspects of your DONEness definition when planning a backlog item. How do you plan to test the completed functionality? What are the test cases? What documents have to be changed? Do any require review/approval processing? Are there any “brittle” or “core” components being modified by the solutions we are creating during planning? If so, we might need to bump the backlog item size a little to account for the additional risk.

Sprint Planning is an important event for the Scrum team. When done properly, the team experiences Sprints that are more easily controlled, have fewer surprises, and create less risk. Teams that control their Sprints (i.e., have fewer unexpected problems) are more likely to learn how to accelerate over a shorter time period than other teams.

What makes Scrum hard is not the framework itself, but the discipline to do something different than our usual (thus Ken Schwaber’s many quotes of the line from the Othello game: ‘A Minute to Learn, A Lifetime to Master’). A good Scrum Master engages his or her team at the white board during Sprint Planning — chairs aren’t even necessary — and the team begins swarming before the Sprint even begins.

Do yourselves a favor. Try it. You won’t be disappointed.

Individuals and Interactions

Some of the hardest work I’ve ever had to do as a coach is convincing teams how to collaborate (interact) when they develop a product. But if an organization REALLY wants to be agile, they have to learn and accept that developers will work better if they collaborate than if they work independently.

So, first things first, how do we convince management? The typical concerns are that 2 or 3 people working together means 3x times the cost for the same output. To get management on-board, we need to create a new paradigm to consider — like this one: when a coder makes a mistake in their coding due to a lack of understanding of the requirements, the cost to solve this mistake is compounded as more and more code is added. Similarly, if a coder misses scenarios or test cases in their solution because they were unaware of them, and then compounds the problem by adding more and more code on top of the invalid assumptions, we create a problem. That same coder, sitting down with team members handling testing and analysis, collaboratively, going through the requirements and the test cases, revising as they discover new ones and correct misunderstandings as they go is going to produce much a higher quality product in the same amount of time. Analysis and design (and thus, code) is emergent — we learn as we go. When we assume that developers (e.g., coders, analysts, and testers) should work independently, we’re suggesting that, once the team has a solution, nothing is going to change so much that we can’t afford to make changes later to correct. Unfortunately, that assumption fails miserably when you consider how much more time it costs to fix things hours or days after we break them as opposed to fixing them immediately as we go (which a collaboration of coding, testing, and analysis skills allows). The increasing cost of these mistakes has been put at an exponential increase in effort every time more lines of code are added in parts of the product that are related to the defect. My experience over 30 years bears this out.

Having suggested a new way of thinking, we now have to prove its truth in action. The most successful way to do this is to pilot something. Something small, but important enough to not be shrugged off as an invalid test when good things result. We need to convince a Scrum team to try it. We need to give them enough time to learn how to do it (a couple of weeks at least of real practicing), and then we need to let them do it without interference. You should see defects decrease as soon as the team learns how to collaborate. You should then start to see productivity increases as the skills of the team improve.

Sometimes the trick to proving to the team that even a really small PBI can be worked on at the same time is to do the following:

1. Make sure you have a comprehensive DONEness definition.
2. Ensure that the team is only working on SMALL PBIs (something that they could complete, working collaboratively of course, in less than 5 days)
3. Make sure you have a good test strategy and test infrastructure (if the team doesn’t know how to test, collaboration might not be your biggest problem).
4. During Sprint Planning, solve and task out the PBI (ensuring that ALL elements of DONEness are accounted for).

At this point, it should be clear that there’s enough work for a couple people to get involved in (beyond simply writing code, writing tests, and updating specifications). Get the team members working side-by-side, communicating, confirming, checking-in code and tests and running them over and over again when changes are made. Don’t open up defect reports (yuck!), just get your colleagues’ attention when something breaks and then fix the code and the tests to cover the failure from ever happening again. Pass documentation and specification changes around to make sure everyone is comfortable with the changes. Keep a whiteboard, flip chart, or an online remote whiteboard-type feature nearby for the collaboration to update their solution as they go.

Give them time to practice and learn but don’t let them back off because it isn’t immediately successful — if every musician stopped practicing because they weren’t amazing on day one we would have a very boring world indeed.

Dealing with Limited Skills Sets

A very common problem that many organizations have to deal with has to do with those “specialists” in the organization that are among the handful of people who have a particular skill. Common skills that fall into this category are technical writers, database architects, UI experience analysts, etc. The problem, of course, is that there aren’t enough of these folks to put them on Scrum teams. Can you imagine a writer assigned to ten Scrum teams at the same time? Unfortunately, I can — I’ve seen it tried. No one can be productive trying to split their time across multiple Scrum teams. Here are some things that you CAN do to solve this particular dilemma.

  1. Cross train (by having the specialists provide some workshops) on the activities that are frequently requested but don’t require a lot of specialized knowledge to repeat. Creating triggers for common situations, creating simple views, etc. are examples.
  2. Develop a process whereby developers do some of these activities with the results being reviewed by the specialists with feedback that can be classed as a) must change, b) consider changing, and c) thoughts for the next time. This way, the activities get performed correctly (in the end) and the developer learns for the next time. Even better, try to schedule time effectively so that the specialist sits down WITH the developer when the work is being done. The feedback, and the learning, is immediate and effective.
  3. Teach the teams how to identify when the specialized skills will be needed so that, as they perform backlog refinement, they can “flag” PBIs that need special handling. Scrum Masters can then have up to 2 Sprints lead time to schedule a specialist to participate in the Sprint during which the flagged PBI gets committed. I had an entire organization embrace this concept with regard to their user documentation. Whenever they refined a PBI that they felt would have an impact on the user documentation, they would literally “flag” the PBI. The documentation team would see the flagged PBIs and follow-up with the Scrum team in time to join Sprint Planning. The writer would then work with the team over the Sprints during which the product changes were made and would update the documentation at the same time. When the product change was completed, the documentation would be as well. This saved weeks of delays caused by language translation because the documentation was ready when the product was.
  4. Avoid trying to work on multiple projects at the same time; this will help your specialists AND your teams by reducing risk and improving focus. In ANY situation, you’ll always here me arguing for better prioritization and less inter-leaving of projects. Making developers work on multiple projects at the same time always looks good on the status report but ALWAYS costs more in the end. But this is a corporate culture thing; as long as the organization believes that developers are interchangeable and context switching is not wasteful, there’s little you’ll be able to do except this…
  5. Try to get a rule in place where only a single project may be worked on in any given Sprint. You can still switch from project to project between Sprints (this Sprint on Project A, next Sprint on Project B), so everything will look like it’s getting done at the same time, but the developers will be engaged in significantly less context switching under these conditions. Shorten your Sprints to two weeks or even one week (hard to do) if necessary to carry this off.

Stop Wasting Time in Detailed Sprint Capacity Planning

A few months ago, I wrote the first in what I hope to become a series of blog posts on things that we need to stop wasting time doing. I want to focus on activities that APPEAR to be really important, but are really just hold overs from old-style management techniques that assume that software development is actually a defined process as opposed to an empirical one. In the first blog post, I focused on the time wasted in release planning. This blog post will focus on my next target: trying to plan detailed capacity for a a Sprint. Let me lay the ground work here. Our team, we’ll call them Team Hourly, gets together to do Sprint Planning. As many Scrum Masters do, Team Hourly’s Scrum Master starts the planning meeting by determining the team’s capacity for the next Sprint. The idea is that the team’s capacity can be compared to the team’s previous capacity in order for the team to decide how much work they are willing to commit to in the upcoming Sprint. If the team has less capacity THIS sprint than in the PREVIOUS sprint, they should commit to less than they accomplished in the previous sprint. If they have more capacity in THIS sprint than in the PREVIOUS sprint, they should commit to a little more than the previous sprint accomplished. While this is, arguably, a worthwhile practice (more on this later), our team has, unfortunately, learned a poor example of how to do this. It sounds something like this:

SCRUM MASTER: “Sally, how many hours do you have available in the current Sprint?”

SALLY: “About 20 hours per week, so figure 60 hours for a three week Sprint.”

SCRUM MASTER: “How about you, John?”

JOHN: “75 hours.”


MARK: “40 hours.”

This continues as the Scrum Master circuits through the entire team, adding up hours as he goes. After polling the entire team, he then adds all the hours together and informs the team that they have 600 hours available for the entire Sprint. This is more than the previous Sprint by 50 hours or about 8%. The team then decides to commit to a little more work than the previous Sprint. Here’s the problem with this scenario — what if John isn’t as available as he says? What if he’s more available? What if a number of tasks in the Sprint Backlog are poorly estimated (it happens, right?) or tasks are missed? What if Mark can do the same kind of tasks that Sally can do, but he takes twice as long because he’s new? We could go on and on with these questions, pointing out the obvious — that even though we can plan down to the hour, IT’S REALLY ONLY AN ILLUSION OF PRECISION. The result looks nice, but we have to make too many assumptions about tasks and team member availability for the hour-based capacity to be of any real use. Thankfully, there are two things we can do to make capacity planning easier (and faster) in Sprint Planning.

Option 1: DON’T USE HOURS – using hours looks nice, but it really doesn’t help. So, an alternative is to simply add up days. In other words, ask, “How many days do you have for this Sprint?” You can even reverse the concept and ask the team how many days will they NOT be available and compare the unavailability to the previous Sprint instead. This option is faster because we aren’t asking people to add up hours and it’s less granular, leaving more room for the unexpected to occur during the Sprint (and it WILL occur). But, there’s an even better option:

Option 2: STOP DOING CAPACITY PLANNING – ask yourself…what’s the worst thing that will happen if the team over-commits? What’s the worst thing that can happen if the team under commits? The world isn’t going to end and, believe it or not, your project schedule will continue mostly unaffected by the team’s changed commitment (unless, of course, your project schedule was unrealistic in the first place, in which case you’ve got a big problem regardless what the team gets done). Here’s what you do instead….commit to what the team got done during the previous Sprint. That’s it. Simple. If the team got 25 story points done in the previous Sprint, commit to 25 again. If they can get more done during the Sprint, they’ll load more during the Sprint and commit to more during the next Sprint. If they can’t get as much done this Sprint as during the previous, they’ll return some work to the Product Backlog and get done what is do-able. And, while they’re doing it, they’ll spend less time trying to come up with numbers and commitments and spend more time actually getting work done.

The Self-Managing, Self-Organizing Scrum Team

Scrum teams are defined as meeting certain criteria. First, they have to have the skills on the team to get the job done that they are going to be asked to do. Second, the team should be between 3 and 9 people (prior to 2007, Scrum suggested that the team be between 5 and 9; more recently, it seems that size was changed to 3-9). Third, the team should be self-organizing and self-managing. It’s the last part I’d like to talk about in this blog post.

When I teach or coach people about Scrum, we talk about these attributes (and I do spend more time on self-managing than just defining it and moving on) — but do we every REALLY give these two key attributes enough time? Sometimes I wonder…

Case in point, a very common dysfunction during the transitioning of an organization from whatever they happen to be doing to Scrum are teams that don’t really seem to know what to do next. Behaviors we tend to see from these teams include (but are DEFINITELY not limited to):

  1. waiting to be assigned to a task on the Sprint Backlog,
  2. assigning themselves to a task on the Sprint Backlog and then going off to work on it by themselves,
  3. delegating planning and estimation tasks to the “senior” people on the team,
  4. expecting a “lead” on the team to determine a design (solution),
    let someone else determine how much work they can do in a Sprint,
  5. doing a poor retrospective (or none at all),
    showing no concern for how to avoid problems that occurred in a Sprint,
  6. showing no concern for how to improve the teams performance,
  7. expecting management to tell the team how to improve.

There’s probably several more common items that could be added to the list (and I’ll do that as I think of them). They all boil down to a lack of self-organization and self-management. Let’s take a quick look at both of these attributes.

  • Self-Organizing Teams decide how they are going to get work done during a Sprint. This is not just about how the team decides to solve a particular Product Backlog Item (PBI), but also how they are going to leverage their skills to get the job done. Who’s going to work with whom? Who’s is going to work on which tasks? Self-organizing teams adapt as they go through the Sprint, moving the right people to the right task on a daily basis. As situations change, the team adapts. Team members self-select for tasks (no one decides for them which task to work on) and work together as miniature “tiger teams” to attack and complete a PBI as fast as they reasonably can. Self-Organizing teams OWN their Sprint Backlogs and work together to build the right product right.
  • Self-Managing Teams look at how they are working and are constantly finding better ways to get things done. They keep their meetings short by keeping each other focused on the task at hand. They OWN responsibility for trying as best they can to get done what was forecasted for the Sprint (yes, I know, it’s a forecast…but unless the situation is outside their control, teams should still hold themselves accountable for doing what they said they could do). Whether they get their entire forecasted content DONE by the end of the Sprint, a self-managing team then takes a critical look at their productivity and their performance and tries to find ways to improve. Self-managing teams OWN their performance and productivity and take their accountability seriously.

If you are on a Scrum team, ask yourself, “do we OWN our Sprint Backlogs and make things happen?” If not, what’s happening instead and how could you get your team and management on board to help fix it. Ask yourself, “do we OWN our productivity and performance and seek ways to improve every Sprint?” Again, if not, what’s happening instead? How could you get your team and your management onboard to help fix the situation.

Scrum is not just about backlogs and prioritization. Self-managing work teams have always proven that they can achieve higher levels of performance (working smarter, not harder) — that’s if you’re lucky enough to be on a truly self-managing work team. Scrum DOES give us a way to make it happen, but its the Scrum Team member that bears responsibility for making a difference — not management.

Get your team to take accountability for themselves. We’re all adults here. And if you fear that your organization’s management won’t let your team self-organize or self-manage, keep in mind that someone has to organize and manage. If it’s not the team, management WILL do it. But I’ve worked with a lot of managers in my day (and been one myself for almost 20 years). There’s a lot of managers out there that, if they saw the teams taking ownership, those same managers would step back and say, “Go for it!”

Is Healthcare.Gov the Alamo of Software Development?

As 2013 begins it’s last few weeks, we may be experiencing the beginning of the end of poorly managed software development projects. I’ll bet, if we take a close look, we will see all the earmarks of yet another disaster in the making. And don’t get me wrong, this isn’t an advertisement for Agile; I’m not condemning waterfall (though you won’t catch me using it ever again). The signs that marked the disaster that has become Healthcare.gov probably looked like this:

  1. Requirements were unclear and kept changing — no matter how you’re doing product development, someone has to OWN the product and be able to make decisions about functionality. When those decisions can’t be made, are made by too many different people, or keeping getting made again and again with a different answer, you get a mess.
  2. Enough time to do it fast, not enough time to do it right — it’s already been said during the Congressional hearings about the project that the team really needed more time, but they couldn’t get it.
  3. Software was not tested properly and was tested too late — USA Today reported today that the general contractor responsible for the project said that testing on the site began two weeks before rollout on October 1. Does this sound familiar? Worse, while each of the independent contractors working on the project were doing some kind of testing during the “construction” period, integration testing didn’t occur until the end.

The list could probably be made much more exhaustive, but there are plenty of people ranting about the website that this information is easily accessible elsewhere. My point is this — this is the first time that a software project of this magnitude and everyday-American-impact has hit the headlines. Sure, there’s been lots of government and privately funded disasters, but they are easily forgotten by the average American. This website, however, not only affects each and every American who needs insurance and doesn’t have it (and wants to avoid the tax penalties in 2014 for not having insurance), but the website also represents a perfect opportunity for some politicians to complain and grandstand and for others to take cover.

In truth, this project isn’t unusual in government or private-sector efforts. It’s not even rare. The overall management and governance approach used in many traditional (and yes, many so-named agile projects) is outdated, ineffective, and wasteful. Politicians are complaining about how badly managed this project was, how many Americans are being hurt and how much money is being wasted. But truly, this project isn’t an anomaly, it’s a poster child for a litany of poorly managed and badly governed projects that are wasteful of funds, time, and people. Those same politicians are keeping silent about many other failed projects in their districts and states, projects that failed for the same reasons, hoping that everyone looks the other way while they rail on about Heathcare.gov as if it were a unique circumstance.

Perhaps the silver lining here is that our brothers and sisters in the software development ranks that took part in this project are not being subjected to this scrutiny in vain. Perhaps, something like this needed to happen in order to open the eyes of the government and the private sector in general that the typical way in which software development projects are managed and governed must change. The Healthcare.gov fiasco isn’t unique, it’s just uniquely positioned. If our leaders in Washington REALLY want to make a difference, they should look to the root causes of these disasters to avoid making the same mistakes again and again and again, instead of jumping on the bandwagon of the cause-célèbre.

What should have happened? At a high-level, some simple improvements would probably have made all the difference.

  • Create a single owner – yes, the United States is a democracy, but software product development is not. In fact, it could be demonstrated quite easily that the fiasco that is Healthcare.gov is simply a reflection of the body ultimately responsible for it, Congress. Congress can’t seem to accomplish anything in a reasonable timeframe either, right? If you want to build a website, you need to know what you want it to do and the kind of user experience you want people to have and you need to have one person who has the final say about functionality. Someone on this project, some close to the development teams, needed to have the authority to have the final decision.
  • Communicate and Collaborate – multiple vendors were involved in the construction of the website and a single general contractor was responsible for the entire project. But in this structure, information has to pass up and down through layers of responsibility instead of across teams. The teams on the project, no matter who they were employed by, needed to be treated as if they all worked together and they needed to work together continuously.
  • Continuous Testing – testing is NOT something you do at the end. Definitely integration is not something that should occur at the end. The development teams should have had a test strategy in the very beginning that would support continuous automated unit and integration testing throughout the course of the project. Yes, this means that development initially may take a little longer, but it supports shorter development cycles (internal releases), smaller batch size (increments of functionality), an earlier and deeper view of the functionality being developed (supporting better decision-making earlier in the project), and would raise the flag far earlier if there were integration or performance problems.

In the end, it’s really not about Waterfall or Agile, it’s about recognizing that software product development is not a defined workflow (think Henry Ford and assembly lines) — it is an empirical workflow (think game development labs or studios where creative, even artistic, work is done). When we understand the underlying nature of the workflow (and stop fooling ourselves that strict management controls is all we need), we can create high-value, high-quality software on-time and on-budget. This is not a Republican failing. It’s not a Democratic failing. This is how the government and most private and public corporations work today. But it’s the wrong way to do software development. Perhaps Healthcare.gov is the beginning of the end of bad software projects?

Advice to the New Product Owner

Have you just taken on the role of a new Product Owner? Well, here’s some advice I’d offer to you as you get started learning the ropes….

  1. Agile Product Management by Roman Pichler. No, Roman doesn’t give me a royalty for each sale of this book attributable to me; it’s just a good book. Get it!
  2. Learn as much as you can about the product, the business plan, the vision, and the business assumptions that qualify the product for development. Identify your stakeholders and start talking with them ASAP about what they want and WHY they want it.
  3. Build a whole new backlog or reassess the current one. Identify business value of all items and make that the Scrum team(s) size the items so you can properly order the backlog.
  4. Communicate a lot. Visit your teams continuously. Stay out of solutioning, that’s the team’s job. Negotiate acceptance criteria. Build based on what you know is valuable. Make sure your end users and customers are frequently consulted.

I’ll add more as time permits. If you have a good addition, just leave a comment and let me know.

Stop Wasting Time in Release Planning!

We live in an economy and in a world where organizations are challenged to do the same amount of work (frequently MORE work) with fewer people. Frankly, in the United States and Europe, if we don’t quickly learn how to succeed with fewer people than we had a few years ago, we won’t be able to compete in a growing technology labor market where labor costs are substantially lower. We must learn how to do two things.

  1. Do it right – We have to learn how to create high quality software without first sending our software to our customers to tell us if we got it right (both in terms of functionality and defects).
  2. Don’t waste time – We MUST learn how to stop wasting time on activities that do not support solid business decision making and do not contribute to the previous item.

I spend a lot of time traveling to locations around the world, teaching Agile Development and coaching organizations to use Agile Development. In pretty much all cases, I find myself confronted with attitudes and beliefs that are ensuring that “Do it right” doesn’t happen and “Don’t waste time” can’t happen. As there are many examples of articles that discuss “Do it right,” in this article, we’ll focus this article on “Don’t waste time.”

Time wasters are amazingly prevalent in the “modern” IT organization. You can find them anywhere, all you have to do is look around a little. Here is an example of what I mean:

Release Planning
Release Planning is one of those potential valuable events frequently overburdened with time wasters that can be easily disguised as a beneficial activity. When done properly, release planning can be beneficial. But usually, it isn’t done properly. Release planning, more often then not, is done as an exercise that runs counter to everything that Agile Development is about. Here’s an example of the wrong way to do release planning.

ACME software has just completed it’s release planning cycle for Version 3 of it’s iACME software (why not? Everyone else uses “i” before their software to make it cool these days!). The release is scheduled for twenty-eight two week Sprints. The entire release backlog has been identified and prioritized and the release plan has been built showing what will probably be built during all of the 28 Sprints. The Scrum teams’ performance will be based on their ability to deliver the content of the release backlog. The next release planning meeting is scheduled for twelve months from now, two months before the current release will be finished, in order to plan the next release.

Now, some might be looking at this and thinking that I just created the worst case situation in order to make a point.  A LOT OF ORGANIZATIONS plan EXACTLY like this!!! And some of you might have finished reading the example and are thinking, “OK. So what’s wrong with this!” Well, let’s review…

  1. The release is scheduled for 28 2-week Sprints – If you want to run a thirteen or fourteen month release, go for it. But ask yourself this question — “Do you and your customer know what they need in the product so well that you can plan it out in detail for the next year or more?” In reality, the more we try to plan into a release, the less right we are going to be. Regulatory changes occur, market shifts occur, economic changes force content changes, and technology changes as we go too. By planning for large releases, we are INCREASING product risk and development costs, not decreasing them. Plan for shorter cycles — you don’t have to ship every release.
  2. The release plan has been built showing what will probably be built during all of the 28 Sprints – here’s another problem. It is rare indeed that our ability to plan the development of a complex product can withstand the uncertainty of 28 Sprints, much less 1 Sprint, and not change or grow. Stuff happens during a development project. Technology changes, defects are discovered, operating systems behave in unexpected and unwanted ways. When this happens we have to adapt. Frequently, adaptation leads to adding content (to change unwanted behaviors) or adding more time (because it takes longer to get something to perform than we expected). This means that, unless we’re going to be willing to just add Sprints to the end of the project until we get everything done (which, hey, maybe you can do that), we’re going to be delivering bad news about release content pretty much from the end of the first sprint to the end of the project.
  3. The Scrum team’s performance will be based on their ability to deliver the content of the release backlog – Holding the teams accountable that nothing in the release backlog will change is kind of like asking them to reverse the effects of gravity or slow down time. It’s not going to happen. They don’t have that kind of control over the environment around them. When teams are measured in this way, we engage in a couple time-honored time-wasters: first, the team spends extra time trying to make things look like everything’s OK (“cooking the books”); second, we spend more time writing status reports and updating Excel spreadsheets trying to convince everyone that everything is OK (“greenshifting”); third, we spend even more time trying to figure out why everything isn’t OK and who’s responsible for it (“the witchhunt”). This is what I call “dysfunctional.”
  4. The next release planning meeting is scheduled for twelve months from now, two months before the current release will be finished, in order to plan the next release – The problem here is that the next release planning meeting should be at the end of the first Sprint and another should occur at the end of every Sprint in the release. The two things we can count on in software development is that 1) our plans aren’t perfect and that 2) they WILL change. There’s enough variability in software development that no plan survives the first couple days of the Sprint. Viewing content change as something to be controlled and minimized is simply saying that the plan cannot possibility be improved — and that’s just wrong. No matter who you are, what market you work in, or what product you’re building — there’s always room for improvement in your release planning.

So, what should we be doing instead? Let’s try this example instead…

ACME software has just completed release planning for Version 3 of it’s iACME software. The release plan is detailed for the next two or three Sprints but is pretty much high level stuff for the rest of the release. The iACME Product Owner worked with many people in the organization (sales, marketing, regulatory, management, etc) to create the prioritization of the backlog; he checks back with those personnel on a regular basis to learn more. Each release of software is planned for eight two-week Sprints. At the end of each Sprint, the plan is re-evaluated and updated based on what the organization has learned by building the software, by showing features to customers and stakeholders, and by analyzing market trends. Short term (high-priority) changes are worked immediately into the current release plan. Other changes are added to the planning for the next two or three release cycles. As each release is finished, the product needn’t be delivered to a customer, but is considered DONE if it is at the same level of quality as if ACME WAS planning to ship the product.

In this example, ACME builds the iACME product in short, two month release cycles. Not every release has to be shipped to a customer, but every release must be potentially shippable, regardless. Short release cycles reduce risk and, therefore, cost. ACME also has learned that the release plan is a good long-range prioritization tool (for managing product development over many months), but that the plan is subject to constant change as we learn more and more about the product, the market, and the technology. ACME can still use the release plan to say, “Here’s where we’re going and here’s what we think it’s going to cost,” but they haven’t decided that change is bad. They haven’t decided that the plan can’t be improved or that changes to the plan are the result of mistakes as opposed to changes being the result of learning more about what they are doing.

Release management in an Agile environment is about accepting the fact that the further we try to predict what’s going to happen, the more wrong we are going to be. Building a plan without understanding and accepting that the plan will change compounds risk and, as a result, cost. To truly embrace release planning in an Agile environment, one must be willing to accept that priorities, features, and customers change and that frequently those changes lead to a better product in the end. Stop wasting your time trying to be a perfect planner and get busy writing software!

We’ll examine more time wasters in future posts.

The Proper Role of Testing in an Agile Organization

We labor under an invalid premise that what works in the traditional factory setting, works in software application development. We have chosen to believe that building software is a defined process where we first identify the product requirements and the system requirements and then move forward to analyze, design, code, and (finally) test — a method historically called the “waterfall” approach.  The roots of this approach reach all the way back to gentlemen like Frederick Taylor (1856-1915) who championed the workflow engineering and Henry Ford (1863-1947) who perfected assembly-line concepts — approaches that were quite successful during the 20th century and, understandably, were then adapted and applied to software application development.

The adaptation of these ideas in the 70s and 80s as software application development became more and more prevalent is to be expected, giving birth to the concept of the waterfall, where development begins with requirements gathering, continues through analysis, design, and coding, and finally ends with testing. However, Dr. Winston Royce once commented, “the testing phase…is the first event for which [the software is] experienced as distinguished from analyzed. Yet, if [the experience fails] to satisfy the various external constraints, then invariably a major redesign is required.”¹

Agile Development embraces this thinking and strongly suggests that all aspects of software development, from requirements gathering to testing, all continuous and constant, rather than done in phases.  Thus, when we look at the activity of testing in an Agile Organization, we realize that testing is NOT a separate activity done after coding, but rather a perception of software application development that is continuous during the development process. In other words,

  1. As we gather product (system) requirements, we should begin to consider how we would test these requirements and, conversely, the practical limitations of the requirements so that we test the product properly and reasonably exhaustively.
  2. As we determine software requirements, we must consider the testability of the application as well as how the application is to be constructed. If we build the application in a way that hampers testability, we increase the overall costs of ongoing proper testing and very likely decrease the attainable level of quality of the application. We also consider the test infrastructure with the same attention we pay to the application infrastructure.
  3. As we analyze features, we consider the acceptance criteria and identify ways that the application should work as well as the many ways that we might wish to ensure it is protected from working (test case analysis).
  4. As we design features, we design tests that work within the defined test infrastructure, satisfy the identified test cases, and even explore avenues of conditions that had not yet been identified.
  5. As we code and test features, we build test scripts and test data beds, ways to create product environments that allow for clean execution of test scripts and minimize false positive and false negative results. We explore how the product works with the newly added or modified code and if we find aberrations in the code, we fix the code and firm up the tests to ensure that the same issue can’t occur again. We run our tests again and again and again, making sure that any feature previously completed continues to behave as expected.

Testing, therefore, is not a phase or an activity, but rather a way of looking at the application you are building. How will you, efficiently and effectively, ensure that the application continues to work from day to day, despite the fact that tens and even perhaps hundreds of people are adding and changing your product code on a daily basis?  In Agile Development, you answer the question with testing and tests that are built as PART of the application, rather than at the END of the application development effort.

¹ 1970. Royce, Winston (1970), “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9.