A metaphor for the Scrum Master is a vigilant sheepdog protecting their flock.

At the Fall Scrum Gathering, I met practitioners facing different challenges in their agile practice.

Some faced profound impediments that their organizations were unable or unwilling to address. The effect on the project and team was dire and the Scrum Master had exhausted all avenues to raise alarm.

It’s human nature, unfortunately, to associate an unpleasant message with the messenger. A vocal Scrum Master can be seen as the problem.

In those fraught circumstances a Scrum Master has to balance the interests of the team, the company and themselves. Can the project deliver in spite of the obstacles? Should the Scrum Master accept the dysfunction or not? At what cost?

As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.” Still, a useless sheepdog is also a useless sheepdog.

As JP Boodhoo says, “develop with passion.” As my friend Luke Melia says, “live with passion.”

Posted: December 15th, 2007 under scrum.
Comments: 1

Things we did right:

• laptops
• table with two tier top so laptops can sit under the surface
• dual monitor setups
• build bunny
• video projector at center of table
• room for product owner and scrum master at ends
• big whiteboards
• big corkboard
• wall space for bulletin board sized post its
• team picked colors
• space invaders
• poster board sign for ript
• webcam
• purell, handwipes, tissues, and hand lotion

Things we could have done better:

• private space in the corners
• better way to leave phone messages for team
• more webcams/better video conferencing
• kept killing plants
• needed a cleaning person
• better HVAC

Posted: November 24th, 2007 under Uncategorized.
Comments: 6

John Maeda has another post on leadership.

“In movies we often see two scenarios: 1) the leader is surrounded by her soldiers as a wall of protection; or 2) the leader is the one that is the first to rush into battle.”

I have trouble with war metaphors in a time of war but I get that success is built upon both protecting potential and creating it.

This sentiment reminds me of Garry Kasparov’s description of his chess play, attacking, aggressive, “where the player who makes the first mistake loses” versus a maneuvering, defensive style that “accumulates small advantages over time.”

I have played the latter, quiet game, advancing through various roles and towards an agile organization over years.

My game was winning over peers, demonstrating success, removing many obstacles and flowing past others, educating executives as they became receptive to it, and, above all, showing by doing — proving value on our terms by delivering value.

But as Mr. Kasparov points out, circumstances may require us to adopt alternative styles and I am clearly in that situation now.

My company may soon be integrated into a larger one. In that larger organization, I have met conscientious, competent people. If the acquisition goes through, they will work to realize as much benefit as possible while managing risks and minimizing harm.

However, drastic change will need to happen in a short time and there are three very different cultures at play: that of our team, our current employer and our prospective new one.

Time is a factor in another way as well. My team cannot endure setting the clock back on our product and software development practices. Agile development means little unless it is in partnership with an agile business. We don’t want to just build things well. We need to invent, serve users and win in the marketplace. We need it all.

If circumstances call for a more pressing style of play. So be it.

Posted: November 6th, 2007 under Uncategorized.
Comments: 2

I was just asked whether I had metrics to demonstrate our pairing practice benefits the business compared to waterfall.

In my business context, I can’t cost-justify the kind of measurement Jeff Sutherland illustrates in his paper demonstrating efficiencies with Scrum in a CMMI 5 organization. Someone needs to do the same thing for XP practices. We have raw data from our revision control and tracking if that will help.

What I have to say is subjective. As a VP, I want our work more innovative, our code more maintainable and our progress more predictable. Pairing supports these goals in the following ways:

Shared Ownership

A risk managed approach to IT encompasses the bus test – how deep a hole are you in if one or two key people we’re suddenly unavailable (as in hit by a bus). Aside from specifications, waterfall tries to solve this with comprehensive code reviews and standards guidelines. In my experience, these were good intentions that NEVER happened. The problem was they sat outside the inherent work of writing code and felt like overhead.

In pairing with switching, these goals are largely accomplished in real time. And rather than management pulling teeth, the team themselves champion it.

Visibility

In a waterfall process, accurately monitoring progress takes great amounts of non-value adding effort by someone with a high-level of development experience. In pairing, the pair is constantly discussing progress. A project manager (or scrum master in our case) in the room, is able to learn a lot osmotically without pulling developers off task.

Momentum

As a developer myself, I understand that even the most talented coder can get side tracked, distracted, bored or otherwise stall out. Pairing forces focus. In a culture of collaboration fostered by pairing, developers use each other to break through obstacles. Progress is much more predictable and developers produce more efficient and purposeful code.

New Hires and New Learning

Bringing new or junior members up to speed is a high overhead to a small team. Often, the best learning happens when two people of roughly the same skill work together. Sometimes someone with less experienced needs mentoring by someone with more. Pairing ensures each person has the opportunity to learn from everyone else. Carefully vetted, new hires on our team begin contributing within the first sprint.

I have complete confidence my team can bring in new technologies and languages. They’ve proven it to me with Ruby, WPF, and SQL Server OLAP/Analysis Services.

Creativity and Collegiality

The types of people who seek out a pairing environment are social, take initiative and want to engage in the big picture. These types of developers create a vital workplace and contribute more fully to product development. I’ve written several papers getting at the relationship between collaboration and innovation.

Pairing fosters friendships that extend beyond the workplace. Gallup has found a high correlation between worker engagement and whether they believe they “have a best friend at work.”

To Conclude

I admit these are all subjective observations. However, my day to day experience convinces me our team is much better for our pairing practice.

Since we began pairing, even the most senior of our developers has grown their technical and interpersonal skills. We have delivered predictably for our business on multiple streams of work in diverse, sometimes emerging technologies. I’m confident we can maintain our applications no matter which team member takes vacation.

Finally, not one of my team “clocks in”. They bring their whole selves to our work and our workplace. If a manager needs a chart to tell them why that matters, they shouldn’t have authority over people.

Posted: October 30th, 2007 under Uncategorized.
Comments: 1

Separation of Concerns is a classic software design consideration but in this anti-pattern, management takes a coherent concern (i.e. what opportunity does a potential software project represent), breaks it apart and tasks the pieces out to siloed business units.

One group creates revenue models to meet to top line goals, another group models costs as fixed budgets, yet other groups devise features and schedules. All without engaged participation by the developers who will be asked to implement.

Each actor has strong motivations to push one agenda (high revenues, low costs, aggressive schedules, ambitious feature lists) without offsetting responsibility for other concerns. The result is impossible project expectations.

Finally these separate models are patched together into a PowerPoint presentation and called a “plan”. “It’s alive! It’s alive!”

Related anti-pattern: the Anemic Management Matrix.

Posted: October 25th, 2007 under Uncategorized.
Comments: none

At Oxygen, we have a team.

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

Posted: October 22nd, 2007 under Uncategorized.
Comments: 1

A chain of direct and “dotted line” reporting that makes a worker accountable to many managers with no clear boss.

A near total separation of authority and responsibility. The worker is always at fault but overworked and excused. The communication overhead justifies creating more managers.

Related Anti-Pattern: Value Stream Backwash where analysts specify more projects than workers have capacity to deliver. Again, often solved with more analysts.

Posted: October 20th, 2007 under Uncategorized.
Comments: 1

My 2nd grade daughter earned a place on her school’s FIRST LEGO League (FLL) Robotics team.

“You were chosen based on your ability to work well with your team during tryouts and how well you cooperated with others.

We also looked at your ability to problem solve, on your own and within the group, your endurance with the task, your ability to follow directions, and your handle and care for the pieces, as well as your overall interest and enthusiasm for robotics and the task at hand.”

What a great description of collaborative development! I’m so freakin’ proud.

FIRST is Dean Kamen’s foundation “to create a world where science and technology are celebrated… where young people dream of becoming science and technology heroes”

Posted: October 19th, 2007 under Uncategorized.
Comments: 2

At the precipice of change, we are getting sentimental here at the Oh! Network.

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…

From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

– Ken

From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am - 1pm and 2:30 - 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke

From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

– Ken

From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

– Ken

Posted: October 18th, 2007 under Uncategorized.
Comments: none

I have to admit to some confusion over the verb forms of affect and effect. The free dictionary has this helpful note:

Affect and effect have no senses in common. As a verb affect is most commonly used in the sense of “to influence” (how smoking affects health). Effect means “to bring about or execute”: layoffs designed to effect savings. Thus the sentence These measures may affect savings could imply that the measures may reduce savings that have already been realized, whereas These measures may effect savings implies that the measures will cause new savings to come about.

So an agilist should effect positive change not affect it and affect impediments not effect them.

Posted: October 14th, 2007 under Uncategorized.
Comments: none