Brandon's Notepad

February 13, 2018

Agile: Online Resources


This is a list of interesting articles and videos concerning Agile Software Development. I have read, watched, or listened to each one. They have been added here because I found the content useful, either in my current situation or for future discussions. Expect the list to grow.


The articles and ‘blog posts listed below are grouped by topic, but the topics are in no particular order. I tried to find the originating article for a topic (if possible) and then list below it (indented) other articles that respond to or built upon it.


At the moment, the list of videos is less-stringently organized than the articles in the previous section. The reason is that there are far fewer videos worth watching than there are articles to read, and I tend to favor long videos, which shortens the list even further.


January 30, 2018

Agile: A Conversion Story


This is the story of how I became an Agile convert. After sixteen years of denial, I finally opened my eyes to the benefits of this wonderful framework. Writing this post was a very humbling experience. I was seriously tempted to blatantly rip off Kubrick and title this post How I Learned to Stop Worrying and Love the Scrum.

My first exposure to Agile was sometime in 2001 in the form of XP (Extreme Programming). I was active on several developer discussion forums at the time and XP started coming up as a topic more and more frequently. One of my favorite discussion points was the need for proper traceability from concise, structured requirements to design elements and ultimately to code. XP, with its paper-based story cards strewn about on tables or cork boards and then entombed in boxes or banded stacks when the project was over, seemed to mock the sheer beauty and efficiency of a well-maintained requirements database that could be easily searched and reported upon. And paired programming? What a waste of developer hours! Why dedicate two people to a single programming task? What kind of coder needs someone constantly looking over his shoulder and critiquing every little typo anyway? I conceded that such foolishness may be tolerable for small applications or short-term engagements, but it would never work for real applications, the stuff of corporate I.T. projects that took many months or even years to deliver.

I happily ignored Agile for many years after that. Doing so was easy, as none of my clients or employers used any of the Agile frameworks, that is, until about four years ago when the new CIO at my company started talking about it…a lot…and not as a joke. No one in the department seemed to be taking him seriously, so I dismissed the notion that it would actually take hold, but I also knew that I could no longer flat out ignore Agile. If the CIO was talking about it, then I had to make sure he (and everyone else) knew that adopting it would be a mistake. I didn’t want to look like I wasn’t willing to be a team player, but I also didn’t want to throw away all of the hard work we had invested in creating a very stable and controlled development environment. That CIO left the company within a year. An interim CIO seemed to like the Agile concept, but admitted openly that he had no plans to change the strategic direction of I.T., preferring to “keep the lights on” and let the permanent replacement call the shots. Whew! We were safe. So I thought. The new permanent CIO, though not heavy in development experience, arrived already convinced of the efficacy of Agile.

Any attempt to derail Agile at this point would have been what we call a serious CLM (career-limiting move). It was time to adapt. But how? Our development, test, and release policies and procedures were hardly what you might call Agile-friendly. Frankly, our Project Management policy read like an excerpt from the PMBOK. I had no idea what this was going to look like or where to even start, When one consultant started managing his development team using Scrum, I asked to shadow him so that I could learn more about how Agile was supposed to work. I admit, I would not have been disappointed had I found evidence confirming my previous notions about Agile, but I attended the team’s events with an open mind and tried to leave my skepticism at the door. By the time he left for his next assignment, I still wasn’t convinced that Agile was going to be the right fit for our department, but I had learned enough to understand how it might work if everyone got used to it and agreed to play the game.

My biggest takeaway from this exercise was that, in terms of software development, Agile wasn’t significantly different from traditional development (i.e. the waterfall methodology), in that requirements still had to be gathered, software designed, code written, the product tested, and user documentation produced. What was radically different was that it severely limited the scope of these activities for a specified, short-term period of time; thus, it allowed for course correction at any point should (read: when) requirements change.  I learned that requirements needn’t be quite so formal or design so rigid, and that documentation can be limited to a sane amount that might actually be read again later. I still felt like a lot of useful information — mostly artifacts from the development process useful internally in many ways — was going to be lost in the process.

A few months passed and I continued to monitor the growing use of Agile within the development teams. By this time, most of them had latched onto Scrum terminology in particular. Overall, things didn’t seem to be going well. The teams were struggling with many different things, and it was becoming obvious that most of them were not truly adopting the Agile mindset. Then a golden opportunity arose! I managed to volunteer to be the Scrum Master on one of the teams. “As long as it doesn’t interfere with your regular duties,” my boss said as he gave me permission to fill the role temporarily. The project was failing and the team disjoint, so I figured it was going to be a serious opportunity to experiment and see what Agile could do to improve the situation.

The first sprint was rocky and I spent half of my time figuring out how to produce a proper burndown chart in the task management system we had selected. With the second sprint I began every daily scrum with the burndown chart on the large screen in the conference room. The (positive) impact this made on the team was shocking. Tired of watching me update tasks with hours spent and hours remaining, the team started keeping their own metrics up-to-date sometime in the third sprint. By the fourth sprint, we were “flying by instrument” as I like to put it. It was beautiful! The sprint backlog (in hours) was at about 85% of capacity, leaving a little wiggle-room for error, and we trended downward more-or-less as one might expect. I’d love to report that the project had made a sweeping turn just in time and became a stunning success, but sadly, it did not. Despite the great strides the team had made, it was not happening fast enough, and management pulled the plug on our experiment. The software was eventually released for production use, late, using conventional project management, but I walked away with a completely new perspective. I finally understood why and how Agile worked! I was no longer a critic, but an advocate.

Within two months, half of the department (including myself) had been formally trained and I jumped fast at the chance to be on the Agile transformation team that would be responsible for the formal adoption of Scrum. Half a year later, I earned my certification. Looking back, it amazes me how quickly my view of Agile changed so completely. I have since learnt a great deal beyond what was covered in training, but I will have to write about such things another day.


January 19, 2018

Agile: My Journey


About a year before I wrote this post, I set out on a journey that I was not expecting to take. I became seriously involved in Agile software development, the Scrum framework to be more specific. Prior to that time, I was not only completely uninvolved, I was an outward opponent of Agile as a result of my initial exposure to Extreme Programming (XP). What changed? Where am I headed now? That’s all part of my story.

This is a work in progress. If you find what I have posted so far to be interesting, please feel free to follow me on Twitter and/or

My Journey

In the spirit of Agile, I’ve decided to document my journey in the form of stories, the sum of which constitute an epic. Cute, eh? No, I didn’t plan for it to happen this way. The stories have just emerged. This is the landing page. As I publish the parts of my story, I will link the posts to the list items below. This will take time. I am still on the journey.

  • My Conversion Story
  • Why Agile Works
  • I think I’m missing something here…
  • A (Hard) Lesson in Writing Stories
  • Let Them Eat Cupcakes
  • Team Working Agreements
  • more to come…
  • The Agile Blogger

I’m building a list ofAgile Online Resources as I go, which contains links to interesting articles and videos that have helped me on my journey.

My Goal

As with all of the content on this site, my primary goal is to record my personal notes on this topic for later use. A secondary goal is to make this information available to anyone who may find it useful. Another huge personal benefit is that the preparation required to write on this topic almost ensures that I will ingest the material

Why Now?

So, why am I writing about Agile in 2018? It’s been seventeen years since the Agile Manifesto was penned, and even then, some of the Agile variants had already been in use for ten years or more. Agile isn’t new anymore, it’s not the next big thing. In the grand scheme of things, I arrived on the Agile scene quite late and I am far from being an expert (yet). The answer is that this post (and its related content) is as much about me and my experiences as it is about Agile itself. I’d like to think that this makes the material unique, but I know that I am following where many other developers have already trod. Nonetheless, I hope that writing my thoughts will provide value.


August 15, 2017

Great Leaders GROW

Filed under: Book Reviews,Business & Economics,Management,Self Improvement — Brandon @ 4:52 pm


This is a short review of “Great Leaders GROW: Becoming a Leader for Life” by Ken Blanchard and Mark Miller.

The story is straightforward. Blake Brown loses his father, a successful business executive, just as he is about to complete his college degree. He reaches out to Debbie Brewster, a long-time associate of his father, seeking career advice. In a series of one-on-one coaching sessions, she shares with Blake what his father had taught her both by word and example over many years. Meanwhile, Blake lands a job at one of his preferred potential employers, Dynastar, but is assigned to a cold, heartless boss with impossible expectations. With Debbie’s advice as a guide, Blake manages to lead the company out of a bad business position and helps the boss confront a difficult personal situation to boot.

Just in case it wasn’t obvious, “GROW” (rendered in the title in capital letters) is a mnemonic device. It represents four activities that help people become good leaders. Each activity focuses on an area of continuous improvement. They are revealed by Debbie as the story progresses, and while I would love to provide a summary, I feel like I would be taking away the whole purpose of reading the story. If you really must get to the point without taking the time to read, there is a very concise summary of the activities at the end of the book. Also, Blanchard himself gave away the first three (G, R and O) in this 2012 interview with Forbes, and covers all four in a series of ‘blog posts about the book made just prior to its release.

Was it a good read? Yes. As I said, the story was straightforward and easy to follow. The plot and character development was sufficient for a work of this length. In my mind, it played out like a drama-comedy show (sometimes called a dramedy), despite the seriousness of some of the scenes. I mentally cast a young Jason Bateman in the role of Blake (think The Hogan Family, not Horrible Bosses), a conservative Jack Black as Sam, his ne’er-do-well coworker at Dynastar, and Ellen Barkin (Animal Kingdom) as Debbie Brewster. Ms. Barnwell, the impossible boss, was played by one of my former coworkers (who shall remain nameless), but Michelle Monaghan (Made of Honor) or Liv Tyler would be a close visual approximation. Cinematography akin to that used in shows like The Office or Boston Legal accommodated the serious bits, yet allowed for humor, sarcasm, and plenty of those sideways ‘whatever’ glances. I felt that picturing the books’ scenes in this “format” was appropriate given its length; after all, isn’t that what sitcoms are all about? All problems solved in thirty minutes or less?

One side note, many of the summaries, commentaries, and reviews of this book (e.g. Washington Post) contain the same line, stating that Great Leaders GROW “is an instructive fable”. This line is so prolific that I imagine it must come from the authors themselves, in the promotional materials perhaps. It’s a bit of a peeve, but this story is not a fable! There are no talking animals at all in this book! It may be better described as a parable, because, like a fable, there is a lesson to the story — a ‘takeaway’ to use contemporary office vernacular — that can be summed up in the pithy phrase that gives the book its title: Great Leaders GROW.

April 14, 2017

The Future Workplace Experience


This is a short review of The Future Workplace Experience: 10 Rules for Mastering Disruption in Recruiting and Engaging Employees, written by Jeanne C. Meister and Kevin J. Mulcahy and narrated by Nancy Linari.

Is your company keeping up with the trends of the modern workplace? Have you found that you have been unable to retain new hires in recent years? Times are changing and so is the workforce. The benefits people seek in their careers are different than what they were even a decade ago. This book will help you assess how your company fares in the task of providing an awesome workplace experience and will open your eyes as to what it should (and should not) be doing to attract, engage, and retain good workers in the modern labor economy.

The ten rules mentioned in the subtitle are:

  • Make the Workplace an Experience
  • Use Space to Promote Culture
  • Be an Agile Leader
  • Consider Technology an Enabler and a Disrupter
  • Build a Data-Driven Recruiting Ecosystem
  • Embrace On-Demand Learning
  • Tap the Power of Multiple Generations
  • Build Gender Equality
  • Plan for More Gig Economy Workers
  • Be a Workplace Activist

I have personally watched — and in some cases, contributed — to the implementation of some of these ideas in real-world settings, and from what I can tell, the authors are pretty much spot-on in their recommendations. The book is packed with a ton of case studies and research findings that support not only the direction of the trends, but also the efficacy of the changes. Even though I am not a Human Resources professional, I found the proposal and discussion of these rules to be not only interesting but useful. Now some of the things that I’ve seen changing around me make much more sense. The first — and I would classify it as the most fundamental — rule about making the workplace an experience has caused me to have an entirely new outlook with regard to my own career potential and sources of motivation.

Growing up, I perceived that there were basically two roads to success: the corporate ladder and the self-made man (sorry ladies, rule #8 wasn’t in full effect back then). The former seemed like the better way to acquire wealth, but most have to settle for not finishing their careers at (or even near) the top, which always seemed a little sad to me. On the latter path, you start at the top (e.g. opening a corner grocery, like Mr. Hooper on Sesame Street), but there’s only so much monetary reward that can be gained, and of course, I eventually learned about capital and investors and such, and being either bought out or put out of business by the competition didn’t seem very satisfying either. In recent years I’ve come to realize that the legacy you leave doesn’t have to be about how much inheritance you leave for your children, or the possibility that the company may someday name a building after you, or even that the grocery store you created may eventually grow into a huge chain of stores. All things perish, and the best you can truly hope for is that you are able to inspire others. “Others” may include your children, friends, colleagues, clients — whoever gets to hear your greatest stories. And great stories are made from great experiences. Sometimes you can craft your own experiences, but the authors of this book understand that companies that are not actively trying to assist you in that endeavor don’t perform as well today and are therefore less likely to exist tomorrow.

The other rules are also important to understanding the modern American labor market and how HR must help guide companies in this realm. I find the concept of using work space to drive a culture of collaboration and creativity absolutely fascinating. So-called “gig workers” have been around for some time, but I had no idea that this arrangement had become nearly as popular as it reportedly is today. As an active member of a workplace diversity team, I am very familiar with issues surrounding age and gender gaps and how they can lead not only to ineffectivity but also discrimination. And, if not for continuous on-demand training, well, I wouldn’t be writing this book review right now. The attitude of the authors toward continuous learning is precisely what drives me to share my life learning experiences via this ‘blog.

There are two things I didn’t care for in this book and I think they are related. First, I didn’t care for the narration (I listened to the audiobook format). I looked up Nancy Linari online and discovered that she is an actress and acting teacher. I’m not familiar with her work at all, so I watched a few clips online, and I can’t count this as one of her best performances. Her delivery is a little too steady. Overall, I felt like she was just reading a script and that she wasn’t really all that interested in the material herself. The other thing I didn’t care for was the name dropping, list upon list of companies doing this or that. As I said, I’m not an HR professional, so any anecdotal value the uttering of a particular string of company names is supposed to have was completely lost on me. The inclusion of these references became annoying and the narration did little to help in this regard. Linari’s tone would change in just a certain way and I would tell myself, “oh no, not another list”.

In all, though, it was a valuable read. Part of continuous learning is recognizing when that which you have learned in the past — through either study or experience — has become outdated. It is better both psychologically and for your career to learn new things like those discussed in this book outright and to adjust than to allow yourself to become rigid and set in the old ways of doing things.

February 17, 2017

The 4 Disciplines of Execution (4DX)


I was first introduced to The 4 Disciplines of Execution (4DX) by a colleague at work. Our training department provides the opportunity for employees to host book reviews as part of our continuing education, and since my colleague found this book very useful in setting and attaining his own professional goals, he shared his experiences with the rest of the company and continues to advocate the adoption of 4DX by other teams. I too have found it useful; thus, I am sharing it with you.


The 4 Disciplines of Execution is the title of a book by Chris McChesney, Sean Covey, and Jim Huling, published in 2012 by Free Press. In it, the authors propose a new strategy for accomplishing new goals and producing better results. The problem with any initiative aimed at improvement is that it must give way to the day’s business, what the authors call the “whirlwind.” To use an age-old analogy, they simmer on the back burner while the pot in the front is watched to make sure it doesn’t boil over, and when mealtime approaches, the food in the back is often either burnt to a crisp in an attempt to make up for lost cooking time or never finished at all. How can one manage to maintain steady progress toward attaining their goals without these risks?

The 4 Disciplines themselves are covered in detail in the first section of the book. In a nutshell, they are as follows:

Discipline 1: Focus on the Wildly Important
The first discipline is all about setting goals. The key is set just a few of them, only one or two if possible. If you have too many goals, it is impossible to focus on them all and nothing gets done. Having only one or two will help ensure that you can stay aware of what they are.

Discipline 2: Act on Lead Measures
Most people focus on outcomes, but if you want to drive progress toward achieving a goal, it is much more effective to measure the inputs. A textbook example used by the authors (and everyone else; the “Hello World” of productivity) is weight loss. Don’t measure the pounds. Measure caloric intake and hours of exercise. Outcomes are typically predictable if the right inputs are identifiable, measurable, and controllable.

Discipline 3: Keep a Compelling Scoreboard
If you are serious about achieving a goal, you must know where you stand at all times. A compelling scoreboard that is easy to update and understand improves motivation. The scoreboard must have both form and function.

Discipline 4: Create a Cadence of Accountability
Holding yourself accountable usually means communicating progress to another person or group, preferably on a frequent basis. If there are no consequences for performance (or lack thereof) then the goal becomes meaningless and forgettable.

The authors go into much more detail and cover some important tips and pitfalls, some of which are not obvious or intuitive. After all, if the process was just this simple, it wouldn’t have taken eighty-two pages to describe it. The second section provides practical advice on how to install the Four Disciplines in a team setting, and third on how to roll them out to an entire organization. The latter part of the book contains interesting case studies and answers to some frequently asked questions.


It stands to reason that people and organizations that perform repetitive tasks have a lot to gain from this approach. Take sales for example: the number of customer contacts made in a period of time may be a good lead measure that can predict sales outcomes. Changes in process can then be focused on improving the lead measures first and foremost, and only when the point of diminishing returns is reached should focus be changed to a less-impactful measure.

This does not mean that the approach is limited to granular homogeneous tasks only. One team at my office — the team my colleague is in — is already building the 4 Disciplines into their departmental operations this year. Their work is analytical and more-or-less project-based. There is not a lot of granular work as you would find in, say, a factory or call center; however, they do gather a variety of metrics and are always looking for ways to streamline their procedures. Their first step is to identify which procedures have the biggest impact on their workload and then to figure out how to identify and manipulate the lead measures to produce a positive outcome, to shorten total project time for example.

It seems quite incidental that my company is also changing its approach to employee development, and that while it is not based specifically on 4DX, the two seem to fit hand-in-glove with one another. In fact, I’ve already decided to manage the progress of my own training and performance goals this year using the 4DX methodology.

I have experimented some with 4DX on a completely personal level, mainly to get a feel for the nuts and bolts of it. In my opinion, one of the toughest parts of the process is identifying the lead measures — which are not always obvious. It’s a matter of finding the input(s) that have the highest correlation coefficient to the desired output, to borrow some terms from statistics. Also, it is important to recognize that outputs aren’t always singular, and that optimizing one output may have a devastating effect on another. Going back to the weight loss example, consuming minimal calories may do wonders for reaching the desired weight, but at the risk of suffering malnutrition.


I definitely recommend this book, and to be honest, I can’t wait to start using the methodology in a more professional capacity. The funny thing is that, as I sat here in our corporate library editing and polishing this post today, another colleague came in looking for a book. She asked if I had read any of them and if I had any suggestions. I immediately recommended the 4DX book, as there are still several copies left on the shelf. I told her that it would be instantly applicable to her work and relayed to her that I was planning on using it for managing my performance goals. She walked away with a copy in hand and a smile on her face. I will have to follow up with her in a few days to see what she thinks.

August 9, 2016

The Energy Bus


The Energy Bus This is a short review of The Energy Bus, written by Jon Gordon.

The Energy Bus is a fictional story about a man named George whose life seems to be coming apart at the seams. His performance is being scrutinized at work, his wife is disenchanted with him as a husband, and to top it off, he leaves for work one morning only to find that his car has a flat tire. With no spare and no ride, George is forced to take the bus. This is perhaps the best thing to ever happen to him, for on the bus he meets Joy, the bus driver, and her band of merry passengers who present to George a new perspective on life. George undergoes a miraculous transformation and gets his life back on track.

Though a bit longer than the traditional fable, this story was written to teach a series of lessons about personal happiness, effectiveness, and success. Through the character of George, the reader is reminded that he is the driver of his own bus and is in full control of powering and steering the vehicle, as well as being responsible for the passengers he brings on board. The rules of the bus, established by Joy, provide the basis for having a fun and meaningful ride. The bus, of course, is a metaphor for one’s life. The Ten Rules for the Ride of Your Life can easily be found online, and are even provided in printable poster format by the publisher.

I was introduced to this book as part of a corporate seminar led by ethics expert and motivational speaker, Dr. Paul Voss. The seminar focused on lessons from this and about four other books. From the title, I was concerned that the book was steeped in New Age teachings on how to channel psychic energy in the workplace. Dr. Voss reassured us that the book was not about that at all, just about how our attitudes heavily influence our performance within our work community, so I went along with it. While Voss’ interpretation was certainly valid and my fear was more amplified than what the text warranted, the book did make at least one explicit mention of the Law of Attraction, a pinnacle of New Age ideas prevalent in works such as A Course in Miracles. The author didn’t harp on this much at all, so if you discount the New Age concept of energy and want to read in the context of simply having a positive attitude (as Dr. Voss advocated), the story still works.

The book definitely made an impression on my colleagues, some more than others. Rule #6, “No Energy Vampires Allowed” has been particularly popular around the office. In addition to hiring Dr. Voss to discuss the text to us, the company also purchased some promotional materials for the employees, including some postcard-size versions of the poster linked above, and some smaller cards (approx. 2″x3″) that we were invited to hand out to others or to post in our cubicles as reminders of the lessons contained in the book. In all, as a source of workplace motivation, the seminar and the book were quite successful.

February 11, 2016

ITIL: Service Strategy


To master a body of knowledge means to internalize it and become so intimately familiar with it that the student becomes the teacher. This post was started as a place to capture my notes about the Service Strategy stage of the ITSM model, and with the date scheduled for my ITIL Foundations exam still weeks away, there is already discussion at the office that my team may offer a series of short introductory classes on various aspects of ITSM. That’s why I shifted gears, now less interested in posting yet another set of topical outlines and bulleted lists, and more focused on synthesizing the material and presenting it in my own words, thereby making it more interesting and memorable.

Disclaimer: I wrote this page to capture my perception of the ITIL material, not to provide adequate guidance for passing the ITIL exams. Moreover, this page has been written (so far) without the use of the official ITIL Foundation 2011 Syllabus; therefore, the information may be incomplete.

Service Strategy Overview

The entire ITIL framework is a roadmap for converting IT into a service-oriented business. Of course, external service providers have existed for a long time: web hosting, e-mail, IT outsourcing, and the like. Converting the internal IT department into a more-or-less independent entity is another thing altogether, and can be quite a paradigm shift to many. Service Strategy is the stage of ITSM that most resembles the job of senior management in any given organization. It is the ‘business’ of doing IT.

Purpose. The purpose of Service Strategy is described in the literature as the four P’s: perspective, position, plans, and patterns. (I’ve personally never found mnemonics like this one very helpful, and I only mention it here because it is in common usage.) These are the same concepts found in strategic management textbooks. Perspective is another word for vision, describing the business in terms of customers and services offered. Position basically refers to market position, and includes that which makes the organization unique. Plans and patterns are similar in that they relate to the forward motion of the organization. Patterns refer to the things that the organization does on an ongoing basis, core competencies if you will. Plans are more strategic in nature and focus not just on staying in business, but growing and transforming it.

Objectives. Having a vision is great, but a business must have a concrete foundation if it is expected to survive. If the four P’s constitute the vision/mission statement, then the objectives of Service Strategy is akin to a business plan. The vision must be stated, but the details of how the business plans to get there must be articulated in concise detail. The services to be offered, the value they represent for the customer, how they will be funded and delivered, and what assets will be required are the same sort of details that a bank wants to know before making a loan to a start-up company in any industry.

Scope. All service organizations should have a strategy, even if they operate within a larger organization (such as an internal IT department). It is good to keep in mind that the strategy focuses on two main concerns: how will the organization meet its customers’ needs, and how will the resulting services be managed and maintained?

Value Creation. Ultimately, services will only be used if they provide value, which can take on various forms, from cost reduction measures (such as outsourcing) to value-add items (such as product differentiation). Value comes from the conversion of assets (both tangible and intangible, resources and capabilities) into goods and services. Value must be clearly presented in terms of business outcomes that the customer understands. In a nutshell, the service organization is constantly on the ‘buy’ side of a build-versus-buy cost-benefit analysis. At the same time, the service organization must stay in tune with the customers’ needs and always work toward fulfilling them, even when those needs change. Flexibility can be vital to staying competitive. Of course, these statements are true for any service organization, not just the information technology service provider. Turning the IT department into a profit center (as opposed to the traditional cost center) will drive efficiency and effectiveness. How does the customer perceive the value of a service? Economic value is usually based on a reference point, the cost of the old service that the new service will replace, for example, or even the price of similar services offered externally. This amount is adjusted based on the perceived benefits and costs of switching. The new service may provide many benefits, but at the cost of giving up one or two key features. It is always important to know if there is a gap between what the customer values and what the service organization thinks it is providing.

Risk Management. Customers will usually purchase a service if they don’t want to own the costs and risks of providing the same service to themselves. The service provider must now identify and assess potential risks.

Service Types. Services that are customer-facing may be basic or “core” services or they may enhance a core service and thus differentiate the service provider from the competition. Services that support a customer-facing service but are not visible to the customer are called enabling services. For example, an online e-mail service is a modern commodity, but a feature that presents communications as aggregated conversations instead of individual messages is an enhancement that differentiates the service from other online e-mail services (at least until they all provide that feature as core). The underlying database, the network infrastructure, and even the third-party virus scanner used by the e-mail service are supporting or enabling services.

Service Strategy Processes

As with all of the ITSM stages, great emphasis is placed in the processes of Service Strategy. Different texts order the five SS processes differently. I’ve chosen to order them in what seems to be a natural progression.

Strategy Management. Without the formation of a strategy, the service organization would lack direction, and some or all of the following would not be implemented.

Portfolio Management. An investment portfolio includes a number of varying financial instruments that, in aggregate, help the investor achieve certain investment goals. Some portfolios reduce risk through diversification, whereas others help protect investment dollars from inflation. This concept has been extended into the project management space, as each project in the portfolio has an estimated net worth and return on investment (ROI). A service portfolio is the same concept applied to the mix of services offered by a service provider. The portfolio includes not only the services that are currently being offered (i.e. the Service Catalog), but also services being developed (the Pipeline) and services already retired. Moreover, procedures must exist for determining which services should be added and which should be retired, and when. A business case can be written for each proposed service addition or modification. The documents that describe all services are stored in a configuration management system comprised of several different data sources.

Financial Management. Services are not free to offer. They have operating costs associated with them that can be reasonably predicted at the time the services are designed. Of course, an initial investment is required to design a new service and to implement it in the operating environment of the customer. And it should go without saying that no business should enter into a new deal if there is no hope of turning a profit from it. Some services cost more than they are worth, and some service providers have a propensity to get in over their heads when committing to dead-end service offerings. It can be very costly to implement someone’s ‘good idea’ for which there is no actual demand. Without a financial management component, the service provider may take on significant financial risks such as these with little or no hope for recovery of investment. Financial Management assists in the valuation of services, and provides information needed for demand modelling and the optimization of provisioning activities. This process also ensures compliance with accounting principles, regulations, and reporting requirements as well as the establishment of good budgetary practices and the billing and collection of revenues from the customer if applicable.

Business Relationship Management. As the name implies, the role of the business relationship manager (or what I’ve always called an account rep) is to maintain the relationship between the service provider and the customer. It is not enough, however, for this manager to ensure that the two entities simply stay in communication with one another at least occasionally. Customer satisfaction is the real focus here. The manager must understand the value being provided to the customer, identify new and changing customer needs, and ensure that the service provider adjusts as necessary to meet these needs. Feedback from the customer (including compliments and complaints) is one obvious source of information the manager can draw from, but changes in the customer’s industry, as well as changes in technology should also be monitored. Business Relationship Management falls on the strategic end of the spectrum, whereas Service Level Management is far more operational in nature.

Demand Management. Services cannot be stored in inventory like physical goods can. Costs are incurred and revenue generated as services are consumed. Therefore, the service organization should avoid generating too much (excess) or too little (insufficient) capacity. Analyzing patterns of business activity can help predict the demand for individual services. Uncertainty in demand is a risk.


Nothing in the Service Strategy literature should come as a surprise to someone who has studied business in the university. The contents are a mishmash of topics from strategic management, marketing, cost accounting, and microeconomics. In fact, some of the example scenarios I read were in the context of running a hotel or other common type of business. It appears that ITIL basically expresses what non-IT service organizations already do in an IT context.

September 8, 2015

ITIL: Foundation Certification


ITIL has become very popular at work, so I am currently studying for the ITIL Foundation certification. This page was created to capture my notes, not only on the exam material itself, but also on my approach to learning it.


Several of my coworkers have passed the ITIL Foundation exam after only a few days of instructor-led training, and I’m a fairly good test taker, so I figured that I’d try self-study first. At work we have access to CBT modules, which are often helpful. Before diving into that, however, I wanted to get an idea of what the material should look like, partly to gain some external verification that the CBT was covering the same topics that I’d see on the exam. To this end, I started watching introductory videos on YouTube. I quickly found that the ITIL training materials are diagram-rich, so I started collecting links to the same or similar diagrams on the Web. I also procured a few additional resources, both online and in print. Finally, producing this page forces me to know the material well enough to organize and present it.

Resources At work, we have access to, which includes a 7.75 hour ITIL Foundation course presented by Mark Thomas. I enjoyed this course thoroughly. The material is covered in a very logical, methodical way that is easy to follow. Mr. Thomas is obviously very passionate about the material he is presenting. His style gives him away, as he speaks like many other SVP/C-level executives I’ve known in the past. I highly recommend the course, and I think that this course alone is worth more than the fee for a one-month subscription to

YouTube. As mentioned above, I started by viewing introductory videos on YouTube, primarily to get familiar with the basic ITIL concepts. Here are a few of the more noteworthy choices:

The last video, recorded by Jesse of Bit2Brain, contained some good insight into the experience of taking the exam. It was comforting to hear how the exam isn’t necessarily difficult depending on your experience, and that this certification is truly meant to be entry level. Incidentally, Jesse highly recommended Mark Thomas’ course on That’s all I really needed to hear before diving in.

Axelos ITIL Glossary. Alexos is the official accreditor of ITIL. They have made available online Glossaries of Terms in a variety of languages. This is very handy, as I reference the definitions to specific terms in my notes here instead of pasting the text directly.

Print Materials. I obtained two print resources at the office:

  • Passing your ITIL Foundation Exam published by TSO (The Stationary Office), Crown Copyright 2009
  • ITIL Foundation (June 2014 ed.) by Global Knowledge Training LLC, copyright 2014

The former covers the 2009 update of ITIL v3, and not the (current) 2011 update, but it looks like the differences are minuscule. The latter is used in the Global Knowledge training course, which is the one my coworkers attended. The material strictly adheres to Axelos guidelines and even contains a printed version of the glossary.

Test Bank. I have considered, but have not yet decided to purchase access to Kaplan’s ITIL 2011 Practice Test.

Exam Overview

The following is a distillation of what I understand the exam to be like. I will reserve details for additional posts linked herein.

Qualification Scheme. Do an image search on ITIL and one of the first diagrams you will see will resemble a pyramid. This is the Qualification Scheme, or at least that’s what it is called in the TSO book. I won’t go into detail about the various levels that must be obtained to become an ITIL Master, but I do want to point out two things. First, this exam covers the bottom layer only. Second, the content covered on this exam is obviously an overview of the five Lifecycle modules and does not appear to cover the Capability modules. The Foundation certification is designed for those who only need a basic understanding of ITIL and the Capabilities stream is the more in-depth of the two. Here are some examples of the Qualification Scheme diagram (with links to their sources):

Introduction to Service Management. More to come…

The Service Lifecycle

Like I said above, the Foundation exam is structured based on the Service Lifecycle and heavy emphasis is placed on its five stages and their various processes and functions and how they interact with one another. Here is a table of Service Lifecycle processes. For the exam, one should be familiar with the definitions found in the glossary for all processes. Those processes listed in italics should be studied in greater detail.

Service Strategy Service Design Service Transition Service Operations Continual Service Improvement
Read My Summary Coming Soon… Coming Soon… Coming Soon… Coming Soon…
  1. Strategy Management
  2. Financial Management
  3. Service Portfolio Management
  4. Demand Management
  5. Business Relationship Management
  1. Design Coordination
  2. Catalog Management
  3. Service Level Management
  4. Capacity Management
  5. Availability Management
  6. Continuity Management
  7. Info Security Management
  8. Supplier Management
  1. Planning & Support (TPS)
  2. Change Management
  3. Service Asset
    & Config Management (SACM)
  4. Release
    & Deploy Management (RADM)
  5. Service Validation
    & Testing (SVT)
  6. Change Evaluation
  7. Knowledge Management (SKMS)
  1. Event Management
  2. Incident Management
  3. Request Fulfillment
  4. Access Management
  5. Problem Management
  1. 7-Step Improvement Process

The stages of the Service Lifecycle are not strictly sequential, like the Waterfall SDLC in application development, but is partially iterative and partially holistic. Services are designed (SD), implemented (ST), and maintained (SO), but all within the scope of a core strategy (SS) and within a spirit of continuous improvement (CSI). Here is how the lifecycle is typically depicted:

Key Definitions

The following is a vocabulary list that I’ve compiled based on the recommendations made in my various study sources. Most of the sources gave more or less the same suggestions. I tried to form logical groupings, but this proved to be difficult considering that these concepts are interrelated in so many ways. Most if not all of the terms and phrases should be found in the ITIL Glossary.

Service (Core, Enabling/Supporting, Enhancing)
Outcome & Value (Utility & Warranty)
Service Management, Service Provider
IT Service & IT Service Management (ITSM)
Service Provider (Types I, II, & III)
Customer (Internal & External)
User / Supplier / Contract
Risk, Governance, Business Case, User Profile
Critical Success Factor (CSF)
Key Performance Indicator (KPI)
Metric, Vision, Mission, Objectives
Vital Business Function (VBF)
Pattern of Business Activity (PBA)
Business Impact Analysis (BIA)
Service Level Management (SLM)
Service Level Requirement (SLR)
Service Level Target
Service Level Agreement (SLA)
Operational Level Agreement (OLA)
Baseline (Performance)
Process / Function / Role
Assets (Capabilities & Resources)
Assets (Customer vs. Service)
Service Owner
Process Owner/Manager/Practitioner
CSI Manager

Event / Alert / Incident / Problem
Normal Service Operation
Incident (Model, Procedure, Major)
Known Error / Workaround
Escalation (Functional & Hierarchy)
Service Request

Service Desk
Technical Management
IT Operations Management
Application Management

Service Portfolio / Catalog / Pipeline
Service Design Package
Configuration Management System (CMS)
Configuration Item (CI)
Change Advisory Board (CAB & ECAB)
Change, Remediation Plan


ITIL Infographics

I am a big advocate for using comprehensive infographics. “Put it all on one page if you can!” I say. So, here are a few diagrams that do just that

The Big Picture.

Value Creation (Utility & Warranty).

Process Model.

Processes (ITIL v3).


The Service Lifecycle (Alternative View).

RACI Model.

Cross-System Comparisons

COBIT. There are some obvious similarities here. A few graphics are available to show how COBIT functions map to ITIL.

Microsoft Operations Framework (MOF). Look familiar? Yep, Microsoft has created a framework of its own, claiming that it’s simplified process eliminates the problems of top-heavy ITIL. Sounds like a shortcut to me. The upside to this one is that it is free. Here is a comparison.

ISO/IEC 20000. From what I’ve read, ITIL and ISO 20000 are highly compatible.

Just For Fun

Who said ITIL can’t be fun? Here are a few pieces of “fan art” I’ve picked up along the way.

Periodic Table. I used to know the periodic table of elements by heart. I’m not sure I could use this graphic as a way to memorize ITIL, but it certainly is a neat idea.

Map of the ITIL Empire. This map has absolutely nothing to do with the ITIL framework, but it does spark an idea. Why not create a map like this one that shows the interactions between various ITIL functions and processes?

Mass Transit Map. This map, in the style used for mass transit systems, shows tops along the various processes. Interesting idea! I found another version as well.

More to come…

Blog at