Posts Tagged ‘Scrum’

Communication is Broken

Posted: October 20, 2011 in Rant, Writing
Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
4
Communication is Leadership: everyone row in the same direction

Communication is Leadership: everyone row in the same direction

INTRODUCTION

Communication is the bedrock of the human condition: there is perhaps no greater accomplishment of homo sapiens than being able to share an idea, a concept, or an opinion with a fellow ape. In the 21st century, there are more ways to share your own unique perspective on the world to the world than ever before in the blink-of-a-galactic-eye that we upjumped animals call human history than ever before, yet I keep running into the same old problem: people don’t know how to communicate. I am not talking about using the right emoticons in a text message, or being unable to get their video running on their GoToMeeting videoteleconference, or attaching a file or photo to an e-mail message. I am talking about the raw ability of people to actually communicate: that is, to exchange information effectively. I have recently run into two situations where this lack of what I consider to be a fundamental skill–like walking upright and breathing regularly–has driven me to take definitive, tie-cutting, self-preservationist action.

SITUATION ONE: Read My Mind

As a self-proclaimed King of the Nerds, a hard-working employee, a small business owner, and a 15 year IT veteran, I have a constant stream of requests coming in to assist people with an alphabet soup of apps, platforms, strategies, tech help, troubleshooting, and plain old good advice from a geek. Most of these pleas for assistance I handle with my inimitable blend of slightly-pedantic schoolteacher and humorous, patient, step 1-2-3 teach-a-man-to-fish wizardry; I like to see people do great things with their ideas, and I understand how frustrating a simple tech impediment can be for someone who just wants it to work. Occasionally I will run into a situation where communication breaks down because someone is making the assumption that you can read their mind. And they will get very frustrated because you cannot read their mind. This also breeds the Catch-22 situation of either requesting additional clarification–thus angering them further–or making your best guess–and then running afoul of not having delivered what was in their mind. This is maddening, and I am certain that most everyone has run into this situation before.

Spock IS able to read minds; however he has to lay his hands on you to do so

Spock IS able to read minds; however he has to lay his hands on you to do so

Case in point: while assisting a small company with the creation of their corporate website, I was bluntly accused of not following the proper policies and procedures. Since I had never seen these policies and procedures, I asked for a copy of said P&P, and none were produced. Instead, a stream of angry invective about “common sense” and a slew of unrelated issues were produced with how unhappy this company was with my performance. Seeking to understand where the communication had broken down, I continued to probe the issue by pointing out the obvious disconnect: I cannot follow P&P if I don’t know what the P&P are. And lo! the client was enraged further. For the first time in my life, I was sincerely agog at the wrath of the client. There was only one option: I calmly handed off all of my projects and responsibilities to other team members and quit working with that company.

From my training and experience with teaching both high school and college classes, I am fond of reminding people that “the only dumb question is the one that goes unasked”. Without bending the thrust of this idea through ridiculous situation-based specifics, I strongly believe that anyone who is asking a question is trying to communicate effectively. You have to extend this basic credit to a person who wants clarification. It should also cause you to listen to the question, both the content and the context; and this simple act of communication–between a someone asking a question and someone responding with information–is literally how the world works. No amount of technology, power, or skill is going to change this most basic of things on a fundamental level. It just boggles my mind that some people are so caught up in themselves that they make no attempt to listen. Willingly or unwillingly, they are breaking the time-honored chain of communication from one individual to another. The only recourse is to join them in the obstruction: stop attempting to communicate and effectively, give up.

"He said 'this one's for Becky', as he watched the last one fall..."

"He said 'this one's for Becky', as he watched the last one fall..."

Choosing to walk away–or as Kenny Rogers puts it in “Coward of the County”, turn the other cheek–is incredibly difficult for me to do. It is like choosing to fail, and I avoid making that choice at all costs; there HAS to be a way to compromise, remove this impediment, or find a win-win situation. On the other hand, I really don’t like to choose to fight, but in the most reductionist, simple terms: communication comes down to fight-or-flight, and you gain more information by fighting to communicate than by fleeing and guessing.

And, if you really want to talk about policies and procedures, it is now my policy to not do any more pro bono IT work or consulting. It is very much why lawyers are so careful not to hand out advice willy-nilly; it can be construed as an attorney-client relationship, and now you are on the hook to see the issue through in one way or another. This is colloquially called the Cocktail Party Client phenomenon [PDF, 123kb]. There was also a phenomenal Reddit thread (that of course I can’t find) from a lawyer walking all the way through how much work one “free” piece of advice from a lawyer could cause–and this was via experience, not theory–including the fact that the lawyer had to prove in court that there was no attorney-client relationship (thus NOT representing the “client’s” best interests) and a running total of dollars lost versus a paying client who would benefit from all the skill and knowledge of the attorney in a proper relationship. Doctors also can’t–or shouldn’t–give free information for approximately the same reasons. I hate to be the bearer of bad news, but IT people: you must protect yourself in the same way by getting an agreement in place or by resisting the urge to fix things for free. Although this goes against every fiber of my being to help, teach, assist, educate, and un-frustrate people, the same technologies that enable people to communicate often fail to do so effectively.

My final thought on example #1: Read My Mind: if I had a do-over with this same client, I am pretty damn certain that I would handle it exactly the same way as I did the first time. NOBODY reads minds, and when you explain to someone that “I cannot read your mind” if their response is “everyone else does; why can’t you?” then it is time to end that relationship post-haste. It is unreasonable to expect someone to be a Jedi mind-reader (presumably like everyone else), and unconscionable to excoriate someone who “can’t”.

SITUATION TWO: Occupy San Diego and the Threat of Legal Action

A sympathetic OWS protester in Munich (AP Photo/Joerg Koch)

A sympathetic OWS protester in Munich (AP Photo/Joerg Koch)

It is no secret that I am fascinated by the Occupy Wall Street phenomenon that is sweeping the globe. Although a lot of assumptions can be made about my politics, civics, and sympathies by this fact, I have carefully considered where I stand on the #OWS issue, and I can assure you that you don’t have any concept what my actual position is. The corollary to “I can’t read your mind” is, conveniently, “you can’t read mine”. In a nutshell, I am enthralled with the real-time adventures of the American people voicing their discontent by exercising their Constitutional rights to be n

oticed, seen, and heard. Some people describe this as “democracy in action” — I think that it is certainly “communication in action”, and as such, deserves paying attention to and forming your own opinion about so that you can participate in the melee in one way, shape, or form, whether it is on the ground at an #OccupyEverything event, around the watercooler at your job (if you have one), or heated and valuable Facebook wall discussions. Trust me: I have actively participated in all three in the last 168 hours.

I have been following the OWS movement since early September, when I first got wind of it. I am very interested in what sort of reactions and results happen because of regular people deciding to come together and test the exercise of their rights in America, especially in this economic depression, this political landscape, and this unprecedented age of information. The Internet has transformed communication at its core: it really can only be compared to the invention of movable type and the printing press; perhaps even the written word and language itself; i.e., communication. Much has been said about the role of Facebook, YouTube, Twitter, and other new media in communicating real-time information, as evidenced by the “Arab Spring” and the riots in the UK, but now we see this come to the American heartland. What are we Americans–who invented a lot of this tech–going to do with it?

OccupySD protesters being arrested for refusing to take down tents at the San Diego Civic Center (AP Photo/ Gregory Bull)

OccupySD protesters being arrested for refusing to take down tents at the San Diego Civic Center (AP Photo/ Gregory Bull)

So when the OWS movement came to San Diego, I figured “think globally; act locally” and started trawling the websites, Facebook pages, Twitter and Tumblr accounts, LiveStreams, and other Internet-based intel that were available to get some local boots-on-the-ground information as to how this event was happening in real-time. The experience was eye-opening, to say the least: not only did it take an inordinate amount of browser windows to keep track of all of the latest breaking rumor, news, announcements, and innuendo, everyone participating had the best of intentions, yet were engaged in an organic exercise of “telephone”. Because all of this chaos was happening within 30 blocks of where I live in San Diego, I was enthralled with the way that my sleuthing and juggling of two different browsers packed with 20+ tabs of information would see the same event ripple out with dozens of voices and opinions, none of which quite aligned. It was an awesome firehose of information, and yet I couldn’t get over the fact that if this communication was coordinated just a little bit better it would make all the difference in the world between having a geek like me able to piece together all of the relevent info from a dozen technologies and a regular person being up to speed on the latest by checking a Facebook page.

Violating my pro bonorule from the previous example, I decided to jump in as a volunteer on the LiveStream chats and lend my skills to squash rumors and promote advantageous information sharing across these social networks, calling out my sources with links and pleading for representation on Twitter, Facebook, etc. Meanwhile, let the opinionated move the chat room along with discussion and conversation. It was a powerful, organic solution that included either loops of relevant video production and occasional live events brought to you by a number of dedicated personnel including video producers, tech people, anonymous donations of equipment, and most importantly, several dedicated LiveStream anchor personalities. It was the height of professionalism when I could depend on the LiveStream coming up and someone like Kym or Kali was dependably giving us on the receiving end of the latest on-the-ground information backed up with a full audio-video stream.

Protesters marching on October 7, 2011 at the start of the Occupy San Diego movement (Nelson C. Cepeda)

Protesters marching on October 7, 2011 at the start of the Occupy San Diego movement (Nelson C. Cepeda)

I was so impressed, I decided to get directly involved. I have been to #OccupySD locations dozens of times. I have been invited to moderate committee meetings due to my percieved neutrality, focus on coordination, and leadership via discussion and compromise. I have personally driven to multiple locations to provide boots-on-the-ground reporting to the members of the live chat so that they could get accurate information out. I have donated a significant amount of time, money, and effort just to insure that people can get factual, relevant, real-time information out of the Occupy San Diego movement so that we don’t come across like a bag of dicks. This is an inside joke from the Occupy SD “Media Team” worth explaining. One person trying to figure out if the LiveStream was actually live said “if you can hear me, say ‘bag of dicks'”… I said “bag of dicks” in chat. That went out to roughly 150 people on the LiveStream, including international news media. Oops. Now search YouTube for “Live TV News Bloopers”. Shit happens. Let’s get back to getting accurate information out, right? I will just get back on the phone and try to continue to negotiate win-win situations, and having everyone associated with OccupySD row in the same direction.

Last Wednesday, I went down to the Civic Center (CC) for the first time to attend the PR/Media Committee meeting before General Assembly (GA). I came in my Boy Scout uniform and ridiculous camo hat with a whiteboard of suggestions, requests, and feedback from the chatroom. I had told my friends on the Live Stream chat that I would go represent their interests; after all, I should have some weight representing 150 people or so, right? I was effectively ignored, besides contributing some “let’s move along” Certifed ScrumMaster advice. I figured I had more value going back to the Live Chat and reporting that the Committee had heard me…sortof…and continuing to quash rumors and link to verified information.

It became pretty easy to recognize kindred spirits in the chat room; they were the ones who really wanted to insure factual information dissemination and quash rumors. I am pleased to report that I made quite a few good acquaintances via the OSD chat infrastructure. That is why I took another crack at organizing the online presence of Occupy SD: I stood up the “SMC” or “Social Media Committee” Friday night.

Full regalia for the BSA uniform; although I have all this stuff, I just wore the shirt

Full regalia for the BSA uniform; although I have all this stuff, I just wore the shirt

On Saturday, I went to the Civic Center and moderated a small group of dedicated people in a discussion of Social Media. I think we started out with 10 people, most of whom had come down to have this discussion because I had deigned to appear in person to help moderate the discussion, and ended up with an unruly crowd of 40+. I was there to promote healing. I believe my catch-phrase was to “rise from the ashes like a Phoenix!”. I have never in my life drawn on that many hidden reserves of calm and patience as I did for that meeting. If you did not understand that there were a lot of egos and misplaced anger and flat-out territorialism concerning the flow of information out of Occupy SD after that gathering, well, then you weren’t there. We accomplished having most people leave with a sense of purpose, unity, and urgency: the Occupy SD social media had to do a better job of coordinating accurate information. Let’s get to work; I will help coordinate and broker win-win situations.

It was later Saturday evening that one person, understandably frustrated, uttered the words “file criminal charges”. It was not in any way directed at me, nor my efforts for Occupy SD; however, them’s fighting words, and my self-preservation kicked in.  This is why I quit answering my phone, responding to e-mails, and otherwise participating in the movement for the time being. I have witnessed more nefarious bullshit–circulating chat room logs, threatening legal actions, locking people out of accounts, redirecting websites, hijacking donation sites and their funds, bitching on live-to-the-world broadcasts, accusing people of being “infiltrators”–than I have ever seen in my life. You all should be ashamed of yourselves, and you know who you are. In fact, this clash of egos is the Achilles heel of the entire OSD movement.

Occupy Wall Street, and “We Are the 99%” has to understand what including 99% means. A constituency of 99% it is a movement of inclusion, not exclusion–we all have to get along and agree on basic principles to be able to communicate.  In order to communicate effectively, you have to broadcast at a 6th grade comprehension level in the US. A lot of my friends would insert a Fox News joke here; I have learned to insert a MainStream Media (MSM) joke here because they are the same thing: profit-driven talking heads with fancy graphics and reliably suspect information. When you see an organic movement such as Occupy SD actually get a live broadcast of a semblance of a news report that glues you to the screen because it is actually happening in real-time, this is nothing less than a triumph of communication and technology.

No amount of technology replaces simple, time-honored communication skills

No amount of technology replaces simple, time-honored communication skills

My final thoughts on Example #2: Occupy Wall Street and the Threat of Legal Action: Communication is broken within the OccupySD Media Team from the perspective of the Internet; this audience is measurably 100+ people strong and can occasionally multiply by a factor of 10, and they are figuratively dying to help out, participate, and communicate. They are doing the best that they can with the tools that they are given, and they want their voices to be heard. I don’t see the difference in this 21st century of me speaking in person or through Skype / Facebook / Twitter / Chat Room. I don’t believe my voice is diminished because I am rendered on a computer screen versus standing there in front of you saying the same thing, and OccupySD should pay equal attention to the awesome volunteers that are participating virtually as well as the physically present ones.

CONCLUSION

Communication is broken: we just don’t know how to get our point across effectively any more, from the hundreds of communication technologies to the strangeness of having to talk to another human being in person–like during the SD Blackout of 2011–without your iPhone, tablet, or computer signaling you and demanding your attention with a never ending stream of update messages, SMS messages, e-mails, phone calls, Skype conferences, Facebook posts, Twitter retweets, Dropbox syncs, Growl pings, FourSquare check-ins, Yelp! reviews, YouTube video suggestions, LiveStreams, GoodReads notes, software updates, and the rest of the cornucopia of ADHD business that occurs through your tech. Redouble your efforts–regardless of the platform–to understand whether or not you are listening, and in return, if you are being heard.

None of this technology can read your mind.

None of these gadgets removes the fact that you are responsible for your own actions.

ART OF SCRUM: Agile Does Not Mean By the Seat of Your Pants

Posted: November 17, 2008 in Art of Scrum, Writing
Tags: , , , , , , , , , , ,
1

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.

ART OF SCRUM: We Do Scrum But…

Posted: November 13, 2008 in Art of Scrum
Tags: , , , , , , , , ,
7

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.

ART OF SCRUM: Honesty is the Only Policy

Posted: February 21, 2008 in Art of Scrum
Tags: , , , , , , , , , , ,
0

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]

ART OF SCRUM: Here’s a Little Story I Gots to Tell…

Posted: February 13, 2008 in Art of Scrum
Tags: , , , , , , , , ,
0

“…about three bad bullet points you may not know so well.”

# INVEST in the Creation of a Good Story:

Anyone who sits down to write a Story should not just dash something off to get the project / feature / defect / doohickey started because you want it now. Although Chris has mentioned the INVEST acronym before, it bears repeating.

* INDEPENDENT
* NEGOTIABLE
* VALUABLE
* ESTIMABLE
* SMALL
* TESTABLE

Nothing helps create a good Story like keeping it small. I have overheard discussions where people say that it is too small to make a Story out of it. I profoundly disagree — creation of the Story IS the Discovery phase of the Achieve Approach. Investment in a Story is more than the acronym itself; investment also means to put some critical thinking, time, and effort into writing a good Story. A Story in time saves nine, my friend.

# Good Stories are SMART:

SMART Stories also consider another clever acronym to keep Storytelling focused and to the point::

* SPECIFIC
* MEASURABLE
* ACHIEVABLE
* RELEVANT
* TIME-BOXED

One crucial concept in SMART is “Time-Boxed” — a fancy way of saying that the Sprint is a non-negotiable timed event. Time is one of the three sides of the Project Triangle (ding! ding! ding!) and is one of those things that is tweaked as a factor throughout project life cycles in order to make the other sides (Quality, Cost) look better to a Client. Time-boxing a Sprint stops moving the goalpost on this aspect of working, and it really makes a difference when you know that you must deliver working code by a fixed date.

# Well-designed Stories SELL:

Once upon a time (last week), with a Client far, far away (ok, up in LA), there was an IT Manager who was trying to explain what he wanted to do with his website budget. After several frustrating meetings with the holders of the purse-strings while bandying around phrases like “anonymous user caching performance tuning”, “multi-vertical expletive parsing modules”, and “discombobulation of dilithium crystal flux capacitor obfustication”, a certified Achieve Internet Product Owner wrote some Stories to explain what he was really wanting to do. These Stories had a formula:

### OVERVIEW:
[general summary goes in here]

### BUSINESS GOALS:
[business value / reasoning goes in here]

### BUSINESS LOGIC:
[logical flow goes in here]

### REQUIREMENTS:
* [bulleted list of “doneness” requirements / use test cases]
* xxx
* xxx

### QUESTIONS:
* [bulleted list of questions for PO to ask Client if needed]

### ASSUMPTIONS:
* [any assumptions being made by the Client or Achieve relating to this Story]

By following this formula (and attaching a quick table of phases with time estimates), the Product Owner followed the Achieve Approach and Scrum. However, this is normally an internal process; in this particular (and highly educational) case, providing the Stories to the Technical Contact at the business armed him with the ammunition needed to succinctly explain what he wanted to do with his budget! In short, writing Stories in this fashion sold the services because they were comprehensible to the Business Owners at the Client.

This is truly value-add for Project Management at Achieve, and I believe it is an eye-opener for our massive and talented Sales and Marketing divisions. Writing good Stories lays out the proposed solution (read: expenditure of money) in a clear, concise, organized fashion, and leverages the Client’s own business goals and logic to justify the project. When a Client can read that this money spent will do x, y, and z right next to “our business goals are x, y, and z”, they are much more likely to make the connection that will turn that light bulb on over their head and produce their checkbook.

But wait…there’s more (besides not being sold in any store)…in addition to Client comprehension, the inclusion of Stories also plays it forward by being the foundation for Scrum and the Achieve Approach within our own Company. This will allow a formatted vehicle for true Client communication all the way through our enterprise in a procedural, Agile fashion. A Story that has been approved by a client-side decision maker allows the Product Owner to get that signature line that says “this is what we are going to deliver for you”. The Lead Developer, ScrumMaster, and Team now have an official from-the-Client document that can be negotiated with the Product Owner, then tasked out effectively, and delivered to the Client to their own specification of “doneness” (the bullet list of requirements above). This will enable everyone — from the Client to the PO to the Team to the Business Owners) to all have a central agreement to refer to. At least to me, this seems a heck of a lot more Agile than arguing the meaning of paragraph 5, page 215, of the Technical Specification document version 1.13 referring to Wireframe #522.

As a Certified ScrumMaster at Achieve — and the Scrum evangelist — I take a lot of crap from my beloved Lead Developers because everything I do or say has to embody Scrum in it’s highest form. Now, no matter what I ask of them, large or small (could you remove my unpublished blog from the published blog list please? could you PDF this web page for the CIO please? Are you ever going to pay me back my two dollars?) the response I always get is…

Story please!

ART OF SCRUM: Process Makes Perfect, Part II

Posted: February 6, 2008 in Art of Scrum
Tags: , , , , , , , , , , , , , , , , , ,
1

Let us review Part I of this immense Blog:

* An existing process is necessary for Agile technologies to bolt on to
* Agile means to think multidimensionally
* Process + Agile = efficient goodness
* Thinking nimbly means to find the ideal solution

Q: What is similar between hopscotch, Agile, Libras, and Aikido?

A: Balance

Hi, I’m Michael; I’m from Ocean Beach, I enjoy hacky sack, body surfing, and spinning vinyl; I am not much into health food — I am into champagne, and I am — you guessed it — a Libra.

Now, I don’t put much stock in whoroscopes, but I have always been fascinated with the concept of Balance. It is a positive thing; it is something that you can always work towards; it is not static. You must continually work to keep your Balance, and in this regard it is a lot like juggling (cue Karl with the flaming chainsaws). Balance is what must be struck at Achieve Internet between Process and Agility. We have plenty of both with the crazy brainpower, talent, and good looks at this Company, but as we struggle towards the lofty goal of being Balanced, I have a few long-winded observations on our Process for y’all to comment on:

1. UNFUDDLE TIMESHEETS ARE DA BOMB: Do you like getting paid? Then do your timesheet. Ye Grand Experiment of moving from Excel timesheets to a web-based, I-work-in-this-damn-thing-all-day-anyways application is Chris Fuller’s brainchild — I am just implementing and championing it — and it is much closer to an Agile way of tracking time. If this is not clear to you already, your paycheck is fueled by this Company billing time to the Client. We have to know what you are doing at all times in order to explain to the Client the value that they are getting from Achieve Internet. Once upon a time, there was Tracker, then there were Excel Timesheets [insert Alfresco integration link here]; now we are on the cusp of jettisoning a big pain in the ass locked up on the CLIENT drive for a much more flexible solution for every single employee. As the ScrumMaster, as the Resource Manager, as the Project Manager, and as a member of this Team, I have got to know what you are doing with a reasonable +/- WTFBBQ you are doing to move the ball forward on the football field so that I can explain to the owners why we want to extend your contract to next season. I’ll harp with just one of my many pieces of headgear on: as a ScrumMaster, I want to remove impediments for my Teams, and the Excel-based timesheets are an impediment. Help me help you: do your Unfuddle timesheets religiously or I will rent a tent and hold a revival meeting on one of our Lunch and Learns, including high-volume full-duplex teleconferencing for NYC and Costa Rica.

2. THE ACHIEVE APPROACH WORKS REALLY @*^(%*#^@ WELL: I have had this strange sense of deja vu in the last few weeks. Every single person who I tell “we’re gonna apply the Achieve Approach — Discover, Architect, Develop, Deploy…” gives me a funny look like, “what the hell is the Achieve Approach?” This makes me sad. There was a whole slide on this that Gary lovingly built and explained at the wonderful Summit that gave us all a day at the beach on Achieve Internet: drinking mimosas, eating ribs, throwing the football, and having Chip take closeups of everybody’s grill. Or did you forget about the presentation that the Business Owners worked on for a whole week because that was too much fun? Remember: keep your balance, folks. The Achieve Approach (and that’s capitalized for a reason) is both Agile and Process, and I have seen it work on every single employee. Each time I have put the AA thumbscrews on and started ratcheting them down — from the front line developers to the executives — I get the eyes rolling at me and 15 minutes later this same person is excited because we — as a Team — have caught 10 or more hours of time we would have missed if we hadn’t taken the time to ask ourselves these questions. I have seen the Achieve Approach work when a bunch of the crew wants to decide where they want to go to lunch that day! I cannot believe that we are not asking those four simple queries; every Story, every Task, every initiative, of every Client’s “business goals”, of every time I see someone rush off to do something and I watch the see-saw tip drastically in that direction. Stop, drop, and roll…with the Achieve Approach. At least for a month or so, just like the timesheets. The Achieve Approach is what our Agile is bolted to, and as a series of quick questions, it is pretty damn scalable and it saves a lot of time when the estimates are in, keeping us balanced and trusted.

3.YOU ARE RESPONSIBLE FOR THE SUCCESS OF THIS TEAM: Teamwork…Resiliency…Road Warriors…this is the Clydesdale horse puckey that Super Bowl filler is made of. While we were all tuning into the ball game, we were so amped that this stuff sounded like the Gospel. After the Game, that crap is forgotten and dragged all over the parking lot on the bottom of whatever footwear you decided to come to work in. And nobody wants to take responsibility for crapping or picking it up. This is represented best by how many times I have gone into an Achieve bathroom and there is no toilet paper on the roll. Not even a nice note on the cardboard saying “haha your f****d now!”. No thought at all, just an impediment caused by your teammate. Apparently, this is how we do our best work? I don’t have to be a CSM to tell you that this is not Agile, nor is it polite. I see this every day in little ways, and it really isn’t conducive to the Process, Agility, Teamwork, or anything else that gets us more Balanced. I hate to overemphasize, but in this toilet paper metaphor, do your diligence: Discover (no toilet paper! where is the next roll?); Architect (this is how this clever roll thing works); Develop (go and get the refill); Deploy (put it on the roller and recycle the empty). This may seem like I am talking down to y’all, but I am really not happy working in an environment where I might be shanked by an empty toilet paper roll at any time. If we cannot refill the roll for each other, we have no business building COMMUNITY WEB SITES for other people! The point I am trying to illustrate is that Achieve Internet is a TEAM; it is founded on Teams, it relies on teamwork, and this is the heart and soul of Process AND Agility. Without this fundamental core, we cannot build anything like Process, Agility, or a successful business. YOU are part of this Team, and the office doors are wide open for your contribution to the Balance of the business, and this Intranet is the forum to “get your node on” in. Community does not succeed unless every voice is heard, evaluated (Discover, Architect, Develop, Deploy), and occasionally, everyone has to refill the roll for the next Client. Baby steps always help people balance on that playground equipment.

Whitney Cali — my previous boss at Achieve — used to go to Yoga every Tuesday, leaving early at 5PM to make that class. She told me she was going to “get balanced”. I am a CSM because Whitney had the foresight to take me with her to ScrumMaster training because Achieve Internet needed it. I think Scrum has helped Achieve in a significant and measurable fashion, but there is a lot of work to be done yet. All good jobs — that you enjoy coming to, working at (most of the time), and partying with the people you meet — are this way: they need balance.

OUTPUT:
* Do your Unfuddle Timesheet
* Quiz yourself on the Achieve Approach
* Change a roll of toilet paper.

ART OF SCRUM: Process Makes Perfect, Part I

Posted: January 29, 2008 in Art of Scrum
Tags: , , , , , , , , ,
3

Scrum is really fond of recoiling at anything that vaguely resembles Waterfall methodology, but after a while, this provokes the following question: How do you balance Agility and Process? By definition, [Business] Process means following established procedures, usually in a certain order. This is already starting to quack like a duck in a Waterfall to Scrum aficionados.

On the other hand, it is patently stupid to be Agile for the sake of saying that you are being Agile. That is like pretending that there is a hopscotch board in front of you wherever you need to walk. Entertaining for a little while? Perhaps; however, over time, you will not only expend a lot of unnecessary effort, you will look foolish. Scrum, XP, Lean Development, and other Agile methodologies are, well, methodologies, and as such, are processes. Although clever witticisms such as “Scrum: it depends on common sense (Danube Training)” and “Scrum is not a methodology — it’s a pathway (Ken Schwaber)” are helpful when in the context of the tapestry that they pertain to, lifting them out as sound bites will insure that they are used in the wrong circumstances to justify incorrect assumptions.

So, back to my Blog title: Process Makes Perfect. I am not quacking here; even Agile PM has procedures to insure results. The introduction of Agility to a company is always tough because it forces the employees at all levels to think sideways, not completely out of the box. No Agile screed that I have ever heard of asks an enterprise to jettison everything in the name of Agility; rather, it is learning to recognize that you have many more options besides ludicrous speed and ranking full stop.

If you look at all of the fancy diagrams that supposedly depict Scrum processes with 3D delivery time loops, poetry and Bible verses, and even BHAG flowcharts, they really all say the same thing:

Wait for it…

Think Different

OK, I am not joining the ranks of the Apple fanatics (NSFW) here at Achieve with this bold appropriation of their late 90’s advertising campaign. It just so happens that this describes Agile thinking very, very well…when it is paired with a standard process to follow.

Nobody complains about the Waterfall when it is producing quality software, meeting deadlines, communicating well, and insuring that clients feel like heroes. No one cares how Agile your company is if you deliver a shoddy product that the customer didn’t ask for, late and over budget. There is a balance that can be struck — and should be found — where the best practices of differing methodologies can actually provide better results than any one on its own.

If a process is a series of steps in a predictable order, such as points on a straight line, then agility is thinking multidimensionally: away from the line. The main cause of grief from Waterfall is the strict adherence to the idea that “we can’t do that until we have done this”. This dot is in front of that dot on the line, and you cannot think differently enough to see that there is more than one dimension. Agile methodologies encourage anyone who is familiar with this mode of thinking to do a sort of mental Aikido when the standard operating procedures meet with resistance or raised impediments:

Aikido techniques are normally performed after first blending with the motion of the attacker, so that the defender may redirect the attacker's momentum without directly opposing it, thus using minimum effort...Aikido demonstrates this philosophy in its emphasis on mastering martial arts so that one may receive an attack and harmlessly redirect it. In an ideal resolution, not only is the receiver unharmed, but so is the attacker.

If the process is running smoothly, and product (quality “potentially shippable” code) is being generated, there is no real problem. It is when one perfectly-shaped piece of gravel catches your left front skateboard wheel at high speed that you realize that the attack is imminent — in this metaphor, the asphalt meeting the side of your face. Being flexible in your processes not only allows for agility, but brings you closer to not only dealing with your “attacker” (WIBNI, anyone?) but finding an ideal resolution to the apparent confrontation.

Here is some more abuse of the code block tags; something else to pair up with this idea of an Agile process, this time from the buzzword bingo that is the Agile Manifesto:

Simplicity--the art of maximizing the amount of work not done--is essential

As I have stated before, Achieve has an Approach. This is where I am going with my defense of Process. Recent hard work has determined that we may have found a balance point between Scrum and Process that will provide the Company with the best of both worlds.

Stay tuned for the other side of the double-wide!

ART OF SCRUM: Discipline and the Scrum

Posted: January 15, 2008 in Art of Scrum
Tags: , , , , , , ,
1

I would like to hijack a quote from The Shawshank Redemption:

“I believe in two things: Discipline and the Scrum. Here you will receive both.”

There are too many stories (note the lack of a capital S there) about how Scrum or some other Agile Flavor of the Weak fails to take hold in a corporate environment. I believe that this is due to Scrum being seen as some magical panacea, some sort of instant oatmeal solution to right a foundering project or product. This is not the case, and is the acknowledged dodge of Scrum trainers everywhere. It is even an early PowerPoint slide in the Danube standard CSM training presentation: Scrum is Not a Silver Bullet.

Here is what Scrum is NOT going to do for you:

* Fix a lack of honesty
* Make a Team play nice in the sandbox
* Remove micromanagement
* Force clients to play by our rules
* Produce good code / product for you
* Make your job easier

You have to do this yourself.

This is where discipline comes in. Martial arts are called disciplines for a reason. Discipline can be thought of as a form of punishment, or it can be seen as a form of self control, and the latter (not the former) leads to hallway usability testing, spontaneous code reviews, staying late to get something just right (and avoiding technological debt), and other evidence of pride of ownership. Discipline is what leads us to quality; Scrum is just a way to help you to be successful in your job description. To paraphrase Ben, own your code.

Achieve doesn’t hire weaksauce. Of that, I am certain, having seen most everyone’s resume, written your corporate bio, and definitely seen how, when we put our minds to it, we turn out excellence. The new year promises many more opportunities to churn out quality solutions for name-brand clients, great Web 2.0 honour, and ph@t l3wt. Discipline is focus, pride, and that extra effort that effectively makes our clients heroes, and it should not be a warden enforcing it: it should come from within.

ART OF SCRUM: Scalability and The Achieve Approach

Posted: January 7, 2008 in Art of Scrum
Tags: , , , , , , , , , , , , , , ,
1

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.

ART OF SCRUM: No Jargon Scrum

Posted: January 2, 2008 in Art of Scrum
Tags: , , , , ,
0

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.

ART OF SCRUM: Pay Your Debts Promptly

Posted: December 26, 2007 in Art of Scrum
Tags: , , , , , , , , ,
1

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.

ART OF SCRUM: Transparency Leads to Agility

Posted: December 18, 2007 in Art of Scrum
Tags: , , , , , , , ,
1

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.

ART OF SCRUM: Why Product Owners Want to Tell You Stories

Posted: December 12, 2007 in Art of Scrum
Tags: , , , , , , , , , ,
0

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!

ART OF SCRUM: Wallpaper with Whiteboards

Posted: December 4, 2007 in Art of Scrum
Tags: , , , , , ,
0

Going through two years of graduate work (and still paying for it) for a MS in Educational Technology was an eye-opening experience. It seems that no matter how old you are, kindergarten tactics for teaching still works wonders. I still marvel at my hard-earned teacher salary going towards instruction content such as “Effective Use of a White Board”, “Zen and the Art of the Overhead Projector”, and the much-feared “Copyright Law and Properly Setting Your VCR to Record a Show”. All of this post-graduate work can be summed up in two sentences:

  1. Write legibly, and do not obscure your own writing; i.e., write on the board / projector and then get out of the way
  2. Read the instructions and practice at home

Back in 1997, these were high-tech gadgets to use in the classroom. 10 years later, and this stuff seems Stone Age. But I still love the whiteboard because it allows people to add a visual component to an oral discussion. Instruction theory describes a theory of mental retention of content by how many senses are involved with learning it:

  • Hear it: 10% — audio
  • Hear it and see it: 25% — audio, visual
  • Hear it, see it, and write it down: 45% — audio, visual, kinetic
  • Hear it, see it, repeat it verbally, and write it down: 65% — audio, visual, kinetic, and more kinetic

In this case, more interaction leads to better retention of the data. Essentially, more involvement allows the brain to interact with the subject matter on a variety of levels, firing multiple synapses in different areas of the neocortex to facilitate full comprehension. I probably need to draw a diagram and make you repeat after me to get that concept to stick…

Anyhow, I was pleased to see that the new AI East whiteboard is being used frequently. I know that the Wall ‘O Board at AI West is used quite a bit as well. The greatest trick to effectively using whiteboards, however, involves a step that is not normally taken — extracting the needed information off of the board at the end of the session so that the surface is not marred by either ghosting or by questioning if you can erase what is currently on the board. Someone has to be responsible enough to write down what is needed to be saved and insure that this is filed in the appropriate manner — hopefully, not paper in a filing cabinet.

Fret not; the act of copying down what is on the whiteboard is a productive activity. This is an opportunity to grab only the real fruit of the labor, organize it again in a more readable or understandable fashion, all the while being polite enough to allow for the next whiteboard user to have a clear surface. This was one of the complaints about using the Conference Room for the Scrum Task Board; nobody else dared to touch it in fear of disturbing the controlled chaos of different colored sticky notes progressing across the snowy landscape of the tileboard, so the expanse of writable surface was effectively lost for other uses.

Joel on Software is a big fan of Hallway Usability Testing; I believe that whiteboards facilitate this sort of information transfer. A picture is worth a thousand words, and a handy whiteboard is a low-tech interactive space for gnoshing out problems and quickly suggesting alternate approaches because you can point to established agreed-upon concepts, draw arrows, gesticulate at thaumaturgic symbols, spit out theoretical code samples, and otherwise use more than one sense to get a sense of what you are talking about.

ART OF SCRUM: Why Scrums Need Squeaky Toys

Posted: November 27, 2007 in Art of Scrum
Tags: , , , ,
2

In Scrum training, I was a little weirded out when Dan Rawsthorne, the session leader, insisted on handing out rubber mice for each table that squeaked when you squeezed them. Everyone at the table looked a little sideways at them, then forgot about them as the presentation went along.

That was, until Dan picked one off of a participant’s table when the one inevitable “I-have-a-question-that-takes-10-minutes-to-ask” person interrupted him with a monologue for the third time in a half an hour. He started squeezing the toy vigorously until this person got the hint to STFU. Dan had demonstrated the Importance of Squeaky Toys in Scrum.

The point of ALL Scrums is to be quick and to the point, that point being to maximize the helpful knowledge transfer between team members and minimize the time-stretching effects of those that soliloquize. A good Planning Scrum for a week-long sprint should be no more than 30 minutes, including taking whatever you need off of the whiteboard and making a list of action items. A Daily Scrum should be over in no more than 15 minutes, and when really done well, less than 10. This brings me to the Use of Squeaky Toys.

No matter how excellent the opportunity looks to get your team members’ input on that thorny issue you have been contemplating how to tackle, dollars to doughnuts, it should NOT be discussed in a Daily Scrum. In my experience, usually these things arise as part of the “what you did yesterday / what are you going to do today” round table, and then someone else jumps in with a possible solution, and then we are off to the races trying to figure out this one problem instead of staying focused. It is difficult to derail these types of (usually) enthusiastic participation, so the completely-out-of-left-field sound of a Squeaky Toy does a great job of breaking into a sidetracked conversation without hurting anyone’s feelings.

After two days of Scrum training, and witnessing the effectiveness of a compressed Scrum (we had 5 minutes for Planning and 2 minutes for Daily at the end of the session), the elected ScrumMaster would always keep his or her hand on the Squeaky Toy, nobody got off topic, and the exercises were completed much faster than we ever thought possible.

Of course, the phrase “OFFLINE!” also became very popular…