Posts Tagged ‘ScrumMaster’

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]

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.

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.

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

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

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

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

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

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

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

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

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

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

Without a common language it is difficult to communicate.

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

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

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

Originally published: Tuesday, 12/11/2007

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

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

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

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

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

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

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

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

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

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