Tag Archives: head

Benefits of Agile Adoption – from a manager

Posted on by

To help some peers advocate for agile adoption, I prepared an experience report to demonstrate how my old team benefited from XP and Scrum practices. This is an extension and refinement of an earlier post on the benefits of XP.

Team Cohesion

yellow rope with knot by limonada on flickrBefore and during our agile adoption, I informally administered the Gallup Q12 employee engagement survey. It is composed of twelve simple questions. Agreement correlates to retention, customer loyalty, safety records, productivity, and profitability.

From the beginning to the mid-point of our adoption, staff went from a response rate of 70% agreement 30% disagreement to 80% agreement, 15% neutral and 4% disagreement.

The most improvement was in daily opportunities “to do my best” and daily feedback on performance and expectations.

I’m convinced if I had administered the Q12 late in our adoption, we would have had even better results. The key un-addressed concerns were about having a best friend at work and feeling connected to the mission of the company. By 2007 our team grew to include people brought in by personal recommendation of other members of the team and our portfolio included consumer facing work directly for our CEO.

Rather than re-take the Q12, we undertook a 360° performance review. That we did this on our own initiative shows just how much trust we had built with each other.

Test Coverage/Code Quality

Green Light by wiccked on flickrXP practices enforced methodical unit test coverage, mutually arrived at coding conventions, and real-time code inspection by multiple members of the team. The team went from no unit test practice to comprehensive coverage over the business logic and controller layers. (Unit tests against data access and gui were less comprehensive. I don’t intend to get in the middle of that debate here.)

A user story, test-driven approach to development has been shown to reduce defects in final testing by 40%.

XP and Scrum force conversations between the development team and product owner that incentivize all to build quality into the software rather than allowing technical debt to accumulate and relying on downstream QA process to fix the application.

In 2006-2007 there were no business impacting failures of our internally authored software. We were able to function as a project team with no dedicated developer maintenance staff. Change requests were minimal enough that we were able to prioritize them into our project sprints as overhead.

Reduced Risk

While any team has experts, “Agile” practices reduced our reliance on “specialists”. The entire team was capable of working on and maintaining any aspect of the code base. We passed the “bus test”; despite our small size, no project was at risk if any given member of the team became unavailable.

Leadership

Our team raised our skills and began contributing to our field. We write, present and teach at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases.

Recruiting and Retention

After establishing “Agile” practices we recruited skilled candidates from higher paying positions who desired to work in our culture and with our practices. We received inquiries from as far away as South America and Europe. Despite the reputation of our team and market demand we retained staff.

An additional benefit is that pairing provided an efficient on-boarding process for new hires. Developers joining the team provided immediate contribution. A metrics-based way to demonstrate this is to show that sprint commitments weren’t affected new hires first weeks. I observed that but mainly base this on comments from the team lead and existing members of the team.

Workplace Diversity

A 2006 paper by McDowell, Werner, Bullock and Fernald found that pair programming practice, “may help increase female representation in the field.”

Agile values and practices support a collaborative, empowering and sustainable work place. Such environments support diversity and take advantage of the breadth of experience each worker represents.

Client Satisfaction

We asked for quotes from our clients, vendors and even competitors which we included in our budget presentations (I’ve pretty aggressively scrubbed them):

“Working with the agile Software Development team has been rewarding on many levels…it’s a team that celebrates creativity, organization, listening, feedback, openness, honesty…and is proof positive that a great process results in great product. I look forward to our very regular meetings (I even readjust my travel schedule as much as possible to not miss anything) and am never disappointed. They are an engaging and engaged group of individuals.” – CEO

“[____ saved] half a head in [another team] and a full head in my team.” – VP

“The _______ written by our development team are the guiding-light to our decisions. [third party solution] has a vast wealth of information but no good reporting and our in-house [solution] enables us to divine meaning from the mountain of data.” – VP Traffic Operations

“We also use [third party solution] for all of our broadcast networks but I have heard about your software technology for ____. We currently do that through manual operators but I’d like to understand how you do that more sometime and how it works…” – Senior Executive, Competitor

“Given the complexities of ____ that includes the combined limitations of automation, graphic and traffic systems I believe [the team] has created a solution that has proven to be much more capable than most systems than I’ve worked with.” – Vendor

Frequent Delivery, Adaptability

Throughout 2006-2007 our team of 3-8 developers balanced two simultaneous lines of work on diverse projects built in Microsoft Windows Forms, ASP.NET to SQL Data Analysis Services Data Warehouses, Vista compatible Windows Presentation Foundation and XAML, open source .NET MVC frameworks and Ruby on Rails including a rich windows application built on beta Microsoft Technology.

The team completed eight IT and three consumer projects while doubling head count from 5 to 10 (+2 contractors). We initiated our consumer product initiative and achieved our first release of a rich windows application with a six month allocation of effectively 1.5 – 2.5 developers.

Invention/Innovation

Agile practices evolved from Lean management and associated knowledge creation theory. In this, it shares ancestry with Six Sigma.

Agile is based on empirical not plan-driven process control. It is closer to lean product development than lean industrial manufacturing.

Lean product development models sustained innovation as a process of knowledge creation and conversion within an organization that acquires and shares learning in an cycles within and across teams and up and down from leadership.

Agile fosters true joint work which is the only form of workplace collegiality that advances organizational change and innovation.

Our consumer product was recognized for its design and implementation by Microsoft’s platform and developer evangelist team as well as by the WPF team. It achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.

Inspect and Adapt – A Fable

Posted on by

There once was a carpenter building a metal box. Try as he might, he couldn’t get nails to stick into much less attach two pieces of metal.

Apparently, other people were having a lot of success using nuts and bolts. So he got some.

Hammer as he might, all he ended up with was dented metal and bent bolts.

Tools - collage made with Ript

So he consulted an expert. Careful observation indicated the expert used a screwdriver. Great! He happened to have one in his toolbox.

He noted that the useful part of a screwdriver was the slotted tip at the end. So, he cut it off and taped it to the head of his hammer.

After one strike, the tip broke off and fell to the floor.

“Boy, my hammer is really letting me down,” he thought to himself. “I guess I’ll have to use the whole screwdriver.”

He went to the store and bought another one.

Once he got home, the man held it in his hand. It didn’t feel right. Any decent tool has a grip that goes at right angles to the head. He found a piece of wood and attached the screwdriver to the end.

That felt a little better but the screwdriver was very light. No decent tool was that insubstantial. So he attached a weight to the tip. That felt better! Now he was making progress!

Confident in his tool, the man pounded away at more bolts.

He managed to make a dozen deep scratches and bend several bolts before the screwdriver broke.

“That was worse than before! Screwdrivers are really overrated and it took so much work before I could even use it, ” the man said to himself.

“I’m not making that mistake again. I’m going out and get a really good hammer!”

Love of Craft

Posted on by

My wife is a trained Ringling Brothers Clown College Clown.

Clowning is a difficult profession. It doesn’t receive much respect. It’s hard work. Physical comedy can easily wreck your health as quickly as it drives you broke. Material success means getting to work.

But clowning is a craft with roots as old as performance itself. True practitioners bring great discipline and joy to their work. A talented clown relates to their audience with the spontaneity and innate intelligence of a child while employing a mastery of performance honed by years of training. Good clowning is surprising, stunning, human and hilarious.

However, the level of talent, skill and training vary to extremes. There is no official apprenticeship process. When people think of clowns, they’re often thinking about amateurs who’ve had very little exposure to the work of veteran performers.

It’s easy to be a frighteningly bad clown. Many amateurs paint both the top and bottom of their mouth with a broad stripe of red makeup. They turn their character’s mouth into a gaping maw large enough to devour a child’s head.

If you ever get a chance to hang out with experienced clowns you’ll find out how embarrassed they are by bad performers with horrifying makeup and costume, few skills and little respect for the history and rituals of clowning.

I’d say the difference between what I do and what my wife does is that software developers earn a lot more money and are a lot less fun to watch. Still, what I do is also a craft. To do it well requires aptitude, discipline and apprenticeship. Just as in clowning, there are common mistakes perpetrated by bad or inexperienced developers.

Similar to my wife’s clown college class mates, I feel great pride in my craft and in those who take it up with talent and integrity. I also feel frustration, disappointment and a little outrage at peers who strive for less.