The Agility Series

by
The Agility Series focuses on agile and agility across the organization not just in software and product development. Areas of agility that will be covered in blog posts will include: - Organizational Agility - Leadership Agility - Strategic Agility - Value Agility - Delivery Agility - Business Agility - Cultural Agility - Client Agility - Learning Agility

About this Blog

RSS

Recent Posts

Guiding Principles for an Adaptive Organization

Reflections on 40 Years in IT - Agile by default!

InfoQ Podcast Interview of me on The Agility Series, Cultural Agility, and more

You might be a management red-neck if…

Strategic Debt  — What it is and how to avoid it

Guiding Principles for an Adaptive Organization

This is a bit of a different post for me.

My partner and I have crafted a set of Guiding Principles for an Adaptive Organization which I invite you to comment on in this thread.

The final version will be posted for download at www.AdaptiveOrg.com under a Creative Commons license.

All contributions whose comments are used in some way (meaning either directly or caused us to think about something differently) will be recognized in the final release.

So what would you change, drop or add?

Here are the principles (we thought ten was a nice round number): 

  1. Act with intent through clearly defined and transparent strategic priorities that are reviewed and adjusted based on the evidence and through collaboration inside and outside of the organization

  1. Recognize that becoming and remaining an adaptive organization is not a project, it's hands-on, with live experiments and adjustments until it becomes the way of organizational life

  1. Have fully engaged and clear-the-path leadership

  1. Recognize shared values and principles are the necessary ingredients for people to create and sustain aligned personal and organizational purpose and adaptability

  2. Recognize true organizational sustainability and resilience can only be achieved by becoming adaptive in action and in thought – we do (act) so we can train the adaptive muscle in our brain

  3. Have a strong focus on clients/customers and engage them directly to establish overall strategic priorities, and to achieve specific initiative goals

  4. Hire and promote the creative and productive power of gender-balanced, intellectually, and culturally diverse teams at all levels

  5. Create and support a fail-forward safe environment

  6. Provide collaborative workspaces that can adjust to the needs of people and the organization over time

  7. Recognize that organizational policies exist to support the achievement of organizational and client/customer desired outcomes. When there is a conflict, the outcome wins

These principles support one another equally in achieving mastery as an adaptive organization

 

Posted on: January 25, 2018 06:26 PM | Permalink | Comments (13)

Reflections on 40 Years in IT - Agile by default!

Fair warning....this is a self-indulgent piece that probably only matters to me. If you find it interesting. Yeah! If not. Yeah!

It's hard to believe that 40 years ago, on January 3, 1978 was my first day of work.

In December 1977 I had completed my degree in Computer Science at the ripe old age of 19 (we only went to Grade 11 in high school at the time). I had done my entire degree on punched cards, except for one course in APL.

One of my university professor's claim to fame was that he was the first to have created a graphical rendering of an egg...so naturally he taught graph theory. As he was one of the cool dudes, he occasionally hung out with us wanna-be-cool students on weekends doing what we all did in the 1970's - I hear it will be legal in Canada next summer. :) Fun times.

I chose the Forest Gump theme as, looking back, I feel a bit like the Forest Gump of the IT and computer industries - I have watched an entire industry unfold before my eyes and got to participate in what has been probably the most tectonic shift in the history of technology and work.

To put it in perspective, when I graduated in the fall of 1977:

  • Apple Computer was just over a year old and Microsoft was only 2 years old
  • The home computer market was in its infancy and was mostly hobbyists experimenting with kit computers like the Heathkit H8
  • The first spreadsheet (VisiCalc), word processing (WordStar) and presentation (Bruno later called HP Draw) software were still more than a year away
  • The internet was still 15 years away (though it was invented in 1989)
  • Computer Science was only established as its own department at my alma matter the following year

As we approach 2018 we're talking about quantum computing, AI, deep learning, Apps, self-driving cars, digital services, and cyrpto-currencies. Quite a shift indeed.

So here's what I saw and experienced over the past 40 years (what follows is rather long because...40 years is a really LONG time):

1978-1990

  • In my first job with Newfoundland and Labrador Computer Services (that we affectionately called Knuckles (NLCS)) I did everything - requirements, analysis, design, coding, testing and deployment. So while we did not have the cross-functional team concept, as individual developers we had to have a very good understanding of all of the competencies required to get software from idea to production
  • My brother-in-law, Wayne Kelloway (sadly he passed away in 1999), worked in production support at NLCS and observed that most developers, who simply threw their mess over the wall to prod, ought to have to find their own bugs and fix them in the middle of the night (like he did when the batch jobs ran and often crashed). He figured it might prod them to do better design and testing. This was 1979...DevOps took another 30 years to materialize
  • Throughout the 1980's, after I had moved on to the Federal government with the Atmospheric Environment Service (aka the Weather Service) in Gander NL (the Come from Away town), I got even more exposure to the world of Dev and Ops as I was responsible for both development and operations within the Weather Centre. In 1980-1981 I was the ONLY computer guy in the office so I really was Dev and Ops. I got to do what my brother-in-law had suggested...fix my own crap at 2am! It left an indelible mark (along with some sleep-deprived weeks of my life).
  • I also got to do hardware and operating systems...when the nearest vendor guy is at least 4 hours away, you become cross-functional or nothing works for long. As the office was at the airport, it's also the period I got to learn that DND radars and disc drives don't mix. We had an HP1000 with a whopping 50mb hard drive. The actuator coil that drove the read-write heads would beep every 12 sec in time to the radar sweep. We had to copper shield and ground the room to create a Faraday cage
  • On the side, while I was in Gander I got to help my brother in-law introduce computers into the school system in the form of the Commodore PET. We developed software in BASIC to track students grades throughout their high-school years. We started that around 1981. We also ran an adult education class on the Commodore VIC20 teaching BASIC. I also started introducing the IBM PC to my work place in 1983.
  • Cool fact: Commodore BASIC was written by Bill Gates and Paul Allen from their fledgling Micro-Soft Corporation  (later renamed to Microsoft Corporation). Commodore BASIC was the only unlimited software license ever granted by Microsoft to any company for all products regardless of the number of copies used. Commodore went on to produce literally millions of machines with various forms of Commodore BASIC and did not pay Microsoft a single cent beyond the initial licence purchase in 1976.
  • On a sad note, I was still in Gander on December 12, 1985 when Arrow Air Flight 1285 went down killing all 248 passengers and 8 crew members on board, most from the 101st Airborne Division. From my office window, I watched each individual soldier receive full military honors as they were being loaded onto a plane for their final journey home. One of the saddest and most awe-inspiring events I have ever witnessed.
  • In 1985 the US DoD came out with DoD-Std-2167A which is when waterfall was essentially made into a standard - and the rest as they say is history (even though the main author gave a mea culpa in 1996 and said oops...sorry about that, "in hindsight, said he would have made a strong IID recommendation, rather that what was in 2167"). So if the guy who started the mess says sorry...can we stop defending this nonsense and move on?

1990-2000

  • In 1990 I moved to Ottawa (via Halifax from 1986-1990) to Ice Services (Canada's Ice Forecasting service for the Arctic, Ice Berg alley off Newfoundland, and the Great Lakes and Seaway). In the early 1990's Canada was preparing to launch RadarSat - a satellite that would transmit 7.5gb of new data/day at 10 meter resolution for our area of interest (previously we had two aircraft that flew around collecting data). Our biggest hard drive at the time was 424mb. This meant wholesale replacement of our entire infrastructure - all hardware, networking gear such as it was, and well as all of the software in the data centre and on the Forecaster workstations had to go.
  • (Side note: As an employee of Environment Canada in Halifax I got to go to Sable Island for work and to see the ponies. A highlight still.)
  • We looked at the magnitude of the task before us realized we needed to think differently if we were going to pull this off in 3 or so years. 1) We moved to Unix from HP-RTE and Vax VMS, 2) We decided to use C++ and object-oriented design instead of Fortran and procedural, 3) We looked for the commonality across all of our software and built what we called Global Services before we built the new applications, 4) We automated as much of the operations monitoring as we could with HP OpenView for network node management, BMC Patrol for capacity and process monitoring , and Remedy ARS for automated Incident management and initiating automated fixes
  • This was the period 1992-1994...and almost fifteen years before ITIL started to become a thing on this side of the pond. We did the ops automation part in three months...when you are already overloaded, you don't over analyze things - you simply get them done and move on. Oh, and we installed the first 100mb network in the city.
  • As we knew nothing about object-orientation, we bought books. Lots and lots of books by the pioneers of the day: Rebecca Wirfs-Brock, Ward and Mellor, Ed Yourdon, Tom DeMarco, Peter Coad, Grady Booch, Ivar Jacobson (who went on to co-create RUP), and James Rumbuagh. Their work in OO is what eventually led to the advent of JRP/JAD/RAD which I used in the late 1990s. It's a lot of the same kind of thinking that led to the Manifesto for Agile Software Development.
  • I attended the inaugural Object-Management Group Conference around 1993 and found out that what we had called Global Services they called Common Facilities as part of the CORBA Specification. This was the precursor to Service Oriented Architecture (SOA) almost ten years later. A big difference in what we did back then, versus SOA now, is that we also had to build the inter-system communications layer mostly from scratch to make it all work. We used Kerberos for and DCE for security. These were also the very early days for the concept of open systems. We were a big proponent and made it part of our architecture.
  • We also got to go visit all of our tech vendors and ask for things like 4-foot wide flat screens (the Arctic is a big place to see on one screen) - we were told we were about ten years early; We were told that a lot about what we were trying to do...we also didn't listen a lot to being told what we could not do.
  • A cool thing about our visit to HP in Palo Alto was they demonstrated what the future could be like. They used to make video's of products that existed, would soon exist, were still in the labs, and those that might be possible to exist in the future. You had to guess which was which. Their example was of a little girl having a medical emergency at an accident scene and the EMS personnel using a hand-held video device to communicate with emergency room doctors; To read about what that is really like, take a peek at Estonia today (search for doctor). That was 25 years ago at HP...another cool thing about the visit was when an HP engineer walked up to me and asked "Are you THE Larry Cooper from Gander NL?" He told me that everyone who worked on the HP1000's knew about me because of the radar problem. This was over ten years after our Faraday cage...my little bit of fame :)
  • Instead of our applications taking 12-24 months each to build, once we had our services layer in place, we were able to crank out the replacements in 3-5 months. It forever changed how I looked at software, design, and what was possible in short time-frames. We stood-up several small development teams (we used consultants), each with all of the required competencies, to work on the different product areas we had to tackle. Looking back now, we were pretty radical in what we did and years ahead of most everyone else. Oh, on the employee-side we were a shop of about 5 IT people. It's not the size of the team, it's the size of their ambition.
  • Cool fact: In 1993 we used Usenet groups via our new Internet access to find a solution to a communications problem between a Sun Micro Systems server and Windows NT box - the answer was to turn off the timeout on the NT side and it would eventually give up and accept the connection! We got our answer in less than two hours from Usenet - the Internet was not invented by Al Gore. We replaced the MS TCP/IP stack with a third-party one to get around it. Those were the days of proprietary everything. Solving that problem allowed us to use PPP over InMarSat to send Ice charts and forecasts to Canadian Coast Guard ice breakers and international shipping in the North Atlantic. Cool indeed!
  • As my time was winding down at Ice I got asked to write about our design approach as part of a book series that Auerbach Publications of NY ran at the time called the Manager's Handbook series. I had two chapters in the 1995 addendum and the 1996 full book. My first foray into writing. Three-tier architecture? We had designed and implemented an n-tier architecture with services; At the time Gartner was pushing client-server. We really didn't understand why you would want to be so limiting in your thinking on architecture
  • A side-bar to this period was that I got exposed to the PMBOK for the first time. As what we were doing was so big, our leadership felt we needed some project management exposure so they hired someone to come in once a week to start educating us on the PMBOK. After about three months of these sessions, I remember looking at the mentor they hired for us, and saying "this stuff is evil!" (sorry PMI...).
  • After his initial shock, he asked for my reasons; I responded with "because I can see how this can become the focus and not the thing you are trying to build"...I felt that then, and even more so now. If you look back over the past 25 years, my gut feelings have been validated many times over (not to mention the fact that in V6 of the PMBOK, for the first time, it says that the process areas are not to be seen as stages in a project).
  • Not only did the project management deliverables become the focus in many organizations over what was being created (and often still is), what we viewed as the competencies that individuals and teams needed, also became roles and org structures. I was sad when that started, and became even more sad as it got entrenched. Why do we need BA and PM and architecture organizations? Aren't we building solutions in teams? What makes me even sadder? Seeing 20-somethings still being exposed to that kind of thinking. Just like waterfall, can we stop already?
  • I think the only reason we were able to do what we did during that period was because we literally did not know any better - we never thought it couldn't be done, we never overburdened ourselves with unnecessary process and project management overhead, we created small teams with purpose and the right competencies, we learned the things we needed to learn when we needed to learn them, we fixed what wasn't working, we sought help outside our team when we needed it, we read...a lot, and we got our hands dirty. Sometimes being relatively young and inexperienced is a great thing as you are not encumbered by experience or doubt. Too bad so many of us lose that as we get older. And even worse, turn the younger ones into the five monkeys.
  • After I left the government in the mid-1990's I got exposed to something called the IDEF Standards which refers to a family of modeling languages in the field of systems and software engineering. They were the genesis for information modelling, ER diagramming, and the BPMN stuff we see today. I bring that up, as much of what was intended in the IDEF work got lost over the years; This is especially true in the business process space, where process got confused with work instructions and procedures. It's why so very few business process diagrams are actually process diagrams.
  • I started applying the design principles I had learned at Ice Services to business process design. I have since wondered how BP design in general got turned into such a mess over the past 20 years with swim-lane diagrams that occupy whole walls...what went wrong? It was such a simple concept - any more than 7 plus or minus 2 boxes on a process diagram meant you were doing it wrong... near as I can tell, most still do it wrong. And it has turned into a whole industry onto itself. Really, it's only something you do because you are doing something else (as most of these things are). It should not be a thing by itself!
  • In the mid-1990's I learned about benefits realization and outcomes management. Unfortunately, when it got introduced to our federal government it became the brick that had to be created in order to get money for major-capital projects. I was at DMR (later Amdahl and finally Fujitsu) when they helped TBS set it up. At the same time as this, I also got exposed to JRP/JAD/RAD which was "rad" for a lot of people at the time, but for me was more of the same kind of thinking as we had done at Ice. As a result of both exposures, I started thinking about combing the two. I liked the start-at-the-end thinking of outcomes, and the iterative and incremental approach of building things. I didn't get to do both together for a number of years.
  • In 1997 I was asked to work on the Y2K problem that everyone believed was the impending doom. I declined as I did not want to dedicate 3 years of my life to something that had no life after January 1, 2000. I had already started living what I thought the future of software would be, and I had no desire to go backwards. Lot's of my contemporaries made lots of money...and set their careers back years. My final poke at the craziness that was Y2K was to get married on January 1, 2000 - we figured if the world was going to end at least we had each other. And besides, now I can never forget how many years we have been married. What year is it?
  • In 1998 I was doing what amounted to Lean (had not heard it was called Lean until years later...). We had to figure out how to improve our OEM procurement process. I guess we did a pretty good job of getting the non-value-add parts out as we saved the company $25M USD/quarter on their OEM purchases
  • In 1999 I got to work on the worlds first web-enabled supply chain funded by 7 major telecom and electronics manufacturers. Recognizing that supply chains run hundreds of suppliers deep, we developed a business capability release strategy instead of a software release one. That business capabilities matter most of all, is what stuck with me ever since. We worked on the early versions of XML (a variant of SGML)...it allowed the big guys like IBM to seamlessly communicate in a supply chain with the small mom-and-pop shops. What resulted became E2Open, which still exists today

2000-present

  • After that I got to go to a start-up that was later sold to PayPal for around $900M - I only lasted 6 months before the Canadian side was shut down. It was a micro-payments solution and what was interesting in that one was being able to get new fully-tested releases out every 30 days - this was 2000-2001 so around the same time as the Agile Manifesto was being penned. We had an amazing team of 35 or so developers, architects, and testers that split into 4 or 5 different product teams who worked as one on the micro-payments solution. This was well before most people were talking about scrum or agile at scale. We did it already - though for a too-short period of time.
  • Most of the early 2000's was pretty nondescript, though I did get to work with our Treasury Board on XML Standards and Taxonomies as part of the BTEP work in 2003. This was the period of Zachman and TOGAF, rampant ITIL, the PMBOK and eventually the BABOK in corporate and government IT. I spent the 2006-2009 period mostly in the ITIL space and back on the Ops side. I noticed that the more of these frameworks and methods that got added to the fray, the worse the delivery timelines became and the bigger the failures became. Gee, I wonder why?
  • In 2009-2010 I had the good fortune (good fortune has happened to me a lot throughout my work life...) to be asked to do an agile procurement for a crown agency. I was hired to "procure and implement a Learning Management System". I used the opportunity as my first real chance to combine agile thinking with an outcomes focus. We started with asking a lot of why questions - this allowed us to work backwards from the business results to be achieved as we figured out where we would need to start (I have since learned this is called back-casting instead of forecasting). Counter-intuitive but completely logical. We were to use Scrum as our approach
  • We used a variant of the business-model canvas that I called the Service Canvas to help the internal business group document their existing services to the rest of the business. We then used the same canvas to design the new services they would need to offer. This is how we figured out the answers to our other questions; What kinds of new business capabilities do we need to create? What kinds of tools (beyond the LMS) do we need to support those capabilities? What processes do we need to design and put in place? What's the right way to organize the teams for delivering these new services using these new tools and processes? What are the competencies they will need? Etc.
  • The result of our work was astonishing - at least to me. We spent 2.5% of our original budget for the LMS procurement (yes you read that correctly), we stayed within the original 18 month timeline, and within the original overall budget; Yet, we delivered about 4-5 times the originally intended business value. We issued a 10-page RFP for the LMS and had a decision on the winning vendor within a 5-day window. The fellow in charge of procurement for the agency said we had run the best procurement he had ever seen. And we had stayed within Treasury Board guidelines at the time for a procurement.
  • So why did it work? The primary reason was we had both the business and IT teams focusing on the same outcomes and working collaboratively towards them. The teams were also the ones who figured how they need to be re-organize and designed the processes they would need. I think another major factor, was that much like back in the Ice Services days, we kept the overhead to a minimum and sorted out our issues together as a team as they arose. We were also able to ask the hard questions and get them resolved. For example, IT architecture was against the chosen product as it ran on Windows instead of the "standard" of Unix. When we asked whether an "IT standard" ought to trump business need, which would have meant spending the other 98.5% of that part of the budget, we won the day. It might not be magic, but it truly is magical when it works
  • Using the outcomes map we developed, we got to see how the projects that were identified would fit together in a portfolio. Each project was purpose-defined to contribute to specific outcomes. It also helped us visualize their sequence for delivery. It opened my eyes about what portfolios and programs ought to be versus what they often are - a grouping of unrelated projects organized by business line. Our projects had purpose with specific identified results they would help deliver on
  • Based on that experience, in the fall of 2010 I prepared and delivered what I think was the first ever class anywhere on Business Value Management at BA World in Toronto. It kind of crystallized everything I had learned up to that point. To illustrate what had happened in the IT industry over the previous 25 years since DoD-2167A, in the first part of the course I put TOGAF, ITIL, the PMBOK and BABOK and a few others into a medicine cabinet as labelled them as the "drugs" that the IT industry pushes to overcome the symptoms of project failures. I postulated that we needed to stop using the IT drugs...and go to root cause by starting with the results we want to achieve and work backwards. Start with intent
  • In January 2013 I got to participate in a Leadership Leaning Path as part of ICAgile in Boulder CO. This led to the opportunity to significantly influence the focus on Outcomes in their Business Value learning track using content from my course that I delivered in 2010 (the Business Value learning track has since morphed into a Business Agility learning track). It also indirectly influenced the Value portion of the PMI-ACP via the lead for the Business Value learning track who also contributed to the PMI-ACP
  • In 2013 I helped a little bit with the Gatineau-Ottawa Agile Tour (GOAT) where David Marquet spoke about intent-based leadership. It fits quite nicely with starting from intent (outcomes/results) to determine what we need to work on when. Believe it or not, there is neurosciences behind that approach - the Reticular Activating System in the brain helps us focus on what we value most which happens to be the things we set as our goals or intent. It then filters out the things that don't matter to us and filters in the things that do. In other words it makes us more likely to achieve the things we set our intent on.
  • So starting at end, and back-casting to the present, makes it far more likely that you and your team will achieve what it sets out to do and also make it far more likely you won't focus on things that are not related to that intent. Creating visual maps further enhance the RASs focus on achieving it. Now that's cool science that can help us do better at delivering results that matter
  • Over the past 4 or 5 years I have been mostly focused on agility and adaptability in my work, writing books (three so far with another one in progress), teaching, and presentations.

As William Gibson said "the future is already here - it's just not evenly distributed yet".

For those who may think all of this agile stuff is new because it's your first exposure - it isn't. If you think it's only about software or product development. It isn't that either. For those who think it refers to the period AAM (after the Manifesto for Agile Software Development) - it doesn't. It was made possible by some very leading-edge thinkers over 30 years ago...people like Ed Yourdon, Peter Coad, Rebecca-Wirfs Brock, Barry Boehm and others before them like Winston Royce and W. Edwards Deming. We all build on what came before. We should remember that.

Over the past 40 years, I got to be like Forest Gump, and be present at the different stages of this still evolving thinking, and make it part of me and what I do. It`s been a blast. It still makes we want to keep being a part of it.

What do I see looking ahead? The same thing I concluded in Agile Value Delivery: Beyond the Numbers in 2015 - that in the not too distant future, we will stop talking about agile as "a thing".

The reason? Because as humans we are naturally adaptable. Once we simply recognize the inherent nature of our adaptability, we can stop trying to put unnecessary structure and process around ourselves. Once we learn to do that, we become agile by default.

Here's to the next 40!

Posted on: December 21, 2017 02:36 PM | Permalink | Comments (13)

InfoQ Podcast Interview of me on The Agility Series, Cultural Agility, and more

@ICAgile's Shane Hastie's podcast interview of me has been posted on @InfoQ http://bit.ly/2tZePa2 - we talk about The Agility Series, Cultural Agility, the NFPPC, Value Management, Organizational Sustainability and Resilience, and whole lot more. Check it out!

Key Takeaways:

  • Value management is about doing the right thing, rather than doing lots of stuff, right
  • The reason for doing something should always trace back to an organizational strategic goal, and if it doesn’t then we’re wasting the organizations money
  • Introducing the ideas of cultural agility
  • The ability to understand multiple local contexts and work within them to obtain business results
  • A statement of strategic intent is not a statement of fact, it is a current direction which can change
  • Sustainability and resilience are enhanced through agility
  • Everything changes – the practices we are using now won’t be the ones we will use in the future, be adaptive to changing everything about how we do work

Posted on: August 02, 2017 08:08 AM | Permalink | Comments (5)

You might be a management red-neck if…

Full disclosure...this is meant as tounge-in-cheek...sort of...it was fun to write though....

The signature routine of American stand-up comedian Jeff Foxworthy is his “you might be a red-neck if…”. For example

“You might be a redneck if . . . you think you are an entrepreneur because of the “Dirt for Sale” sign in the front yard.”

So what does this have to do with management (and leadership too..)? Plenty. Especially if you are a manager in a traditional organization or one who continues to hang on to traditional approaches while everything else around you is changing. So how would you know if you might be a management red-neck?

You might be a management red-neck if…

  • you think you have the right to tell resources what to do, because well, you’re the manager
  • you think you need to tell resources what to do, because after-all, they are generally lazy and stupid anyway, and you’re the manager
  • you consider the time a resource spends at their desk an indicator of their productivity
  • you think the amount of documentation a resource creates while at their desk is an indicator of their productivity
  • you like to surround yourself by resources who are just like you are because you like resources who agree with you
  • you think it’s OK to take the credit for the work of your resources
  • you think it’s OK to call out one your resources in front of other resources
  • you’ve mastered management-speak and consider it a status symbol
  • you think status meetings are actually useful
  • you hold said status meetings every week
  • you like to hold said meetings because it shows you are the boss and you get to sit at the head of the table
  • you don’t see the distinction between reporting and actual progress on delivering something of value
  • you think being “the boss” is power and you like to tell every resource you meet that you are one, and have it
  • you think you have to make all of the decisions, because, you know, you’re the boss
  • you think having an office with walls is a status symbol (or worse, it’s just a larger cubicle than anyone else on your team has but you’re the boss so you get a bigger one…)
  • you think that negative feedback and “tough love” are the only way to get resources to do your bidding
  • you think that resources have to do your bidding without any questions
  • you think that knowledge is power, so you like to hoard it
  • you think it’s OK to watch another manager flounder because it will make you look better
  • you reward resources who thrive at fighting fires
  • you have no time for resources who like to avoid the fires in the first place
  • you will adhere blindly to a policy even when you know it will get the wrong results, because well, that’s the policy
  • you think outputs are more important than outcomes or business value
  • you’re now thinking “what the heck does he mean by business value?”
  • you refer to people as resources…and treat them as interchangeable pieces of raw material (see what I did there in the rest of the list :))

So what do you think? Any others you’d add?

PS: This is meant as humor…so if you are offended or if you see yourself in it, then you just might be a management red-neck… :) and I’m sorry to call it out…well not really…

The bright side is that we are never too old to change our ways!

Posted on: July 13, 2017 12:19 PM | Permalink | Comments (24)

Strategic Debt  — What it is and how to avoid it

Defining and delivering on a vision and strategy has been a hit and miss proposition for most traditional organizations for many decades. The reason for this is twofold.

First, traditional Industrial Era management thinking, and its accompanying models rely on the notion that we can use the past to predict the future.

The industrial era approach, often manifested itself in the 3 to 5-year strategic plan. The focus of this era was standardization (limited change), and mass production.

Secondly, this is not the reality of the Digital Era in which all organizations now operate. The current reality is constant and accelerating change from an ever increasing variety of vectors.

Yet, some still insist on trying to create the perfect plan to satisfy the perfectly indescribable problem.

This failure to adapt is creating strategic debt. Strategic debt, when left to accumulate, leads to the collapse of once vibrant enterprises in the private sector, and to the increasing irrelevance of organizations in the public sector.

Strategic debt is the deficit between the planned strategic goals and objectives that are set out at a point-in-time in strategic plans, versus the ones that emerge and evolve during execution. Such goals and objectives are both stated, and rightfully perceived, as hard targets. But what if the goal or objective statement is malformed, is the wrong one, or is no longer relevant?

Strategic debt accumulation is directly correlated to the time-gap between the point-in-time goals and objectives setting exercise and the time at which the organization begins to take a more adaptive and iterative approach to strategy execution.

Failing to accommodate changing realities while continuing to execute to the goals and objectives of a rigid strategic plan creates strategic debt, and since strategy sets the tone for the organization as a whole — the cost and associated risks are very high as the debt continues to accumulate.

To resolve this dilemma we need to iterate strategy in the same way we iterate product development that use frameworks such as Scrum. In this way, strategy undergoes a number of course corrections over time in an effort to achieve corporate value, similar to a sailor using tacking to make most efficient use of the wind.

Instead of casting our goals and objectives in stone in the form of specific strategic goals and objectives, we instead need to formulate them as statements of strategic intent.

A statement of intent is a statement that indicates what we are likely to do in the near future. Statements of intent are positive statements of the future you are trying to create, that are also intended to garner your personal commitment to their achievement.

Statement of strategic intent, which are statements of intent applied to a strategic context, can have any combination of near-term, medium-term, and longer-term components. They are expressions of the means by which we expect to achieve our organization’s vision. They are designed to provide context to the expected results that would be achieved if the vision were realized — without the how. How to achieve strategic intent is rightfully left up to the people who have to do the work.

As they are statements of intent, it also means we can both evaluate what we are about to do as well as the results from what we have just completed, against that stated intent; That is, it provides the opportunity to evaluate the intent itself, and to make needed adjustments based on new insights and experience. It also allows us to run experiments to validate portions of our intent before we make large people, time or financial commitments.

By using statements of intent, we are acknowledging that we might not have gotten it right the first time, or the second, or the third…It’s the relief valve that helps us to avoid creating strategic debt. It assumes strategy is indicative rather than fact.

To illustrate, consider the graphic below:

· Intended strategy is based on our statements of strategic intent.

· The deliberate things we do to achieve a given strategic intent become realized strategy (top line).

· There will also be statements of intent that we lay down that can remain unrealized for myriad reasons (poorly stated, not achievable, no longer relevant, etc.).

· And finally there will be that which emerges or evolves along the way that also get realized through deliberate action.

· So realized strategy is a combination of both deliberate and emergent strategy.

 

My partner Dan Murphy provides an example of using a statement of short, medium, and long-term strategic intent from his Cisco days; Larry Carter, then CFO of Cisco circa 1995 tasked his organization with closing the books world wide in two weeks instead of four weeks so that Cisco would have the financial data required to make better decisions. It took the team a few years to pull it off, but they did, by working in small tight iterations with small teams. However this was not a project at Cisco — it was a process. They kept going to continually refine and better the process providing continual improvement and delivery of value. Today, Cisco closes its books worldwide daily (effectively in real time). The intent was defined by Mr. Carter — not the how!

Posted on: July 10, 2017 12:51 PM | Permalink | Comments (9)
ADVERTISEMENTS

"Ninety percent of the politicians give the other ten percent a bad reputation."

- Henry Kissinger

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events