IT Planning and Agile

Some of the new organizations I’m dealing with are going crazy with “Agile”.  The Hype Cycle  is in full force.  Soon Agile with be advertised to put the kids to bed on time, solve world peace, and feed the world.  The problem I see is not with Agile its with its close cousin “Addle” which is often what I see organizations implementing (I.e., the worst of each methodology glued together).   I will point out that I am neither a zealot for Waterfall or Agile; its a tool and like other power tools –notice the woodworking reference– it should be used carefully.  Too often I’ve seen Agile be used for an excuse for poor or no planning and/or poor development practices.

If one reads the original materials, nowhere does it say don’t plan.  Actually it indicates you need plans, just not at the level of precision and scope previously and wrongly drummed into people’s heads.  Agile suggests or recommends planning in short enough horizons such that the problem doesn’t change before you finishes planning (accuracy) and to a granularity (precision) that is enough to get the job done.  Another way to look at it:

If my problem was to cross the river and you spent five years planning to build a bridge, by the time you actually built the bridge I may have cross the river with a boat and now I’m faced with climbing a mountain (problem has changed).  If I want something to sit on I may want a chair, but it may not need to be designed and constructed to 1 millionth of an inch tolerance –which would cost a significant amount.  I could probably get by with 1/32 of an inch, produced at lower cost but yielding the same level of performance I desire.  So in the end Agile is a balancing act that I believe still requires planning; just different types of planning and a whole lot of thinking.


IT Planning Methdology

Started putting together a tutorial deck this morning for an Enterprise Architecture Methodology which is more business based than IT.  Having watched IT over the years get lost in the technology details I though it was about time to create an approach towards really designing Enterprises; the thoughts I had years ago when I presented at the IBM Application Institute and AIAA Operations conferences.  Why couldn’t you design an Enterprise (not just the IT) the way you design any other product.  Years later, several “internships :-)” in other roles within the corporations, and researching various methods from multiple disciplines I’ve started to integrate these into a design methodology:

IT Planning

The above approach has business model as the root where other aspects are details to that end.  That is IT Planning is based upon enablement of the business model, Market Planning, etc. all come from that common root.

Business Models and Organinzational Development

During my mentoring session this morning one of my colleagues posed an interesting dilemma.  The famous success trap.  She was asked to lead development of a solution rapidly.  Which she did famously, so much so that the offering made the IT press channels by word of mouth rather than a publicity campaign.  The problem though is now the company she is working for wants to scale selling it.  The problem however is that the company or rather the various stakeholders in the company don’t understand that the offering is not a simple shrink-wrap product, it is a mixture of product and service and requires customization via configuration setting tuned to the way each organization works and their respective infrastructures.  Thus a marketing person can’t sell a license, have the customer download, install and be successful.  However, marketing just wants a 10 minute dog and pony show from the development organization so they can spread it through the channels to sell just like previous products.

The problem is she needs to either find a service organization that can develop the deep knowledge and readiness collateral to support such or develop such, however, the organization she works in has not come to grips with the concept od services yet.  The way this skunkworks project was successful creates a problem for the organization that understands silos and hierarchy.  It was tough enough to incorporate agile but dynamic groups in addition is a tough pill to swallow.  As I continue my R&D on Enterprise Architecture methodology, I’m thinking there maybe a change formula that will help senior management more accurately understand the challenges of change.  Something like:


Change Challenge = { [Organizational Structure Change] x [Process Change] x [Business Model Change] x [Technology Change]} / [Adoption Period]


Or a vector model that shows the multiple change dimensions above yields a significant change (e.g., moving 4″ vertical and 4″ horizontal in actual distance is more than 4″.Over 5 1/2 inches which may be too far for the organization to reach in a short period of time).

IT Planning Issues

Several of the problems I’ve been noticing with all the Portfolio and IT Planning methodologies are the build-in assumptions in the process:

Most often in I see planning committees act if the transformations are developed and implemented as simple greenfield or state changes; current state “a” then state “b”.  In most situations this is never the case.  Typically one is forced to address changing the tire while the wheels are turning.  On a small scale initiative such as a software upgrade this is possible but still problematic, witness all the planning for deployments vendors do from readiness to rollback planning.  Businesses are much more complex so when a mission critical component used continuously goes down all hell breaks loose (e.g., Airline Reservation Systems).

The second common problem I see is non-integrated planning or planning in islands.  You would think after years of hierarchical management experience this would have been addressed by implementing a system like Hoshin Planning to provide linkage across the hierarchy but these tools are not so prevalent or understood…maybe because IT behaves as a product development and run organization rather than a service (despite all the recent hype).  I still see efforts to increase programmer productivity outweigh efforts to manage services ongoing.  Not looking at the interdependencies of that various elements in the system is like expecting a sports team to operate effectively in competition without a game plan, one that address every member of the team and its opposition.

This week I’ve stated to map out the IT Portfolio Methodology or rather IT Planning Process to account for such issues as well as the bigger issue alignment to the business.  Originally I figured the spreadsheet I was building to integrate all the components would be enough.  Now I see a complete methodology will be needed.


Joy at work

Spent most of yesterday focused on creating a draft of a slide deck.  Previously I would hurry through creating a deck.  However, now I’m having to slow down…because I will not be the one presenting to the executive committees.  So I will not be there to answer questions or bridge the gap in logic.

Over the decades I’ve loved to give presentations on the fly (Chalk Talks) as they seemed more dynamic, interactive and honest.  You’d get to address the areas of topics your audience had rather than a predefined path and conclusion.  It was more exploring the area together.  At SharePoint Saturdays –though I had a slide deck that covered the topic, I won’t follow a script– I’d typically have more “Actor’s Studio” dialogs with the audience as one reviewer put it.  I prefer dialog to speeches I guess.  However, in my role now, I have to ensure my team gets the message across accurately to Executive Management.  So spending time crafting the story and message is more important as the windows of time is so short.  It goes back to a comment I made on Facebook to a friend.  The joy in a job or role derives from developing the precision in executing it more so than the financial remuneration.

Business Theory

Spent morning looking at Theoretical Physics videos (String Theory, M-Theory, and the like).  I know some of my co-workers will question the value of such and ask how do these relate to “real work”.  However, its that cross domain thinking that brought ideas like OOP, Active Directory, etc. into the IT realm.  With all the business architecture and business theories floating around I’m still looking at how I piece these together into a coherent system that allows for another seeming paradox [logical design that includes emotional factors].  I often see the dilemma that business researchers face: an calculus of design that should work, only to be destroyed by human factors.  Consider products that should have been successful earlier: computer watch –which is now all the buzz; PDA which morphed into the Smartphone; etc.  Technically the predecessors to these should have been successful, but something just didn’t click.  One can point out a lack of a single factor and say without this feature … however, how does one explain the Edsel which was an advance to then current industry products.  There is something emotional -which marketers, social network researchers and now Data Scientists are trying to understand.

I had a discussion with a collogue last week regarding patterns –data science, machine learning, etc.– while pattern matching is useful, its results are not always correct as “we” the observer overlay patterns on what we observe.  These patterns we detect maybe just that a coincidence, not a intentional or guided structure.  In other words: “correlation is not causality”.


-anyway just insights for me to muse over during this morning’s coffee.  How I apply such to the Enterprise Architecture Methodology I’m writing about is still a TBD.

Book Title(s) and messaging insights

Started to rethink the title of current book project this morning during drive into work.  Structure in Threes maybe too esoteric for some.  Considering “Discussions” as that is what all the tools and techniques in the book are designed to provoke.  I had a few colleagues weigh in on all the methods I’ve been documenting.  One comment was that he didn’t think a prescriptive approach to Enterprise Architecture was viable.  I was rather surprised at the comment given all our discussions that these are visualization tools that help decision makers see what they are talking about and/or see the results of decisions before these are put into place.  Just goes to show you that old maxim about remembering only a small portion of what is said is true.  I’ll have to add a chapter up front on the importance of discussion verse prescription to ensure my audience gets the point of the book.


Get every new post delivered to your Inbox.

Join 456 other followers