This article is a collection of conversations that demonstrates some of the tangible and intangible benefits of successful agile implementation. The idea grew from a corporate engagement to pilot agile methods in a heavy process-focused organization. We added conversations from other agile teams that demonstrate characteristics of successful implementation. Some of the conversations were written down during sprint retrospectives, but others were documented as part of a concerted effort to simply observe some of the behaviors and dialogues of collocated individuals in a real agile environment.
We are passionate about setting up successful agile implementations and watching empowered, self-organizing teams create real business value, giving the business unit a tangible competitive advantage. Juxtaposing this team behavior against behaviors learned in a process-focused, waterfall organization reveals the right way of solving empirical problems with smart people—rapid feedback is fundamental in a complex adaptive system. For organizations wanting to move to the lean/agile software development model, guidance from experienced professionals will help facilitate these types of conversations and ensure that the organization is adequately staged to lead agile teams with vision and right-sized, prioritized work.
Look for similar conversations in your agile organization to ensure that healthy teams are creating business value at the most rapid, sustainable pace.
Who Is Doing What?
Line manager to ScrumMaster, reflecting on successful software release...
Line manager: "I'm amazed at how the team can rally around stories and get them done with little or no task assignment. The team commits to the stories in the planning session, and then seems to get done whatever we make visible. When was the last time you assigned tasks to individuals on the team?"
ScrumMaster: "I've never had to..."
No One Had to Call Me ...
Sprint Retrospective: Developer was describing the benefits of constantly pairing up with team members and feeling confident that he not only understood all the code, but that his code was well understood by others. This developer just closed on a house, and had to take time off to do the normal closing and moving activities. This developer had previously worked on "Old Waterfall Project":
Developer: "I know that pairing up with different people works—with just a few days left in our sprint, I received no phone calls about my code while I was away, because the agile team understood it ... "Old Waterfall Project," however, called me twice for questions about code I wrote for "Old Waterfall Project."
Who Built This?
(Collocated team in open, agile area)
UI Designer (stands up, holding a screen shot): "Who built this?"
UI Developer: "I did."
UI Designer: "Come here a minute ..."
UI Designer and Developer point to a computer screen, have a quick discussion, and Developer says "OK," I'll fix it right now ..."
(Swarming) You're Done Already?
Developer 1 (coming back to his cube and finding Developer 2 typing away): "What's that?"
Developer 2: "I wrote a method to allow the background color to be passed into the Flash component."
Developer 1: "That's impressive, but the color is yellow, I think it's supposed to be putty brown."
UI Designer (overhears the conversation): "If you want the tag code for putty brown, it's 'F7F7E8.'"
... within seconds, the team is staring at a completed Flash component displayed on a real screen that allows simple change of background color.
Peer Pressure
At the end of the daily stand-up meeting, a high bandwidth communication breaks out:
Developer 1: "Before we break, I've seen some 'to-dos' in the code. We should spend some time going after them."
Developer 2: "Everyone should take some time to close on them. Developer wrote a tool to summarize them from the logs, so get with me after this and I'll show you how to run it."
The end result is that several team members quickly synchronized on technical debt (build up of "to-dos" in the software) and rapidly formulated a plan to get rid of it. It is very powerful to get team buy-in with this type of collaboration and visibility.
System Test-Driven Design
Sprint planning session (sprint day 1): The team is discussing estimates for a screen where the user enters information and a calculated result is returned ...
Mid-tier Developer: "Looks like you'd want to store this in a table and retrieve allocation data based on the delta between 'input 1' and 'input 2' ..."
Systems Tester: "For me to test that, I'd want to be able to change the allocation table and make sure that the results change with the 'input' delta ..."
UI Developer: "How about a page that lets you change the table to help testing?"
Product Owner: "Sounds like something that business would need to make changes to the application."
ScrumMaster (to business systems analyst): "Let's write a story that describes this feature and put it in the product backlog so we don't forget about it. Let the product qwner determine its priority."
Result: Uncovered a major impediment during estimation, juxtaposed with typical systems tester sentiment: "I feel like the bad guy."
Business Client's New Problem ...
Business client: "This project approach (agile) now puts the focus on me. The team delivers product so fast, I have to get business decisions made much quicker than on waterfall projects ..."
Prior to the agile pilot, business clients never had a sense of urgency to get answers for development teams, since projects were so long in duration. With rapid delivery every two to four weeks, the business clients now appreciate the development team's need for rapid answers.
The Value of Priority
ScrumMaster: We've estimated 2700 hours of work, but the capacity of the team is 2500 hours. We have two choices: delay the lowest priority item 'feature' until later, or extend the sprint five days and slip the elevation date by five days ..."
Product Owner: "We'd rather make the planned date, so let's delay 'feature'."
Business Client's New Agile Role ...
Product Owner (after three sprints, looking at the backburner outside his office): "I feel like a chef, and this is my kitchen."
You Get What You Pay For ...
After seeing productivity metrics (LOC/PersonHour) of the agile team compared to the prior outsourced team. The collocated agile team was producing higher quality code (backed up by automated unit tests) at ten times the rate of the outsourced distributed team ...
CEO: "I can't afford to outsource."
Cross-Training, Role-Sharing
A new agile team made up of specialists not used to pairing up had to get over the desire to create documents. UI tier specialists and middle tier specialists were notorious for spending long design periods creating API documents to base their coding activities. Working together (paired up) they soon realized that the documents were not needed. Instead, they quickly agree to the interface and code both sides. An unintended benefit was that each specialist quickly learned the designs and practices of each specialty, and was quickly "cross-trained."
A real quote from a sprint retrospective was "I'm confident now to code in both tiers." This allowed the agile team to adapt to changing demands from sprint-to-sprint versus being dependent upon the organization to supply varying numbers of specialists based on each projects estimated demands.
Cross-Training, Role-Sharing Part 2:
Product owner (during sprint retrospective): "I'm amazed at how I can go to any person for any issue, and he or she can answer my question. There's no silo of expertise."
Intern Thank You Note ...
A college summer intern who worked on an agile team sent a thank you note. It's obvious that a well-formed agile team offers a great intern experience for the right candidate. Paired programming and daily completion of end-to-end work allow the intern to learn immeasurable design, architecture, and coding skills, mostly through osmosis:
Intern: "I am writing to thank you for giving me the opportunity to intern this past summer. The experience was of immense value to me, not only through the technical training I received but also through my exposure to agile management techniques and to the energy and excitement of a living, breathing start-up venture.
"I want to thank you for treating me as an equal member of the team and giving me the opportunity to make an immediate contribution to the company. By allowing me full freedom, you maximized the value I could add to the development team and helped me learn much more than I would have had I been constrained to more menial tasks.
"During my time this summer, I was impressed with not only your agile management techniques but also your skill as a manager. You gave the team 'just enough' management, empowering us to make decisions and generate new ideas while instilling in us a strong sense of the company's priorities. You accepted responsibility for any shortcomings (such as overextended sprints) and gave all credit for successes to the team. You played less the role of manager and more the role of facilitator by providing a positive working environment and any required resources and then getting out of the way. From what I've learned in my business courses, this seems to be an ideal way to approach management ... "
Summary
One of the inspiring outcomes of building a collocated team of individuals guided by common vision and goals is that conversations will appear that demonstrate team learning. This team behavior is one of the hardest implementation tasks of agile management. It can't be forced, but instead is an outcome that experienced coaches look for as validation that the agile engine is operating at its peak efficiency. Management should listen for conversations similar to those above as signs of a healthy team.
About the Author
Alan Chedalawada is president and senior consultant at Net Objectives. Alan has a proven performance record with corporations such as: EDS, Computer Associates, IBM, Cable Wireless, Telia, Deutsche Telekom, ATamp;T, Calvin Klein, OMO Norma Kamali, as well as several entrepreneurial startups. Alan's experience spans the manufacturing, telecommunications, technology, finance, energy, and distribution industries.
