Posts Tagged ‘Team’

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.

Honesty is not only the best policy; in Scrum, it is the ONLY policy. There is a pseudo-phrase that is used in Scrum training to describe the appearance of Impediments: they ‘bubble up”. This only happens when Team members are honest — with themselves, with each other, with their ScrumMaster. The ScrumMaster is a facilitator and a communicator. It is the job of a well-trained and courageous SM to prod, poke, investigate, cajole, bribe, berate, beg, reward, entice, and otherwise convince both the Team as a unit and individual members to communicate impediments — no matter how large or small they may seem — by “bubbling them up” to the surface. The brave ScrumMaster then takes the Impediments and communicates them to the rest of the Team, the Product Owner; if necessary, the Business Owner, and possibly even the Stakeholders (read: Clients). Good ScrumMasters are always in jeopardy of having their heads ripped off because many times they are the bearers of bad news. Agility is also helpful in dodging thrown staplers, monitors, and other heavy, close-at-hand office items.

Honesty leads to Agility in this manner: the communication should be like greased lightning. Every employee at Achieve has seen me absorb some information and immediately turn around and start communicating it to someone else. Whether this is by walking into someone’s office, picking up the phone, crafting an IM or an e-mail, creating or refining an Unfuddle ticket, or driving between offices, you have witnessed the lengths I go to insure that communication is happening quickly, effectively, and honestly. Scrum — and I would suspect most Agile methodologies — completely falls apart if the channels to move information slow down or become clogged. Lack of transparency to the Client is the bane of Waterfall, where you work in a bubble on a project for a segment of time only to find out at delivery that this is no longer what the end user wants. It is better to confront a known Impediment than to pretend that there isn’t one or that there is nothing that you can do about it; ignorance is NOT bliss; it is cowardice.

The central strength of Scrum is that everyone is in the loop all of the time. Developers should raise impediments as they appear, not after they have been trying to solve it for an hour. Lead Developers should be ready to (and encouraged to) step in to team program around a thorny issue — after they tell their ScrumMaster that something has come to their attention in this vein. ScrumMasters should be central communication hubs that are constantly talking to the Team and the Product Owner to keep everyone appraised of progress and Impediments, all the while shielding their Team from outside interference. Product Owners should be speaking with their Clients daily in order to provide their feedback to the Team and to tell them of both good news and bad. This is colloquially known in Scrum as “swarming” and it is fantastic when it happens. Transparency may lead to Agility, but transparency comes from being honest.

[snip]

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.

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.