There's a pony in here somewhere ...
I've been using that phrase a lot recently at work. It's really a callout to the process- and procedure-driven; let's open up a bit to a less structured, iterative development / project process. We're implementing a number of things - PMO, project methodology, wiki / KM, stuff like that - that sit at a lower priority level than the "formal" business projects. Most of the forward progress happens during the slack time of the day, nights and weekends, and "deliverables" appear in various states of completion.
Regardless of what most folks say, this is still intrinsically foreign to many folks in IT. I don't believe it is an age-based phenomenon; I notice it more in folks who have worked in large corporate environments, often for more than 5-10 years at the same place. A contributing factor is "career homogeneity"; if one has not worked in a variety of roles, in a variety of industries and companies / organizations, there can be resistance to agile-style projects.
Atwood observes another contributing factor - the tools we use. For many, MS Project is the critical hammer for every nail, and the waterfall mindset is baked into the heart and soul of the gantt chart. Waterfall traps many into the firm belief idea that requirements are understood, defined / definable, and fixed. His pair of posts also reflect on the difficulties of estimating / predicting / scheduling of software development projects - more reason to work on your agile tendencies.
<aside> Note that requirements and change orders can be a critical source of tension, disconnect, "lack of alignment" between IT and the business. It's natural for folks to work with a new capability for a bit and find their ideas for effective use of the data start firing. The IT project team will push back - the plan, schedule, and budget are complete! Real business value is locked up in the new insights of these business users, and an agile delivery style (many releases, smaller feature sets) can bring a lot more value. </aside>
Anyway, I came across a pair of posts I thought were interesting:
- Macomber writes about Toyota's "relentless attack on complacency". Something to note for companies driving Lean / Six Sigma initiatives for the new year. There is a steady drumbeat at Toyota, always looking for the next improvement. It strikes me that this is closely related to the agile development / fluid requirements meme, a bit of a reality check; I can't understand the next improvement (requirement) until I see the sum of all improvements (development) to date. The "project" is never complete. The requirements are always changing. And yesterday's terrific idea can very easily lead to additional insights, and get tossed out / reworked tomorrow. The value is not in the destination, but the journey.
- Patton put out a pretty deep post about how "tricks and techniques" (insight? understanding?) trump process and methodology for design work. Ok, I had to read it twice before the light started to go on, but to me, there's an ever-present oxymoron of design/process when diving into a new project. If you can pick up the threads and make the insights (at the very least, open your mind for the possibilities), then real value-adding work gets accomplished.
posted by James P. MacLennan at 11:33 AM
| Permalink
| 0 Comments
