About Christopher R Goldsbury

Delivery is about making it happen. Persistent, and tested through practical experience, I'm a creative problem solver that seeks to balance the cutting edge with practical application. I believe in getting to success, rather than calling it done. Follow my thinking and reach out for business opportunities at www.pragilematic.com. I am available for consulting and can be reached via email: chris@effectivelogic.biz

Iterations Are to IT What Containers Were To Shipping

Introduction

Container shipping transformed the way goods were transported across geography and channel.   Instead of having many diverse payloads in differing container configurations for different modes of transport; a standard was defined for a rectangular container that could, through a set of standardized connection points,  be bolted to ship, train, or truck.   The result of simplifying the container configuration meant that transferring cargo between modes of transport became easier, shipping times were reduced from port, to rail, to truck.  Handling and management costs also went down because there was less variation in the cargo.

In the same way agile is standardizing the time-boxed delivery mechanism for software development.  Widely, today, the iteration is seen as that container.  In the majority of agile shops the 2 week iteration with a daily stand-up, front end planning session, and back-end review session; is the norm.  The channel of delivery might be scrum, xp, lean/kanban, or some hybrid of these.  The choice of which channel to use is deeply dependent on the business environment surrounding the software shop.   But regardless of the rails the iteration rolls over; it has become the choice for time-packaging completed requirements.

What are the implications of this to business and development groups?  What changes does this standard for team delivery impose/challenge the modern organization with?

Finance and Accounting

How capital projects are financed for internally used software has not followed the train of direction the iteration has brought forth.  Traditionally, project estimation is bottom up and we derive funding by establishing a level of effort ( LOE ) across the project, with some breakdown into work packages.    Iterations have the capacity to be the bricks of capital financing upon which projects are funded.

The challenge to IT finance groups is to derive the cost accounting for an iteration ( essentially a two week productive work team ) and then establish capital planning policies and procedures that estimate, plan, track and account by those iterations.

At first blush this sounds simple.  Why not just figure out the appropriate team composition: say 3 developers, 2 qa folks, 1 product owner and 1 team leader.   7 people X 50 hours a week = 350 hours X $70.00 per hour = $24,500.00 per iteration.  So now we just need to figure out how many iterations we need.  Right?

But wait….

What if I need a DBA, Infrastructure Person, or support analyst engaged?  How about software licensing, pc costs,  PTO ( paid time off ), employee rates vs consulting rates,  and other indirect costs?   What about the funding mix for any iteration?  Surely not all of it is CAPEX.  Some of it may be OPEX.  But what mix of a typical iteration should be OPEX vs CAPEX?   Should certain iteration models exist depending on what the team is doing?

These questions begin to explode the subtlety.  By standardizing delivery on iterations, the finance group and IT leadership can standardize the IT shop and its costs.  Should success be achieved, CAPEX and OPEX planning should become less complex and more routine; fundamentally reducing the infrastructure, roles, and process associated with this annual event while simultaneously establishing a standardized point of accountability and process planning.

This also changes the very nature of estimation from detailed to relative.  We’re now looking at value creation, rather than cost control.  The challenge back to the business will be how much value is derived at various cost points and at what point cost becomes too much.   Project costing becomes a negotiation toward shared value based on relative targets achieving a defined set of NPVs.

Management and Leadership

In an iterative organization the control, power, and operation are at the iteration team level.  Influencing those groups will require a leadership and management structure that is comfortable with fluid and mobile adaptation of resources to project needs.  Leadership truly begins to shine in this type of paradigm.  No longer dependent on a static formal organizational structure to derive power, the real leaders will begin to exert influence over these mobile iterative pods.

Those succeeding in such an organization will be gifted in the art of servant leadership, coaching, influence, and mentorship.  Command and control will be reserved for extreme HR issues alone.

Innovation

Iterations also change the shape of R&D and new innovative initiatives.  Iterations demand transparency, accountability, and risk reconciliation.  The iteration opens things up and standardizes the cycle of delivery.  To many this may stifle the idea of invention and creation by putting it on a disciplined cycle, but does it?   In plain english: business demands a return on its investment.  Research for research sake is a university concept.

Org Charts & Structure

How is organizational structure affected by the expansion of iterations?  While most IT shops today are familiar with the matrixed organizational structure, the iterative organizational structure groups teams into standardized pods for delivery.

The pods would favor generalists who are good at a multitude of IT functions but perhaps are not perfect at all aspects.  This structure would be fluid and adapt to organizational need.  An example iterative structure is below.  In this way the iterative POD is responsible to the director as a team.  All individuals in those pods report to him/her.

Personal Career Growth and Development

Iterations have already had an enormous influence on personal career development at software shops.  It’s not enough to be just a code whiz. Iterations place emphasis on teamwork, personal accountability, and decent communication skills.  Flexibility is also a key aptitude sought in the iterative individual.

Good delivery PODs are ready made hired guns.  Teams of professionals that could potentially write their own engagement.  In this way staffing by placement firms and consulting groups changes from individual placement to team sourcing.

Summary

The transformation of the shipping and distribution industries to containers wasn’t a simple overnight change.  Standardization requires upheaval and new ways of thinking, approaching old problems.  Organizations that adapt to the standard IT container and see it as more than just a ‘development thing’ are best positioned to yield the benefits that this change could bring.

About these ads

A Caboodle of Pragilematic Posts

I’ve been hanging out and posting at the ASPE SDLC blog.  Yes…I have their permission to do that.  Geesh.  Check em out Gilbert:

Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.

This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.

An Axiom of Project Success –  What’s the common thread to project success?  We’ve seen projects that should have died.  We’ve also seen projects fall apart that seemed like they were in the bag.  This post attempts to nail the overriding factor.

That’s Great…But How Does Agile Benefit Our Shareholders?  – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing.  This post brings it home for those wanting  a bigger bang for their agile swang.  Whatever that means.

Custom Built Software Is a Depreciating Asset

Custom built software.  It occurred to me this week that this ‘asset’ as it’s categorized by GAAP is a depreciating asset, much like a car or piece of capital equipment ( machinery ).

Does it derive value?  Yes….indirectly.  But ultimately it’s value is underutilized, and quickly de-valued.

Imperfect as it is…there is little alternative….FOR NOW.   So what’s the best strategy for investing in this ‘asset’?

Minimize it.  The less you put in.  The less you lose.

Find the cheapest way to accomplish your custom software needs and invest in that first.  Any other investment strategy invites disappointment, and reduced expectations in the future.  This strategy, however stark, also recognizes the truth…..big things start small and simple.

Prove it out with a minimal project and then decide whether additional value could be derived.

KTTW

Productivity can get lost in the haze of doing.  We often mistake the furious completion of many tasks in short order as an example of accomplishment.  Proudly, we mark it ‘done’ and then triumph in our ability to execute so well.

But productivity that counts means getting key things done effectively.  Always striving after the low hanging fruit yields many trees in need of further, incomplete harvest.

Agile rekindled the power of the time-boxed effort for teams.  Through an iteration we discover a game of sorts, an artificial finish line.  By the team committing to some set of work within that iteration there’s a bond of ownership and determination to complete.

While agile does this on a team level, the application is just as effective on a personal productivity level.  KTTW ( Key Things This Week ) is an example of this.

How does it work?

Friday Before You Leave Work:

Make a list of the key things you need to complete next week.  You define ‘key things’ by answering these questions:

  1. By completing this task this week will I move my project, team, company forward significantly?  Will it make a difference?
  2. If I don’t complete this task next week what’s the worst that would happen?
  3. Will completing this task move me closer to success?

Key things should answer yes to question number 1.  Each key thing should move your project, your life, or your company forward in some significant way.  I’m not suggesting you should complete a 6 month project in a week, but the question focuses you on what will make a difference versus what’s just keeping you floating along.

Question two validates in the opposite way.  If you never actually complete this task…what would happen?  Would you be let go?  If so…better do it.  If it’s low value work that can get done later…then save it for when you’ve completed the key things for the week.  Then you can knock out a handful of these low hanging fruit, and you won’t feel like you’re avoiding the 1000 pound white shark  in the room.

In the last question you define success.  Notice, I’m not asking if it gets you closer to done.  Who cares if you’re done. Lots of people get ‘done’, but how successful is their completion?  What matters is success.  Here’s where being effective comes in to play.  It’s not about just being efficient, it’s about getting the right things done to achieve success.  Your answer to this question should be ‘yes’ if it’s a key thing.

When you start up work on Monday…. break out your list and start tackling your KTTWs.  Your commitment should be to getting this list done by Friday irrespective of your other work.   Commit to this no matter what. What order?  Doesn’t matter. How much time should you devote to each key thing? You decide. Should I use a tool to track them? If you want.

KTTW is a light, time-boxed personal productivity tool.  I’ve used it effectively for many years, and can attest to it’s power in consistently focusing my mind, and effort to what truly needs to be completed to achieve success while at the same time weeding out the nonsense which clutters my day.

 

Getting to Success Instead of Getting to Done

Projects are about getting things done…right?

Uh-Uh.

They’re unique, collaborative, human efforts endeavored to achieve success.  Success is can be defined with certain goals.  Success has a point, a place we reach and can say “Ah-ha!….we did it!”.   There’s a finish line.  Done, on the other hand, is never done.  Excuse the pun.  And the rhyme.

Done is an endless backlog.

Done is a never ending series of requests.

Done is code that’s never perfect.

Done is test cases that still need to be refined.

The fog of “Done” can envelop the project and the minds of our teams.  It obscures the truth.  We’re not looking to get everything “done”.  We’re looking to succeed.  Within success there is room for variation on “done”.

Go After Your Dream…

Follow on Twitter Friend of Facebook
Apply for the Arch Grants Business Competition Today!
Arch Grants, a new nonprofit organization aimed at creating a strong entrepreneurial economy and image of St. Louis, is awarding 10 or more grants of $50,000 each and offerring additional support to startup companies willing to grow their companies in downtown St. Louis. Intersted startups should submit their 1-3 page Executive Summary on the Arch Grants website.The deadline for apply for the Arch Grants Business Plan Competition is Friday, March 9, 2012. Winners will be announced in May. To learn more and apply, please visit archgrants.org/competition.
Apply Today