When choosing how to allocate resources, it can be difficult to do an effective cost benefit analysis in a short period of time. A technique that I stumbled upon is to look at things from the perspective of “what would I do if I was the only person on the team?”
In 1992, I convinced my manager at the Open Software Foundation (OSF) to create the position of tool smith and allow me to work on the OSF Development Environment (ODE) full time. As I now had much more time for doing development and made many more changes to ODE than I had ever made before, there was much more testing to be done.
Initially, I didn’t realize just how much testing was fully required for ODE. Not only were there no automated tests for ODE, there were no documented test cases either. The test plan consisted entirely of “round up as many volunteers as you can and have each volunteer test on one of the nine platforms.” The testing that each volunteer did was entirely up to their discretion. It was different volunteers every time, and there was no record of what they did, only a “seems fine to me” or “I found these problems.” Once the number of problems got down to an acceptable level, we’d ship the new version.
After a couple of releases it started to sink in that I had to do something differently. My first attempt was to document a standard set of test cases. At first this seemed to work really well. Testers commented that it was much easier and took much less time. I felt like I had gotten a consistent set of results from a consistent set of tests. But a test/fix cycle requires running the same tests over and over again until things stabilize. Following the same steps over and over again can become pretty mind-numbing. Pretty soon I couldn’t get the volunteers I needed and I was starting to suspect that people were skipping steps.
I also discovered another problem. As bug reports came in from production use, and as I thought of test cases that were missing, the list of test cases mushroomed. I was very careful not to include overlapping test cases, but still the list grew and grew and grew.
Since the QA of the tool was ultimately my responsibility, I had to pick up the testing slack. The combination of the ever increasing list of test cases and the diminishing pool of volunteers soon made the QA of a new release pretty much impractical. I would end up spending much more of my time testing than coding.
But then I remembered how I had gotten the job of tool smith in the first place, by automating myself out of my previous job of manually kicking off builds on all platforms. Test cases are basically a set of steps to take and the expected results. Automating test cases is basically coding, and that was much more fun than manual testing. A couple of inspired weekends later I had automated all of the test cases and added many more new ones as well.
That was the last time I ever relied on manual tests.
Read more from: "Zero to Hyper Agile in 90 Days or Less"
Wednesday, June 25, 2008
Reinvest in Your Engine by Improving The Work Environment
There are really only five ways to increase the profitability of a business based on software development: reduce costs via outsourcing, reduce headcount, reduce other expenses, increase productivity or increase revenues. Reducing expenses can only go so far. The most expensive part of software development is the people. Thus, one of the most successful ways to increase profits is to increase the productivity of the software development team.
Your development infrastructure is really no different than the general company infrastructure which includes your cube or office, the carpet, the artwork on the walls, the company cafeteria, your phone, your computer, and the company location. These are all part of your work environment. If you have a computer that is 5 years old, your work environment is not as good as if you have a computer that is only 2 years old. If you are writing in C rather than C++, C# or Java, your work environment is sub-optimal.
The closer that your development infrastructure is to the ideal environment for your circumstances, the more productive your team will be. This principal extends to all aspects of the development environment, from development language, to build system, to build farm, to issue tracking system, to the process that you follow.
Next: Your Development Process is Part of Your Work Environment
The Agile Workplace
At Litle & Co., developers like the fact that Agile provides the additional challenge of solving business problems instead of just technical problems which requires thinking at a higher level. Developers at Litle report that they have a higher level of job satisfaction than in previous companies that were not using Agile because they see the results of their software development efforts installed into production every month. Also, they like the fact that there is much less work which amounts to “implement this spec.”
Your development infrastructure is really no different than the general company infrastructure which includes your cube or office, the carpet, the artwork on the walls, the company cafeteria, your phone, your computer, and the company location. These are all part of your work environment. If you have a computer that is 5 years old, your work environment is not as good as if you have a computer that is only 2 years old. If you are writing in C rather than C++, C# or Java, your work environment is sub-optimal.
The closer that your development infrastructure is to the ideal environment for your circumstances, the more productive your team will be. This principal extends to all aspects of the development environment, from development language, to build system, to build farm, to issue tracking system, to the process that you follow.
Next: Your Development Process is Part of Your Work Environment
Your Development Process is Part of Your Work Environment
Your development process (regardless of how it is implemented), is also part of your work environment. If as a result of your development process you regularly end up redoing work because problems weren’t discovered until just before the release, or projects get cancelled or shelved, then this is also likely to reduce productivity and job satisfaction. As this process improves, so does your work environment. The smoother it operates, the more pleasant your working environment will be.
There are many problems which you may think of as being unrelated to your development process. For instance, broken builds. Broken builds are simply the result of somebody making an idiotic mistake, right? Perhaps that’s true some of the time, but most of the time it is due to the complexity of integrating many changes made by many people for software that has many interdependencies.
To be sure, a “perfect” process does not guarantee happiness, success, or the absence of problems. You still have to debug complicated problems, port to new platforms, deal with unforeseen circumstances, etc. However, the state of your process impacts the efficiency with which your effort is applied.
If your process is perfect and completely frictionless, then 100% of your effort will be applied to the work that creates value. If it is rife with problems, it may mean that only 50% (or less!) of your effort will be applied to work that creates value. If there are problems with the process, then you are already expending effort which is essentially wasted. You would be better off investing some of that effort in removing the problems permanently instead of losing it to friction on a regular basis.
Next: Quick Summary of The Benefits of Adopting Agile
There are many problems which you may think of as being unrelated to your development process. For instance, broken builds. Broken builds are simply the result of somebody making an idiotic mistake, right? Perhaps that’s true some of the time, but most of the time it is due to the complexity of integrating many changes made by many people for software that has many interdependencies.
To be sure, a “perfect” process does not guarantee happiness, success, or the absence of problems. You still have to debug complicated problems, port to new platforms, deal with unforeseen circumstances, etc. However, the state of your process impacts the efficiency with which your effort is applied.
If your process is perfect and completely frictionless, then 100% of your effort will be applied to the work that creates value. If it is rife with problems, it may mean that only 50% (or less!) of your effort will be applied to work that creates value. If there are problems with the process, then you are already expending effort which is essentially wasted. You would be better off investing some of that effort in removing the problems permanently instead of losing it to friction on a regular basis.
Next: Quick Summary of The Benefits of Adopting Agile
The Benefits of Adopting Agile
The benefits of moving to Agile development can be split into two categories: benefits to the organization, and benefits to you personally. As a result of increased productivity, higher quality, and responding more rapidly to market demands, Agile can provide the following benefits to the organization:
Next: Having Dev Team Performance Problems Using Traditional Development? Try Niagra!
- Increased revenues
- Reduced costs
- Increased market share
- Higher customer satisfaction
- Getting a raise and/or bonus
- Having more discretionary income to buy cool stuff
- Improving your working conditions
- Actually using all of your vacation time
- The opportunity to spend more time working on cool stuff
- A less stressful environment
- Less canceled or shelved work
- Career advancement due to learning new skills
- Having the resume that gets you your dream job
Next: Having Dev Team Performance Problems Using Traditional Development? Try Niagra!
Agile Development Scenario
Here's an Agile development scenario. For simplicity, let’s use two month iterations. Marketing says the three features with the highest ROI are a Facebook plug-in, a Second Life plug-in, and an RSS feed plug-in.
You start with the Facebook plug-in. You plan. You design. You create a test plan while the code is being written. You discover potential problems and deal with them. You automate those tests while the code is being written. As the code is written, it is integrated, built and tested continuously; problems are found and fixed immediately. At the end of development, the only problems that remain are the ones that could only be found at the end of development. If you wanted to, you could cut a new release with very little overhead.
Marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. So, you start on the RSS feed support. Now marketing says the Second Life plug-in is worthless but iPhone support is hot, so you add iPhone support. During the whole process, you kept your options open. At the end you have produced more business value than using the traditional process, and you were in a position to start realizing that value much earlier.
To get the primary benefits of Agile, as described above, you don't have to use 3x5 cards or pair programming, and you don’t have to do frequent releases. These things are optional and you can use them or not according to your preference and circumstances.
Next: Achieving the Primary Benefits of Agile
You start with the Facebook plug-in. You plan. You design. You create a test plan while the code is being written. You discover potential problems and deal with them. You automate those tests while the code is being written. As the code is written, it is integrated, built and tested continuously; problems are found and fixed immediately. At the end of development, the only problems that remain are the ones that could only be found at the end of development. If you wanted to, you could cut a new release with very little overhead.
Marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. So, you start on the RSS feed support. Now marketing says the Second Life plug-in is worthless but iPhone support is hot, so you add iPhone support. During the whole process, you kept your options open. At the end you have produced more business value than using the traditional process, and you were in a position to start realizing that value much earlier.
To get the primary benefits of Agile, as described above, you don't have to use 3x5 cards or pair programming, and you don’t have to do frequent releases. These things are optional and you can use them or not according to your preference and circumstances.
Next: Achieving the Primary Benefits of Agile
Traditional Development Scenario
A useful way to describe Agile is by contrasting it with traditional development. To do that, let's consider a typical development scenario: adding new features to stay competitive. First we'll look at the scenario using traditional development and then using Agile development.
In a traditional project, you have a known timeframe for major releases. Too short and you’ll spend too much time on overhead, too long and you’ll miss opportunities. For the sake of argument, let’s pick a timeframe of six months and say that allows you to provide three “big features.” Marketing says the three features with the highest ROI are a Facebook plug-in, a Second Life plug-in, and an RSS feed plug-in.
Midway through the design process, marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. You think, oh well, nothing we can do about that now. Just after you finish coding marketing declares that the Second Life plug-in is going to be a complete flop and when can they get iPhone support?
Now that the functionality has settled down, QA starts writing tests and running them. Planning and development took longer than expected and the release deadline is looming. Testing time is compressed, QA concentrates on the most critical stuff and gives the rest a spot check. Here’s a mystery. If your full test cycle takes two days, why does testing take a month? The answer is that you aren’t really doing a month of testing. Problems have been creeping in all along the way that you are just now finding out about and it takes many test/fix cycles to expose them and fix them. Once the find/fix rate gets down to an acceptable level, you declare victory and deliver the new release.
Next: Now Let's Try Agile
In a traditional project, you have a known timeframe for major releases. Too short and you’ll spend too much time on overhead, too long and you’ll miss opportunities. For the sake of argument, let’s pick a timeframe of six months and say that allows you to provide three “big features.” Marketing says the three features with the highest ROI are a Facebook plug-in, a Second Life plug-in, and an RSS feed plug-in.
Midway through the design process, marketing announces that the Second Life plug-in is not as marketable as they had hoped and iPhone support is showing signs of becoming very lucrative. You think, oh well, nothing we can do about that now. Just after you finish coding marketing declares that the Second Life plug-in is going to be a complete flop and when can they get iPhone support?
Now that the functionality has settled down, QA starts writing tests and running them. Planning and development took longer than expected and the release deadline is looming. Testing time is compressed, QA concentrates on the most critical stuff and gives the rest a spot check. Here’s a mystery. If your full test cycle takes two days, why does testing take a month? The answer is that you aren’t really doing a month of testing. Problems have been creeping in all along the way that you are just now finding out about and it takes many test/fix cycles to expose them and fix them. Once the find/fix rate gets down to an acceptable level, you declare victory and deliver the new release.
Next: Now Let's Try Agile
Tuesday, June 24, 2008
The "Faberge Egg" Widget
There was a developer that worked for me once, I’ll call him George. He wrote a lot of really good code. But one day he decided he wanted to make his mark on things. George believed that the way to do it was to create a beautiful widget. He wanted it to be so beautiful and so useful that it could be used generically and would be something that we could sell separately on its own merits.
The widget was part of a Java/Swing user interface for an issue tracking system. It was responsible for the data model used by a form, a query editor, and a handful of other objects. So, it did need to be fairly general purpose, but it didn't need to be so generic and so functional that it would be something that people would want to buy separate from the application.
George referred to this widget as his “Faberge Egg.” It was an apt name for the widget. It was overly ornate, intricately detailed, and supported a very wide range of functionality that we had no immediate use for and still don’t to this day.
I was very clear with George that I only wanted a “Cadbury Egg” and tried hard to convince him that he could provide much more value to the company in other ways and the company would reward him for that, not the Faberge Egg. I like folks to have the freedom to grow and explore. Even though we were under deadline pressure, I gave George some wiggle room while at the same time trying to guide him towards the simplest design that would work. Unfortunately, after weeks of work and many conversations, George’s desire to produce a masterpiece of a widget prevailed.
Over time, that widget has been the source of more than its share of problems, both in bugs and in making it more complicated for other developers to maintain it and extend it. It has been partially refactored several times, but it seems there has never been the time to really do the full job required.
The same functionality that the widget provides was needed in our new web interface. Instead of reusing the code as we have done for other functionality, we decided to start from scratch. Doing just what was needed for the job at hand took only two days and that code has been very reliable right from the start.
Next: Frequent Releases Improve Code Quality Faster
Related: The Iterative Design of a Transforming Lego Sports Car
Monday, June 23, 2008
Do You Need a Standup Meeting?
Stand-up meetings are a great way to reduce delays in communicating important information. Another benefit of stand up meetings is the elimination of time-wasting status and progress meetings.
Stand up meetings are most closely associated with Scrum and are called “Daily Scrum Meetings” within Scrum, but have become populare independent of any particular methodology which is a good indicator of suitability for mainstream use.
A stand-up meeting is simple to implement. There are just a handful of guidelines:
The point of a stand-up meeting is to improve communication and to discover and resolve impediments, not to have a meeting just for the sake of having a meeting. If the team feels that other practices make the stand-up meeting redundant, then by all means reduce their frequency or even discontinue use until such time as it appears to be necessary again.
To help make this decision, let’s take a look at the expense side of stand-up meetings. First, people have to get to it. And then they have to get back to their computers. Scrum discusses how to minimize this time, but practically speaking, there is more overhead than just the ideal 15 minute meeting. If you are at a larger company, somebody has to book the room and let people know where it is. Let’s call the cost of the meeting 20 minutes per person. If you have 12 people in a stand-up meeting, that’s 4 person hours per day. That’s the equivalent of half of a person. Those meetings had really better be worth it!
Now let’s take a hard look at the stand-up meeting itself. One of the basic ideas of Agile (and Lean) is continual self improvement. If the value of the meeting exceeds the cost, then there’s no problem with the meetings, especially if they are eliminating other meetings. If the stand-up meeting is the only remaining meeting, that seems like a good thing. However, continuous improvement means we’re never satisfied. Now that you are down to just the one meeting, you should still ask the question: “is it providing more value than the cost? Is there a better way?”
What is the purpose of a stand-up meeting? To quickly find out if people are getting their assigned work done and if not why not. If it is more efficient to do that via e-mail, IM, an issue tracking system, or other means, then use those means. Someone might say “but seeing folks face to face is worthwhile.” Ok, so why not just do that then? Go out to lunch together or something like that.
Or perhaps the stand-up meeting is needed because otherwise folks wouldn’t complete their work, or people wouldn’t speak up when they run into an impediment. In that case the stand-up meeting isn’t a solution at all, it is a crutch. For instance, perhaps somebody isn’t completing their work because they don’t like it, but the constant peer pressure of the standup meeting is goading them into completing their work anyway. So then the real problem is lack of job satisfaction or low moral or something along those lines. Until you fix that problem, the stand-up meeting is just acting as a band-aid.
The real measure of project status and health is having an increment of shippable value at the end of every iteration. A standup will only expose problems that are on people’s minds, but the forcing function of the increment of shippable value is where you will get the true picture of how things are going. A one month iteration interval is good, but if you can get it down to 2 weeks or even 1 week, that may do far more to expose real problems than a standup will.
Next: How Agile Helped Litle & Co. Get to #1 on the Inc. 500
Stand up meetings are most closely associated with Scrum and are called “Daily Scrum Meetings” within Scrum, but have become populare independent of any particular methodology which is a good indicator of suitability for mainstream use.
A stand-up meeting is simple to implement. There are just a handful of guidelines:
- Limit the time to fifteen minutes.
- Pick a regular time for the team to meet, preferably in the morning.
- Start on-time regardless of who is absent.
- Each person answers these three questions:
- What have you accomplished since the last meeting?
- What are you working on next?
- What impediments do you have?
- All discussion and problem solving is deferred until the end of the stand-up meeting.
- Follow-up as needed in smaller groups
The point of a stand-up meeting is to improve communication and to discover and resolve impediments, not to have a meeting just for the sake of having a meeting. If the team feels that other practices make the stand-up meeting redundant, then by all means reduce their frequency or even discontinue use until such time as it appears to be necessary again.
To help make this decision, let’s take a look at the expense side of stand-up meetings. First, people have to get to it. And then they have to get back to their computers. Scrum discusses how to minimize this time, but practically speaking, there is more overhead than just the ideal 15 minute meeting. If you are at a larger company, somebody has to book the room and let people know where it is. Let’s call the cost of the meeting 20 minutes per person. If you have 12 people in a stand-up meeting, that’s 4 person hours per day. That’s the equivalent of half of a person. Those meetings had really better be worth it!
Now let’s take a hard look at the stand-up meeting itself. One of the basic ideas of Agile (and Lean) is continual self improvement. If the value of the meeting exceeds the cost, then there’s no problem with the meetings, especially if they are eliminating other meetings. If the stand-up meeting is the only remaining meeting, that seems like a good thing. However, continuous improvement means we’re never satisfied. Now that you are down to just the one meeting, you should still ask the question: “is it providing more value than the cost? Is there a better way?”
What is the purpose of a stand-up meeting? To quickly find out if people are getting their assigned work done and if not why not. If it is more efficient to do that via e-mail, IM, an issue tracking system, or other means, then use those means. Someone might say “but seeing folks face to face is worthwhile.” Ok, so why not just do that then? Go out to lunch together or something like that.
Or perhaps the stand-up meeting is needed because otherwise folks wouldn’t complete their work, or people wouldn’t speak up when they run into an impediment. In that case the stand-up meeting isn’t a solution at all, it is a crutch. For instance, perhaps somebody isn’t completing their work because they don’t like it, but the constant peer pressure of the standup meeting is goading them into completing their work anyway. So then the real problem is lack of job satisfaction or low moral or something along those lines. Until you fix that problem, the stand-up meeting is just acting as a band-aid.
The real measure of project status and health is having an increment of shippable value at the end of every iteration. A standup will only expose problems that are on people’s minds, but the forcing function of the increment of shippable value is where you will get the true picture of how things are going. A one month iteration interval is good, but if you can get it down to 2 weeks or even 1 week, that may do far more to expose real problems than a standup will.
Next: How Agile Helped Litle & Co. Get to #1 on the Inc. 500
Wednesday, June 11, 2008
Sustainable Pace: Supply vs Demand
In a traditional project, the demand for resources from the four major aspects of software development see-saws dramatically over the course of a project. These aspects are project management and planning, architecture and design, development, and QA. You need resources on hand to serve the peak demand level, but during periods of low demand those resources will either be idle or used for activities which have a lower ROI.
A common circumstance is that there are insufficient resources on hand for the peak demand level and so people end up working in “crunch mode.” During crunch time, people tend to make more mistakes. Agile levels demand out over time and removes this see-saw effect which simplifies resource planning and removes the need for crunch time.
In the figure above, the straight green lines represent the resource load in an Agile project and the zig-zagging purple lines represent the resource load in a traditional project.
With traditional development, delays during development compress most of the testing to the end of the process which then requires taking shortcuts due to schedule pressure. I used to think that one way of compensating for insufficient QA resources was to delay the release until QA finishes. On the surface it seems to make sense. But only if the folks writing code sit on their hands while QA does their work. Ok, so you have multiple projects and the developers work on another project. But then they finish that. Now QA starts on the second project and the developers move to the third. The problem is still there.
On the other hand, as a result of the need for increased QA resources during testing, you may have two other problems. If you have enough QA resources to handle the pressure of the endgame, you may have too many QA resources during the rest of your development cycle. Alternatively, you may bring on additional QA resources on a short-term basis to compensate. Both of these options are obviously undesirable.
There’s a natural balance between the amount of effort required for developing something and the amount of effort required to QA it. No matter what you do, if you have the wrong ratio of development resources to QA resources, it will cause problems. If development creates more than QA can absorb, you will create a backlog of QA work that will always grow.
There are six options for dealing with a QA backlog: do less QA than needed and thus shift the burden of finding problems that you could have found onto your customers, increase your QA capacity, decrease your development capacity, have development idle, have development help with QA or allow the backlog to grow. The larger your testing backlog, the longer it will take to ship it and the greater your opportunity cost.
The imbalance may be in either direction. After you transition to Agile development, you may find that you have more QA resources than are needed. In that case, you have the option of having QA take on some of the work currently done by developers. See The Role of QA in an Agile Project for more on that topic.
This natural balance holds between all four aspects of software development. Depending on your organization, there may be an imbalance between supply and demand at any stage in the pipeline. Wherever there is an imbalance you have the same six options as described above. For example, you may end up with project plans that are never used, developers idle because the design isn’t ready yet, etc. To the extent that some of the resources are actually the same people you can use that fact to manage this problem.
When using short iterations, resource imbalances are easier to detect and correct. Having balanced resources means that all development activities are done consistently and on a regular basis and there is no need to take the shortcuts that are typical of traditional development.
Next: The Usability of Short Iterations
TOC: Zero to Hyper Agile in 90 Days or Less
A common circumstance is that there are insufficient resources on hand for the peak demand level and so people end up working in “crunch mode.” During crunch time, people tend to make more mistakes. Agile levels demand out over time and removes this see-saw effect which simplifies resource planning and removes the need for crunch time.
In the figure above, the straight green lines represent the resource load in an Agile project and the zig-zagging purple lines represent the resource load in a traditional project.
With traditional development, delays during development compress most of the testing to the end of the process which then requires taking shortcuts due to schedule pressure. I used to think that one way of compensating for insufficient QA resources was to delay the release until QA finishes. On the surface it seems to make sense. But only if the folks writing code sit on their hands while QA does their work. Ok, so you have multiple projects and the developers work on another project. But then they finish that. Now QA starts on the second project and the developers move to the third. The problem is still there.
On the other hand, as a result of the need for increased QA resources during testing, you may have two other problems. If you have enough QA resources to handle the pressure of the endgame, you may have too many QA resources during the rest of your development cycle. Alternatively, you may bring on additional QA resources on a short-term basis to compensate. Both of these options are obviously undesirable.
There’s a natural balance between the amount of effort required for developing something and the amount of effort required to QA it. No matter what you do, if you have the wrong ratio of development resources to QA resources, it will cause problems. If development creates more than QA can absorb, you will create a backlog of QA work that will always grow.
There are six options for dealing with a QA backlog: do less QA than needed and thus shift the burden of finding problems that you could have found onto your customers, increase your QA capacity, decrease your development capacity, have development idle, have development help with QA or allow the backlog to grow. The larger your testing backlog, the longer it will take to ship it and the greater your opportunity cost.
The imbalance may be in either direction. After you transition to Agile development, you may find that you have more QA resources than are needed. In that case, you have the option of having QA take on some of the work currently done by developers. See The Role of QA in an Agile Project for more on that topic.
This natural balance holds between all four aspects of software development. Depending on your organization, there may be an imbalance between supply and demand at any stage in the pipeline. Wherever there is an imbalance you have the same six options as described above. For example, you may end up with project plans that are never used, developers idle because the design isn’t ready yet, etc. To the extent that some of the resources are actually the same people you can use that fact to manage this problem.
When using short iterations, resource imbalances are easier to detect and correct. Having balanced resources means that all development activities are done consistently and on a regular basis and there is no need to take the shortcuts that are typical of traditional development.
Next: The Usability of Short Iterations
TOC: Zero to Hyper Agile in 90 Days or Less
Monday, June 09, 2008
Agile Adoption Stage 2: Establishing a Natural Rhythm
The first stage in adopting Agile is Preparing for the Transition to Agile.
The next stage is to make some early and measurable progress to encourage adoption. As it is, you have actually already experienced some success. You’ve planted the idea of process improvement, you’ve got a map of the areas of general consensus and contention, and you’ve provided a forum for people to learn more about the current process, uncover misunderstandings and correct them.
One of the areas of consensus you’ve uncovered is very likely a problem which everybody agrees should change, there is a consensus or near consensus on how to improve it, enough pain to easily instigate a change, and a sufficiently small scope that the change can be made in a relatively short amount of time. That should be your first area of attack. It doesn’t really matter what it is or if it has anything at all to do with Agile. At this point, you just want to establish the idea that process improvement is worthwhile, doable, and worth doing on a regular basis.
Short Iterations
The main point of this stage of adoption is to discover the natural rhythm of your team and the project that you are working on. It may be a month, it may be a week, or it may be some other timeframe between 1-6 weeks.
For your first iteration, start with a goal of a one month iteration time. It is better to make it a goal rather than a hard requirement. Making it a hard requirement will encourage rushing to finish or taking shortcuts at the end which will defeat the purpose of establishing a rhythm. It will take time to get used to short iterations.
Don’t plan to do a release from the first iteration. Whichever iteration you do plan to do a release from, keep your release process the same for now. The purpose of the first couple of iterations using Agile is to identify obstacles in order to start removing them.
The Backlog
To determine what to work on for the first iteration, make a conservative estimate of how much work your team can take on. Create a backlog of the highest priority items, adding estimates to them as you go in order to determine the cutoff point. You don’t need to have a product owner or ScrumMaster or make any changes to how you plan a release at this point. Just do whatever you would normally do to plan the contents for a release, but keep the timeframe to a single iteration.
If there are one or more work items which are too large to fit into a one month iteration, you have a variety of options at this point. First, you can postpone going to short iterations until they are done and concentrate on the other aspects of the first stage of adoption. I don’t recommend this. If you’ve gotten to this point, this is your chance, don’t postpone it, find a way to move forward.
Second, if the work items would fit into a slightly longer iteration, use that as your iteration time. It isn’t ideal, but it is a better alternative than giving up!
A third option is to delay the oversized work items until after you’ve got 1-2 iterations under your belt. If they are in your backlog, somebody thought they were important, but if your release isn’t for many iterations anyway, perhaps it won’t matter to the overall release.
Done Means Done, But What Does "Done" Mean?
You should have a clear definition of what “done” means for a work item. At a high level, any definition of done should include whatever you believe is necessary for that work item in isolation to be considered shippable. Think about your entire release cycle, not just what it takes to get something ready to check-in. Do you eventually do a code review? Then that should be a pre-requisite for “done.” Other candidates are: documented, tests written and all pass, demoed by a QA person to a third party (that is, not just the developer and the QA person themselves).
Iteration Retrospective
Before you get too giddy with the success of your first iteration, be sure to schedule a retrospective. This is exactly same as the traditional “post-mortem” but doesn’t have the same air of death about it. The purpose of the retrospective is to take a look back at the iteration and look for opportunities to improve your next iteration. What went wrong? Why did it go wrong? What went well? What ideas do people have for improving the next iteration?
Most likely, the duration of your first iteration overshot your goal. This should be the focus of the retrospective. If in fact you did make the goal of 1 month, what could you do to reduce the time to 2 weeks? What could you do to have a higher ratio of value-producing activities such as adding more new functionality? You should not change your goal of 1 month to 2 weeks, even if you made the goal. At this point, it is more important to establish a rhythm rather than reduce the time of the interval.
At the end of the retrospective, decide as a team which changes you want to make in the next iteration. Don’t try to change everything at once, concentrate on the top 3-5 ideas. Make sure that somebody is taking notes. The notes will be invaluable in your next retrospective for detecting trends.
Repeat
Breaking down entrenched habits and ingrained beliefs while simultaneously establishing new habits and beliefs takes time and patience. The most important things at this stage are to establish a rhythm via the short intervals of the iterations and to find and remove obstacles. Because you should already be experiencing positive results, there is no need to rush to the next stage and endanger the progress that you’ve made. Remember that there are lots of people watching the success or failure of this process and support for a new way of doing things is still shaky at best. That includes you and everybody else on the team! I recommend you simply repeat the process with another 2-3 iterations, finding and removing obstacles as you go.
Considering a transition to Agile? Read more of "Zero to Agile in 90 Days or Less."
The next stage is to make some early and measurable progress to encourage adoption. As it is, you have actually already experienced some success. You’ve planted the idea of process improvement, you’ve got a map of the areas of general consensus and contention, and you’ve provided a forum for people to learn more about the current process, uncover misunderstandings and correct them.
One of the areas of consensus you’ve uncovered is very likely a problem which everybody agrees should change, there is a consensus or near consensus on how to improve it, enough pain to easily instigate a change, and a sufficiently small scope that the change can be made in a relatively short amount of time. That should be your first area of attack. It doesn’t really matter what it is or if it has anything at all to do with Agile. At this point, you just want to establish the idea that process improvement is worthwhile, doable, and worth doing on a regular basis.
Short Iterations
The main point of this stage of adoption is to discover the natural rhythm of your team and the project that you are working on. It may be a month, it may be a week, or it may be some other timeframe between 1-6 weeks.
For your first iteration, start with a goal of a one month iteration time. It is better to make it a goal rather than a hard requirement. Making it a hard requirement will encourage rushing to finish or taking shortcuts at the end which will defeat the purpose of establishing a rhythm. It will take time to get used to short iterations.
Don’t plan to do a release from the first iteration. Whichever iteration you do plan to do a release from, keep your release process the same for now. The purpose of the first couple of iterations using Agile is to identify obstacles in order to start removing them.
The Backlog
To determine what to work on for the first iteration, make a conservative estimate of how much work your team can take on. Create a backlog of the highest priority items, adding estimates to them as you go in order to determine the cutoff point. You don’t need to have a product owner or ScrumMaster or make any changes to how you plan a release at this point. Just do whatever you would normally do to plan the contents for a release, but keep the timeframe to a single iteration.
If there are one or more work items which are too large to fit into a one month iteration, you have a variety of options at this point. First, you can postpone going to short iterations until they are done and concentrate on the other aspects of the first stage of adoption. I don’t recommend this. If you’ve gotten to this point, this is your chance, don’t postpone it, find a way to move forward.
Second, if the work items would fit into a slightly longer iteration, use that as your iteration time. It isn’t ideal, but it is a better alternative than giving up!
A third option is to delay the oversized work items until after you’ve got 1-2 iterations under your belt. If they are in your backlog, somebody thought they were important, but if your release isn’t for many iterations anyway, perhaps it won’t matter to the overall release.
Done Means Done, But What Does "Done" Mean?
You should have a clear definition of what “done” means for a work item. At a high level, any definition of done should include whatever you believe is necessary for that work item in isolation to be considered shippable. Think about your entire release cycle, not just what it takes to get something ready to check-in. Do you eventually do a code review? Then that should be a pre-requisite for “done.” Other candidates are: documented, tests written and all pass, demoed by a QA person to a third party (that is, not just the developer and the QA person themselves).
Iteration Retrospective
Before you get too giddy with the success of your first iteration, be sure to schedule a retrospective. This is exactly same as the traditional “post-mortem” but doesn’t have the same air of death about it. The purpose of the retrospective is to take a look back at the iteration and look for opportunities to improve your next iteration. What went wrong? Why did it go wrong? What went well? What ideas do people have for improving the next iteration?
Most likely, the duration of your first iteration overshot your goal. This should be the focus of the retrospective. If in fact you did make the goal of 1 month, what could you do to reduce the time to 2 weeks? What could you do to have a higher ratio of value-producing activities such as adding more new functionality? You should not change your goal of 1 month to 2 weeks, even if you made the goal. At this point, it is more important to establish a rhythm rather than reduce the time of the interval.
At the end of the retrospective, decide as a team which changes you want to make in the next iteration. Don’t try to change everything at once, concentrate on the top 3-5 ideas. Make sure that somebody is taking notes. The notes will be invaluable in your next retrospective for detecting trends.
Repeat
Breaking down entrenched habits and ingrained beliefs while simultaneously establishing new habits and beliefs takes time and patience. The most important things at this stage are to establish a rhythm via the short intervals of the iterations and to find and remove obstacles. Because you should already be experiencing positive results, there is no need to rush to the next stage and endanger the progress that you’ve made. Remember that there are lots of people watching the success or failure of this process and support for a new way of doing things is still shaky at best. That includes you and everybody else on the team! I recommend you simply repeat the process with another 2-3 iterations, finding and removing obstacles as you go.
Considering a transition to Agile? Read more of "Zero to Agile in 90 Days or Less."
Friday, June 06, 2008
Preparing for the Transition to Agile
Once, when I was just starting to snowboard, I was at Sugarloaf for the weekend and they had very little cover and very few trails open. But then Saturday night, they got 33” of powder. A friend and I came to a trail that was closed. It looked like a great trail; endless powder with no tracks. The problem was that it had been rocks and grass the day before and there was no base underneath, so it was just the same as riding on rocks and grass. It was not a pleasant experience. Adopting Agile without understanding it and without creating a proper ecosystem for it is destined for a similar fate.
Adopting Agile development requires breaking down mental barriers and building up new skill sets. There is nothing particularly hard about actually doing any of the Agile practices, but many of them are counterintuitive and do take a bit of practice to get used to. That said, don’t underestimate the amount of effort required. The effort required is at least on the order of taking a team which is very used to writing in C++ and moving to Java. There’s nothing particularly difficult about such a transition, but there are many subtleties which must be learned and it takes a while to build up the same base of experience.
Self Education
Before getting too far along, make sure that you have done your homework. Read other books on Agile, find other folks in your organization that have done Agile development before. Go to conferences, join the local Agile user group, become a certified Scrum Master, do whatever you do to find people that you can lean on when you need it.
Scope
Determine the best scope of the adoption. As with most things, it is best to think big, but start small. Is there a small project with no more than 12 people that is amenable to piloting something new? There are two advantages in starting small: minimizing disruption and leveraging what the pilot group learns about doing Agile in your environment when transitioning other groups.
Scouting
Agile development has certain perceptions related to it. One of the most prevalent perceptions is that it is “for small groups.” That was certainly my perception when I first started hearing about it. Another perception is that small iterations aren’t a good thing because customers don’t want frequent releases, there’s more overhead involved, the quality will be lower that way, and it makes marketing’s life more difficult.
If you just advocate Agile without knowing the landscape, you run the risk of alienating the people whose support you need in order to go Agile. Find out how receptive your organization is to going Agile. Think about who is in a position to help or hinder its adoption. Those are the key stakeholders. You will need to find out where they stand, what they like about the idea of going Agile, and what their objections are. This information will come in handy later in the adoption process.
Prepare Your Organization
Once you have a basic lay of the land, see what you can do to raise people’s awareness and understanding of the advantages and potential pitfalls of Agile. Do a presentation for folks that are interested, invite in somebody from the Agile community to do a presentation or workshop. Recommend books and websites that you found helpful.
Transition Development and QA Together
The most important component of reducing the rework period that comes from long iterations is improving your testing process. For many if not most organizations, this is the hardest goal to achieve in practice.
If you don’t have any automation at all, it is a good bet that there is an ingrained belief that automated testing is either a bad idea, doesn’t work as well as manual testing, is too expensive, or that the tools are too expensive. As a result, it may be that there are no QA automation experts in the building and possibly nobody with scripting skills in the QA group. The best course of action in this case is to concentrate on introducing the idea of QA automation.
If it is clear that there is a bias against automated testing that is too strong to overcome any time soon, another tactic is to have the development organization champion automation with an eye towards handing it over to QA once the idea catches on. A good place to start is with unit tests. It should be clear from the start that your goal is to have QA own test automation. Developers will write good tests, but they are too optimistic by nature. Developers start from the assumption that “it will work.” QA people start from the assumption that “it doesn’t work and I’ll prove it to you.” Pessimism is a good trait for a person creating tests.
Keep Your Healthy Skepticism
Think carefully about the value of each practice that you plan to adopt and make absolutely sure that it is appropriate for your exact circumstances before you adopt it. You shouldn’t be adopting practices simply for the sake of saying that you are adopting Agile practices. Every practice you adopt should be because now that you know about it you simply can’t imagine getting by without it.
Don’t Throw Out the Baby With the Bath Water
I’ve seen many first-time Agile projects fail because they threw out everything they already knew about developing software. Most of the individual steps of developing software with an Agile methodology are the same as traditional software development. You still have to talk to customers, decide what you are going to do, write code, write tests, do testing, etc. Agile development is simply a different framework for those steps. You have a business to run, and you don’t really need to introduce large and sudden risk factors. Before you decide to chuck everything that you know and start from scratch, spend some time developing your knowledge and understanding of Agile. Look closely at your existing practices and see which ones will fit well within Agile, and which ones may cause problems. Create a game plan and start out gradually.
Next: Agile Adoption Stage 2: Establishing a Natural Rhythm
Adopting Agile development requires breaking down mental barriers and building up new skill sets. There is nothing particularly hard about actually doing any of the Agile practices, but many of them are counterintuitive and do take a bit of practice to get used to. That said, don’t underestimate the amount of effort required. The effort required is at least on the order of taking a team which is very used to writing in C++ and moving to Java. There’s nothing particularly difficult about such a transition, but there are many subtleties which must be learned and it takes a while to build up the same base of experience.
Self Education
Before getting too far along, make sure that you have done your homework. Read other books on Agile, find other folks in your organization that have done Agile development before. Go to conferences, join the local Agile user group, become a certified Scrum Master, do whatever you do to find people that you can lean on when you need it.
Scope
Determine the best scope of the adoption. As with most things, it is best to think big, but start small. Is there a small project with no more than 12 people that is amenable to piloting something new? There are two advantages in starting small: minimizing disruption and leveraging what the pilot group learns about doing Agile in your environment when transitioning other groups.
Scouting
Agile development has certain perceptions related to it. One of the most prevalent perceptions is that it is “for small groups.” That was certainly my perception when I first started hearing about it. Another perception is that small iterations aren’t a good thing because customers don’t want frequent releases, there’s more overhead involved, the quality will be lower that way, and it makes marketing’s life more difficult.
If you just advocate Agile without knowing the landscape, you run the risk of alienating the people whose support you need in order to go Agile. Find out how receptive your organization is to going Agile. Think about who is in a position to help or hinder its adoption. Those are the key stakeholders. You will need to find out where they stand, what they like about the idea of going Agile, and what their objections are. This information will come in handy later in the adoption process.
Prepare Your Organization
Once you have a basic lay of the land, see what you can do to raise people’s awareness and understanding of the advantages and potential pitfalls of Agile. Do a presentation for folks that are interested, invite in somebody from the Agile community to do a presentation or workshop. Recommend books and websites that you found helpful.
Transition Development and QA Together
The most important component of reducing the rework period that comes from long iterations is improving your testing process. For many if not most organizations, this is the hardest goal to achieve in practice.
If you don’t have any automation at all, it is a good bet that there is an ingrained belief that automated testing is either a bad idea, doesn’t work as well as manual testing, is too expensive, or that the tools are too expensive. As a result, it may be that there are no QA automation experts in the building and possibly nobody with scripting skills in the QA group. The best course of action in this case is to concentrate on introducing the idea of QA automation.
If it is clear that there is a bias against automated testing that is too strong to overcome any time soon, another tactic is to have the development organization champion automation with an eye towards handing it over to QA once the idea catches on. A good place to start is with unit tests. It should be clear from the start that your goal is to have QA own test automation. Developers will write good tests, but they are too optimistic by nature. Developers start from the assumption that “it will work.” QA people start from the assumption that “it doesn’t work and I’ll prove it to you.” Pessimism is a good trait for a person creating tests.
Keep Your Healthy Skepticism
Think carefully about the value of each practice that you plan to adopt and make absolutely sure that it is appropriate for your exact circumstances before you adopt it. You shouldn’t be adopting practices simply for the sake of saying that you are adopting Agile practices. Every practice you adopt should be because now that you know about it you simply can’t imagine getting by without it.
Don’t Throw Out the Baby With the Bath Water
I’ve seen many first-time Agile projects fail because they threw out everything they already knew about developing software. Most of the individual steps of developing software with an Agile methodology are the same as traditional software development. You still have to talk to customers, decide what you are going to do, write code, write tests, do testing, etc. Agile development is simply a different framework for those steps. You have a business to run, and you don’t really need to introduce large and sudden risk factors. Before you decide to chuck everything that you know and start from scratch, spend some time developing your knowledge and understanding of Agile. Look closely at your existing practices and see which ones will fit well within Agile, and which ones may cause problems. Create a game plan and start out gradually.
Next: Agile Adoption Stage 2: Establishing a Natural Rhythm
Thursday, June 05, 2008
How Does Choice of Methodology Influence Strategy and Tactics?
Once More Unto the Breach, Dear Friends
As Helmuth von Moltke (the Elder) said, “No battle plan survives contact with the enemy.” In the case of software development, the “enemy” is reality. What we think we need to do to satisfy customers and how we think we need to implement it generally changes as we implement and as we get customer feedback.
Similarly, Dwight D. Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable”. Planning (short and long, tactical and strategic) is still important in the Agile world. The difference is that Agile is specifically designed to take advantage of the fact that planning, design, and development have a learning component and to accommodate and embrace the resulting need to change plans on a regular basis. As you discover new information during an iteration, you can easily adjust your plans to take what you have learned into account in future iterations.
Too Busy to Plan
Short iterations and other Agile practices such as “You Aren’t Going to Need It” (YAGNI), may seem to indicate that Agile is tactical in nature. However, I would say that it is when looked at through a Waterfall lens. For instance, with Waterfall the planning horizon and iteration length (the full start to finish time) are the same. So if you look at Agile with this perspective you might think that the longest that Agile folks look ahead is 30 days. You might then conclude from this that Agile can only be used tactically. But in fact there is no connection between the planning horizon and the iteration length.
Many teams use very short iterations; two weeks or one week. What happens within an iteration is whatever has been planned for that iteration. Different Agile methodologies use different approaches for planning iterations. In any case, you can plan as far out as you would like. As an Agile product owner I can tell you that some of my products have plans going out multiple years.
Sometimes there is work that can’t be fit into a single iteration (whatever iteration length you have chosen). In that case, you can use multiple overlapping iterations. For instance, a one-week iteration for most stuff and an overlapping one month iteration for the exceptions. Over time though, teams generally get better at avoiding the need for exceptions.
Wherever You Go, There You Are
In my experience, whether the software development of a company is done tactically or strategically is connected to the planning culture of an organization, not the methodology. If an organization thinks and plans strategically, that will be reflected in their software development whether they are using Agile or Waterfall.
I’ve seen plenty of companies that use Waterfall but think tactically, packing mostly tactical features into a large release. Feature creep is a good example of how tactical thinking is fairly common in Waterfall projects. While of course it is true that “that shouldn’t happen” the facts on the ground are that it does.
I’ve also seen plenty of Agile projects that were strategic in nature. For instance, an Agile company that thinks strategically will have a strategic plan which they carry out using multiple iterations. As they discover that they need to do something tactical in the middle of their strategy, or they need to change their tactics in support of their strategy, it is simple to do with short iterations. They just change their plans for future iterations. As soon as their current iteration is done, they begin the next iteration which has now changed to take into account the new information.
It may well be that folks that think and plan strategically are less inclined to look deeply at Agile because it appears on the surface to be tactical in nature. I know that was true in my own case. I believe that people and organizations that think strategically will bring that thinking with them into the Agile world. Having crossed over I can report that I have been able to very happily and successfully bring strategic thinking with me to the other side.
Read more about Agile in "Zero to Agile in 90 Days or Less" .
[Note: this post was inspired by Jordan Bortz’ post, Agile and Waterfall are Two Sides of the Same Coin where he states that ‘ “Waterfall” is basically a Strategic method of attaining goals, and “Agile” is basically a Tactical method for achieving goals.’ ]
As Helmuth von Moltke (the Elder) said, “No battle plan survives contact with the enemy.” In the case of software development, the “enemy” is reality. What we think we need to do to satisfy customers and how we think we need to implement it generally changes as we implement and as we get customer feedback.
Similarly, Dwight D. Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable”. Planning (short and long, tactical and strategic) is still important in the Agile world. The difference is that Agile is specifically designed to take advantage of the fact that planning, design, and development have a learning component and to accommodate and embrace the resulting need to change plans on a regular basis. As you discover new information during an iteration, you can easily adjust your plans to take what you have learned into account in future iterations.
Too Busy to Plan
Short iterations and other Agile practices such as “You Aren’t Going to Need It” (YAGNI), may seem to indicate that Agile is tactical in nature. However, I would say that it is when looked at through a Waterfall lens. For instance, with Waterfall the planning horizon and iteration length (the full start to finish time) are the same. So if you look at Agile with this perspective you might think that the longest that Agile folks look ahead is 30 days. You might then conclude from this that Agile can only be used tactically. But in fact there is no connection between the planning horizon and the iteration length.
Many teams use very short iterations; two weeks or one week. What happens within an iteration is whatever has been planned for that iteration. Different Agile methodologies use different approaches for planning iterations. In any case, you can plan as far out as you would like. As an Agile product owner I can tell you that some of my products have plans going out multiple years.
Sometimes there is work that can’t be fit into a single iteration (whatever iteration length you have chosen). In that case, you can use multiple overlapping iterations. For instance, a one-week iteration for most stuff and an overlapping one month iteration for the exceptions. Over time though, teams generally get better at avoiding the need for exceptions.
Wherever You Go, There You Are
In my experience, whether the software development of a company is done tactically or strategically is connected to the planning culture of an organization, not the methodology. If an organization thinks and plans strategically, that will be reflected in their software development whether they are using Agile or Waterfall.
I’ve seen plenty of companies that use Waterfall but think tactically, packing mostly tactical features into a large release. Feature creep is a good example of how tactical thinking is fairly common in Waterfall projects. While of course it is true that “that shouldn’t happen” the facts on the ground are that it does.
I’ve also seen plenty of Agile projects that were strategic in nature. For instance, an Agile company that thinks strategically will have a strategic plan which they carry out using multiple iterations. As they discover that they need to do something tactical in the middle of their strategy, or they need to change their tactics in support of their strategy, it is simple to do with short iterations. They just change their plans for future iterations. As soon as their current iteration is done, they begin the next iteration which has now changed to take into account the new information.
It may well be that folks that think and plan strategically are less inclined to look deeply at Agile because it appears on the surface to be tactical in nature. I know that was true in my own case. I believe that people and organizations that think strategically will bring that thinking with them into the Agile world. Having crossed over I can report that I have been able to very happily and successfully bring strategic thinking with me to the other side.
Read more about Agile in "Zero to Agile in 90 Days or Less" .
[Note: this post was inspired by Jordan Bortz’ post, Agile and Waterfall are Two Sides of the Same Coin where he states that ‘ “Waterfall” is basically a Strategic method of attaining goals, and “Agile” is basically a Tactical method for achieving goals.’ ]
Subscribe to:
Posts (Atom)