Monitoring and incorporating feedback at every level, from continuous compiling, to continuous integration, to retrospectives, to customer meetings, is a key to success. Choosing the length of the feedback loop can make or break the project.
In an attempt to bring together development on three related, but different, efforts we are employing some Agile Practices. Chief among the practices are Short Iterations, Feature Based Management, Planning Meetings, and Daily Stand-ups. Of the four projects, two are development, one is Operations and Maintenance (O&M) on the software delivered from the first 2, and the fourth is an O&M contract for maintaining system architecture and direction. Each is a separate government contract with different prime contractors. The teams are widely distributed around the world, from Hawaii, to Colorado, to Washington DC, to England. There are no reporting relationships between the contracts, no formal interfaces, and no contractual obligations. In order to make progress toward any goal, the hearts and minds of the other contractors must be won. The total number of people on the collective products is about 15.
After about 3 months things were coming together:
· All 4 efforts were on the same 6 week cycle
· Everyone was workingSingle integrated Product Backlog
· One development team doing Agile
o New development
o Continuous integration
o Automated Test
o 2 week iterations
o 2hr to 2 day features tracked in a cycle backlog
· Second Development team was Modified Agile
o Support for operational system
o Extensive new development
o Co-located with users
o Daily deployments to a test network for user feedback
· O&M working 2 week tasks
o Deployments
o Consolidations
o System and Database Administration
· System Architecture team working coordination and prioritization
o Gathering customer input on needs and priorities
o Designing Infrastructure Architecture
o Guiding Software Architecture and Development
But after about 3 more months:
· Stand-ups were not providing value
· Design working meetings were not happening
· Backlogs were not being managed
· “What to do next” was not being articulated
· Long term goals were not being communicated
And – great software was still being produced, and operational systems were operational!
So, here is what we did:
· Suspended daily stand ups – A well architected project/system should minimize dependencies
o Each team communicated as needed – cross team coordination was minimized by the separate missions, so daily meetings were not necessary for the developers
o Teams continued development with successful practices including Continuous Integration, Automated Test, Feature Driven Development, and Planning Meetings.
o Re-emphasized one-on-one communications instead of stand-ups.
· Established development design meetings
o Where common code and frameworks were necessary, the teams needed to work together. These were low level technical meetings, not 15 minute updates.
o Oversight team facilitated the first few meetings. Multi-time zone design meetings can be difficult, especially when some of the team members have never met face to face.
· System Architecture team meetings with teams and individuals
o Continued to meet with customer to gather input
o Managing backlogs
o Communicating direction to development team
The Feedback loop is key. As with everything new or different, it takes a while for Agile practices to settle in and become productive. Sufficient time must be given to ensure the break-in period happens, and then the feedback can be incorporated.
Using Stand-ups when they are not indicated does not make you Agile.
Abandoning Stand-ups after a few days doesn’t make sense;
Valuing communication, even in the absence of Stand-ups, does.