Archive for February, 2008

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.