Software Engineering, Project Management, and Effectiveness
Change happens. One of the many things Ward Cunningham taught me years ago was that Agile isn't about fast. It's about "responding to change." It's the Agile way.
I thought it was great that rather than pretend change doesn't happen, simply embrace it.
Simplicity was another aspect that I found compelling. Ward had a way to keep things simple. If something felt heavy or complicated, he would cut right through -- "What's the simplest thing we can do now?" Rather than get overwhelmed or lost in analysis paralysis, he simply decides to take action.
I remember thinking how sweet it is to put your burden down, and travel light.
One burden for me was all the stuff that was yet to be done. The other burden was all the stuff that might matter someday. The problem is, how do you plan for what you don't know or can't expect? You don't. Instead, you figure out the most valuable thing now to work on, and when you come to a bridge, you cross it. When there's no bridge, you build one. If that becomes the next most important thing now.
The sense of now vs. someday maybe is important. There's something empowering about knowing that you're on the right path, and that the path you're on flows value -- to yourself, for others, or whatever matters. Mistakes turn into lessons, and success builds momentum. Paving a path of value down a road of learning and responding beats betting on a map that no longer works or is no longer relevant.
Speaking of relevancy, time changes what's important. All the things we think we know, and all the things we thing we want, don't always match what we find, once we're there. The ladder may be up against the wrong wall, or the grass isn't any greener. In fact, sometimes there's no grass.
The irony is, the trip is lighter when we don’t carry the burden, and the trip mean more when we know it matters. If we don't enjoy the journey, and we don't end up with what we want, what's the point? Life's short. Throwing your time and energy down a path should matter. But, how do we carve out these paths that matter?
Stories. Stories help you find what matters. I remember the first time Ward asked me to tell him a story. He wasn't looking for once upon a time. No, he wanted to explore and test possible paths. He wasn't interested in a laundry list of requirements. He wanted a simple story told from the user perspective of a single, meaningful goal. We used the whiteboard and mapped out one scenario. Disney would have been proud.
This one chunk of value was compelling. The story put things in context. The flow made sense. Value was obvious and explicit. More than that, it was testable. A testable chunk of value. We could test whether it mattered, and we could test whether it was feasible. We could even test the risk early and reduce the gap from what we know, don't know, and need to know next.
Having a story helped us do a dry run. The dry run produced immediate feedback. Feedback is a good thing, and it supports learning and responding, the Agile way.
All this goodness in approach, painted a better picture, of a better way forward. Rather than over-engineer up front, or over-plan for some day maybe, start flowing value now. Rather than travel with burden and assumptions, travel lightweight and sustainable. Rather than fear change, allow for it, and embrace it – be adaptable. But does this approach to work, also work for life?
I asked Ward how he did his career planning and figured out his year ahead. He said he simply works backward from the experiences he wants. He writes his story forward, by focusing on the experiences he wants to create. He leads an experience-driven life. What a simple, yet elegant, and insightful approach. What an empowering way forward.
The journey is the trip and the destination. It's the way we travel and it's the end in mind. It's the Agile way.
This is why my latest book is Getting Results the Agile Way.
Congrats and thanks for sharing! This is going to be a headline next Monday in MSDN Flash newsletter.
@ Diegum -- Enjoy! Thank you.
it must have been a wonderful experience to work with some one who wants to listen. where i work, you get letters written and put into your personal file if you talk to anyone. which is sad because many times when in the course of writing software you need some one who will just listen and help you break apart the minutia, so that you don't feel over whelmed.
thanks for sharing!
Thanks, this is great writing and will be sure to share it among my colleagues.
Very interesting read. But maybe I am missing the bigger picture: when trying to translate this into my daily work, the question comes up: how do you estimate a project (big or small) when using this technique ?
I very much like this approach, but in 'real life' I find it extremely difficult to implement, as the customer wants to know how much this particular modification will cost and by using this method, it will be very hard to estimate.
Note that I am talking about very small development projects that can go from a couple hours to a couple days.
@ Rob -- Estimating is an art and science, but there's tools that work.
I could write a book on estimating (I've been on time, on budget for 10 years), but I'll try to keep the key points brief here to get you started:
Here's what works in the "real world":
The keys to estimating are:
- knowing the work to be done
- knowing your own capacity and throughput or velocity
- knowing when the work must be done (game over if you ran out of time or budget)
Tools of the Trade
- Work Breakdown Structures (WBS)
- Network Diagrams
- Delphi Method
- Planning Poker
- Critical path analysis
- Dependency analysis
- winging it
- not knowing the work
- not chunking up the work effectively (stories within time boxes help)
- not including the people who do the work, to estimate the work
- not checking your thinking with others or even with yourself
- Not accounting for efficiency or availability
- taking on dependencies
- not knowing the critical path
- not having cuttable scope
- not getting estimates down to the smallest useful units
- not having a way to revise estimates as you go
- not updating when people change or tasks change
- not having a way to checkpoint or revise estimates
- not having a way to reset expectations
Remember at the end of the day, flowing value keeps you in the game.
The key with Agile Results is that it's a simple theme of reducing your estimates to the day, the week, the month, and the year, and checkpointing / adjusting your results each day, week, month, and year ... learning and responding based on learning the work and learning your own throughput (Friday reflection is where the ah-has happen)
@ Aaron -- It sounds like you have an unsupportive work environment. I'm a fan of teamwork, collaboration, and a big believer that the sum of the outcome is through pairing, sharing, and lifting each other up.
@ Alejandro -- Thank you!
Nice article and very impressive