SCRUM - Agile Methodology

Initial Experience

I've been intrigued about Scrum since I ran across a research paper describing it in
the mid 1990's. It seemed that a few folks, Ken Schwaber, Mike Beedle and Jeff
Sutherland were experimenting with a new way of operating technical teams for
software projects.

I was very much intrigued by the process and my perceptions of how it might
operate and improve some of the systemic problems I'd been experiencing in my
own projects. Fast forward a bit...

Around 1997-98, I was working on some challenging software projects. One of them
was a project focused on upgrading a great deal of our existing software product
architecture and interfaces to be more current and competitive. The target for the
project was to demonstrate our efforts at the leading annual trade show for our
industry in North America. Of course, this was a "real" fixed date project.

We applied some unique approaches to this project effort (at least unique in our
domain). For project planning, we leverage a great deal of collaborative planning
with the entire team, using sticky notes, team prioritization, etc. We also had a full-
time customer (representative) with us for the duration of the project. In many ways
we used some of the planning and customer interaction bits that are so effective in
XP and Scrum.

As we approached building our first "iterations" of software, we began cross team

integration of our deliverables. This had a strong testing focus, but included team
members from every function. We used a Scrum-like daily meeting with their Q&A
format. We also had Agile "information radiators" for issues, next steps, key
accomplishments, etc. in our project meeting area.

The short version of the story is that (A) we nailed the software for the trade show
and blew away the competition with our product future shift. And in the project
retrospective, we (B) the team felt that the #1 reason for our success was the Scrum
team patterns of daily meetings, team cohabitation for integration, cross team
reporting and team collaboration towards a unified goal.

I've since completed a book on Software Project Endgames, and these techniques
have become one of the powerful tools that I use in as many Endgames as possible
to increase our probability of success.

Certified Scrum Master

I've recently (September 2004) been through the Certified Scrum Master course and
am looking for opportunities to begin implementing Scrum practices more holistically
within software projects.
I'm also looking to begin introducing Scrum via local training and speaking
engagements. If you have a project that you'd like to try Scrum on OR if you'd like
to learn more about it, simply contact us - info@rgalen.com

Core References

• Agile Alliance
• Ken Schwaber's ADM central Scrum site - www.controlchaos.com
• Scrum Gathering - www.scrumgathering.org
• Mike Beedle and www.balancedagility.org
o www.e-architects.com
o www.newgovernance.com
• Boris Gloger - www.glogerconsulting.de
o www.scrumeducation.com
• Jeff Sutherland's Scrum log - http://jeffsutherland.org/scrum/
• Certified ScrumMasters - http://www.scrumalliance.org/
• Mike Cohn has a wonderful "portal" for Scrum -
http://www.mountaingoatsoftware.com/scrum/
o http://www.mountaingoatsoftware.com/scrumfigures.php
• Linda Rising IEEE 2000 article -
http://members.cox.net/risingl1/articles/IEEEScrum.pdf
• Jeff Sutherland (SCRUM)
• Bill Wake's "Scrum on a page" - http://xp123.com/xplor/xp0401/Scrum-
dev.pdf
• www.xbreed.net (SCRUM +XP)
• Yahoo group for SCRUM -
http://groups.yahoo.com/group/scrumdevelopment/
o http://sdn.agilemovement.it/ (Newsletter derived from the Yahoo
group)
o http://scrumwiki.org/
o http://wiki.scrums.org
o http://www.sdforum.org/scrum
o http://www.scrumforums.com/
• Scrum Tools -
o www.scrumworks.com, http://groups.yahoo.com/group/scrumworks
o www.versionone.net
o Microsoft Project, Scrum tool -
http://www.microsoft.com/downloads/details.aspx?
familyid=81daab54-6701-4fbc-b3d0-7f261383f371&displaylang=en
o
• IBM - RUP article - http://www-
106.ibm.com/developerworks/rational/library/feb05/krebs/index.html

Podcasts & Other References

 • http://agiletoolkit.libsyn.com/
• http://www.itconversations.com/shows/detail175.html
• http://www.podscope.com/search.php?q=agile&sourceID=19&sa.x=0&sa.y=0
• http://blogs.conchango.com/howardvanrooijen/archive/category/1018.aspx
(Scrum Podcasts)
• http://odeo.com/audio/28536/view (Discuss various methodologies)
• http://odeo.com/channel/5623/view

Beyond reading any introduction on the above websites and the two books by Ken, I
would recommend joining the Yahoo group as a starting point for gathering more
information. There are some lively conversations and the discussions normally cover
beginner to advanced topics in parallel. It's a safe collaborative learning
environment!

Scrum Team Collaboration Demo: Share-Point

Tiran Dagan from www.6footmedia.com has setup SharePoint prototype for a scrum
site located at: http://sharepoint.6footmedia.com/scrum for demonstration
purposes. If you are asked for a username, enter: guest@6footmedia with a
password of demo1234.

The overall site is an example of how you can provide scrum information to the team
or other "chicken" in the company. To see the team collaboration area, go right into
the "SCRUM Room" section (on the top nav bar) or go to:
http://sharepoint.6footmedia.com/scrum/Pages/ScrumV2.aspx

Please use IE 5 or newer. Toggle the "discuss" button (yellow note on the main IE
toolbar) to see my comments about the pages, especially when you are in the
"SCRUM Room" page.

The entire sharepoint site template is available for download from the home page
("Download STP" in the quick launch bar on the left). Use it to create an identical
sharepoint site on your company's server. I am working on documenting the web
parts you will need to make it work.

Comments to - tiran@6footmedia.com

Personal Observations of Scrum

There are a few general observations to immediately make.

I like the Scrum model and the Agile philosophy of empowered and independent
teams. It makes a lot of sense to me - always has and always will. I've not fully
deployed Scrum (yet), but I've seen these practices contribute to some of my
greatest project experiences and successes.

However,

Scrum fundamentally changes the management dynamics of software teams. It

changes the manager's role and all aspects of traditional management - HR
processes, rewards & recognition, performance review & salary increases &
promotions, performance actions (improvement and firing), team conflict resolution,
team building, employee development and training, etc. are all basically not covered.

It also doesn't cover how to effectively deploy parts of Scrum into organizations.
Entry is usually couched into a hypothetical organization that (1) understands and
(2) is totally receptive to Scrum. Anything else, and the "literature" provides little
guidance.

Even when "listening" to the Yahoo group, a great resource BTW, most discussion is
Green Field based and not helpful to those encountering resistance or trying to map
it into an existing command-and-control organization that will not fundamentally
change overnight.

I think this is a real shame. While on the one hand, I can understand why folks are
so focused on the principles and don't want to compromise, a good dose of reality in
deployment can't possibly hurt. I want to use this space as a mechanism, over time,
to explore the softer side of Scrum deployment and expanding upon some of the
above points.

Agile deployment strategies are key to its mainstream adoption and growth.

Look for more later...

Scrum within a Test Context

I've been informally using Scrum within a testing context for a number of years.
You'll also see references to it in my Software Endgames book. I find the simple
practices wrap quite nicely around testing activity - independent of development
methodology used.

I've developed a presentation around this and am sharing it at Star East 2005. I'd
love to get feedback on the presentation details and drive further conversation.

Look for more later...

Agile Performance Management

These comments are from an exchange in November 2005 between Brad White &
Michael K. Spayd.

We've been doing scrum for about a year and it is going pretty well.

One issue we've had has been compensation. I'm after my boss to increase pay so we can hold onto people
longer. In response he wants to implement performance
based pay. Pay people a base salary and then on top of that for meeting certain targets.
My position has been that there are no metrics that can drive good software. All the things you can
measure are objective and quality software is subjective.

Now he reads this about Travelocity

http://www.optimizemag.com/article/showArticle.jhtml?articleId=172901560

Do I go ahead and let him measure something to make him feel better and try to not let that impact the
quality of our work? How would you approach it?

And Michael's reply...

At my current client (large Fortune 500) doing a enterprise-scale Agile implementation they are currently
grappling with performance metrics as the end of year approaches quickly. They are quite individually
oriented in their ratings system and some of them know that needs to change. If your boss is talking about
measuring something like productivity (through points or some measure of velocity) or some supposedly
objective thing, that requires caution I would agree. However, most performance management systems
have user judgments about someone's effectiveness (I personally do not consider these *subjective* with all
the pejorative baggage that implies, but rather individual judgments). If you have a system like that,
perhaps the following bullets will help.

If ratings were made on the following criteria, that would likely drive the right behavior:

• Focuses on delivering business value frequently

• Clearly supports the team in achieving its goals; takes personal responsibility for the team's goals
• Works collaboratively with others; helps create a team culture of collaboration
• Acts as a leader in service to the team as appropriate to their skills without attempting to control
others
• Makes other team members better through encouragement, support, feedback and mentoring
• Proactively solicits feedback from others and uses it to improve their own performance
• Provides feedback to others (with their permission) in a constructive and insightful manner
• Performs any work the team needs to reach its goals, even outside their area of comfort or
expertise
• Seeks to gain new skills and knowledge to make themselves more useful to the team
• Attempts to see value as the customer sees it

I thought this exchange brought to light some interesting points about team
management and performance evaluation in an Agile environment. As of late 2005,
you see very little