March 2009

Monthly Archive

My Talk @ SD West 2009 on “Managing Software Debt”

Posted by on 27 Mar 2009 | Tagged as: Acceptance Testing, Agile, Architecture, Distributed Computing, DotNet, General, IASA, Java, Jini/JavaSpaces, Leadership, Maven, Open Source, Podcasts, Product Owner, Ruby, Scrum, Software Architecture, TDD, User Stories, XP

I have uploaded the talk I did at SD West 2009 on Yahoo! Video and here it is:

It’s BeyondAgile: people making software that works

Posted by on 25 Mar 2009 | Tagged as: Acceptance Testing, Agile, Architecture, DotNet, General, Leadership, Product Owner, Scrum, TDD, User Stories, XP

The hopefully-not-anticlimatic second event of the still-pretty-new BeyondAgile is happening on Thursday:

“Agile Challenges Clinic/Swap Meet”
Thursday, 26 March 2009
6:30 to 8:30 p.m.
Locations on the Eastside and Seattle!
Read on for agenda and location information, or visit our Google Group at
http://groups.google.com/group/beyondagile

The Blurb
At the first event, everyone (over forty people) created a backlog of ideas, suggestions, and work items. Among them were two suggestions that gave rise to this event’s focus: “a bring-a-problem” session where everyone helps everyone with their challenges. We’ve extended the idea of a clinic, where you bring a problem to an expert and get help, to a swap meet (or potluck), were everyone brings something and gets something. So come if you think you’re brimming over with answers and expertise, and come if you’re wanting other perspectives or advice on how to tangle with the problems that bedevil your days.

We’ll also form a program team, a group that’ll work proactively to plan interesting and exciting events in sufficient time for the blurb-writer–that’s me–to write and distribute the blurb a few weeks before the event. If you’re wondering who’d be good at doing that, go look in a mirror—it’s you we need!

Second Event Agenda

  • Welcome and Announcements (10 min.)
  • Formation of Program Team (10 min.)
  • “Agile Clinic/Swap Meet (85 min.)
  • Giveaway Drawing (5 min.)
  • Meeting Retrospective (10 min.)
  • Socializing and Breakout/Breakup/Beer

Event Locations

Eastside: SolutionsIQ
First Floor Training Center
10785 Willows Road NE, Suite 250
Redmond, WA
NOTE: directions and picture of building at http://www.solutionsiq.com/about-us/contact-us.php?Look for the tent signs and the blue BeyondAgile logo

Seattle: Amdocs Digital Commerce Division (formerly QPass)
Greece Room
2211 Elliott Ave Suite 400
Seattle, WA

Questions?
Contact us at beyondagile@taoproductions.com, or visit our Google Group, or contribute to the nascent Wiki at beyondagile.org.

Why come?
Here’s your chance to be in on the beginning of an exciting new collaboration of the Puget-Sound area (and beyond!) agile-interested. And if that’s not enough, we’ll hold a drawing to win exciting and valuable prizes!

What’s BeyondAgile?
It’s the combination and follow-on to a number of the agile-oriented user and interest groups that have operated in the Puget Sound area. Representatives of the Seattle XP User Group and Seattle Scrum came together in December to try and combine the efforts of all of us who care about and use agile methods.

Why does BeyondAgile exist?
o Find best practices among all agile processes
o Build a bigger agile community
o Take advantage of overlaps between existing groups
o Expand beyond meetings and provide a place to collaborate
o Align software development and business
o Explore cutting-edge ideas and techniques

What is BeyondAgile like?
That, in large part, is up to you. A primary reason for consolidating our efforts is to broaden our base of support, capability, and leadership. We envision a more active, multi-faceted organization that does more than just host talking heads. We’ll gather at least once a month on the 4th Thursday of the month, and probably more often, once you figure out what other events you’d like.

Where do BeyondAgile events happen?
Our goal is to have many answers to this. As a result, we’ve worked to remove the impediment offered by bridges and commuting: for our monthly meetings, we hold our events in both Eastside and Seattle locations, through the semi-magic of videocasting. We’re experimenting: we’ve thought of trying to alternate the “real” physical meeting between sides of the lake. At this point, we’re only at the stage of using a semi-okayish video link between the two locations, and try *very* hard to make the meeting balanced between locations. That’s harder than it seems; come and help us work it out! We’re still dreaming of enabling people anywhere to attend through streaming video, even after the meeting’s already happened, but we need more knowledge, resources, and volunteers before that’s going to happen.

I have question for you.
Great! Visit the Google Group (BeyondAgile) or send a message to beyondagile@taoproductions.com

Choking Productivity — Shared “Resources”

Posted by on 06 Mar 2009 | Tagged as: Agile, General, Leadership, Product Owner, Scrum

When introducing Scrum into an organization with many teams there are usually questions about particular roles and how they will work with teams. Questions that I have heard in the past are:

  • I work on features that cut across all or most of the teams, how can I possibly work with all of them?
  • I am the only person or part of a small group that supports all of the teams, how will they work with me?
  • Our department handles all of these aspects of software delivery, how will we assure quality won’t go down?

As has been said many times by many individuals, Scrum is NOT a silver bullet and it will NOT solve your problems. Scrum will make your problems visible and then it is up to the people within your organization to fix the problems. This is why I believe that the greater your organization can exhibit the five value of Scrum the greater success they will achieve with Scrum. Here are the five values:

  • Courage
  • Commitment
  • Openness
  • Respect
  • Focus

I want to point out that all of these are needed, in double order, when we find out that people within an organization are “shared”. These people are usually called “shared resources” and anytime that I hear the word “resources” used to identify people it causes me to flinch. “Resources” can be moved around wherever they are needed with specific objectives and not a worry about how they will interact with people around them. At least this is my experience in discussions about moving “resources” around the organization. I like to call human beings “people” and even call them out by name because this causes people who are discussing their movement to address their skill sets and interactions more explicitly. OK, enough of my rant on “resources” versus “people”.

Courage is needed for management to acknowledge that sharing people across Scrum teams is going to cause a bottleneck and to take action. I have found that this phenomenon of going through a single source for that person’s function was already causing a bottleneck but the “hand off” culture allows it to hide from daily view. It takes commitment of either funds for more people or a program to distribute knowledge through mentoring for parts of this person’s functional role. It takes openness on the part of a person who is being “shared” too thin to point it out and make sure that something is done about it. Respect is necessary for all involved to assess the situation and ask for help in resolving the issue. Finally, focus is the value that guides us towards working with one team or at least one Product Backlog at a time.

Depending upon the granularity at which a person functions well, you may find working with a Scrum team or on the Product Backlog a better choice. If your functional role supports the delivery of technical functionality in terms of software development artifacts that are actually used by your end users then being on a Scrum team is better. If your functional role influences the product strategically but does not directly generate software development artifacts that end users use then working with a Product Owner ahead of the Scrum team may be more appropriate. Here are some symptoms of sharing people too thin:

  • People mentioning that there are too many meetings
  • Scrum teams waiting on dependent artifacts to be delivered
  • People working overtime continually to keep up with demand
  • Mentioning vacation time causes multiple organizational groups to think about how they will get along while a person is gone

Sharing people is always a potential bottleneck within an organization. Your organization may be able to function for a while with shared people but at some point, if you are lucky and your company grows, they will become spread too thin. Scrum can help you identify this problem and make it visible but it takes people in your organization with courage, commitment, openness, respect, and an eye on focus to fix the sharing of people too thin. Look for ways to find the granularity at which that person in their functional role works within the software delivery process and figure out how they can interact at that level for more appropriate focus and results.