(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."
About the author
Guy Beaver is the CIO at Perfect Commerce, a software company that provides SaaS procurement solutions for large corporations. At Perfect Commerce, he leads and oversees the development, delivery and support of all Information Technology. Guy's career of over 25 years spans several industries including Aerospace, Financial Services, Healthcare, and Procurement. He co-authored the book, Lean-Agile Software Development: Achieving Enterprise Agility.
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
