The New Floodgates of the Mind

T’was Agile – A Holiday Treat
V. Lee Henson

Twas the night before code drop and all through the land
Not a person was coding, not even one hand

The code was all tested and checked in with care
Even the documentation was completed and there

The PMO Director & VP of Dev were nestled all warm and snug in their beds
While visions of bonuses danced in their heads

Joe closed his laptop and Sue hit the sack
Knowing morning was near and they needed the nap

When from my pocket there arose such a clatter
I reached for my iPhone to see what was the matter

To the office I flew like a Senior VP
Tore open my briefcase and fired up the PC

When what in my unsettled eyes might appear
But an incomplete test case as I trembled in fear

I regained my senses and checked out the code
Reviewed the regression and distributed the load

It passed all the tests now, my mind was at ease
Knowing that many would certainly be pleased

That I put forth such effort on a cold chilly night
To re-sync our code and ensure all was right

Soon morning approached and I knew not to worry
As none of the testing was crammed in a hurry

It makes my heart filled with holiday cheer
To know Agile methods make everything clear

As the holidays are with us and our hearts fill with joy
Help us all to remember the framework we enjoy

On XP, on Scrum, On Kanban & Lean,
On DSDM, On AgileUP, On Crystal Extreme

To the ends of the project, no greater joy shall we call
Than celebrate, celebrate, celebrate all

As we conclude the current project and realign our sites
Happy Holidays to all and succeed with Agile Might!

The recent discussion about Risks had my thoughts going back in time to events in my own life and how taking risks has always worked out for me. Although there are many examples, the one that stands out in my mind most these days is the following:

Many, many years ago, I had been working at a company for 5 years and had grown quite a bit during that time. What I was responsible for, the type of work I did, the folks who reported to me, etc, etc, etc. Everything had gotten larger and more complicated but it was great to have it all at my fingertips.

Then, seemingly out of nowhere, an opportunity came up which would completely change my day-to-day work from the hours I kept to the responsibilities I had. It was a risky venture in that I was leaving a good “job” as a Network Manager for something that could go either way. In the end, I took the new position as a Project Officer at the new company and left my comfort behind. I am actually quite Patriotic and the idea of taking on a position that would allow me to “give back” to my country was quite alluring. That new job would only last 4 months but in that time I got to spend time working on our Navy’s ships! The thrill of being on the ships, seeing them in drydock, and so many other events (including my first trip to Victoria) was well worth the risk!

Yes, I admit to having to live through some trepidation when the contract was over before I found another job, but in the end it did come through and that new job helped me grow even more than any before it. So, all in all it worked out all right 🙂

I used to think I was a big risk-taker, but I’ve come to realize that my desire to push the boundaries was due to 2 things: First, (according to Clifton Strengthfinders) is the fact that my Top Strength is STRATEGIC. Clifton writes of this strength: “People who are especially talented in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.” The way I look at it is this: I see the Big Picture and know where we have to go/ should position ourselves. Because of that, I make decisions that will take us closer to that endpoint. (This also touches upon that well-known Stephen Covey point from his 7 Habits book: Habit 2: Begin with the End in Mind)

The Second Point is one that took me a little by surprise. During a recent conversation, someone I respected pointed out that I am actually an “Agent of Change”. Now, I’ve always believed this of my wife who has an innate gift for Process Improvements (among other things) but for me? Slowly, it began to dawn on me. I could see how the things I’ve done (like improvements in Application Support and growing an Agile Adoption methodology) did fit that bill. Who knew?! 🙂 Discovery of self is such an adventure, don’t you think? 🙂

So, as is normal at this time of year, I have been looking back over 2010 and reflecting on the challenges 2011 is going to bring. As a colleague and Professional Speaker, Guy Cabana, said recently, for 2011, it is better to live with convictions than with the excuses of 2010.

So, set your sights on the future! never give up, never surrender! maximum warp! And, keep reaching for the stars 🙂

Enjoy your end-of-year celebrations!

A few years ago, after a particularly harsh sprint with unhealthy demands, I took a panel from Tatsuya Ishida’s SinFest comic strip and created this “warning” for folks who just did NOT get what “Agile” really means/ meant. It’s about Priorities, not about doing More with Less.

Until I decide whether or not to start another blog specifically on Technical aspects, I’ll at least indicate in the Subject that they will be such. For today, the question is once again focused on Agile Development.

I recently had a conversation about how “risky” Agile is and how difficult/ impossible the person found it to properly understand what the “plan” is on delivering a project that way.

In my experience, I don’t believe Agile is any more or less risky than any other methodology. After all, in the end, what you’re trying to deliver is a product that your client (whoever it is) can use to make their daily work easier. Whether you spend all your time and effort “up front” trying to figure out exactly ‘how’ your system is going to work and interact with other systems and then try to build it, or whether you take the “build what you need” approach, there will be risks.

The beauty of Agile however is that once you’re done, you’ll (hopefully) have a product that the client loves and can use because it was built “together” as a team. Along the way, as parts and parcels were built and delivered, the Agile Team (ie; developers, product owners, end users, etc) all had buy-in AND a voice on what they want the system to do and behave. If I can make an artistic analogy, this allows a “rough picture” (ie; early Iterations) to slowly be “inked” or “erased” or otherwise get a tighter “line” as it advances. Agile gives you that flexibility to tweak what you’re working on to more accurately match the day-to-day realities your client has to deal with as well as tweak (or improve) how the work gets done.

With the Waterfall approaches I’ve seen/ been involved in, all the up-front analysis, documentation, interviewing, estimation, etc is all done by different people who are usually not involved in the actual coding and developing. Forget having a developer try to understand why they’re being asked to build something, they just do what they’re told. In the end, you may get a wonderful system, but if market situations had changed along the way, it’s just as possible to end up a system that does what it was designed to do, but does not do what it needs to do. And since not everyone works the same, if you build something for the benefit of one person but not the one who will actually use it in the end, chances are high that they won’t be very satisfied by everything either. (This is part of that wonderful discussion of “don’t tell me how to do my job or how it should be done!” 🙂 )

To get back to the “risks” remember that even though a project is Agile, it doesn’t mean it’s a free-for-all (if it is, I would strongly recommend you find yourself another partner). Agile is a methodology for development. Risks exist as possible events and being prepared for them allows you to (normally) mitigate the highest ones. An experienced Scrum Master will not ignore the idea of risks. They will or should hold a Risk Session with the Agile Team (especially including the Product Owners and Sponsors) to identify what those risks are and what can be done about them. Having them thus identified, the Sponsor and Owner will be the ones to prioritize when to tackle them. They become an active part of whichever Sprint they become assigned to.

Is Agile riskier? Only if you’re not following a proper procedure to identify and follow-up on them. As for the whole question of having a “plan” … I’ll adress that at a later time. Once I can stop laughing at the idea that Agile doesn’t really have a plan 🙂