Agile - Scrum
One of the things that I talked a lot about in some of my previous posts about how we run our agile process is tasks. They have become a very central part of our process, and as such, have become our obsession. You see, when doing estimation it is very important to break things down into manageable tasks, otherwise you end up with riskier (and less accurate) estimates. It's well documented that developers are better at estimating smaller tasks than larger ones. Thus, we break everything into nice small manageable units of work. We then have our whiteboard full of each and every task that's necessary for building out the features for the current iteration. Throughout the week we can look at the whiteboard and see all the remaining tasks. When we finish one task we go to the board and find another. By the end of the week we aim to get all the task cards to go green since that signifies the completion of all the work.
Not quite. Unfortunately, our iterations aren't about getting our task cards to go green. They're about working software. By following our tasks we get a large portion of the way to our goal, however, it's my suspicion that they prevent us from getting as far as we need to.
You see, while task cards can help guide you along your way, they can also blind you. Rather than deciding what the most important thing for you to do next is by thinking, you instead rely on your task cards. Instead of seeing with your own eyes the software work, you instead rely on your task cards. Rather than thinking about how best to design something, you instead rely on your task cards.
Don't let your task cards control you. If you need to use them as a guide, and use them as a barometer for where you are in the iteration, so be it. However, do not obsess. Do not live vicariously through a little white task card. Instead think about what your building. Think about what the software needs to do. Think about the most important things to complete. Think about your software, not your mother f'n task cards. 
A couple weeks ago I talked about how we run our one week iterations. I've received a couple questions regarding how we actually pull one week iterations off using the "schedule" that I outlined. The main questions people generally have when I mention that we use one week iterations are:
- When do you have time to fix bugs?
- Is there always enough time to fix all the bugs within such a short timeframe?
- Is it always possible to have a demo after 1 week?
- What happens when people take vacation?
- What do you demo when you spend the week doing framework libraries or infrastructure tasks?
Before moving onto answer each of these questions I should probably thank Patrick Altman for covering many of the common questions I get asked in his "One Week Itererations" post.
When do you have time to fix bugs?
As I mentioned in my last post we usually have a couple hours on Friday dedicated specifically to fixing bugs. That certainly doesn't mean that's the only time we spend working on issues that crop up. Throughout the week as we finish tasks and stories we let our QA & product teams know what things are done. They can also take a look at our whiteboard to see what's ready (or maybe only semi-ready) to be tested. If they think its worth testing they go ahead and start looking for issues. If they find "bugs", we scrutinize them and tell them that what they found is a feature not a bug and move on. You see, if you never let QA report a bug, then you never have any to fix. You didn't realize it was so easy did you? Ok, not exactly. When a "bug" is found our QA and product team typically lets us know of the "bug" by either stopping over and announcing the bug to the team, or by telling the pair that worked on the story/task which the bug is related to about the bug. After a short discussion, we either fix the issue right then, create a task card to remind us to fix the bug, or deem it not worth fixing due to the fact that other parts of the story which are not finished are what is making it a bug (aka: what was being tested wasn't quite ready to be tested).
Is there always enough time to fix all the bugs within such a short timeframe?
No. The iterations that we just finished today resulted in a handful of bugs which could not be finished by the time we closed out the iteration. We usually try and fix any bugs that are left after an iteration at the start of the next iteration. From time to time we carry the bugs longer, but, we usually try not to since the longer we wait to fix the bug the longer it will take development to remember what needs fixing.
Is it always possible to have a demo after 1 week?
We've only canceled our demo 1 time. We've also had several demos go poorly, and several demos that had to be mostly discussion and/or showing of FIT documents because what we planned to get done didn't get done. It really sucks when this happens, but it does happen.
What happens when people take vacation?
We simply put it into the schedule and deliver slightly less functionality. We currently have 7 full time developers, so we can typically churn out at least 1-2 business stories per week which are demoable. You should keep in mind that the demo isn't always all that exciting, but it does happen, and we are demoing new business functionality.
What do you demo when you spend the week doing framework libraries or infrastructure tasks?
What are framework libraries and infrastructure tasks? The only time we spent a full week doing "framework" and "infrastructure" stuff is when we implemented our security infrastructure. Every other week we've worked on business stories, along with framework/infrastructure stuff. We typically tie any technical stories that we need into the business stories that product is asking for. This results in slightly higher estimates, which product isn't always thrilled with, but such is life.
I have plenty more things to write about but considering this post has been sitting within Live Writer, in half written form for about a month I think I'll post what's here so far. What other questions, concerns, or thoughts do you have?
Car manufacturers have entire departments dedicated to finding better ways to do things. If a car company spent all its resources producing cars and no time finding better ways to produce cars, it would quickly go out of business.
http://codebetter.com/blogs/jeffrey.palermo/archiv...
With all the advantages that Agile provides, I think it can lead to teams spending all their time producing "cars". Afterall, what immediate business value does research time spent investigating how to do things better provide?
tags: agile, software
I was recently asked for some details about how we run our one week iterations so I figured I'd post some details to this here blog. We've been doing one week iterations for a while now with some pretty good success. While the nitty gritty details of every iteration varies we tend to keep the overall flow the same.
Of course everything starts off on Monday. With a nice weekend to relax and reflect on the previous weeks work we come in refreshed and ready to rock. We kick things off with a demo of the functionality added in the last week at 9:00 AM. The demo includes everyone from our office as well as our colleagues in our other offices around the world and a few interested clients. The demo is typically done by a member of the "business team" since they tend to have better presentation skills then us introverted anti-social developer types.
Once the demo is complete we go into a retrospective which is used to reflect upon the previous week and identify things that we can improve upon in the coming week. The retrospective usually runs for one hour. Once complete we begin discussing the stories slated for the week. Our story discussions involve an overview of the objective for the week, a high level discussion of what's entailed with each story, a discussion of the FIT that has been created for the stories, and finally a hodge podge of questions that the developers ask in order to figure out what exactly is being developed in the coming week. The discussions can last anywhere from 1-4 hours. Once the developers have a firm understanding for the work that needs to be done we breakdown the stories into tasks and estimate. The task breakdown and estimating varies A LOT, and largely depends on how familiar the team is with the work and its overall complexity. Task breakdown and estimation takes anywhere between 1-4 hours. As I'm sure you've figured out by now sometimes our entire first day is taken up story discussion, task breakdown and estimation. I'm not a big fan of taking the entire day but its important for everyone to have a firm understanding of what's being developed so at times its a necessary evil.
Monday
- 9:00 AM - Demo of the functionality added in the previous weeks iteration
- 9:30 AM - Retrospective
- 10:30 AM - Discuss this weeks stories
- 12:00 PM - Break for lunch
- 1:00 PM - Break down this weeks stories into tasks
- 3:00 PM - Start working on this weeks iterations
Tuesday-Thursday
- 9:00 AM-6:00 PM - Get shit done
Friday
- 9:00 AM-12:00 PM - Finish up the remaining work for the iteration
- 12:00 PM - Break for lunch
- 1:00 PM - 3:00 PM - Fix bugs, prepare for demo
- 3:00 PM-EOD - Research
After we get everything planned out for the week we get started on the tasks. From the time planning is complete until Friday morning we stay pretty focused on completing all the stories we've agreed to. We try to keep an eye on where we are throughout the week to ensure we're not in jeopardy of missing our commitments so we take a break every now and again to checkout our whiteboard and evaluate what work is remaining. We often set aside some time for design discussions and etudes as well during the week which we intermix throughout. On Friday we try and wrap everything up by noon, but...well...that rarely happens. If we do finish by noon we spend our afternoon fixing any bugs which have been uncovered and preparing for Monday's demo. In an ideal world we wouldn't have any bugs and would spend Friday afternoon doing minor polish and research. I'm still dreaming about that ideal world.
tags: agile, xp, agileplanning, iteration
This past week we started experimenting with a "long distance collaboration tool" called CardMeeting. Our team has a big ocean in between them which sometimes makes it difficult for everyone to stay on the same page. As I mentioned in How to prevent an agile face plant post, we use index cards for all of our planning. We have a big visible whiteboard that "holds" all of our cards. As we start a task we "brown it", and when we finish it we "green it". At times the card can go red as well which means its blocked due to something development can't control (such as needing clarification from business).
Our whiteboard has a lot of valuable information. At any given time anyone can walk over to the whiteboard and see where we're at. Unless of course they're across the ocean. To help keep our colleagues across the pond in the loop this past week we used CardMeeting to hold a duplicate "copy" of all of our cards. This allowed everyone on the project to have the latest and greatest information about where we were. For the development team it was a bit of a pain maintaining two copies of all the cards, but, being the great team that we are we managed.
In addition to using it to track the current iteration we've also started a couple of other card meetings which are being used to plan out future iterations. I'm not exactly sure how we'll use it going forward, and if it will be useful or not, but at the very least it's an interesting experiment.
tags: agile, agileplanning, taskbreakdown
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.
Successful agile projects require far more discipline than any other methodology I've ever used. Doing XP right, all the time, is very hard work.
— Brad Wilson
Are you doing Scrummerfall? Are you having success?
A couple days ago in my “What happens when an agile team falls flat on their face?” post I talked about how last week we failed to deliver on our commitments. In the comments of that post Howard asked “
Doing one week iterations can be tough. They leave very little room for error and place a lot of pressure on the development team to perform well each and every day. Throughout the course of our project we’ve tried a bunch of different things to help ensure we meet our commitments and know when things are going off course. While we’re no-where near perfect I think we do a very good job of identifying what needs to be done within our iterations as well as tracking our progress throughout the week.
At the beginning of each week business puts on a demo for others within our organization as well as a few select clients. This allows everyone to get a feel for what was done the previous week and provide feedback on what they like, and don’t like. Not meeting commitments for an iteration makes the process of giving the demo difficult since it is glaringly obvious to everyone involved when things weren’t quite finished. Fun times!
Following our iteration demo we go into a retrospective where we talk a lot about the previous iteration. We identify “memorable moments” and classify them into several categories (enjoyable, frustrating, puzzling, more of, less of, same of). As a result of this process we’re able to identify areas that we need to take correctionary action, as well as areas where we’ve improved. The retrospective is a vital part of our process as it ensures we don’t fall into a rut and struggle with the same issues over and over. In short it helps us be crazy-agile.
After completing our demo and retrospective we start talking about the stories we have planned for the next week. Par the course, business always has more stories then we can fit into a week. From a development perspective we need to ensure we can complete the stories we commit to. Since everyone is always going to want development to be able to go faster and complete more stories in a shorter time period its important that we don’t commit to too much (or too little). If nothing else we need to be consistent with our estimates and reliably deliver what we commit to.
To determine the number of stories that we should breakdown into tasks we look at our previous iteration velocity (aka “yesterday’s weather”). Using yesterday’s weather provides us with a starting point for our story breakdown. While it’s nowhere near perfect it helps get us started with the approximate number of story points we’ll be able to complete in the coming week.
Once we’ve identified the approximate number of story points we break each individual story into tasks. This has proven to be a critical part of our process. This past week during our retrospective we realized that we did a piss poor job during our task breakdown last week. We had about 15 task cards on the board for last weeks iteration while this week (which is just the completion of our previous weeks work) we have 40+ cards on the board. It goes without saying that we didn’t identify a lot of work that was required for the story.
After breaking down our stories into tasks we estimate each task. Over the past 12 weeks each member of the development team selected cards that they felt they could estimate and did so. To try something different this past week we estimated the tasks as a group using “poker estimation”. Once we have estimates on all of the tasks, as well as cards for all the non programming tasks that happen throughout the week we add everything up to see if everything will fit within the available time. More often than not we have more work than time available so business goes through the difficult process of prioritizing stories and figuring out which they’d like to fit into the iteration.
After the stories are selected by business we place the cards on our large magnetic whiteboard. Story cards go from top to bottom on the left hand side of the board and task cards go from left to right across the board. When we start a task we grab the card off the board and mark it as started with a brown marker and our initials. When a task is completed it is marked with a green marker and the amount of time spent on the task is placed on the front of the card below the original estimate.
By marking our cards with brown and green markers we’re able to see how we’re progressing through the iteration. If by Wednesday afternoon half the board isn’t green we start to determine if we’re going to need to cut tasks or stories from the iteration. As mentioned earlier this is where task breakdown proves to be key. If we’ve done a lousy job of breaking down our tasks we may get a bad read on how we’re progressing. If on the other hand we’ve done a good job of breaking down our tasks then the board gives us a perfect read on where we are with things.
Of course we never have and never will be able to identify every task at the beginning of the week. As new tasks are identified we create new cards with an original estimate of 0 and an Updated Estimate of whatever is appropriate. In previous iterations we would place the new tasks on the board along with the original tasks, however, for our current iteration we’ve decided to track our new task cards by putting a yellow line above the card on the board to ensure we don’t get a false sense of progress. If we’ve completed 25% of the cards on the board but all of those cards were new task cards that could be a sign of trouble.
As we get towards the end of the week we begin to get bug reports from QA. The bugs are placed on index cards and put up on the whiteboard with all the original tasks. The cards are typically separated into a “bugs” section on the whiteboard. “Bug” tasks are handled the same as normal task cards except for when they’re very small in which case they usually get combined into a single card for time tracking purposes.
We follow the above process which does a pretty good job of ensuring we don’t have weeks like last week. When we do have a bad week the process is there to ensure we do the things necessary to prevent it from happening again (hopefully). What do you do to help increase your likelihood for success?
Much has been written about the benefits of doing Agile software development. I won’t spew the various catch phrases and mantra’s that you’ll find across the web on agile, sufficient to say it has proven to work well for many people. With that said, there is a great number of developers who haven’t tried agile software development. Some because they just don’t buy into it, others because their organizations won’t let them, and others because they don’t know what it is. With all that’s been written about the benefits of Agile I think we often times forget to tell people that it isn’t the easiest thing in the world to do. While thats understandable given the fact that many people are trying to bring people to agile, not scare them away, I think we do run the risk of giving people a false sense of what is involved with doing agile development. It can be hard, it can be frustrating, and it can be painful.
This past week was one of those painful times. At the beginning of the week we went through our planning session and identified a single story that we were going to focus on for the week. While the story was quite large it wasn’t something that we didn’t think we could handle. As the week progressed we all felt we were making decent progress (we weren’t) and we all felt that we’d be able to meet our commitments (we didn’t). By Thursday afternoon many of us started to realize that we were in trouble. We’d have to put together a Herculean effort in order to finish everything that was left by Friday afternoon. As you might have guessed we didn’t make it, in fact we didn’t even come close. It sucked. To make matters worse we didn’t cut our loses on Friday afternoon. We all decided that we wanted to try and put some time in over the weekend to complete the story. After-all we had committed to finishing the story and we’ve done a pretty good job of meeting our commitments over the last several months. While we made an attempt it wasn’t nearly enough. It sucked…big time! To make matters worse today we broke down the remaining tasks required to complete the story and realized we had enough remaining work to fill up the entire next week. SH*T! How depressing.
When doing Agile software development your going to fall on your face from time to time, and it’s going to be painful. The Green bars might make you feel a little bit better but its still going to hurt. Lucky for you you’ll get to do it all over again “next week”.
Bob Martin recently addressed some criticism of Agilists and stated:
Agile is not a silver bullet. Agile is not THE ANSWER. But Agile techniques, and especially TDD, are very powerful techniques to get software written well, and to increase the level of professionalism in our industry.
Agile not a silver bullet? What? You’ve got to be kidding me. You mean it won’t solve all my problems and make my life easy? Unbelievable. I’ve had enough.
In case you didn’t know I taught Jim Shore everything he knows. So go read my thoughts on what constitutes “good design” via Jim’s latest article, “Quality With a Name”. Sam (who also learned everything he knows from me) has some nice reflections on Jim’s article as well.
This evening I came across an interesting post by Brian Marick. The following paragraph was of particular interest.
I'm not sure whether people on the Agile projects of today have it better or worse. On the one hand, ideas like the above are no longer so outr, so it's easier to find yourself in situations where you're allowed to indulge them. On the other hand, people's actions are much more visible, and they tend to be much more dedicated to meeting deadlines—deadlines that are always looming. I'm wondering these days whether I'm disenchanted with one-week iterations. I believe that the really experienced team can envision a better structure and move toward it in small, safe steps that add not much time to most every story. I'm not good enough to do that. I need time floundering around. To get things right, I need to be unafraid of taking markedly more time on a story than is needed to get it done with well-tested code that's not all that far from what I wish it were (but makes the effort to get there one story bigger and so one story less likely to be spent). It's tough to be unafraid when you're never more than four days from a deadline.
source: http://www.testing.com/cgi-bin/blog/2006/03/15#two-formative-experiences
I have the beginning of an opinion on this but its not fully formed so I’m going to let it settle before posting. What do you think?
Right now our planning days suck. They take a long time, they're filled with a ton of back and forth conversations, and a lot of unneeded questions. The good news is that we're getting better at it, the bad news is it still sucks.
In an effort to figure out ways to help us improve our estimating and planning I picked up Mike Cohn's
Agile Estimating and Planning book a couple weeks ago. I've recently started working my way through it and have been reviewing a lot of information on how agile teams estimate stories and plan their iterations.
A couple nights ago I read about Poker Estimation which goes something like this. Every member of the development team gets a series of cards. A total of 5 cards are given out each with a number on it. The numbers are 1, 2, 3, 5, and 8. After business describes the story everyone on the development team picks a card and shows the rest of the team. After reviewing everyone's "number" and evaluating whether or not the team is in agreement the process is continued (if necessary) or the team moves onto the next story. The focus of Poker Estimation is getting everyone on the team to quickly give an estimate. Rather then long drawn out discussions about all the intricit details of a story the team instead focuses on the overall "feel" for the story. Each developer gives the story a relative score by comparing it to other stories that they've either completed or estimated.
I'm not sure if it would help, or work, but it sounds like an interesting approach. I think by switching to Poker Estimation as well focusing on estimating in story points rather then ideal days we might be able to speed up our estimation and planning and make it suck less.
Usability is a very important aspect of building great software. No matter how great the backend of your software is if it doesn't look good and isn't usable users aren't going to
love it.
Good usability can help your users kick ass.
One of the problems that I've run into over and over again when working as part of agile teams is how usability fits into the process. Usability engineering doesn't jive with agile. Most usability "experts" that I've dealt with expect to have a nice long design phase where they can consult the usability wizards, create "intergalactic" visio documents, and consult customers. After a couple weeks they come out of their room with an extremely nice interface that has every "i" dotted and every "t" crossed.
Of course when working on an agile team you don't have weeks to design every aspect of the interface. You also don't have weeks to review all
Jacob Neilson's usability writings. What you do have is an hour or two to think up some ideas and sketch them on a sheet of paper. You also have the freedom to come back to the design and tweak it to get it closer to what your after. And perhaps most importantly you have the ability to get your interface in front of customers sooner rather then later.
Why aren't "typical usability folks" agile fanatics? Isn't the principles behind agile software development what they're after? Isn't continous delivery of their interface to customers and the chance to get real users feedback on the interface what they're after? Why aren't more usability folks
like the folks over at 37signals?
Jason from 37signals has a post today about product roadmaps and why they’re dangerous.
Our answer: Product roadmaps are dangerous. They close your eyes and often put you on the wrong path.
The question boils down to this, if a product roadmap is out of date the minute it hits the “printer” what value does it provide? It’s nothing more then a long list of items that seemed like a good idea at the time the roadmap was written. As time passes by the items that seemed important a couple months, weeks, or days ago may no longer be relevant. The beauty of Agile development is that it allows you to stay flexible, and allows you to change your roadmap at any moment. Since the roadmap isn’t etched in stone the team won’t feel bad ditching it for what’s most valuable now. An important note to make is that while a roadmap may not be necessary a vision is absolutely required.
Brian pointed to an experience report from last year's agile conference that a number of people at our office have talked about since we started pairing a couple months ago. One of the points that Brian highlighted was:
- After experimenting with pairing time periods from 30 minutes to a full week before swapping pairs, 90 minutes proved to be the most productive.
My question is this, how is it possible to switch pairs every 90 minutes and still stay productive? We try to switch every 4 hours or so but we often end up going longer because people are about to finish something and in order to get a new person up to speed we'd have to spend a bunch of time reviewing what was already done. Hrm, perhaps that is point. If you spend too much time working on a single thing with a pair it takes too long to get someone else up to speed. If, however, you only spend 90 minutes there is much less to get the pair up to speed on. The other advantage is that if you force yourself to switch every 90 minutes there is less likelihood of a pair getting stuck on something since a fresh set of eyes will roll into the pair. Don't you love when you start a post with one intention but end up with something completely different?