FPFM: Development Team Growth Leads to Quality Chaos
Written by Ed Willis
Saturday, 11 May 2013 18:36
Rapid growth in the development team leads to chaos. I've seen that a few times now. Some of it is a question of who is assimilating whom - you see that when you grow crazy fast. But in general, growth in the product development team has nearly always led to quality problems, even when you make concerted efforts to ensure new recruits are brought into the local quality culture. One reason this happens is that a quality process that's just acceptable for ten people won't be when you grow to twenty five. Certainly you can't expect your modus operandi to scale from there to a hundred people without serious changes - but we don't tend to think of the problem in that manner. We tend to think of growing the team, of expanding capacity. We don't tend to think of growing the development process to accommodate our expanding teams.
Consider a five person team of solid developers. Each developer operating within the organization's development process will only make a mistake leading to a severe quality issue once a year - think a breakage in the product's essential sanity that disrupts the work of a majority of the people working on the product. One boneheaded mistake a year for each developer - pretty good, I would think. If we take a look at what quality looks like for that team over a year, it's about what you'd expect - major problems only come up once in a while.
Now the team expands due to their success - they grow to twenty developers. They hold firm to their process and make sure new people are every bit as good as the team members they are joining - seemingly a solid growth plan. But let's look at the stability of their product now - suddenly issues aren't all that infrequent and sometimes we even see more than one appearing at once. Still, things seem fairly stable, for the most part.
Success continues to rain down in them and with it comes commensurate growth - this time the team explodes to 250 people. Still, they somehow manage to hire people just as good as they already have and similarly manage to integrate them just as well as their predecessors. Despite this, their year together is utter chaos. Severe quality issues are near-daily occurrences and it's very common to see more than one of them at a time.
Now, consider that in this analysis, I've really been pretty generous. Odds are that if you grow like this you won't hire people as good as those you started with. Odds are that maintaining the per-developer level of quality will elude you in the face of this kind of growth.
Also we've not discussed anything about the problem or solution domains - we could be talking about internal web applications or software for controlling nuclear power plants. It makes no difference - as your team grows, so must the quality bar rise.
Last Updated on Thursday, 13 June 2013 18:09
When not to Scrum?
Written by Ed Willis
Thursday, 05 April 2012 00:00
In Scrum training sessions, someone would invariably ask variants of these questions:
What kinds of projects aren't a good fit for Scrum?
When would you advise against adopting Scrum?
I always managed to get caught flat-footed by those questions. I'd stumble through some sort of response but all the while I knew I hadn't really given the matter enough thought. This article is intended to address that.
Getting started in process improvement: what should we work on first?
Written by Ed Willis
Wednesday, 28 March 2012 00:00
When I was working my way towards becoming a CMMI SCAMPI B&C Team Leader, I took a couple of courses with the SEI. It was an interesting bunch of people that attended those sessions - largely the haute process crowd from the Raytheons and Lockheed Martins of the world, swapping war stories about their drives to attain CMMI Maturity Level 5. As for myself, I was barely paying attention during my Intro to CMMI training when they covered anything above capability level 1. I figured I'd never need to know this stuff - it was never going to come up.
My fellow candidate SCAMPI B&C Team Leaders thought it adorable when I told them my experience with the CMMI and appraisals had all been at capability level 1. Whereas they likened themselves experts in high maturity, I told them I liked to think of myself as a bit of an expert in the low maturity organization. When they laughed at that, I asked them how big their market was - I'm pretty sure mine is enormous :)
Eventually I got my authorization and started leading appraisals. At the end of each one we would have a final briefing with the sponsor. The intent of this meeting was to give the sponsor the opportunity to ask questions about the appraisal findings in a private setting. In every single one of these briefings, the sponsor would ask us "what should we work on first?". As appraisal team lead, I'd have to answer that question - and in the early going, I'd always say something weasely like "estimate the value and cost of each one and then build a plan that delivers the most value while keeping cost to where it won't prove a distraction from your day job". I think I can do better that that now.
At the time, my own organization was fairly small - as we grew and I saw the kinds of problems we encountered in our own nascent processes, I realized the real turning point for us had come when we started with Scrum. What Scrum did for us in the early going was give us:
An effective planning model.
A way to get our stakeholders to trust us (because we were now meeting our commitments most of the time).
An on-going focus on improving ourselves and a way to get those improvements prioritized and implemented.
That first bit was key though - Scrum taught us to plan better and that one improvement led to everything else we were ultimately able to accomplish.
After this experience, I had a much better answer for people in low maturity organizations looking for guidance in taking their first steps down the process improvement path:
Get better at planning.
If you can plan well, you can do anything else.
Last Updated on Thursday, 29 March 2012 23:09
Hiring developers: in the software biome, attrition is death
Written by Ed Willis
Tuesday, 20 March 2012 00:00
I once knew a senior manager who, when asked about a well-respected person who had just left their organization, commented that he didn't know why they'd left but that attrition was a necessary part of personnel management. As an outlook on attrition, that's just plain wrong. Rationalizations like these equate whatever successes the organization has had with the methods in place - so if those successes have been had in an environment that historically saw a high degree of personnel turn-over, then that must be a part of how those successes were achieved. But market success does not imply operational excellence.
In evolution, the genotype is the genetic code for an organism while the phenotype is the organism itself. If we posit the existence of a real Blind Watchmaker, he'd be an entity that throws spaghetti at the wall in terms of genotype but studies the phenotypic outcome (that is whether or not early death prevented the propagation of the genotype for that organism) to determine the value of genotypic traits. This imagined Blind Watchmaker would then be dependent on death as his only source of information regarding the phenotypic quality of genotypic traits. Leaving aside forms of Lamarkism, that's a pretty scarce source of information for the poor Watchmaker. In a development organization however - the local development biome - management has a lot more leverage on the situation. Equating genotype with the software developer's inherent traits and characteristics, the environment with the operation of the development organization as a whole (its culture, projects, history and so on) and the phenotype with the outcome of a given developer's tenure with the organization, it's clear that a manager can exert a lot more influence over the biome than can the Watchmaker.
But in the end, phenotypic failure is the most important piece of information in both systems - in software development, phenotypic death is termination of a developer's employment with the organization. Firing and attrition are death - and with some estimates putting the costs of attrition at over $150K per occurrence, it's the wise manager who looks at every occurrence as an opportunity to improve the selection process in hiring or the biome itself.
Why did they leave? Why did we have to let them go? How can we use this painfully bought feedback to make the organization better?
So whatever you do, don't take a laissez faire attitude to attrition - if you do, better managers will clean your clock for you.
Last Updated on Thursday, 15 March 2012 14:48
Scrum in 15 minutes
Written by Ed Willis
Sunday, 18 March 2012 23:29
In this video I present Scrum staying close to the canon as it is described on scrum.org. All major aspects of Scrum are covered. This video should be a useful starting point for people wanting to start to understand Scrum and whether or not it will make sense for them in their work. I hope it proves useful.
Handouts accompanying the video are available here.