Working with Agile and ITIL: Teamwork


In this article, I'll explore one reason why Agile and ITIL compliment each other in IT service delivery. By design, they support teamwork at a micro and macro level respectively.

Agile promotes teamwork through the Agile Manifesto which contains the value of “individuals and interactions over process and tools” (Manifesto for Agile Software Development, n.d.). This should be interpreted as we value individuals and interactions more than process and tools. Individuals and interactions do not supersede process and tools and nor should process and tools be ignored.

One of chief Agile methodologies is Scrum which derives its name from the view that a product development team should behave much like a rugby team - a group of individuals, working as a unit, moving the ball down the field. Cohn (2010, p. 217) outlines that teams who embrace the Scrum methodology thoroughly, can demonstrate behaviours like:
  • whole team responsibility for delivery and quality,
  • minisiming individual tasks and expand on group based tasks,
  • team learning and knowledge management,
  • elimination of knowledge waste, and
  • renewing the team spirit.


This is reinforced by Smith and Sidky (2009, p. 33) who assert that all team members should sign off on the work that will be pursued during the sprint.

Scrums tend to be small teams, usually no greater than 8 people but scrums can scale for large projects. To achieve this, Cohn (2010, p. 340) suggests the following items should be in place:
  • shared backlog,
  • careful of dependencies between teams,
  • multiple scrum coordination, and
  • cultivating communities of practice.


So while scrums can scale (e.g. I've been in a 50 person project organised with a hierarchy of scrums), scrums by their nature are not designed to scale for large organisations with thousands of staff.

ITIL, on the other hand, is great at bringing silos of numerous IT teams together to work with a common purpose, and provide consistent service delivery with managed processes. In the ITIL Service Strategy book (Cabinet Office, 2011, p. 48), it states that "functions (teams) tend to optimise their work methods locally to focus on assigned outcomes. Poor coordination between functions combined with an inward focus lead to functional silos that hinder alignment and feedback critical to the success of the organization as a whole. Process models help avoid this problem with functional hierarchies by improving cross-functional coordination and control. Well-defined processes can improve productivity within and across functions".

To assist in cross-functional coordination, Spafford (2010) suggests that (ITIL)  process design and implementation methodologies should take into account the following:
  • Processes need to be formally documented for consistency, training and continuous improvement,
  • The process documentation should outline the intent and goal(s) of the process,
  • Process integrations need to be identified in the documentation,
  • Roles and responsibilities are clearly identified,
  • Training provided to staff at induction and regular intervals, and
  • Management should design processes to include the necessary data collection and reporting to provide oversight both on a specific process and on the system overall.


An interesting similarity between Agile and ITIL is the need for strong team leadership to ensure success. A Scrum team can’t be successful without a strong ScrumMaster, which makes the process highly dependent on one individual (Cohn, 2010, p. 33). The ITIL texts repeatedly asserts that an ITIL process is weak and ineffective without strong process ownership and support for the teams who underpin or support the process.

In summary Agile promotes intra-team work. ITIL, on the other hand, promotes collaboration across multiple teams or inter-team work. As a result of the presence of effective intra and inter team work, Agile and ITIL compliment each other, especially in larger organisations.


References
Cabinet Office (2011). Service Strategy. London, UK: TSO

Cohn, M. (2010). Succeeding with Agile, Boston: Addison Wesley

Smith, G., and Sidky, A. (2009). Becoming Agile in an imperfect world, Greenwich:Manning

Spafford, G. (2010). Breaking Down Silos - An ITIL Imperative. Retrieved January 8, 2013 from http://www.itsmwatch.com/itil/article.php/3889621/Breaking-Down-Silos--An-ITIL-Imperative.htm

Manifesto for Agile Software Development. (n.d.). Retrieved January 8, 2013 from http://agilemanifesto.org/

Comments

Post a Comment

Popular posts from this blog

Using the Lean Canvas for an IT solution proof of concept

Image
I was assisting a client with sourcing some new IT solutions. For one particular IT need, the client had shortlisted a potential solution with a trusted vendor but they needed to explore the potential solution further to understand its capabilities in more detail. They were unclear as to whether they should directly source with this vendor or go to the wider market (with a Request for Proposal (RFP)) to address this particular need. Further to this, it was unclear how long this project would run for so it was important to understand the time and effort that may be involved without consuming too many resources.  The client was seeking to employ a specific approach for this potential solution, where a “fail fast” lean Proof of Concept (PoC) would be conducted to rapidly test whether the potential solution was fit for purpose without spending unnecessary time and effort required to conduct a RFP. To start, we confirmed the following principles to guide the PoC: Do no...
Read more

Continuous Improvement with Agile, ITIL & Lean.

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 ...
Read more

Applying Scaled Agile Framework (SAFe) to IT Service Management and IT Operations

Image
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 ...
Read more