Posts Tagged ‘Sprint’

Something about “being Agile” tends to make people think that productivity magically appears when you install Scrum as if it was some sort of speed boosting software optimization. This is not the case; it takes preparation, dedication to the methodology, and above all, discipline. Daily Scrums are a good case in point; many times I have seen participants show up to this critical forum without being prepared to transfer knowledge. The traditional Daily Scrum asks three questions to try to evoke the necessary intel from the Sprint participants:

  1. What did you accomplish yesterday?
  2. What do you plan on accomplishing today?
  3. Are you impeded?

There are two issues that arise from the Daily Scrum formula that I have encountered: one, the answers to these questions from each Team member don’t always get to the best information that needs to be shared; and two, Team members are not prepared to answer these questions with valuable 411. Both devalue the Scrum, and with a 15 minute timebox, it is critical to impart focused, specific information as fast as is productive to the Team. With this in mind, here are a few suggestions to keep Daily Scrums from becoming rote meetings that developers and other participants show up at, roll their eyes when they’re asked the same old questions, and — as one developer I worked with threatened — produce a simple audio file to play when asked the questions above.

Ask the right questions to get valuable answers:
Every project is different, and the questions asked of the Team should be designed to insure that knowledge is transferring properly between the Team members. This does not mean that you abandon the yesterday / today / blocked formula; rather, it means that the ScrumMaster should know enough about each Team members’ commitments to be able to help them with getting to the good stuff. The key here is to reinforce that the Team succeeds or fails by the estimation, communication, and hard work of the individuals that comprise that Team, as Clinton Keith adroitly notes on his discussion of Daily Scrums. The questions that are asked of the Team are not designed to be a simple formula so that you can repeat the same valueless information; that is why I prefer to use the term “accomplished” rather than “do”; this engages the Team member in a different way — it asks him or her to report to their Team members if they met their commitment from yesterday’s Daily Scrum. Keith makes a good point that the key to the first two questions is commitment: if a Team member commits to finishing feature x and does not, this is an impediment that is telling you a lot about the progress of the Sprint.

Be a Boy or Girl Scout; come prepared to the Daily Scrum:
Because Daily Scrums are usually timeboxed to 15 minutes, a lot of participants think they can just show up and answer the three questions and then get back to work. If this is what is happening in your Daily Scrums, you are in danger of having these crucial meetings become valueless and might as well let people play audio files to report their status. I found quite a bit of value when I insisted that Team members bring the ticket numbers for the Tasks that they were working on from whatever tracking system was in place was enough to make ’em prepare just a little bit before showing up to the Daily Scrum. This also had the side benefit that they would bring a pen and a piece of paper, which would at least have the materials present to make a note in case (shocking!) that something came up in the meeting that they were not expecting, such as “have a conversation with so-and-so immediately after this meeting to help them with impediment z”. Stacia Broderick has a wonderful phrase for a common symptom of Daily Scrum fatigue: DSW or Daily Standup Withdrawal. She prepares herself before each meeting; I don’t see why the same, short, focusing process shouldn’t be encouraged for each participant.

Handle diverging conversations immediately:
As a CSM, I have always found that the most memorable part of teaching Scrum to people is using squeaky toys to prevent Daily Scrums (or other meetings, for that matter) spiraling out of control into technical discussions, impediment removal, or other unfocused diatribes. Scrum is full of animals, starting with Jeff Sutherland’s Pigs and Chickens, but I can still remember the rubber rats from my CSM training with Dan Rawsthorne when he handed them out and thinking “what the hell are these for?” Since then I have used a front desk bell, a squeaky dog bone, and even threatened an air horn with a particularly garrulous group. The squeaky toy almost becomes like the conch shell in Lord of the Flies with some groups; even reaching for the talisman has an instantaneous effect on someone who is off on a soliloquy once they know what it means. This does not mean that you should be a heavy-handed ScrumMaster; on the contrary, it is the sign of a good Daily Scrum when a Team diverges to try to solve a problem. In this case, I take a page from XP and shut it down by providing a concrete way forward, such as “ok, you three obviously need to have an offline discussion about this; how about right after this meeting for 15 minutes and somebody be responsible for communicating the resolution?” This prevents the squeaky toy from becoming something to be feared and restores it to what it is for: focusing the Daily Scrum.

Provide concrete output from the Daily Scrum:
Whether it is on stickies, a quick set of notes, or directly updating the community Scrum Board, make sure that there are tangible results coming out of your Daily Scrums. The most important thing is definitely in the heads of the Team members, but it is highly valuable to have some sort of record of what went on yesterday today. This is a prime way to ask those extra questions suggested at the top of this list if necessary — review what the commitments were from yesterday and insure that each Team member is answering whether or not they accomplished what they set out to get done. These notes also become a key starting point for Sprint Retrospectives, when I have found there is naturally a lot of brain fade after a successful delivery. Like most everything else in Scrum, find what works for you; I have provided concrete output from Daily Scrums a variety of ways, but it is another Scrum operation that can be shifted from person to person, or combined with the Scout rule above — if Team members know that there is concrete output from the Daily Scrum, they are more likely to come prepared. These types of notes, especially in an electronic format such as a shared document or an e-mail update, also provide the added benefit of being able to communicate Sprint status on a daily basis to other interested parties, such as business owners and / or stakeholders, if necessary.

As usual, these are my observations from practicing Scrum at several different organizations, and I would be interested in any feedback about how you focus your Daily Scrums to prevent DSW, insure effective knowledge transfer, and make your Daily Scrums something that people look forward to because they provide help and value to the contribution of the Team to the Sprint.

The popularity of Agile project management has come with a lot of people saying that they “do Scrum” or “we Scrum” or “we be Sprinting” or any other combination of buzzword + us. This is known in the community as doing “Scrum but” because it inherently identifies that agility has not been fully embraced. This leads to three things:

  1. Poor results
  2. Frustration
  3. Anger at Scrum / Agile methodologies

Introducing Agile methodologies into a company is a subject for future blog posts, and won’t be covered here. Suffice it to say that without understanding and embracing, at least for the duration of a medium-sized project, an Agile tech completely, you’re going to be disappointed with the results. “Scrum but” begets butt results — just remember that.

I could go on and on with the metaphors that might explain how doing “Scrum but” is a terrible idea (it’s like thinking one or more tires on a car are optional to go on a road trip; it’s like trying to grill steaks with no propane; it’s like trying to land a job with no resume) — it all rolls up to three issues:

  1. Doing Scrum because it is cool / a buzzword / makes you feel cutting edge
  2. Believing that Scrum is a la carte rather than a whole methodology
  3. Unwillingness to let go of old Waterfall habits

Let’s discuss these three points.

One: Scrum / XP / Lean / Agile may sound cool — and done right, providing clean, measurable results, it is — but that is not the point. The point of Scrum is to force participants to think outside the box and provide continuous feedback on specific deliveries to insure that nobody is working in a vaccuum. The agile part of Scrum is reducing the battleship to a PT boat; it is able to turn on a dime rather than lumber around to a new heading. I believe that some of the attraction of Scrum is due to the flexibility of the methodology; however, when Teams start skipping Scrum Retrospectives because they have to rush to the next Sprint, or the Sprint Stories are “close enough” or “placeholders” or “XP Style” (a note to have a conversation about this later on), or there are other shortcuts taken in the process, you are accumulating Tech Debt which is guaranteed to bite you in the ass like a rogue wave (or a rogue VP). I am not arguing against the coolness of Scrum or any other Agile PM; again, they ARE cool, but it’s not in the name, it’s in the results of using Scrum effectively, and that means the whole enchilada.

Two: Scrum is not a buffet line, where you take a few Sprint sausages, some scrambled egg Stories, and a tall glass of Tasks, passing on the perceived parsley of a complete Planning Scrum and the dubious gridwork of well-formed Retrospective waffles. If you are going to try this approach, you might as well skip the plate while you are at it. There is a reason that CSMs are certified: it’s because Scrum is a methodology, and although Scrum purists will dislike that I point this out, there is a 1-2-3-4 to Scrum. It works best if the tech is embraced fully, even if you don’t understand why right off of the bat. Reusing the food metaphor, eat your veggies; it makes for a properly balanced diet. Try it, you might like it. Three pain points that I have found while implementing Scrum into businesses are the following:

  1. Planning Scrums are not prepared for (Stories ready, Backlog prioritized, etc.)
  2. Sprint Retrospectives are skipped (gotta get going on the next Sprint — no time!)
  3. Daily Scrums are not transferring knowledge properly (usually not asking the right questions)

A list of things to do is not a Backlog; an ad hoc 5 minute “how’d that Sprint go?” is not a Retrospective; “what’d you do yesterday? how bout today? are you blocked?” is not a Daily Scrum. Feel free to try to fool yourself and your organization that this is adding value, but see the first ordered list in this post for the results.

Three: As a veteran PM, I have ridden the inner tube of Waterfall-style project management, and it really isn’t all that bad if you are working for a huge company with lots of specialists and compartments, have all the time in the world to complete a project, and you are employed by the government. Even software development with ever-changing requirements can be successful with the right amount of documentation, change requests, and a battery of people willing to trade speed for bulk; i.e., the battleship. I would, however, like to point out that the dreadnought became extinct in World War II, when the strategic air power of carrier-based fighters and bombers sunk the Yamato in port in ’45. It couldn’t hide from a swarm of agile aircraft. The introduction of Scrum / Agile into a business is always fraught with the dangers of incorporating Waterfall-style PM into the process. “The Tech Spec IS the Backlog” is one I have heard countless times, and this leads to skipping the work of creating the needed pieces to properly Sprint. “These meetings are a waste of time; get back to coding!” is another one, typically from Business Owners who are trying to buffet their way to agility, usually because Waterfall — “we’re in development phase!” — is how they understand the surface of the project and because saying that the company is “Agile” or “does Scrum” is some sort of competitive advantage jargon. One of the reasons that Scrum is flexible is to be able to USE Waterfall-style documents to create solid, prioritized, accurate Backlogs, well-formed, spot-on Stories with full doneness requirements, and to provide developers with all the information that they need to Task out the Sprint to a high degree of initial accuracy, which provides a framework to embrace the inevitable changes that will come down the pipeline.

Overall, Scrum (and other Agile methodologies) suffer from the coolness factor, the buffet line, and the grandfathering-in of Waterfall thinking. Observation of anything along these three lines should be cause to stop, drop, and re-evaluate. Anytime I hear “we do Scrum but…” I always inquire if the organization has done Scrum with no But. That is the only way to understand how the pure methodology works for you, and from that foundation comes tuning and refinement, THROUGH Scrum, not around it.

At the 2007 Achieve Summit, Gary Markowitz presented The Achieve Approach. This is — from my point of view as a ScrumMaster — essentially a scalable series of questions that needs to be asked and acted upon for each and every thing that an Achieve Team does, no matter how large or small the chore is. To quote Chuck D from Public Enemy, “here come the drums.”

The Achieve Approach consists of four items:

  1. Discover
  2. Architect
  3. Develop
  4. Deploy (or Launch)

If you look at these items as a series of questions that are to be asked of every Task, Story, Project, Sprint, or other work that we do at Achieve, we have a framework to insure that the Team is thinking through a problem, rather than rushing to Development and missing critical bits of information that later crop up as impediments. Even though it may seem — at first blush — a little ridiculous to ask these questions for every Task that a Team creates for a Product Owner’s Story, the scalability of the Achieve Approach will make this a valuable exercise.

Scalability means that a routine (in this case, examining the four parts of the Achieve Approach) is suited for both large and small applications, and that it is nimble enough to apply equally in micro- and macro-environments. The Approach seems to be built for a Project: these four steps are “phases” or “stages” that are dealt with in order to be able to produce the needed information to move to the next stage or phase. This type of approach will be derided by hard-core Scrum practitioners as “waterfall methodology.” Just the fact that you have to complete Discovery before you move on to Architecture sends CSMs into a foaming-at-the-mouth frenzy. “This is not Agile! Waterfall is for lumbering oafs! We don’t need no stinking Discovery!” Although there is some concrete value in having a phased approach, Scrum itself loathes this sort of Six Sigma PM thinking because of the perceived waste of time that comes from doing classical due diligence with rigid phases.

That is not what the Achieve Approach is about. The scalability of the Approach is what keeps it Agile. At a Project level, there may be specific phases that Achieve walks through in order to insure that when we hit the Development phase, we have all of the information needed to successfully Develop. At the Scrum level, it is much more of an Agile process where we simply ask the four questions on a per-Story or per-Task basis in order to bubble up impediments before they interrupt the Sprint. Ingraining these four steps into our everyday thinking should help us ask the questions that need to be asked in order to provide accurate estimates, the correct number of tasks, and bite-sized chunks of work to insure that we can deliver quality and timely releases to our Product Owners within the timebox of the Sprint.

Here’s a real-world example of the Achieve Approach working in a Sprint in question format:

STORY: As a [client developer] I want to be able to [easily theme the four verticals on my website] in order to [implement the new Rotato without making it look like it is a new part of the website]

REQUIREMENTS: [simple functional specifications and use test cases as provided by the Product Owner] — this is to be addressed in a later Art of Scrum

TASK IT OUT: Normally, the Team would start throwing out sticky notes with tasks on them in order to try to meet all of the requirements that were laid out by the Product Owner within the Story; here is where, as a ScrumMaster, I am going to ask for the Achieve Approach to be considered.

  • Scrum it up and bounce out all of the Tasks needed to complete the Story
  • Arrange the Tasks in the order that is needed to complete the Story
  • Keep in mind the Team’s resources, and if Tasks can be done in parallel — this is important for Agility
  • Have the Team consider the four elements of the Achieve Approach: even if it takes 15 minutes extra per phase (mostly Discovery and Architecture I am guessing) it is massively important to think these things through at the Planning Scrum so that estimates are accurate and that the Team does not incur Technological Debt
  • Perhaps each Task can be labeled with the Achieve Approach steps in order to insure none are missed

START SPRINTING: If an impediment occurs, again run through the four elements and see where the impediment was missed, if applicable

DELIVER THE GOODS: Make your Product Owner feel like a Hero by giving them a Product that they cannot wait to demo to their Stakeholders

I would like to see Achieve be able to understand Projects, Stories, and Tasks — especially with their resulting impediments — categorized into Discovery, Architecture, Development, and Deployment so that we could understand better where additional work is being generated by not thoroughly planning ahead of time. Although Scrum is designed to deal quickly with problems as they arise, I still feel that the best way to avoid problems is to think them through in the first place. Perhaps we as a company are not doing enough Discovery. It may be that we are arrogantly trying to Architect on the fly. It could be a common misconception that Launching (or Deploying) is a simple push-button process.

This is a rather long blog (hooray for Nyquil), but the upshot is this: learn it, love it, repeat it: Discover, Architect, Develop, Deploy. This mantra will become a saving grace as we find it reminding us of the path to quality code and products.

Here is the very basics of Scrum methodology; we will start simple for the new year:

* Make a list of the things you need to do (Product Backlog)
* Get someone to decide what’s most important and put the list in priority order (Product Owner)
* Set a fixed deadline in the foreseeable future (Sprint Duration)
* Estimate how much you’ll be able to complete by the deadline (Planning Scrum)
* Work through the list in priority order, completing each thing before moving on to the next (Sprint Itself)
* Check your list every day to see how you’re doing (Daily Scrum)
* Even if you haven’t completed everything on the list, release the software when the time is up, in order to realize some benefits
* Review how it went to see if there’s anything you would do differently in future (Sprint Retrospective)
* Repeat (Iterate)

Sometimes, the jargon gets in the way.

Kelly Waters has a great blog called All About Agile that I have recently discovered that has good, no-nonsense Scrum articles, Here are the 10 Points of Success for Agile Development:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight and visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative and cooperative approach between all stakeholders is essential

Keeping in the spirit of “no jargon”, just contemplate the meaning of the above list. If you would like to read more, check out the full article here.

Once upon a time, there was a project that was supposed to be done at the end of the month. There was a full Product Backlog, some of which was well defined into twelve Stories, and an enthusiastic Team ready to tackle the four week-long Sprints it was expected to take to finish the project. Confidence was high, and the predicted due date seemed to be no problem. Flip the hourglass with the sands of time; enter: Reality.

Once upon another time, a college student was given a credit card. Charge all you want and pay it off at the end of the month and it was like getting an instant, interest-free loan. Payday is the 30th (read: end of the month), so let’s get some shoes.Again, enter Reality.

Both of these scenarios, when adding the cosmic constant called Reality, are the beginning of accruing debt. In Scrum terms, technological debt is that work that is NOT done when trying to hit a predicted due date once reality enters the picture and starts to pump chaos into the well-sculpted predictions made at the beginning of the project. Another way to look at technological debt is to think of it as credit card interest. If the Team can hit the predicted deadline dead on (pun intended), no debt accrues. But any deviation beyond the due date creates a situation where, when normal business pressures come to bear, compound interest starts to make things interesting.

Let’s expand my first example. Sprint week one: an Impediment arises that chews up four hours of productive time during the Sprint, causing the third of three Stories to not be completed properly. Planning Scrum for week two: this issue bubbles up to the surface and is taken into account by using the second week Sprint to finish the work not completed on the first week’s third story. This causes the Team to lose Velocity and only complete two stories in the second week. The Team now completes the second Sprint, and has a total of five Stories complete in a quality manner — code is solid, all testing is done, and the work is up to par. Now, halfway through the project, this is noted, but optimism is still high, and somewhere in the next two Sprints, this extra Story needs to get done on top of the remaining six . This is not yet technological debt, but it should be cause for concern for the Product Owner, the ScrumMaster, and the Team. Interest is looming.

As the two final Sprints are planned and executed, somebody comes up with a fabulous idea of a shortcut to keep the project on track to be delivered on the predicted date. These ideas are usually along the lines of not completing due diligence on testing, outputting hacked code, skipping code reviews or full QA, or otherwise not doing high quality work. Project is delivered, client and Product Owner look like heroes, and everyone is happy, right? Wrong.

Technological debt — or interest — exists in the product itself. The entire Team — Product Owner, ScrumMaster, and Team Members, all know that within the delivery lurks something that was not up to par, and may come back to haunt them later. Extrapolating my second example — including the introduction of reality — at the end of the month, it is more important to pay all of your rent and only part of the credit card bill, so your $300 pair of shoes only gets $250 dumped on the bill. Waiting until the end of the next month to pay for your new clogs will actually cost you $75 more, not the $50 that it would have taken had you paid the whole thing promptly before the interest rate started getting that rear-naked choke hooked in. Technological debt works the same way. Your shoes just cost you $325. Next month, as the compounding really gets rolling, they will be a $350 pair of shoes, all the while losing value while you are wearing them to your Scrums every day.

Back to example one: client is so happy with the delivered product, they want it installed on all three of their websites, and expects that it should be an easy chore. We delivered them a quality, scalable, perfectly-factored product, right? Unless the technological debt is addressed immediately in the new estimates — probably a whole week’s worth of Sprint on top of this new client request — the problem is not just going to sit there and be a static problem value; it is going to gain interest. As the product is scaled, built upon, sold as-is to other clients, this debt is accruing interest. As long as this debt is ignored, it will continue to compound and cause problems in the future, especially in terms of codebase. Technological debt really gets good when the programmer who put the hack into code in the first place either is no longer with the Team or doesn’t remember what was done to create the problem in the first place. Time is the factor that is compounding — in this case, to find the problem and fix it. The sharpest pain in the process of catching up on technological debt is that there is nothing that can be sold to the client as an upgrade or a new feature; this was supposed to be done in the name of Quality last month…or six months ago,,,or whoever the dude was that built this code in the first place.

One of the central concepts of Scrum is honesty. Honesty within the Team is crucial, and in the case of this example of technological debt should have been clear communication to the Product Owner that due to the Impediment, the project needed another week to be delivered with the quality that the client deserved. If the client could not wait one more week for a quality product, then the Team has to get a Business Owner involved — usually to OK overtime, working lunches, and otherwise reducing other responsibilities in order to retrieve the additional time to do it once and do it right. In the case of the shoes, you would have saved your money and purchased them the 15th of the next month when you could drop $300 in cash and not absorbed any debt in the first place.

For a good graph-and-chart-laced article on the issue of tech debt, check out Technical Debt and Design Death by Kane Mar.

There are three terms to describe the way light shines on an object: Transparent, Translucent, and Opaque. Transparent means that you can see right through it; translucent means that light shines through it, and opaqueness is the quality of blocking all light. Although you may think that vocabulary lessons are not on topic for this forum, I am a fan of the Definitions section of this collective knowledge repository, and point out this fact:

Without a common language it is difficult to communicate.

Transparency is an Agile quality. Although there are several definitions that might apply from the link above, transparency is a communication art. One of the foundations of Scrum is honesty, and honesty leads to transparency for both internal team members and external clients. Being transparent means that all of the work done on a Sprint is visible to those participating in the process. This means document — lightly — as you go, identify problems — impediments — as they arise, ask for clarification — from your Team, your Product Owner, your ScrumMaster — as the Sprint happens.

Opacity occurs when Team members feel like they cannot lift their eyes from the screen and their hands from the keys. If the ScrumMaster or Product Owner only has a foggy idea of what the Team is doing, this is translucency. Transparency is honest communication all the way out to the Stakeholders — that means the client. Even if it is bad news, it is Agile bad news, which means that it is coming now rather than weeks or months down the road. Whenever you can save weeks and months, you know you are getting more Agile.

Mark Levison writes a great blog-style site out at Notes from a Tool User. Aside from being a proponent of Team Programming, Mark simply states that “Transparency builds Trust”. I think that this is a good sound byte to remember. Transparency = Honesty = Trust.

Originally published: Tuesday, 12/11/2007

Really good Product Owners always start Planning Scrums with something along the lines of “Once upon a time…” The reason behind this is that one of the least understood but most powerful concepts in Scrum methodology (along with the Squeaky Toy) is the Story. A Story, essentially, is a short description of the usefulness of a feature or product, including vital information such as who is going to use it, why they want it, and what it is supposed to do.

From this trite-sounding invention, you can deduce what is important to who in the Scrum process, the business value, the importance in the grand scheme of the entire project, potential use / test cases, and a whole host of other information within the bounds of a properly-formatted sticky note. Product Owners are the conduit to the customer, or Stakeholders, and as such, they are responsible for translating important pieces of the Product Backlog into Stories. Stories are a bite-sized translation of a feature or client request into terms that the Team can understand, cut up into Tasks, and agree to deliver at the end of the Sprint.

According to Mike Cohn, a properly formatted story is thus:

"As a <some role> I want <something> so that <some value / justification>"

This deceptively simple formula drives Product Owners crazy, because it forces them to get rid of all of the ballyhoo and explain the basic purpose of this feature to the Team. In response, the Team is able to meet the Product Owner halfway and start from the bottom to build a feature or product that the client really wants by describing a series of Tasks that will reach this goal — demonstrable and working — by the end of the Sprint.

Once the Story is told, the Product Owner, the ScrumMaster, and the Team complete the Story by negotiating an Agreement. The Story is usually the top half of the sticky note; the Agreement is the bottom half. In order for the Team to be successful, it must meet the requirements set forth in the Agreement. Agreements are usually a series of bullet points that describe what should be demonstrable to the client by the end of the Sprint.

To put this into perspective, here is a Story with an Agreement from Achieve’s history. Note that Achieve has exercised the First Rule of Scrum: if the rules don’t work for you, throw them out.

STORY:
“This Story allows [the site administrator] to deploy quiz question creation to site users while guiding them to provide these questions in the right format.”

AGREEMENT:
* Exactly four answer boxes, all required
* No title field for users
* No feedback per question
* Auto-generate title field based on taxonomy, question field, and an incremental random number (to prevent repeats in any possible case)
* administrative controls to enable / disable functionality
* show mockups for the way this feature would look to a user

With a Story defined with an Agreement, as long as the Sprint is a reasonable length of time for the Team to perform this work without impediments, there will be a happy ending!