Prevailing Service Management

Introduction to (Agile) planning poker In Agile software development, work (new features, maintenance tasks, etc) is timed boxed into sprints or iterations of a fixed time period, usually somewhere between 1 - 4 weeks. Before each iteration begins, the product manager, iteration manager and the team meets in an iteration planning meeting. This meeting aims to determine what work will be pulled from the team's backlog (prioritized list of work awaiting delivery) and delivered in the upcoming iteration.  As part of this iteration planning meeting, the team will either revise or initially score each story card (piece of work) with points. Points are whatever the team decides them to be but usually points are used to gauge how big a story card is to complete. Story cards can be sized using Fibonacci (1,2,4,8) or t shirt sizes (S, M, L, XL). The team usually knows how many points they can deliver in an iteration so assessing each story card, assigning them with their respective po

As an IT Service Management (ITSM) leader with a strong preference to leveraging Agile, Scrum and Lean (including LeanIT) to effectively and efficiently deliver IT operations, I became quite interested in the concept of the Scaled Agile Framework by Dean Leffingwell and his associates. The Scaled Agile Framework ® (pronounced SAFe™) is “an interactive knowledge base for implementing agile practices at enterprise scale”. In the SAFe website, Leffingwell states that “this model of agile adoption has been elaborated primarily in my books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and my scalingsoftwareagilityblog.com . It has been successfully applied in programs of only 50-100 people, and in enterprises employing thousands of software developers.” SAFe has four (4) core values: 1. Code Quality (because you can’t scale crappy code); 2. Program Execution

With the advent of cloud computing (regardless whether it is private, public like AWS, Rackspace, etc, or hybrid) a popular meme has arisen to "treat your servers like cattle, not as pets". This meme suggests that IT organisations should change their views (and therefore behaviors) with servers in the cloud by not treating servers as their favourite pets, but rather act like farmers and view their servers as cattle. There are several blog posts already on this topic by authors like Mark Needham , Greg Ferro , Massino , Simon Sharwood . The  slide below from  Gavin McCance from CERN  provides a great, single image of the meme. His  presentation titled “ CERN Data Centre Evolution ” detailed the scientific organisation's 12,000-odd servers and plans to manage them more efficiently. From this slide, you probably now understand the meme: If pets are sick, we nurse them back to health. If cattle are sick, we destroy them (sounds harsh, but we can spin up new servers

I previously led an IT Service Management team provided Incident, Problem, Change and Configuration Management services in line with   ITIL . Our work was highly variable and ranged  in complexity since we primarily supported other IT professionals in their IT operations. T he whole team used Agile Scrum to manage our work and the problem analysts used Lean Kanban for (ITIL) Problem Management. This blog post will outline how Kanban was applied to effectively deliver our Problem Management service. Our organisation used Agile as the main delivery method for projects, and Lean (based on the Toyota Production System) for operations. Bell and Ozen (2011, p8) suggest Lean aims to empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity, providing individuals with more time and better information to exercise problem solving, creativity and innovation in situations that are not routine. What is Kanban? Kanban means sign, sign

My IT Service Management team provide Incident, Problem, Change and Configuration Management services in line with ITIL . Our work is highly variable and ranges in complexity since we primarily support other IT professionals in their IT operations.  Agile is the chief service delivery methodology in our organisation and so we have adopted and tailored Agile's Scrum methodology as our way of working. I have been fortunate enough to present on this topic to numerous conferences but time doesn't allow me the opportunity to explain how we work in great detail to interested peers. I thought I'd share more detail on how my team has adopted Scrum, and this article assumes you already know some basics of Agile or Scrum. As a side note, my team as a whole uses Scrum; the Problem Management analysts use kanban for their daily business-as-usual (BAU) work (managing problems/known errors). In this article, I'll focus on the team's adoption of Scrum. The main

On 18 June 2013, I was one of twenty four honoured speakers to present at TFT13 , the world's biggest online IT Service Management conference. My topic was Leading IT Service Management using Agile  and this was my first presentation at an online conference. " TFT, Tomorrow’s Future Today , is the world’s first 24-hour, global, follow-the-sun virtual conference. It has a size and level of innovation that has never been seen before.  Speakers are   selected by their peers   and elevated to a global stage overnight.  All content is accessible,   without registration , pushed to Kindle and Evernote, available on iTunes, Vimeo, YouTube, BrightTALK and SoundCloud. " Shortly after the conference had finished, #tft13 had generated 7.6 million social media impressions. I was humbled to be selected for this event, and I enjoyed the opportunity to work with other IT Service Management thought leaders and to learn Google Hangouts. Using my Google+ account , I found infor

One of the key roles for an agile team is the Scrum Master (or otherwise known as the Iteration Manager). Hartman (2009) summaries the Scrum Master's responsibilities as: "The Scrum Master is responsible for ensuring that the Team adheres to Scrum values, practices, and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Team understand and use self-management and cross-functionality. However, the Scrum Master does not manage the team; the team is self-managing." But who should be a Scrum Master, when the team may already have a team leader or manager? I'll briefly explore the opportunities and challenges of two main approaches. Team leader as scrum master: Opportunity : As Hartman stated above, the team should be self managing but when disputes arise, the team leader has

One of the most common practices in Agile is the daily stand-up or scrum. The term scrum, adopted from the game of rugby, is a daily opportunity for team members to unite and share: -          what they did yesterday, -          what they’ll do today, and -          what is blocking them from delivering value to their customers. The reason it is also called a stand-up is because the participants stand. Usually taking 10-15 minutes, this gathering forces participants to stand and encourages them to be brief and provide only relevant information for their team. In most circumstances, the standup works well. However there can be times when the team members start to discuss trivial or irrelevant matters about what they did or will do. There can be various reasons for this, including perhaps a self-induced pressure to say something rather than nothing, or to be viewed as “contributing alot by speaking alot”. While the scrum master or iteration manager (facilitator of the

In this article, I'll lightly explore continuous improvement using Agile, ITIL and Lean. Continuous improvement with Agile Agile is more than just a modern software development process, it is having an agile mindset (or to demonstrate agility for your customers' dynamic needs). While the Agile Manifesto outlines four (4) values, it is principle 12 that highlights Agile's focus on continuous improvement. Principle 12 states " At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly " (Principles behind the Agile Manifesto, n.d.).  Retrospectives are one instrument that Agile provides to check the health of your service delivery and identify improvement opportunities. Held at the end of a sprint (time boxed interval of enhanced product delivery), the retrospective gives stakeholders an opportunity to reflect on: - what went well for the sprint (to repeat it again), - what didn't go well (to