A complex “governance” process sounds like a problem rather than a solution. Agile done right keeps you on course in a very simple way: every two weeks you demo a working system, and the only work you do is towards specific customer-facing features.
FWIW, I’ve seen many teams focus on the two week demo, and, not all the time, but often I’ve seen it end in they only work on things that look-cool demoing and not necessarily things that might help them. For example, tech debt tends to not be very demoable. One can always say “well they aren’t doing it right” but that also has been a problem in the times Agile has been a negative experience: people often don’t know how to do it well. I’m not saying it’s always bad or whatever, just that it’s harder to get right than just being agile.
I’ve seen Agile lead to working with a higher technical debt load than developers wanted to, but often that was actually the level that was best for the business. Particularly for a weak team, trying to make a codebase better as a task in its own right can easily do more harm than good; making sure each codebase change is driven by a specific customer- facing feature, as Agile does, helps keep you on track.
Everything hangs on correctly applying governance tools and methods, and it can take a great deal of experience and a lot of failed experiments before you get that right. But the better you get at it, the more likely that you’ll really be in control of your project, in the sense of consistently steering it toward the optimal result.
Agile as described here is waterfall, but fast, with a huge emphasis on process and top-down control and where that control is exercised (at the top of the waterfall start of each sprint).
Seems like he had the answer in the first few paragraphs: Ideally, the people determining the scope and timing of the work should be the people doing the work. After that, he went elsewhere.
“I’m thinking of a larger program of work in which an entire solution has to be designed and delivered, (more or less) complete. Such projects have distinct beginning, middle and end phases, all of which must complete successfully if the project is to succeed.”
AFAIK, that’s not really a thing to which one applies Agile.
Why not? My company just did this for a year-long project, and it has worked out spectacularly well. We are nearing the end of the project, and everyone is really pleased at how it has turned out and how well by-the-book Scrum[1] worked for the process.
[1] I prefer Kanban, but doing Scrum by the book is actually pretty good compared to Flaccid Scrum
A complex “governance” process sounds like a problem rather than a solution. Agile done right keeps you on course in a very simple way: every two weeks you demo a working system, and the only work you do is towards specific customer-facing features.
FWIW, I’ve seen many teams focus on the two week demo, and, not all the time, but often I’ve seen it end in they only work on things that look-cool demoing and not necessarily things that might help them. For example, tech debt tends to not be very demoable. One can always say “well they aren’t doing it right” but that also has been a problem in the times Agile has been a negative experience: people often don’t know how to do it well. I’m not saying it’s always bad or whatever, just that it’s harder to get right than just being agile.
I’ve seen Agile lead to working with a higher technical debt load than developers wanted to, but often that was actually the level that was best for the business. Particularly for a weak team, trying to make a codebase better as a task in its own right can easily do more harm than good; making sure each codebase change is driven by a specific customer- facing feature, as Agile does, helps keep you on track.
Agile as described here is waterfall, but fast, with a huge emphasis on process and top-down control and where that control is exercised (at the
top of the waterfallstart of each sprint).Seems like he had the answer in the first few paragraphs: Ideally, the people determining the scope and timing of the work should be the people doing the work. After that, he went elsewhere.
“I’m thinking of a larger program of work in which an entire solution has to be designed and delivered, (more or less) complete. Such projects have distinct beginning, middle and end phases, all of which must complete successfully if the project is to succeed.”
AFAIK, that’s not really a thing to which one applies Agile.
Why not? My company just did this for a year-long project, and it has worked out spectacularly well. We are nearing the end of the project, and everyone is really pleased at how it has turned out and how well by-the-book Scrum[1] worked for the process.
[1] I prefer Kanban, but doing Scrum by the book is actually pretty good compared to Flaccid Scrum
That’s great to hear!