In a recent conversation, a technical manager I had just met was describing to me how agile is not a fixed form - it's the ability to change the shape of the organisation to the needs of the time. That's what it means to be agile - to adapt.
With his hands, he indicated his two ideal shapes - the triangle, with its implied hierarchical management approach, & the circle, which encloses the whole team. Sometimes, you need to have a structure, but sometimes you need to flatten it out & work together.
Those two shapes don't just describe the team, but also the delivery pattern. The traditional waterfall model starts at a point to build solely on that, then, when the point (call it project inception) is correct, a larger layer is built (project definition), etc. That triangle could be considered upside-down, but it is the same basic shape.
An agile circle shows how the project is iterative - it produces something today, but continuous integration suggests that this is the state of the whole project being delivered at each sprint, becoming more complete in functionality, but a whole throughout. You should always see the big picture as the goal of each sprint, with functionality being contributions to the whole. When you are building your triangle, layer on layer, each layer is a complete goal in itself.
The reason some people devolve to waterfall models is because they say that the client understands twaterfall better. A client will pay for a fully delivered stage, rather than paying for 50% of the functionality. I don't think the client has the problem here - it's in the way that the project is represented to the client. Unless the client is determined to axe the project if the design (for example) isn't up to scratch, they are effectively committed to the deliverable - they want the outcome.
Managing the client's expectations - keeping them informed & taking their feedback - is a key component of agile, & is supposed to make the whole project management aspect both more client-friendly & less likely to give the client a surprise than the "big drop" of a waterfall project completion. Hiding project status from the client is not only not agile, but sounds like bad business.
Some even hide an agile internal process behind a waterfall delivery system - intentionally keeping the client in the dark. Again, this is not really agile.
So, what's the answer - what shape should your project be in? I think you can take the De Bono approach. When he uses six frames to solve problems, he provides a framework for simply focusing on different aspects of the problem, without prejudice or preconceptions. With practice, you can look at any project & say "Where is the waterfall-ness here?" "In what way are we being agile?" "How is our process differing from pure scrum?"
By all means, use your fingers to make the shape & "look through" that frame to see your project or your team differently, if that helps to expand your vision; but remember that it doesn't change the project in any way. To make changes - process improvements, better client engagement, quality, repeatability, etc - you have to go beyond the circle & the triangle & operate in the third dimension - effort.
No comments:
Post a Comment