Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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:
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
1990-2000
2000-present
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 (15)
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 (10)
Start at the end or the beginning? Perspective Counts!
|
In my recent articles on Outcomes-focused Agility I talked about starting with the end in mind. I said that Outcomes-focused agility helps us to figure the WHY before we focus on the WHAT, WHEN, HOW, or WHERE of our portfolios, programmes, and projects, let alone which products we should build using Scrum. So it makes sense to start at the end. This is of course premised on the idea that your starting point is from Vision and Strategy and you have to figure how to achieve certain results. So when does it make sense to start at the beginning? When you want the process to help you determine where you are going! So what's an example of that? The Agility Series of books that we started last year. When you decide you want to write a book (in a work-world context) it's usually because you feel you have something worth-while to share. Whether you write alone or have a co-author or two, you have a pretty good idea of what you want to write about. So when I wrote Agile Value Delivery: Beyond the Numbers (available here and here), I had already written a few blog posts that had some of the ideas. The rest were developed as it was written - but the core ideas and what the book would cover, were mostly figured out in advance. That is, the expected results were pretty much known. The Agility Series, is an entirely different exercise. I have no idea where it`s going to end up. You can read more about the call to action here that we sent out for the second book we published in the series Leadership Agility: Enabling Sustainable Organizations. In it I ask potential participants to come on an adventure with me as the Agility Series Facilitator, as I have no idea where we end up together. It's an entirely different approach than an outcomes-focused one. We start by asking a series of questions of a Wisdom Council, that I co-develop with 3 others, Jen Hunter of GreatWork, Claude Emond, and Charlotte Goudreault. We ask Council members to offer up individual ideas (as many as they'd like to) for each of the questions which range from 5 to 7 questions in total. Once we get all of their ideas, we analyze them and look for common themes within each set of question responses. We then go back for the second round where we slightly re-word the questions and ask them to rank the themes in a series of pair-wise comparisons. From this set of results, I have the base for the book, to which I add our further analyses and complimentary research. The cycle-time has been roughly 3-4 months for each of the first two books from start to finish. But when we start each book-writing exercise, we literally have no idea where it will end up. It's actually quite exhilarating to get started each time, and extremely rewarding when we finish. The model is based on Jen's truly great work and model that she has used successfully in helping organizations make difficult decisions. By asking powerful questions, she is able to help clients identify the most compelling options to strategic choices that need to be made. In this way she able to help her clients get broad support from their stakeholders for the decisions they ultimately have to make. You can see an example of that over at her website. So perspective counts when deciding whether to start at the beginning (with no idea of where it might lead), versus starting with the end in mind ,where you would first articulate the results you want to achieve. The really interesting part, though, is this. With Outcomes-focused Agility we actually utilize both perspectives. We do indeed start at the end in order to determine what we need to do and the order (or sequence) in which we need to do it. But once we start, we adopt parts of what Jen uncovered in her work that helped her create her great work contribution to her clients. That's the agility-side of Outcomes-focused Agility, as we use an inspect and adapt mindset to iterate our strategies, and to also re-frame our expected results based on what we discover along the way. So we start at the end, and also at the beginning...in an iterative manner throughout delivery. So what do you think? Beginning or end? Does perspective count? ********************************************************************** How to contact me:
Want to engage me and my friends:
We also offer classroom training for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)
|
Posted on: January 11, 2017 07:40 AM
| Permalink |
Comments (3)
Focus on the positive
| A big part of traditional project management is Risk Management which consists of the following steps
Some teams will do all but the last step very early in the project - I have seen it done before they have even established WHY they are doing the project! In a recent post What? You don't know why you are doing your project? I discussed how outcomes-focused agility helps us to figure the WHY before we focus on the WHAT, WHEN, HOW, or WHERE of our portfolios, programmes, and projects let alone which products we should build using Scrum. Too much of an upfront emphasis on Risk Management has us focusing on what will go wrong before we have truly focused on what must go right. Humans have a bias towards negative thoughts according to Rick Hanson, Ph.D., a neuropsychologist. He says Our minds naturally focus on the bad and discard the good. It was much more important for our ancestors to avoid threats than to collect rewards: An individual who successfully avoided a threat would wake up the next morning and have another opportunity to collect a reward, but an individual who didn’t avoid the threat would have no such opportunity. He describes the brain as like "Velcro for negative experiences and Teflon for positive ones." While that may have been important when we were mostly hunter-gatherers, it is not such an important behaviour to have in modern organizations. In our second book in The Agility Series, Leadership Agility: Enabling Organizational Sustainability, we said that mindfulness is a core value of leaders that exhibit agility. Being mindful helps us to counter the effects of negative thinking (or the overemphasis what on might go wrong), as opposed to what must go right for us to be successful. Another example from everyday life - if you watch or read the news you would believe that 2016 was a horrible disaster. However, Col. Chris Hadfield, the renowned Canadian astronaut reminded us recently with a list of 46 things that show 2016 was actually pretty good. He concluded with There are countless more examples, big and small. If you refocus on the things that are working, your year will be better than the last. So what does that have to do with portfolios, programmes, and projects and risk management? Lots. An overemphasis on risk can cause us to forget to focus on the positive. So what is the positive for portfolios, programmes, and projects? Answering the WHY question before we jump into the WHAT, WHEN, HOW, or WHERE. Outcomes-focused Agility enables us to thrive in a VUCA-world where we face mostly holistic messes rather than discrete problems. Having a positive focus enables us to meet each unexpected event using an inspect and adapt mindset. Being mindful as a leader, is having the willingness to self-reflect and change our behaviors, attitudes, practices and processes, based on what we now know to be true. In my webinar Are you an Agile project manager or an Agile project leader? And why does that question matter? I talked about the fact that projects consist of known knowns, know unknowns (the risks we try to identify), and the known unknowns (those things we don't know and could never anticipate but that we must respond to when they occur). Focusing on knowing our WHY enables us to respond to each unexpected event or new realization along the way within the context of the specifics of what we are trying to accomplish, rather than focusing on all of the bad things that can go wrong that may have nothing to do with our WHY. If we instead focus on what we need to do (the positive) to achieve our WHY, then we will be far more likely to actually achieve it. When we spend most of our energy on making good things happen, and when engaging with our stakeholders more often and in a more positive context, then far less of the bad will actually happen. Positive thinking is not only good for ensuring success in our projects, it's also good for own personal well-being and the well-being of those around us. So what are you doing to engage in mindfulness and focusing on the positive so you and your teams can be successful? I'd love to hear your thoughts. ******************************************************************************************** How to contact me:
Want to engage me and my friends:
|
Posted on: January 06, 2017 07:43 AM
| Permalink |
Comments (5)
Outcomes Focused-Agility: Experience Report
Categories:
agile,
strategy,
servant leadersip,
Outcomes Management,
Scrum,
Leadership,
Benefits Realization
Categories: agile, strategy, servant leadersip, Outcomes Management, Scrum, Leadership, Benefits Realization
| In my recent post What? You don't know why you are doing your project? I indicated that I would do a follow-up post on examples of where I have used the Outcomes approach successfully. As you recall, the post was subtitled "Outcomes Focused Agility - Story Mapping our Strategic Intent". In this post, I'll provide two examples of where I have applied it successfully as well as provide an example of where I am currently using it with good success so far. Procure and Implement a Learning Management System (LMS) My role: had overall portfolio responsibility for guiding both the technical and business teams. The Context Several years ago I was hired by the Learning and Development group of a local government agency to help them procure and implement an LMS. They used to have all of their employees in one building. The situation was that employees were now in different cities, in different countries, and on different continents. Most PMs would view this as an IT project and would proceed to begin developing the procurement documents, and then following the procurement, getting it installed and configured for use. And if they did that within the expected 18 month timeline and $2.5M budget we had, they would have considered the project a success. However, by the measures of value that really needed to be satisfied, they would have failed. When you take an outcomes-focused approach, you start by asking why are they feeling they need to do this particular project? Ask why (along with what and how) enough times and you uncover all manner of actual need, many of which are left hidden using most project approaches. Over a period of the first 2-3 months of the engagement I helped them discover/recognize the following :
The Portfolio There were many other things we uncovered by asking why, but the above gives you a good idea of the real problems we had to tackle, which far exceeded just procuring and implementing an LMS. Using outcomes-focused agility, we were able to define the real work we had to do to make the implementation of the LMS a success for them:
We used a Services Canvas I designed based off of the Business Model Canvas to help them figure what services they offered to the rest of the organization and how they would be measured. Once we had the initial versions of the outcomes map and the Service canvas, wee would place the latest iterations of each on our wall and leave stickies and pens on a table beneath them. Most every day stakeholders and team members would walk by and spend a few minutes looking at the canvas and map and use the stickies to leave questions, comments, and ideas. This enabled serendipity across the team and stakeholders - while one person was adding stickies someone else would invariably walk by and they would then have a conversation about the map and canvas and the content of the stickies. Every few days we would collect everything and update the map and canvas and then hold additional brainstorming sessions with everyone. Both the serendipitous and brainstorming events enabled us to create a shared understanding of the why, what, how, who, when and where of our portfolio and it's various programs and initiatives with all of the required players as all of them contributed at different times and to different degrees to their creation. No one felt left out. We used Scrum on each of the initiatives including the procurement process, for doing business process design and development, and for systems integration. We also introduced the idea of using an agile approach to learning content development for the new content that would need be created for the new LMS to deliver. Without suitable content there was no need for an LMS! Having taken an outcomes-focused approach we also created the basis for value-based decisions across the entire portfolio for each of the products that would be created to satisfy each outcome. While Scrum assumes that someone else has already decided which products should be developed, outcomes-focused agility helps us determine which products have to be developed ( in this case learning content, business processes, an RFP, systems integration, etc.). It also helped us to establish the basis for value prioritization within each initiative and product so product owners knew the higher-level strategic goals that were to be satisfied. Remember products themselves are just outputs. They are not outcomes, nor do they measure the benefits of what you have done, and hence they also do not help you understand why you are creating them. They do contribute to outcomes, but they are not themselves actual outcomes. The Results Here is a summary of some of the project metrics (sufficient time has passed that I can share these):
The Learning and development group also restructured based on the new services they were now offering and the processes that supported them. The new processes and the restructuring ideas came from the people who were most affected by it - there was no need for organizational change management as it was change by engagement and with the design being done by the entire team. We managed to achieve far more real value delivery in the 18 months than was expected and for the same money, hence, we were able to deliver what they actually needed, rather than what they had originally intended of simply procuring and implementing an LMS. Build and Implement a Professional Licensure Management System My role: had overall portfolio responsibility for guiding both the technical and business teams. The Context A national professional association wanted to build a professional licensure management system. Again, this sounds like an IT project to most - after all we would be building a software product but in reality it was more complex actual scenario:
The Portfolio Using outcomes-focused agility helped us to identify:
This was way more than simply building a software product. The Results A coordinated delivery was established across multiple years covering facilities, infrastructure, hiring, product development, as well as an organizational restructuring that would enable them to stand-up and support a national professional licensure management system. Mature People, Process and Technology Capabilities My role: portfolio leadership and agility mentoring The Context The last one I'll report on is one that I am currently engaged in to mature people, process, and technology capabilities. The particular team in this case is a technical team that connects business line capabilities to one another. They have been in existence for 4 years and started out as part of a larger project. They split off into a separate team to carry on the operational side for their original development efforts as well as to do similar development work for other business lines. With the prospect of doing work for many business lines instead of just the original two, we felt that we needed to put more formality into what the team does and how it does it. We have identified four value streams to answer the four main outcomes questions as listed below:
The team sits inside of a very large IT organization, inside of a very large government department, so the work they do has a high degree of sophistication as well as being of significant consequence to the business. The team currently owns the entire development and operational support of what they build including at the platform level so we have to address topics such as:
As there are multiple very sophisticated technologies in play, it is not just enough to know what you must do, but you also need to figure out which technology is the right one to use in each circumstance. As a result, in order to determine what we must do (the initiatives) to satisfy a given outcome, we have had to create and execute initiatives whose goal it is to help us sort out our strategy for the actual initiatives to support the identified outcomes. The Portfolio By asking the four key questions above we have so far identified 40 initiatives that we need to undertake. The ones that are developing strategies for their focus areas will lead to the addition of more initiatives once they are completed. This is another of the hidden benefits of outcomes-focused agility as noted above - we can use strategy-development initiatives to both identify and define the initiatives we need to undertake to achieve a given set of outcomes on the map, even after we have already started on the portfolio - now that is the ultimate in outcomes-focused agility! We have also had to tweak some of outcomes statements as based on what we have learned in some of initiatives we have delivered on so far. When faced with such a high degree of uncertainty and ambiguity as this one presents for the team, outcomes-focused agility is proving invaluable in enabling us to do the things we need to do, rather than what we may have intended to do at the outset, across a very complex landscape. The Results - so far The fact that the goal of our work is to mature people, process and technology is not lost on us - maturing our people means constant inspection and adaptation to what we learn along the way. We are also able to adapt to new circumstances as they have emerged as we continue to do other work for the business lines. We are also advantaged by constantly iterating our overall strategy, based both on the strategy initiatives we have identified, as well as the ones that are implementing those strategies, that in some cases, we have yet to define. Another aspect of outcomes-focused agility is that it enables the portfolio team to more quickly assess the consequences of delays and changes in organizational priorities. Due to some external factors for example, we have had to revamp our outcomes delivery timelines within the portfolio. In one example, we were able to assess the consequences of deferring some initiatives to a later FY on the basis of getting less money this FY. We were able to do this assessment in less than 30 minutes! All we were given was the dollar amount that had to be deferred. Our map enabled us to make a value-centric decision as we already knew the relationships between initiatives, products, and outcomes (or results), and hence we could quickly determine which initiatives, products, and outcomes could be deferred while having the least detrimental impact on our overall strategic intent both in the short and long term. Without these maps and their details, this would have taken days if not weeks for something this large, and even worse could have led us to defer the wrong things. I have always ensured wherever possible that each of the initiatives within an outcomes map can be done within 3 months or less and that we use Scrum throughout. This incremental approach allows us to tackle complex situations in manageable pieces. It also allows us to re-vector our remaining work based on what we learn along the way. We are very definitely seeing the value of allowing emergence to guide us by tackling things in small enough chunks, that even if something turns out to not be what we expected, our investment in each one is not that great, so our risk exposure is significantly reduced. The Role of Emergence in Outcomes-Focused Agility Emergence, as I discussed in Chapter 7 of Agile Value Delivery: Beyond the Numbers, is more than just about our architectures and design as described in the principles of The Manifesto for Agile Software Development. It also applies to our understanding of the holistic messes we are solving that often contain many different problems as the examples above clearly demonstrated. In all of the above examples, it was never a single problem to be solved, nor a single project to be executed. I would suggest that this describes 99% of what we encounter in the real world, versus what is often attempted through single monolithic projects. Outcomes-focused agility directly supports this form of emergence, and also provides the context in which to story-map your strategic intent - even when you have yet to fully describe your strategic intent, as was demonstrated in the last example. Understanding emergence, and how to leverage the opportunities it uncovers, helps us to be comfortable with uncertainty and ambiguity. Outcomes-focused agility helps deal with emergence in a rational manner which then allows us to use and adapt multiple frameworks, practices, methods and techniques to achieve value-delivery. We use what is most appropriate to the context of each single problem we are solving, rather than trying a one-size fits-all approach, or even believing that we are solving a single problem, as we rarely are. One of the areas of outcomes-focused agility I have not yet attempted is to take the same focus towards the team itself - what outcomes matter to them? I hope to do some experiments with that over the coming months within my current portfolio. Benefits Realization Rather than address benefits realization under each of the above examples, I though I'd deal with it as a separate topic. For those of us familiar with outcomes-driven approaches, we know that the measure we use to determine the presence of our expected outcomes is to identify the benefits we would need to see in order to determine that the outcome was present. This is as I described it in Chapter 2 of Agile Value Delivery: Beyond the Numbers. Outcomes cannot be directly observed. They are only observable through measurable benefits. Much has recently been written about benefits realization, which is enjoying a noticeable resurgence of interest. However, without the context of outcomes-focused agility, we may end up focusing on the wrong things, and we still don't have a framework that facilitates our emergent and shared understanding in the face of ever-increasing uncertainty and ambiguity. Benefits realization by itself not enough. Conclusion Outcomes-focused Agility enables portfolio, program, and project teams to gain insights into both the magnitude,and the specifics, of what has to be done. It also provides executive levels with a high degree of confidence that we have thought things through enough at the front-end, without locking into solutions too soon, so that we can more fully create a shared-understanding of why we are doing things, and use that shared understanding to drive decision-making throughout and at all levels. An incremental delivery approach through value-streams, and their associated programs within a portfolio framework, also significantly reduces financial, schedule, and delivery risks. So we really don't have to plan or describe everything up-front. Recognizing this simple reality enables us to help the business and its customers/clients end up where they need to be, which may not be where they originally intended to be. And after all, isn't that what we all hope for? ******************************************************************************************** How to contact me:
Want to engage me and my friends:
|
Posted on: December 18, 2016 12:41 PM
| Permalink |
Comments (8)