![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Software, projects, and teams.
Apr. 25th, 2018 10:13 pmDiscussions elsewhere about this article on scrum methodology for software projects prompted me to have many reckons about doing these things right. So let's put them here, too.
I'm not sure I've ever seen a functional team doing "pure" scrum. Heck, even "pure" agile. I think it's probably best treated as a first step, rather than a fully-realised development methodology. Indeed, a lot of the pain points seem to come in when people try to treat it a the fully-realised development methodology that it simply isn't.
A good development framework is strong but flexible. It scaffolds the thing you're building, and doesn't get in the way of it. Too brittle, it splinters. Too heavy, it collapses under its own weight. Too little attention to structural integrity, and it can't hold together. In each of those cases, the project - and the workers - come crashing down in a screaming heap.
Furthermore: effective processes for building a Thing are different from the effective processes for building a Team. If you're relying on a project management tool to do the heavy lifting for the team's leadership needs, you're a damned fool and your project is probably damned too. Management and leadership are complementary and non-interchangeable skillsets. They don't always need to be concentrated in the same people, but they need to be present and actively engaged.
Scrum does put a lot of emphasis on having a product owner and them being responsible for triaging the things that are valuable to work on next. This is useful, but only to a point. When you have a team full of technical professionals, accomplished in the art and science of their jobs, you have a wealth of domain knowledge that can and should be part of the equation for determining what "valuable" means.
It is vital, for both technical and human morale reasons, to treat your professionals as professionals - and this means involving them in the whats and whys of the project, not just the hows and how-longs. It means developing Will to go with the Skill, both as individuals and as teams.
The movement of information and flow of decision cannot just be a top-down "push" process. The people doing the work need to be enabled - and supported - in pushing back when they see a product owner's priorities are out of whack. If there's a good chance your wheels might fall off at speed, you should fix that first no matter how much your product owner really wants a supercharger installed. This is a common agile failure mode, and something you should protect against in your contracts / statement of work. A customer who can't or won't understand the basic principles of quality assurance and risk mitigation is probably one you should be walking away from. Before they take you down with them.
(This post inspired in various parts by the works of Lev Vygotsky, Abraham Maslow, Col. D.M. Malone and Mike Monteiro.)
I'm not sure I've ever seen a functional team doing "pure" scrum. Heck, even "pure" agile. I think it's probably best treated as a first step, rather than a fully-realised development methodology. Indeed, a lot of the pain points seem to come in when people try to treat it a the fully-realised development methodology that it simply isn't.
A good development framework is strong but flexible. It scaffolds the thing you're building, and doesn't get in the way of it. Too brittle, it splinters. Too heavy, it collapses under its own weight. Too little attention to structural integrity, and it can't hold together. In each of those cases, the project - and the workers - come crashing down in a screaming heap.
Furthermore: effective processes for building a Thing are different from the effective processes for building a Team. If you're relying on a project management tool to do the heavy lifting for the team's leadership needs, you're a damned fool and your project is probably damned too. Management and leadership are complementary and non-interchangeable skillsets. They don't always need to be concentrated in the same people, but they need to be present and actively engaged.
Scrum does put a lot of emphasis on having a product owner and them being responsible for triaging the things that are valuable to work on next. This is useful, but only to a point. When you have a team full of technical professionals, accomplished in the art and science of their jobs, you have a wealth of domain knowledge that can and should be part of the equation for determining what "valuable" means.
It is vital, for both technical and human morale reasons, to treat your professionals as professionals - and this means involving them in the whats and whys of the project, not just the hows and how-longs. It means developing Will to go with the Skill, both as individuals and as teams.
The movement of information and flow of decision cannot just be a top-down "push" process. The people doing the work need to be enabled - and supported - in pushing back when they see a product owner's priorities are out of whack. If there's a good chance your wheels might fall off at speed, you should fix that first no matter how much your product owner really wants a supercharger installed. This is a common agile failure mode, and something you should protect against in your contracts / statement of work. A customer who can't or won't understand the basic principles of quality assurance and risk mitigation is probably one you should be walking away from. Before they take you down with them.
(This post inspired in various parts by the works of Lev Vygotsky, Abraham Maslow, Col. D.M. Malone and Mike Monteiro.)
