10 Sep 2010 James Shore/Blog

Continuous Integration is this week's practice from The Art of Agile Development.

Continuous integration, like test-driven development, is one of the few Agile practices to gain wide acceptance outside of the Agile community. Despite its popularity, it's one of the practices I see performed most poorly. The typical "continuous integration" adoption involves installing a continuous integration server, automating the build, and then stopping there. As with many half-baked agile adoptions, teams doing this improve their lives somewhat, but they don't even come close to achieving what the practice is truly capable of.

That's not even close to what continuous integration is about. As Shane and I explain in the book, continuous integration is really about eliminating the risks and roadblocks that typically get in the way of shipping software to customers. A team that's practicing continuous integration well (and writing nearly zero bugs) can literally take their most-recently integrated code and deploy it at any time.

Contrast that to the typical release process for other teams, which involve long code freezes, error-prone manual release processes, and late nights. You can see how a continuous integration server isn't enough to get you from point A (caffeine-and-pizza-fueled nightmares) to point B (product ship nirvana).

The natural next step from continuous integration--done right--is continuous deployment. Once you've eliminated the roadblocks to shipping at any time, why not just ship every time you integrate? That's what IMVU does, and my sources say Flickr does the same.

The main difference between continuous integration and continuous deployment is that you have to manage your user interface so your users don't see anything that's not yet ready for prime time. I'm not going to go into depth on this right now, but the main technique I've heard people using is to have a configurable UI--one that uses configuration settings to decide which features the user can see. This has the side beneefit of allowing you to expose new features to a subset of users, such as a beta group.

Next Week

Next week's excerpt will come from the Planning chapter. We're getting close to having the whole book online (!), so there are only three practices to choose from:

• Vision
• Release Planning
• Risk Management

Vote for your preference by leaving a comment below.

Comments

10 Sep 2010 James Shore/Agile-Book

• Next: Collective Code Ownership
• Previous: Ten-Minute Build
• Up: Chapter 7: Releasing

in 99 words

Keep code integrated and build release infrastructure with the rest of the application. The ultimate goal is to be able to deploy all but the last few hours of work at any time.

To do so, integrate every few hours and keep your build, test, and other release infrastructure up to date. Each integration should get as close to a real release as possible.

Prefer synchronous integration, in which you wait for the integration to succeed, to asynchronous integration, in which a tool tests the integration for you. Synchronous integration requires fast builds, but ensures that they never break.

as haiku

--> Brain Dump

Forces Affecting Continuous Integration

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright &copy 2008 the authors. All rights reserved.

Continuous Integration

Audience

Programmers

We keep our code ready to ship.

Most software development efforts have a hidden delay between when the team says "we're done" and when the software is actually ready to ship. Sometimes that delay can stretch on for months. It's the little things: merging everyone's pieces together, creating an installer, prepopulating the database, building the manual, and so forth. Meanwhile, the team gets stressed out because they forgot how long these things take. They rush, leave out helpful build automation, and introduce more bugs and delays.

The ultimate goal is to be able to deploy at any time.

Continuous integration is a better approach. It keeps everybody's code integrated and builds release infrastructure along with the rest of the application. The ultimate goal of continuous integration is to be able to deploy all but the last few hours work at any time.

Practically speaking, you won't actually release software in the middle of an iteration. Stories will be half-done and features will be incomplete. The point is to be technologically ready to release even if you're not functionally ready to release.

Why It Works

If you've ever experienced a painful multi-day (or multi-week) integration, integrating every few hours probably seems foolish. Why go through that hell so often?

Actually, short cycles make integration less painful. Shorter cycles lead to smaller changes, which means there are fewer chances for your changes to overlap with someone else's.

That's not to say that collisions don't happen. They do. They're just not very frequent because everybody's changes are so small.

Collisions are most likely when you're making wide-ranging changes. When you do, let the rest of the team know beforehand so they can integrate their changes and be ready to deal with yours.

How to Practice Continuous Integration

In order to be ready to deploy all but the last few hours of work, your team needs to do two things:

1. Integrate your code every few hours.

2. Keep your build, tests, and other release infrastructure up to date.

Ally

Test-Driven Development

To integrate, update your sandbox with the latest code from the repository, make sure everything builds, then commit your code back to the repository. You can integrate any time you have a successful build. With test-driven development, that should happen every few minutes. I integrate whenever I make a significant change to the code or create something I think the rest of the team will want right away.

Many teams have a rule that you have to integrate before you go home at the end of the day. If you can't integrate, they say, something has gone wrong and you should throw away your code and start fresh the next day. This rule seems harsh, but it's actually a very good rule. With test-driven development, if you can't integrate within a few minutes, you're likely stuck.

Toss out your recent changes and start over when you get badly stuck.

Each integration should get as close to a real release as possible. The goal is to make preparing for a release such an ordinary occurance that, when you actually do ship, it's a nonevent1. Some teams that use continuous integration automatically burn an installation CD every time they integrate. Others create a disk image or, for network-deployed products, automatically deploy to staging servers.

1...except for the release party, of course.

Never Break the Build

When was the last time you spent hours chasing down a bug, only to find that it was a problem with your computer's configuration or in somebody else's code? Conversely, when was the last time you spent hours blaming your computer's configuration (or somebody else's code) only to find that the problem was in code you just wrote?

On typical projects, when we integrate, we don't have confidence in the quality of our code or in the quality of the code in the repository. The scope of possible errors is wide; if anything goes wrong, we're not sure where to look.

Reducing the scope of possible errors is the key to developing quickly. If you have total confidence that your software worked five minutes ago, then only the actions you've taken in the last five minutes could cause it to fail now. That reduces the scope of the problem so much that you can often figure it out just by looking at the error message—there's no debugging necessary.

Agree as a team never to break the build.

To achieve this, agree as a team never to break the build. This is easier than it sounds: you can actually guarantee that the build will never break (well, almost never) by following a little script.

The Continuous Integration Script

To guarantee an always-working build, you have to solve two problems. First, you need to make sure that what works on your computer will work on anybody's computer. (How often have you heard the phrase, "It worked on my machine!"?) Second, you need to make sure that nobody gets code that hasn't been proven to build successfully.

To do this, you need a spare development machine to act as a central integration machine. You also need some sort of physical object to act as an integration token. (I use a rubber chicken. Stuffed toys work well, too.)

With an integration machine and integration token, you can ensure a working build in several simple steps.

To Update From the Repository

1. Check that the integration token is available. If it isn't, another pair is checking in unproven code and you need to wait until they finish.

2. Get the latest changes from the repository. Others can get changes at the same time, but don't let anybody take the integration token until you finish.

Run a full build to make sure everything compiles and passes tests after you get the code. If it doesn't, something went wrong. The most common problem is a configuration issue on your machine. Try running a build on the integration machine. If it works, debug the problem on your machine. If it doesn't, find the previous integrators and beat them about the head and shoulders, if only figuratively.

To Integrate

1. Update from the repository (follow the previous script). Resolve any integration conflicts and run the build (including tests) to prove that the update worked.

2. Get the integration token and check in your code.

3. Go over to the integration machine, get the changes, and run the build (including tests).

4. Replace the integration token.

If the build fails on the integration machine, you have to fix the problem before you give up the integration token. The fastest way to do so is to roll back your changes. However, if nobody is waiting for the token, you can just fix the problem on your machine and check in again.

Avoid fixing problems manually on the integration machine. If the build worked on your machine, you probably forgot to add a file or to add a new configuration to the build script. In either case, if you correct the problem manually, the next people to get the code won't be able to build.

Continuous Integration Servers

There's a lively community of open-source continuous integration servers (also called CI servers). The granddaddy of them all is CruiseControl, pioneered by ThoughtWorks employees.

A continuous integration server starts the build automatically after check-in. If the build fails, it notifies the team. Some people try to use a continuous integration server instead of the continuous integration script discussed earlier. This doesn't quite work because without an integration token, team members can accidentally check out code that hasn't yet been proven to work.

Another common mistake is to use a continuous integration server to shame team members into improving their build practices. Although the "wow factor" of a CI server can sometimes inspire people to do so, it only works if people are really willing to make an effort to check in good code. I've heard many reports of people who tried to use a CI server to enforce compliance, only to end up fixing all of the build failures themselves while the rest of the team ignored their strong-arming.

If your team sits together and has a fast build, you don't need the added complexity of a CI server. Simply walk over to the integration machine and start the build when you check in. It only takes a few seconds—less time than it takes for a CI server to notice your check-in—and gives you an excuse to stretch your legs.

If you do install a CI server, don't let it distract you. Focus on mastering the practice of continuous integration, not the tool. Integrate frequently, never break the build, and keep your release infrastructure up to date.

Introducing Continuous Integration Get the team to agree to continuous integration rather than imposing it on them.

The most important part of adopting continuous integration is getting people to agree to integrate frequently (every few hours) and never to break the build. Agreement is the key to adopting continuous integration because there's no way to force people not to break the build.

If you're starting with XP on a brand-new project, continuous integration is easy to do. In the first iteration, install a version control system. Introduce a ten-minute build with the first story, and grow your release infrastructure along with the rest of your application. If you are disciplined about continuing these good habits, you'll have no trouble using continuous integration throughout your project.

If you're introducing XP to an existing project, your tests and build may not yet be good enough for continuous integration. Start by automating your build (see Ten-Minute Build earlier in this chapter), then add tests. Slowly improve your release infrastructure until you can deploy at any time.

Dealing with Slow Builds

Ally

Ten-Minute Build

The most common problem facing teams practicing continuous integration is slow builds. Whenever possible, keep your build under ten minutes. On new projects, you should be able to keep your build under ten minutes all the time. On a legacy project, you may not achieve that goal right away. You can still practice continuous integration, but it comes at a cost.

When you use the integration script discussed earlier, you're using synchronous integration—you're confirming that the build and tests succeed before moving on to your next task. If the build is too slow, synchronous integration becomes untenable. (For me, 20 or 30 minutes is too slow.) In this case, you can use asynchronous integration instead. Rather than waiting for the build to complete, start your next task immediately after starting the build, without waiting for the build and tests to succeed.

The biggest problem with asynchronous integration is that it tends to result in broken builds. If you check in code that doesn't work, you have to interrupt what you're doing when the build breaks half an hour or an hour later. If anyone else checked out that code in the meantime, their build won't work either. If the pair that broke the build has gone home or to lunch, someone else has to clean up the mess. In practice, the desire to keep working on the task at hand often overrides the need to fix the build.

If you have a very slow build, asynchronous integration may be your only option. If you must use this, a continuous integration server is the best way to do so. It will keep track of what to build and automatically notify you when the build has finished.

Switch to synchronous integration when you can.

Over time, continue to improve your build script and tests. Once the build time gets down to a reasonable number (15 or 20 minutes), switch to synchronous integration. Continue improving the speed of the build and tests until synchronous integration feels like a pleasant break rather than a waste of time.

Multistage Integration Builds

Some teams have sophisticated tests, measuring such qualities as performance, load, or stability, that simply cannot finish in under ten minutes. For these teams, multistage integration is a good idea.

A multistage integration consists of two separate builds. The normal ten-minute build, or commit build, contains all the normal items necessary to prove that the software works: unit tests, integration tests, and a handful of end-to-end tests (see Test-Driven Development in Chapter 9 for more about these types of tests). This build runs synchronously as usual.

In addition to the regular build, a slower secondary build runs asynchronously. This build contains the additional tests that do not run in a normal build: performance tests, load tests, and stability tests.

Prefer improved tests to a multistage integration.

Although a multistage build is a good idea for a mature project with sophisticated testing, most teams that I encounter use multistage integration as a workaround for a slow test suite. I prefer to improve the test suite instead; it's more valuable to get better feedback more often.

If this is the case for you, a multistage integration might help you transition from asynchronous to synchronous integration. However, although a multistage build is better than completely asynchronous integration, don't let it stop you from continuing to improve your tests. Switch to fully synchronous integration when you can: only synchronous integration guarantees a known-good build.

Questions I know we're supposed to integrate at least every four hours, but what if our current story or task takes longer than that?

You can integrate at any time, even when the task or story you're working on is only partially done. The only requirement is that the code builds and passes its tests.

What should we do while we're waiting for the integration build to complete?

Ally

Ten-Minute Build

Take a break. Get a cup of tea. Perform ergonomic stretches. Talk with your pair about design, refactoring opportunities, or next steps. If your build is under ten minutes, you should have time to clear your head and consider the big picture without feeling like you're wasting time.

Isn't asynchronous integration more efficient than synchronous integration? Synchronous integration reduces integration problems.

Although asynchronous integration may seem like a more efficient use of time, in practice it tends to disrupt flow and leads to broken builds. If the build fails, you have to interrupt your new task to roll back and fix the old one. This means you must leave your new task half-done, switch context (and sometimes partners) to fix the problem, then switch back. It's wasteful and annoying.

Instead of switching gears in the middle of a task, many teams let the build remain broken for a few hours while they finish the new task. If other people integrate during this time, the existing failures hide any new failures in their integration. Problems compound and cause a vicious cycle of painful integrations leading to longer broken builds, which lead to more integration problems, which lead to more painful integrations. I've seen teams that practice asynchronous integration leave the build broken for days at a time.

Remember, too, that the build should run in under ten minutes. Given a fast build, the supposed inefficiency of synchronous integration is trivial, especially as you can use that time to reflect on your work and talk about the big picture.

Are you saying that asynchronous integration would never work?

You can make asynchronous integration work if you're disciplined about keeping the build running fast, checking in frequently, running the build locally before checking in, and fixing problems as soon as they're discovered. In other words, do all the good things you're supposed to do with continuous integration.

Synchronous integration makes you confront these issues head on, which is why it's so valuable. Asynchronous integration, unfortunately, makes it all too easy to ignore slow and broken builds. You don't have to ignore them, of course, but my experience is that teams using asynchronous integration have slow and broken builds much more often than teams using synchronous integration.

Ron Jeffries said it best:2

2Via the art-of-agile mailing list, http://tech.groups.yahoo.com/group/art-of-agile/message/365.

When I visit clients with asynchronous builds, I see these things happening, I think it's fair to say invariably:

1. The "overnight" build breaks at least once when I'm there;

2. The build lamp goes red at least once when I'm there, and stays that way for more than an hour.

With a synchronous build, once in a while you hear one pair say "Oh, shjt."

I'm all for more automation. But I think an asynch build is like shutting your eyes right when you drive through the intersection.

Our version control system doesn't allow us to roll back quickly. What should we do?

Ally

Version Control

The overriding rule of the known-good build is that you must know the build works when you put the integration token back. Usually, that means checking in, running the build on the integration machine, and seeing it pass. Sometimes—we hope not often—it means rolling back your check-in, running the old build, and seeing that pass instead.

If your version control system cannot support this, consider getting one that does. Not being able to revert easily to a known-good point in history is a big danger sign. You need to be able to revert a broken build with as much speed and as little pain as possible so you can get out of the way of other people waiting to integrate. If your version control can't do this for you, create an automated script that will.

One way to script this is to check out the older version to a temporary sandbox. Delete all of the files in the regular sandbox except for the version control system's metadata files, then copy all of the non-metadata files over from the older version. This will allow you to check in the old version on top of the new one.

We rolled back our check-in, but the build is still failing on the integration machine. What do we do now?

Oops—you've almost certainly exposed some sort of configuration bug. It's possible that the bug was in your just-integrated build script, but it's equally possible that there was a latent bug in one of the previous scripts and you accidently exposed it. (Lucky you.)

Either way, the build has to work before you give up the integration token. Now you debug the problem. Enlist the help of the rest of the team if you need to; a broken integration machine is a problem that affects everybody.

Why do we need an integration machine? Can't we just integrate locally and check in?

In theory, if the build works on your local machine, it should work on any machine. In practice, don't count on it. The integration machine is a nice, pristine environment that helps prove the build will work anywhere. For example, I occasionally forget to check in a file; watching the build fail on the integration machine when it passed on mine makes my mistake obvious.

Nothing's perfect, but building on the integration machine does eliminate the majority of cross-machine build problems.

I seem to always run into problems when I integrate. What am I doing wrong?

One cause of integration problems is infrequent integration. The less often you integrate, the more changes you have to merge. Try integrating more often.

Another possibility is that your code tends to overlap with someone else's. Try talking more about what you're working on and coordinating more closely with the pairs that are working on related code.

If you're getting a lot of failures on the integration machine, you probably need to do more local builds before checking in. Run a full build (with tests) before you integrate to make sure your code is okay, then another full build (with tests) afterwards to make the integrated code is okay. If that build succeeds, you shouldn't have any problems on the integration machine.

I'm constantly fixing the build when other people break it. How can I get them to take continuous integration seriously?

It's possible that your teammates haven't all bought into the idea of continuous integration. I often see teams in which only one or two people have any interest in continuous integration. Sometimes they try to force continuous integration on their teammates, usually by installing a continuous integration server without their consent. It's no surprise that the team reacts to this sort of behavior by ignoring broken builds. In fact, it may actually decrease their motivation to keep the build running clean.

Talk to the team about continuous integration before trying to adopt it. Discuss the trade-offs as a group, collaboratively, and make a group decision about whether to apply it.

If your team has agreed to use continuous integration but is constantly breaking the build anyway, perhaps you're using asynchronous integration. Try switching to synchronous integration, and follow the integration script exactly.

Results

When you integrate continuously, releases are a painless event. Your team experiences fewer integration conflicts and confusing integration bugs. The on-site customers see progress in the form of working code as the iteration progesses.

Contraindications

Don't try to force continuous integration on a group that hasn't agreed to it. This practice takes everyone's willful cooperation.

Allies

Version Control

Ten-Minute Build

Using continuous integration without a version control system and a ten-minute build is painful.

Synchronous integration becomes frustrating if the build is longer than ten minutes and too wasteful if the build is very slow. My threshhold is twenty minutes. The best solution is to speed up the build.

A physical integration token only works if all of the developers sit together. You can use a continuous integration server or an electronic integration token instead, but be careful to find a token that's as easy to use and as obvious as a physical token.

Integration tokens don't work at all for very large teams: people spend too much time waiting to integrate. Use private branches in your version control system instead: Check your code into a private branch, build the branch on an integration machine—you can have several—then promote the branch to the mainline if the build succeeds.

Alternatives

If you can't perform synchronous continuous integration, try using a continuous integration server and asynchronous integration. It will lead to more problems than synchronous integration, but is the best of the alternatives.

If you don't have an automated build, you won't be able to practice asynchronous integration. Delaying integration is a very high risk activity. Instead, create an automated build as soon as possible, and start practicing one of the forms of continuous integration.

Some teams perform a daily build and smoke test. Continuous integration is a more advanced version of the same practice; if you have a daily build and smoke test, you can migrate to continuous integration. Start with asynchronous integration and steadily improve your build and tests until you can use synchronous integration.

• Next: Collective Code Ownership
• Previous: Ten-Minute Build
• Up: Chapter 7: Releasing

Comments

A couple of years ago, Justice Gray shared his journey from out of shape, yet still sexy to in shape.  Believe it or not, it was actually a bit of a motivation for me to get back in shape.  It had been a long descent when I left college until my late 20s, until no donut was safe, no fry was left un-eaten, and no shake left unslurped.

So, I joined a gym and decided to get fit.  I proceeded to procrastinate about 4 months, but then got serious.  That was about 2 years ago, and I went from 218 lbs and a 36” waist to about 155-156 lbs and six inches off the waistline.

When I first stepped on the scale, I hadn’t really realized how far I had traveled down bacon lane.  I imagined about 200 or so, but pushing 220 on a 5’ 9” frame can make it difficult to navigate narrow hallways.  I tried to find a picture of me back then for before/after, but unfortunately I didn’t fit in the frame back then.

My journey from flab to fit was deliberate, however, as I wanted to make lifestyle changes that I could live with and habits I could continue for a lifetime.  And if anyone else is in the same boat I was a couple of years ago and wants to make a change, perhaps my journey might help.

A plan of action

I knew I got where I was because of basic biology.  You gain weight when you consume more calories than you burn.  I had let a bunch of bad habits creep in, all of which added up over time to weight gain.  But I knew that my goal was a lifetime of health, so right off the bat I eliminated any kind of diet I wasn’t comfortable with keeping for the rest of my life.  And besides, diets don’t work.  Not long-term, anyway, which is what I cared about.

Since it was a series of bad habits that led me to this point, my plan of action to get back on track was to:

• Make incremental and iterative improvements in my habits
• Measure my progress

Measuring progress

It’s true that whatever you measure will improve.  I started weighing myself on a daily basis, at the same time every day in the morning.  I see folks weight themselves at the gym, which seems rather silly as you lose a lot of water weight after working out.  Morning weigh-ins provide the most accurate numbers, and the same time every day provides consistency.

I do wish I actually kept track on a daily basis, but I just basically remembered as time went on.  I felt quite a bit of apprehension on daily weigh-ins at first, as it was a number I wanted to hide from at first.  But the only way I can determine if I’m on the right track is to measure progress, so every little goal of 5 or 10 pounds was very encouraging.

But unless you weight yourself, you won’t know if you’ve gained or lost weight.  I would know after going home for the holidays exactly how much I had indulged.  Until I measured, I just wouldn’t know.

Changing habits

I had very poor eating habits since I had left college.  I ate out lunch every day, drank lots of sodas, snacked, didn’t eat many fruits or veggies, etc.  I didn’t do a lot of physical activity, either.  Since the formula for weight loss is a simple “burn more than you consume”, I just needed to tip the scales the other way.

I can’t do a complete lifestyle change in one day, so I focused on changing one thing at a time, until it became a habit.  It probably meant I didn’t lose weight as fast as I could, but it was also much easier to deal with.

The habits I started, in order:

1. Cardio exercise 3-4 times a week, for at least 30 minutes at a time (this is where the Wii and PS3 started getting lonely)
2. Eat out at most 1 time during the week, bring lunch the other
3. Eat breakfast
4. No beer during the week
5. Replace chips in lunch with fruit/veggies
6. Include at least 2 servings of fruit/veggies with each meal
7. Include resistance training/lifting with workouts (this pushed me over the plateau of about 190 lbs)
8. Replace sugar soft drinks with diet soft drinks
9. When eating out in a restaurant, divide plate in half and take the rest home
10. Replace diet soft drinks with water in restaurants
11. Replace diet soft drinks with green or black tea during the day (now I do 1-4 cups/day, this alone let me drop about 4 pounds in one week with no other changes)
12. Substitute fries with mixed fruit/veggies
13. Include snacks of nuts and grains during the day

All of these were done over the course of about 18-20 months.  My strategy was to transition away from high-carb diets rich in starches and sugars to one higher in protein and fiber, which incidentally help you feel full.  I also transitioned away from processed foods to more fruits and veggies, which besides the vitamins etc., these foods are harder to digest, so your body won’t necessarily absorb all of the calories present in the food.  This let me lose weight of about 1-2 pounds per week for normal weeks.  Weeks I went on vacation inevitably led to gains.

Restaurants were harder, as the temptation is there to overeat.  Portion size in a restaurant is double what it should be, so an easy fix is just to divide the plate in half and take the rest home.  Saves money, too.

When I met people I hadn’t seen in a while, my answer to “how did you lose all that weight?” is a pretty simple “eat right and exercise”.  Two habits I’m comfortable with for the rest of my life.  The tough part, and it really was tough, was identifying bad habits, substituting better behaviors, and making these my new habits.  Continue until I reached my target weight, 2 years and 60+ pounds lost later.

Treats versus habits

I didn’t really want to give up fries, queso, beer, queso, chips, queso, ice cream, queso or queso.  I didn’t want to live a life of culinary celibacy.  But the material I read was that none of these items are bad by themselves, they just have to be eaten seldom and in moderation.  That’s pretty much what I’ve stuck to.

A cookie is fine, ice cream is fine, fries are fine, but I can’t eat those every day and not expect to blow up like a surprisingly handsome balloon.  Temptations at home are tougher, so I opted instead to not have tempting foods around.  Chips were replaced by celery and peanut butter.  Microwave corndogs with soup that doesn’t have 8 lbs of sodium.  A treat eaten every day is then a habit, and there will be side effects of making a treat a habit.  I still have soft drinks, but I might have 1 a week instead of 10.  And there’s usually some sort of vodka or rum in it, so it doesn’t count anyway ;)  I still play video games, but not 4-5 days a week.  Instead, I’ll go to the gym.

I’ve known quite a few folks go on a diet, make great progress, then quit the diet only to see the weight return.  By identifying habits I could keep for the rest of my life, incrementally adopt these habits, measure my results, and treat myself in moderation, I have a lifestyle I’m happy with and won’t lead to health problems further down the road.

Final tips

Read a lot on diet, nutrition and exercise.  Don’t adopt a diet you can’t do for the rest of your life.  Don’t try and change everything at once.  Weight yourself every day.  And finally, attack this as a transition to lifelong habits for a healthy lifestyle, instead of merely a goal of losing weight.  There are a lot of ways to just lose weight, but most of these don’t work long-term.  If you adopt a healthy lifestyle, weight loss becomes just a nice side effect.

Anyway, I hope this helps some else, as Justice’s journey helped me.

Tuesday night I gave a talk at a local Java User Group (that’s four JUG appearances this year, hoorah!) on RabbitMQ and demonstrated not just using it communicate between two java processes, but also as a way of communicating asynchronously between a node.js application and a java application… I have to say it was pretty awesome and I really think it opens the doors for integrating node.js applications seemlessly into an existing java infrastructure.

The setup was actually pretty simple and I have to admit I only spent a total of two days on it. I first created the node.js application front end using Socket.IO to manage websockets on both the server and client side and Ryan Dahl’s node-amqp plugin for communicating over amqp. Here’s the relevant node.js code:

I think this is pretty straightforward, but I’ll describe what’s going on here. First, we open a connection to the amqp server, which could be configured with any additional details in accordance with the amqp spec but for now it’s just hitting localhost. Once the connection is established we declare the exchange we’ll use and then declare a queue named “queueB” and bind it to the exchange using the routing key key.b.a. This will let us receive any messages from the queue with that routing key.

With all this established, we start up the web server (I am using expressjs) and once it starts up also have socket.io listen on the same port. With the infrastructure setup, we add a listener for when a client connects and route any messages sent from the client to the exchange with the routing key “key.a.b”, which will be picked up by our java app (whose queue is bound to that key on the same exchange). We also subscribe to the queue we previously setup and messages sent out on it will be published back to the client over websocket (which in turn displays it on the page).

What makes this sweet is all of it is event driven… anything recieved on the queue is pushed to the client side and whenever the client sends something over the websocket it’s published (in this case, it’s bound to anything typed into a text box on the ui). For completeness, here’s the client side javascript:

Now here comes the java application portion (brace thyself!), which will take stock ticker symbols and return a hard coded price for that ticker (but hypothetically it could be a real value). Here’s the javaclass that acts as both a listener and a publisher, with it’s onMessage method taking the message it receives, looks up the stock ticker symbol in an ImmutableMap and publishes the price using RabbitTemplate (I’ll show the configuration for it soon):

This is all configured using Spring 3.0’s annotation based configuration:

The CommonConfiguration class is used because in the presentation I showed multiple behavior. The connectionFactory bean simply defines the ConnectionFactory with various details (these are defaults in node) and the rabbitTemplate bean represents the template that will be used to listen on queueC bound to some-exchange using the routing key “key.a.b” (which if you recall is the key used when node publishes messages on the exchange). The binding() is used to just bind the queue to the exchange.

FInally, we create a SimpleMessageListener bound to the queue (this is used in the application runner class to make our StockLookup listen on the queue) and create a bean for our StockLookup, which injects a rabbitTemplate that will be used for publishing messages back out on the exchange. Whew!

Now we have the main class that is used to startup the java app and context. This could just be a one liner that just instantiates the context, but during the presentation I wanted to expose the listener to do some live demonstrations and ended by setting the StockLookup object as a listener.

That’s all… just start up the node.js application and the java app, navigate to http://localhost:3000 and entering IBM or GOOG in the text box should make the relevant stock prices show up. A neat little thing I did in the presentation was modified the java app to publish different prices and intervals, with the client side updating in real time without me doing anything in the node.js side. Fun stuff.

The relevant code is available on github at http://github.com/jamescarr/nodejs-amqp-example for trying it out on your own, the readme gives some instructions on what you’ll need to do to set it up and run it.

This was all the result of spending just a day exploring spring-amqp (which is relatively new) and getting node and java talking… I can’t wait to delve deeper and see what other potential uses will be. The slide deck I used for the presentation is also included below.

High powered messaging with RabbitMQ View more presentations from carrja99.

Today we used a new "Roundabout" mechanism in our daily stand-up, which is in a conference room. We have our artifacts on the walls, and our focal point for stand-up is our sprint status board with our story cards (large post-it's) and tasks on a progress chart. We use this chart in addition to an electronic mechanism to track the progress through the sprint. We have been just each standing around the table and pointing to the story cards and talking about our progress and status.

Today, (at the suggestion of a team member) we each stood by the chart, moved our tasks and story cards as appropriate, and then all the team moved around to the right walking around the table, so the next person could stand by the chart and talk about their tasks. I think this worked very well, as it kept focus on the team member speaking, and the team member was able to focus completely on the tasks and stories on the wall by physically touching them. It helped keep status focused and short. The movement around the room and around the table gave us a new perspective on the room and the chart, each time someone was speaking. Also, it gave us some physical motion to keep our bodies and minds engaged and present. Stand-up was shorter, and more effective. All the team felt that this was a good new addition to the daily routine, and the team is now wanting to add this movement to our working agreements.

Just moving around a table one team member at a time is a small thing, but it's FREE and seemed to help focus and productivity, so I am going to suggest the mechanism to any scrum team I have the pleasure to be part of in the future. Try it out and see what happens!

So far, I've pointed out various issues in test estimation, pointing out the fallacies involved in simple 'naive' test estimation. I also pointed out that is possible to do some kind of estimate, even if all you say is "um, yeah boss -- two weeks."

A couple of people expressed surprise at this. Laurent Bossavit, a board member of the Agile Alliance, was concerend that people wouldn't take me seriously.

But if you've been around the block a few times, you might just remember a test project or two where a wild guess made without context was the test strategy. Someone with no context walked in, said "testing -- hmm. Four weeks." and walked away. They were the boss, and it is what it is, and the team made the best of it.

Hopefully that isn't what actually happened.

It might have looked like that to an outsider, but there was likely something more going on. Perhaps the manager needed to ship the product in four weeks in order to hit some deadline. Perhaps he needed the staff to stop billing on project X because in four weeks, you'd run out of budget.

Or, perhaps, it's possible that some sort of rational process was going on in his head that we could not see.

I'm going to start with the rational approaches. Don't worry, we'll cover the social approaches, and even agile and iterative models -- but I think the next step is to have some logical reason to believe it will take X, instead of wishful thinking.



It might have looked like "Four weeks" was made up, but it's very possible that some complex process was going on in that manager's head. For example, he might have thought:

Hey, this project is about as big as project A. I've got the exact same technical teach as project A. We haven't had much turnover in the dev ranks either. We've actually learning something since project A, and I believe the team will make less mistakes. How long did project A take to test? Oh yeah, four weeks. Okay. I'll use that as estimate.

Check it out -- our theoretical manager might actually had a reason for believing in the four week number.

It's also possible that the manager was considering a number of projects and averaging the lengths, to come up with four weeks. It's unlikely the data was available, but the human mind is surprisingly capable of doing those averages, even subconsciously. I prefer to do it with a pen and paper and a little math, to have something to explain to someone who asks "where did the four week number came from?", but many a tester, lead, or manager can do this sort of comparison in their head without even realizing it.

This happens in other disciplines too. Consider the expert Butch who has spent his entire adult life in the field. You ask him for two pounds of ham and he goes slice slice slice - weight it and it's exactly 2.002 pounds. Ask him how he did it, and he'll likely say "I don't know. I suspect cutting meat five days a week for thirty years had something to do with it.



But we can do one better than that. Write down a half-dozen projects. It's unlikely that any of them are specifically like project X. Project A had a different dev team, project B had more testers, project C was riskier with a more complex infrastructure, project D was the first time we had ever used the new webserver, and so on.

So you end up with a range. "Given our previous projects, we expect this test project to take three to five weeks."

Of course, there's all kinds of reasons that's a bad estimate. But it's better than the first strategy - to make something up - right? And it's likely better than functional decomposition, for reasons we already discussed.

This idea - past history - is a lever, a way to come up with an estimate. In other words, it's a model from which an estimate will "pop out".

When this series is done, you should have several levers. You'll be able to apply several models to your project, get several estimates, and consider which one is correct.

More to come.

This one should be short… When I think about Scrum vs. Kanban question (which is coming back like a boomerang over and over again) I really have just one single distinction in mind – time boxing vs. flow.

If you think about Scrum and Kanban as a process frameworks (and I do so) then you can find more similarities. They both show you how to organize the work flow, give simple tools (backlogs, kanban boards). They focus on team collaboration aspect of the process. They give you simple visual indicators (burndown charts, cumulative flow charts) to quickly spot problems as well as simple metrics to give you the basis for planning (velocity, cycle time).

What is different is that Scrum creates fixed time spans and concentrate some activities around those time boxes boundaries (planning, demos, retrospectives) while Kanban goes for the continuous flow, which usually means that the mentioned earlier activities will blur a bit and change their character to more ad-hoc (instead of Scrum’s meeting oriented) style. So the question you need to answer is actually which type of work flow fits better your organization and the character of your project(s).

Do you prefer cycle with boundaries when you can for example reach your stakeholders every two weeks? Or maybe you need a freedom to make your code base unstable for let’s say 1 week and get it back to deployable state after a sprint without a pressure that this will affect some other features that need to be shipped in the meantime? Scrum might be better here.

On the other hand if you don’t need strict boundaries and you prefer to manage things in ad-hoc meetings. If you can ship features one by one or can work on them independently. If each of those features brings enough value to be shipped alone when it’s ready, then you may find Scrum too limiting and go for Kanban. Maybe you don’t have direct access to your users, your users prefer smaller increments wand want to get updates whenever they are ready. Go Kanban.

As always, you should probably be choosing the best of those two worlds. The important thing to remember is that the framework is not enough. You need to have a high quality engineering practices behind it. And those practices may be the same no matter if you choose Scrum or Kanban.  So don’t spend too much time on it.

• Tweet This!
• Post on Google Buzz
• Add this to DZone
• Share this on Facebook
• Share this on Reddit
• Digg this!
• Share this on LinkedIn
• Share this on Technorati
• Share this on del.icio.us
• Share this on FriendFeed
• Add this to Mister Wong
• Submit this to Netvibes
• Add this to Ning
• Stumble upon something good? Share it on StumbleUpon
• Add this to Wykop!

Nowadays it seems that I always have to work around problems with installing Adobe Flash Player updates on Windows ... And I always have multiple computers to update, whenever there's a new version. So I've decided it's time to actually document my 'process' for doing it, to save myself time from now on. Let me know if this tip helps you, too.

On Sept 14-16, 2010 Joe Little and Catherine Louis will lead a Certified Scrum Master course plus 1-day Workshop in Durham, NC. Joe is an experienced Agile

The studios I visit that have the most success employing agile have something in common.  There is often a champion of the effort to become more agile who has a position of authority there.

Some of the things I have noticed about them are:

• They understand the principles of agile and Scrum.  They understand the source of change comes from the teams, not a process.
• They care about their people.  They want to see an end to the cycles of project madness.
• They are willing to grow trust with the teams.

Although this role isn't defined as part of an agile process, it is often is a valued one.   Lately I came across the description of a role called the "Agile Manager" in a great book by Lyssa Adkins called "Coaching Agile Teams".   In the book, she writes that an agile manager's role is:

• "Organizational change artist:  Guides the organization through agile adoption (and re-adoption).
• Boundary keeper:  Reinforces healthy role boundaries both within the team and between the team and the greater organization.
• Value maximizer: Manages the portfolio of projects like a product owner manages a portfolio of user stories, always asking what the highest business value project is now.
• Lean manager: Uses lean thinking to improve organizational flow so that the value teams deliver can be realized without delay.
• Organizational impediment remover: Finds the gritty courage it takes to remove entrenched impediments.
• Team champion:  Offers observations from the team boundary and releases the team to reach their fullest potential by truly believing they can.

The agile manager is like water--patiently, water can carve away the hardest surface, and it will always find a way to flow.  Making things flow so the team delivers again and again is an honorable (and challenging) job.  In so doing, agile managers offer their highest service to the team. "

While this role isn't unconditionally necessary for success in all cases, it is for teams that don't have the authority to overcome organizational inertia that can prevent a team from becoming agile.

Someone posted the slide deck from Epic's presentation made at a GDC tutorial a few years back.  It's brief, but it was a good presentation.

Its always a great experience to share knowledge with others. Today we had a mini workshop for some of the colleagues of Informatics and few of our new Exilesoft colleagues together to learn agile.

Total time box – 2 hours for the training. (4PM to 6 PM) In that, I had to spend first one hour to take them though the agile concepts and introduction to Scrum. I tried to cover up some of the practical issues too such as planning a huge backlog, vertical designing or so which they are already into.

So we were left with 1 more hour, which I wanted them to go through an exercise to learn and feel agile concepts better by themselves.

So, yesterday night I prepared this small backlog for them…

As a

I need

So that

Weight

Priority

Marketing Manager

a bird with 2 wings

I can sell the toy to kids

VP Marketing

The bird to carry the logo

We can brand it as our own toy

Sales person

The bird to have red color feathers

It will be more appealing to young girls

Marketing manager

The bird to have blue eyes

The bird will be more appealing to the kids

Production manager

The documentation on how to make the bird

I can train more people to produce birds like this

Marketing manager

The bird to have 2 legs

The bird will be able to stand

Marketing manager

The bird to be bundled with a cage

We can add more value in the market

Brand manager

A catchy name to the bird

The bird will be popular among the kids

Angry kid

Soak the bird in water

The bird will be destroyed easily

The product vision: to produce a toy bird to the market, this can compete with other toy birds in the market.

Product backlog

You may notice few points in the product backlog user stories. There are some functional requirements which is a must to deliver and some nice to have features too. With the angry child user story, I wanted them to get the idea of having user stories from hacker’s perspective to come up with security related user stories too to the product backlog. Documentation user story was brought in to the picture, so that team will understand if the documentation is needed by stakeholders to treat it as a user story and deliver it.

We had 8 members, so we split the team to two. My colleagues Shamira Dias and Manujaya Kuruppu volunteered to play the product owner role for the 2 teams. Thanks to them they did a great job of taking teams through the product backlog and helping them to learn estimation techniques.

Shamira and Manujaya prioritized the stories to their teams after having a discussion with them. They prioritized the highest market value items first. Both the teams played planning poker to estimate the user stories with their product owners which helped them to get the real idea about relative estimation using story points.

After that.. They decided 2 releases for the backlog. First release within 15 min and other release within 20 min. which is the final release of the bird. Product owners mentioned to their teams what they need for the release one.

Here they are busy making this bird… Team A

Team B - Making the bird


When they did the final release, Navin came as the customer and he had to make a hard decision about buying one bird. He bought Duckybird J because it could fly perfectly and he was fascinated about his flying skills.

Here is the Mountain bird by team B at the final release :-)

Here is the Ducky bird by team A at the final release :-)

After that we did a retrospective with the teams...( we had no time to do a retro after the release 1 which could have been the perfect scenario.)

The findings

• 1. Team A failed to do the product release on time even with minimal required features. So they saw how their competition came to the market.
• 2. Team B prioritized the red feather story for the release 1 , so they had no time to deliver a stable product which is a bird who could stand.
• 3. Team B delivered extra (Gold plating??)_ nice decoration on bird which was not included as a user story in the backlog and they totally forgot about the flying feature of the bird which made them to loose their opportunity in the market against the competition
• 4. Team B – the whole team spent time on doing documentation and didn’t deliver the cage and the fence. – there scrum master was too involved in building and forgot to get his team guided towards signing in to various tasks to improve the utilization of time. which can happen in real development projects.
• 5. Testers of both teams didn’t add much value to the team from testing perspective.
• 6. They learn the difference of a scrum master from the Project Manager
• 7. They learned how the team culture works in agile organizations.

Rewards

After that , I rewarded the scrum master of team A as his product owner managed to make a sale based on what his team produced.. The team accepted that they didn’t feel very happy about it as they felt he was rewarded at their cost and instead the management could have rewarded the whole team because the whole team worked hard to release a nice toy bird to the market.

Thanks to all who participated the training.. it was a great experience to share knowledge with a team from another company. I'm sure my colleagues also enjoyed it a lot.

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Die Rolle des ScrumMasters ist die bedeutendste Rolle im gesamten Scrum Prozess. Er führt ein Team, hilft diesem Team Höchstleistungen zu erzielen, zeigt ständig Verbesserungen auf und unterstützt die Anfordererseite dabei, erfolgreich mit dem Entwicklungsteam zu arbeiten. Certified ScrumMaster (CSM) Trainings von bor!sgloger lassen die Teilnehmer erfahren, was es heisst, Scrum tatsächlich anzuwenden und Scrum als ScrumMaster in Organisationen einzuführen.

Bei folgenden CSM Trainings gibt es noch freie Plätze, buchen Sie noch heute!

• CSM Training (deutsch) mit ScrumCooking, Wien, 16. und 17. September, mit Boris Gloger und Peter Beck
• CSM Training (englisch), Berlin, 19. und 20. Oktober, mit Boris Gloger

Related posts:

• Trainings im März | CSM Wien, Zürich und Professional ScrumMaster in Wien
• Making of “Certified ScrumMaster class” – (1)
• Making of "Certified ScrumMaster class" – (1)

In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I [...]

09 Sep 2010 James Shore/Blog/Lets-Play

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more.

Comments

Our Windows Azure Security Notes are now available under the Highlights section on TechNet’s Security TechCenter.

It’s a collection of common applications scenarios for Web applications, Web services, and data on Azure, and it’s a map of common threats, attacks, vulnerabilities, and countermeasures.  It also explains the approach we used to understand the security impact of the various application models on Windows Azure.

You can use the examples from the application scenarios in the notes as a way to help you map out and model your application scenarios.  Even just knowing how to whiteboard Windows Azure application scenarios can go along way, especially bridging the gap between application design and runtime deployment.

Enjoy.

We’re a Scrum team (though in reality, we’re also doing XP along with some Lean and Kanban practices and principles). So, on occasion we have Estimating Meetings. Common wisdom in the Scrum world (at least as far as I’ve been taught) is that teams should not spend a huge amount of time discussing each story before estimating. Get an idea what the story is, and estimate it quickly; there’s a point of diminishing returns where spending a lot more time talking does not make the estimate more accurate.

Our team always ends up in long discussions, especially if our product owner has presented a brand new theme. Our ScrumMaster used to try to keep us on track using an egg timer and the like. We couldn’t break the habit, though. Yet, our estimating meetings seem valuable the way we do them. We don’t have them often, and our discussions save time later.

Our PO works through an example on the board (note remote team member on monitor)

We’ve gotten into a pattern for estimating new themes. Our product owner schedules at least two meetings for a new theme: one for talking about the new functionality, which we call a “brainstorming” meeting, and one for writing and estimating the stories. For complex themes, we might have more than one “brainstorming” meeting. However, they are time boxed to an hour each. This gives us a chance in between meetings to think about the new functionality, how it might be modeled, talk amongst ourselves about it. Often, someone comes up with a brilliant idea in the second meeting that will save a lot of time in implementing the new features. It also helps us slice and dice the stories into appropriate size and priority.

In today’s brainstorming meeting, we talked about a new theme, to collect custodial fees from 401(k) participants. A custodial fee is a tiny percentage (for example, .05%) that our clearinghouse charges us for servicing the trades for our 401(k) participants. Up to now, we’ve notified participants that they’ll be charged this fee, but we’ve never taken it; we just pay the fee ourselves. We have enough assets under management today that it’s worth the trouble to collect the fee.

An Example

Today’s meeting ran long, but it was productive. These fees are similar to other fees, and if we come up with a better way to collect and process them, we can use the same model elsewhere. The programmers thought about some problems that currently can occur in production, and ways we might proactively prevent them with this new code.We decided to discuss this just within our development team tomorrow, then have an estimating meeting on Friday to write the stories and estimate them.

A Related Issue

Our product owner also raised an interesting issue. In the past several sprints, our velocity has been almost twice what it was in the previous few years. At the same time, he feels our estimates for stories have been much higher. Does our velocity look higher because we’re over-estimating? Or are we just getting more efficient and able to do more work each sprint? We discussed the reasons our velocity is higher, and what we can try to make sure our estimates are as consistent as possible so that the business can estimate ROI for potential stories and plan when features might be ready to release. We decided to start doing retrospectives when we complete a story that either takes us much longer than estimated, or much less.

Is This A Good Idea?

Are we doing estimating meetings “wrong”? I don’t think so. I think we have found a pattern that works for our team. Discuss, ruminate, discuss some more, estimate. It’s not BDUF, it’s usually just enough. When we don’t do this, we go with higher estimates because of the uncertainty – which is what we think may have happened lately (our PO has been so busy, we haven’t had brainstorming meetings for months). When we do, it often pays off in finding simple solutions.

I’m not recommending talking stories to death before estimating. But see if some time working through examples and discussing potential production issues, effects on other parts of the system, and other concerns will help deliver good solutions in a more timely manner.

How Do You Do It?

Have you come up with good approaches to tackling new themes and providing useful estimates that help the business figure ROI and prioritize stories?

Regular expressions span exactly the same languages as the mathematical construction called Finite atomata. With the Pumping lemma, we can prove that it’s impossible to create regular expressions for many problems, e.g.:

1. All palindromes
2. All text strings that doesn’t consist of a prime number of identical characters

Since Regular expressions have become popular as extensions to imperative programming languages, new features have been added. Languages from Context-free grammars and Pushdown automata (essentially a finite automata with an attached stack), can be matched with these features. Regular expressions are Type-3 and Context-free grammars are type-2 in the Chomsky hierarchy.

To not be confused we call these built-in languages that are more than Type-3, Regex. Regexes are more powerful than Regular expressions.

Non regular prime number finder

With the (non regular) feature back-reference, it’s possible to create a regex that only match strings with a prime number of identical characters:

irb(main):001:0> r = /^.?$|^((.)\2+?)\1+$/
=> /^.?$|^((.)\2+?)\1+$/
irb(main):002:0> r.match "22"
=> nil
irb(main):003:0> r.match "333"
=> nil
irb(main):004:0> r.match "4444"
=> #<MatchData "4444" 1:"44" 2:"4">
irb(main):005:0> r.match "55555"
=> nil
irb(main):006:0> r.match "tttttt"
=> #<MatchData "tttttt" 1:"tt" 2:"t">

Non regular palindrome finder

If we also add the (non regular) feature recursion, we can match all palindromes:

irb(main):001:0> p =
/\A(?<palindrome>|.|(?:(?<prefix>.)\g<palindrome>\k<prefix+0>))\z/
=> /\A(?<palindrome>|.|(?:(?<prefix>.)\g<palindrome>\k<prefix+0>))\z/
irb(main):002:0> p.match "otto"
=> #<MatchData "otto" palindrome:"otto" prefix:"t">
irb(main):003:0> p.match "dallas sallad"
=> #<MatchData "dallas sallad" palindrome:"dallas sallad" prefix:"s">
irb(main):004:0> p.match "rais air"
=> nil
irb(main):005:0> p.match "1010"
=> nil

Missed your chance to sign up for GoGaRuCo? They just sold the last ticket over the weekend. It's looking like an awesome line-up. But have no fear, you still have one chance to win a ticket!

It's the Pivotal Tracker GoGaRuCo Haiku Contest!

We're giving away one ticket to GoGaRuCo, the Golden Gate Ruby Conference happening here in San Francisco September 17th-18th.

Rules: Submit your Pivotal Tracker-related Haiku to tracker-haiku-contest@pivotallabs.com by one minute to Midnight Pacific Time, this Thursday night, September 9th. Multiple submissions are allowed, but of course only your best one's going to win, now isn't it.

We'll pick one winner, at our sole discretion, to be announced here. What are our criteria? I'll mostly be looking for awesomeness, but adherence to standard North American 5-7-5 form does count. (It would take a lot of awesomeness to overcome divergence from this style, and no submission without at least a little awesomeness is going to make it.) References to season a plus.

All submissions are licensed to Pivotal Labs to use however we see fit, and you retain the ability to use them as you see fit, under the Creative Commons commercial attribution share alike license. The winner will be granted one ticket to GoGaRuCo. Your travel is of course up to you.

Valid entries must include name, telephone, and email. Name will be used in attribution, but neither the telephone number or email will be made public.

So have at it! Give us your Tracker haikus. Don't know Tracker yet? Really? Check it out!

I might get shot for this, but trying to be an agile purist on a marketing team isn’t possible. Most practitioners realize that agile project management works best when it’s adapted to the unique environment of the team. But that doesn’t mean you can just make things up as you go just because you’re outside of software development. There are key agile processes you shouldn’t mess with when you’re starting to practice agile, and others that can modified.

Daily Standup
Having a daily standup doesn’t automatically make you agile, but you can’t really be agile without standup. At first I didn’t understand the value of meeting every day for 15 minutes. I was on a small team, and we met almost every day already. I soon realized that the format of the meeting (what did you do yesterday, what are you going to do today and do you have any impediments) helped focus the team, and having a quick meeting at the same time and place every day helped set a rhythm. Don’t mess with daily standups.

Fixed Iteration Length
As I’ve mentioned before, it’s OK to change the length of your iterations when you’re trying to figure out what works best for your team. But once it’s set, try not to change it. You can make some pretty persuasive arguments for shortening or lengthening an iteration (holidays, vacations, looming deadlines), but it will most likely disrupt the team’s established cadence and productivity will suffer.

Estimating
Our product owner likes to say that she “reserves the right to get smarter.”  One of the primary reasons we estimate stories is for predictability, and the more we practice as an agile team, the smarter and more predictable we’re getting. Now you can’t just not estimate, but don’t get too hung up on one method if it’s not working for you. Fine-tuning the way you estimate is a good thing.

No matter what, agile is an iterative and collaborative process. If you’re not breaking down work into smaller pieces and sharing that work across the team, you’re just not agile. But don’t be too hard on your team if you need to make some changes in your agile implementation.