GrowingAgilePractices2004 Identifying Ways to Promote a more Agile Workplace.
Topic: What do Agilists and Traditionalists have to talk about?
Initiator: Deborah Hartmann
Participants: Rick Innis, Scott Ambler, Bo Hanchuk, George Latkiewicz
Deb had been looking for topics that would draw both Agilist and Traditionalists to an Open Space meeting.
Scott reported that, in his experience, Open Space:
- worked beautifully with groups of Agilists
- failed miserably with groups of Traditionalists
Scott observed that
- until now, Agile has been relatively self-selecting:`people who value collaboration and emergent solutions gravitate toward it, others resist, hence this divide.
- Emergent behaviour is difficult for some traditionalists
- Thought leaders in the Agile and Traditional camps: there is very little cross-over here, so the camps are remaining separate despite the fact that projects are increasingly relying on both of these at once.
- Traditionalists are now being required to join or work with Agile teams
Discussion followed up on this last theme: What Agilists and Traditionalists have in common is that they need to work together in a given organisation. Such interfaces can still exist between:
- Agile developers and Non-Agile: DBAs, QA, Config Management, other software teams
Discussion focused on Data specilists, but other areas probably could be pursued similarly.
Differences between the two groups: (in general)
- o-o vs. relational modeling and paradigm
- continual learning vs. expert empires
- different personality types gravitate to jobs in the two camps
- craftsmanship and generalisation vs. specialisation
- small iterative cycles vs waterfall
- heavily, actively into development vs. removed from actual development
- need employment
- need software tools (however, most have been coming out of the o-oéAgile camps, and are skewed to that kind of work)
- need to work together in one organisation
- require Databases to build software
- need to map objects and relational tables in these databases
- each group requires the other but often adversarial relationship
There was discussion of DBAs who understand both camps and can translate, facilitate between the two.
So Deb asked: do we need to train "blockers" in these areas? Scott countered:
- blockers add only cost to a project (no value add)
- the `blocked`add additional cost as well
- is management aware of these costs?
- if we made management aware, would they encourage cross-training
Ok, so can we replace blocker by conduits? People who
- evangelise Agile
- foster acquiring of new skills by traditionalists
- play a training role
- A suggestion: that we can use 3rd-party training materials, along the lines of Scott`s book Agile Database Techniques or agiledata.org website to encourage colleagues to adopt agile practices for their work. Such books are starting to appear for other cross-team functions as well (QA, SCM).
- once we make them available to them, they have the choice to join and change or stay the same and pay the eventual consequences (some feel the consequence of obsolescence is inevitable).
- The benefits to those who do change: job growth, enter the 21st century paradigm of iterative incremental development, become more effective in their job, benefit their organisation
- Idea: do we need new contracts for people working in these traditional groups? If they are held to non-agile contracts there is no payoff to switching to agile.
- Objective: bring traditionalists and their important specilisations into the agile teams.
- Make educational info more available thru an Agile Reading list wiki on agilenetwork.ca
Article by Scott Ambler on the role of "blockers" on Agile teams. Blockers are a necessary evil to free the team from interference by those demanding non-agile processes and documentation. http://www.sdmagazine.com/documents/s=8269/sdm0307h/sdm0703h.html
Suggestion: if you decide to take this discussion offline to a newsgroup, please indicate the location of the group here so others can join you.