The Agility Series

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!

The Cultural Agility Questions are now live!

I am excited to kick off the first round of questions on Cultural Agility which you can start to answer immediately by clicking on https://lnkd.in/d259Ny8

We will be closing the first round on March 31st with the second round to follow shortly thereafter. We hope to have both rounds concluded by mid-April so we can prepare to speak on the this topic at Spark the Change Montreal being held on May 11-12.

The questions can be answered by anyone so please share as widely as possible in your own networks - the more insights we get the richer our collective wisdom will be! Thank you so much for helping us spread agility!

Kindest regards - Larry

Now that the New Year is off and running, we will be getting started on the next book in The Agility Series which will be on Cultural Agility. So what exactly is Cultural Agility and why does it matter?

Within the agile space much has been said and written about creating/enabling an agile culture or a culture of agility. Here's one definition I came across for an agile culture that pretty much sums it up: 

An "agile" culture (with a lower-case "a") is one that has adopted a style, approach, and community that is tolerant of failure, willing to test hypotheses, and able to adjust to changing market conditions as deemed necessary.(1)

But is that the same thing as cultural agility? Apparently not.  There are multiple definitions out there such as:

Cultural agility is the mega-competency which enables professionals to perform successfully in cross-cultural situations. Culturally agile professionals succeed in contexts where the successful outcome of their jobs, roles, positions, or tasks depends on dealing with an unfamiliar set of cultural norms—or multiple sets of them (2)

And this one:

Cultural agility is the ability to understand multiple local contexts and work within them to obtain consistent business results.  For today’s global organizations, cultural agility is the new competitive edge. While individual capacities are important, successful organizations build an institutional level of a global mindset and skills for effectively coordinating, negotiating and influencing across boundaries. (3)

While there are many other definitions, all seem to be focused on the fact that organizations may operate in different locales and need to be culturally aware (3) or there are many different cultural groups that may exist inside of your local organization (2). Most organizations that I have dealt with in recent years have an incredibly rich set of international cultures resident within them. This trend is increasing. And to me, that's a good thing.

I would take culture a step further and say that modern organizations need both an agile culture, and their people need to be culturally agile. My hypothesis is that the former provides focus for developing the shared values and principles that guide our collective actions, while the later helps us understand how we personally interpret and apply those shared values and principles, which will necessarily affect how we interact with those who are culturally different than we are. I feel both perspectives are crucial to success in modern organizations. I think it also fits with my humanist tendencies. Wikipedia defines humanism as:

Humanism is a philosophical and ethical stance that emphasizes the value and agency of human beings, individually and collectively, and affirms their ability to improve their lives through the use of reason and ingenuity as opposed to submitting blindly to tradition and authority or sinking into cruelty and brutality.

For those who may be wondering, this definition is not, for me, an anti-religious stance. It's more focused on the idea that we really all do need to get along if we are to create vibrant and long-lived organizations. We also need to be able to draw on the collective wisdom of all rather than on the ideas of just the few people at the top. 

The two books in The Agility Series so far have been guided by the ideas provided by people from Australia, Great Britain, Canada, USA, Singapore, France and Belgium. As these two were by invitation-only to be a member of the Wisdom Council for each book, we are planning to open it up for the remaining seven books in the series so that we can have an even greater mix of countries and cultures represented.

What better book to start doing that than with the next one we are tackling on Cultural Agility?

Want to explore what cultural agility means to you and why it matters?

To join in our next adventure in agility, look out for a post in a few weeks when we officially launch our first round of questions for the third book in The Agility Series on Cultural Agility. If you want to read the first two books in the series, go to www.mplaza.ca and download Organization Agility and Leadership Agility to get you into what we have explored so far. I have removed the pricing on Leadership Agility so it's now free to download!

Want to have a say in the questions we'll be asking in Round one?

Jen Hunter and I will be giving a presentation at PMIOVOC on January 25th at noon called Best decision yet: Aspiring together to co-create global wisdom! If you are in the Ottawa area, come join us as we let you in on how the Series came about. You'll also get a chance to provide input to the set of questions we will use in the first round of ideas gathering for Cultural Agility! Hope to see you there!

PS: also come join the conversation on our LinkedIn Group 

(1) https://www.quora.com/What-is-Agile-Culture

(2) http://www.culturalagility.com/

(3) http://lexicon.ft.com/Term?term=cultural-agility

*********************************************************************************

How to contact me:

• Send me an e-mail directly
• Follow me on Twitter: @cooperlk99
• Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

• Check out our LinkedIn Group
• Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
• You can also purchase the second book in the Agility Series on Leadership Agility or my very first book Agile Value Delivery: Beyond the Numbers
• We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details

We also offer classroom training for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

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:

• Send me an e-mail directly
• Follow me on Twitter: @cooperlk99
• Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

• Check out our LinkedIn Group
• Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
• You can also purchase the second book in the Agility Series on Leadership Agility or my very first book Agile Value Delivery: Beyond the Numbers
• We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details

We also offer classroom training for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)