Recently I was asked to serve as mentor for two "e;agile"e; teams. Both had been practicing agile methods for a little over a year. Specifically, they were using Scrum, but I’m convinced that that doesn’t matter much. In both cases my initial contact was with the team coordinators, and both of them made a fantastic impression. They talked about ecosystems, incremental processes, teams that could self-organize, satisfy their customers, implement good design practices, even though because of the Scrum box they’d opted for a less extreme path than TDD, and they’d chosen not to do Pair Programming. More than once I wondered why they’d called me. Even when I talked to the teams, I kept on living in an ideal world, made of colored papers stuck up on the walls in a balanced and orderly way, active team members having meetings with their customer and monitoring their own progress.
Again I wondered – in both cases – why did they call me? I asked to see their code, thinking “thrill me”. And that’s when it hit me – I realized why they called me. Both of them. Despite the brilliant preliminaries, the code they produced was catastrophic.
The usual bad code, to tell you the truth. Full of IFs, exceptions, coupling of heterogeneous logics, etc. Experience told me that in a short time both teams would slow down and stumble over the rigid, fragile design.
After checking out the developers’ ides, I noticed that in both cases the project coordinators talked to me with different words. They might have felt like a burden had been lifted off their shoulders. I never doubted their sincerity, but maybe now they were more aware of the reason why for some time things taking a turn for the worse, why they had a nagging sense of oppression, a feeling they had to chase after events, that the advantages they should have been enjoying they were actually experiencing less and less.
I thought that this was a case of “photo XP” syndrome again. But unlike the teams two years ago, these teams were none-too-aware of what XP and agile methods were. These teams were capable of theorizing, arguing, and explaining (and believe me, even quite convincingly) their agile experience. But they were incapable of realizing that experience effectively. I immediately thought of my team at XPLabs and the teams I coach and I wondered what criteria a team might follow to figure out that they may seem agile, but they’re grabbing hold of the agile peel and throwing away the best part of the banana.
No one on those teams knew how much effort was dedicated to bug fixing. No one gathered or systematically processed product metrics on the design quality of the code the team produced. No one knew how much effort was expended on analysis, design, and development. Both teams understood the importance of self-observation, but in actual fact they didn’t know how to apply the process. Both teams realized the importance of design, but they didn’t get beyond the use of a class diagram drawn up on the white board.
