Me and My Kanban

(also posted on www.devops.com)

There has been a trending interest in Kanban Boards, a tool that helps teams visualize their workflows, limit work in progress and get more “done”.   Kanban Boards are mostly associated with Agile Scrum teams as a collaborative means of seeing the burndown of a sprint.   In fact, Scrum and Kanban are considered to be so interdependent that a new framework called Scrumban is starting to emerge.   However, Kanban is not limited to Agile.  A Kanban board can be very useful for any project or scope of work that would benefit from visualization. 

The premise behind the Kanban is almost deceptively simple.  A board is built with three columns:  “To Do”, “In Progress” and “Done”.   At the start of each sprint, all of the work that needs to be completed is captured on individual sticky notes and placed in the “To Do” column.  When the task or work is actually being undertaken, the note moves into the “In Progress” column.  Upon completion, it is moved to the “Done” column.   If the team has successfully completed the work that was planned for a sprint, all of the cards that began in the “To Do” column will end in the “Done” column.  Any other result opens the opportunity for questions about impediments, team velocity (the ability to absorb work) and sprint planning.

You will often see team kanban boards built on whiteboards and peppered with multi-colored sticky notes.  There is also a great online tool (www.leankit.com) that offers a virtual team Kanban board with many of the same characteristics (including virtual sticky notes.  If the three columns are too basic, you can certainly add more columns because of the nature of the project.   The only caution is that it is easy to inadvertently make deceptively simple into overly complex.  Beware!

I have recently started to use a personal Kanban board to manage my own workload.  While not perfect, I have seen a significant improvement in my ability to get things done.   It also helps to keep me organized and focused.   I like moving the sticky notes around.

To begin, I created a backlog column with a colored note for each of my outstanding tasks.  The list is never-ending so notes are added to the backlog just about every day.  At the start of each week, I re-prioritize the backlog to ensure that deadlines and other considerations are addressed.  I then take a reasonable chunk of tasks off the top and add each note to the “To Do” column.  These are my goals for the week.  When I start to work on a particular task, I move its note into the “In Progress” column.  Upon completion, the note is moved to “Done”.   At the end of the week, I celebrate what I have accomplished and analyze what was left behind.   

If a note stays in the “In Progress” column for too long or moves back to “To Do”, I have to question why.  Did I overestimate my velocity or time it would take to complete a task?  Have I been faced with extensive interruptions or unplanned work?  Was I waiting on someone else?   The visualization of the Kanban board helps me understand my own patterns of work and recognize how I contribute to or impact the results of my team.  

I highly recommend that everyone to set up a personal Kanban, whether for work tasks or home tasks.  You can use the whiteboard in your office or set up a free basic online board through LeanKit  (www.leankit.com).   The results were be very interesting.

The DevOps Diet (Getting Lean)

(Also posted on devops.com)

IT has gotten fat – fat silos, fat processes, fat procedures.  Adopting DevOps is a great opportunity to look at some of our unhealthy habits and identify where we can eliminate unproductive waste from our process diets.  DevOps will ultimately teach IT how to exercise more with less effort, trim the fat and get lean.

According to lean principles, the seven main areas of waste are:

• Defects –  variations from requirements that result in interruptions and re-work
• Overproduction – delivering something more or before it is required
• Inventory  –  carrying excess raw materials, work in progress (WIP) or finished goods
• Over-processing – doing more work than is required
• Motion – moving people or equipment more than is required
• Transportation – moving products from one location to another
• Waiting – doing nothing or moving slowly while waiting on a previous step

What are the greatest sources of waste in your IT organization?  Are defects being regularly passed downstream? Are ITSM processes overproducing through complexity and bureaucracy?  Are Agile teams  dealing with excessive work in progress and less finished product?  Are unresolved bottlenecks resulting in frequent delays while waiting for something to get done or someone to be available?  Could automation reduce "motion sickness" and make transportation nonstop? These questions will hopefully facilitate dialog between Dev and Ops about analyzing and streamlining existing workflows.

While waste is fattening, it is not necessarily ineffective.  Projects and other tasks are still getting done and therefore some areas of waste may be difficult to recognize.  To become leaner, start simple by identifying and eliminating one unhealthy habit from your IT diet.   Engage stakeholders from Dev, Ops, customers and suppliers (if appropriate).  Discuss ways to improve the work with healthier habits.  Agree on what to do next or what not to do anymore.

Every diet should be supported by recipes for success.  The upcoming DevOps Cookbook by Gene Kim, et al. will provide more tangible guidance and recipes for healthy IT habits.  More on that in future blogs.

Most of all,  identifying and eliminating waste through Lean DevOps is a great opportunity for collaboration.  After all,  it's always better to diet with a friend.

Cultural Debt

There has been a lot of talk lately about IT’s accumulation of “technical debt’.  Technical debt describes necessary work from a prior deployment that was deferred in favor of other tasks.   As technical debt grows, the ability to make future changes is hindered because of backlog was not addressed.

I have recently come to recognize that IT suffers from another type of debt – cultural debt.  IT is a young industry that grew rapidly  while facing constant pressure to bring technical innovation to the market. Cultural considerations were deferred  in favor of building and deploying products and services.  IT’s silo culture grew organically out of the need for diversifed sets of specialized experience and expertise.

While cultural debt was accumulating,  IT’s complexities were increasing.  The single platform mainframe vanished in favor of multi-platform servers.   Production applications grew exponentially. The IT supply chain went from a single location department  to a network that spans multiple geographies and organizations. Although IT’s silos were also acknowledged to be  IT’s constraints, converging different processes, frameworks,  vocabularies and customs was not going to be easy.  And so the cultural debt grew.

Like all debts, payment is eventually due.  For IT, the due date is  today. Cultural debt is having a tangible impact on the bottom line by hindering IT’s ability to meet the pace of deployment that the business now requires. Every bottleneck in the workflow between Dev and Ops affects the entire system of supply and demand.  The business has zero tolerance for missed deadlines, poor quality code or fragile applications.   A paradigm shift is required in order to improve IT’s consistency and speed.

The good news is that an increasing number of individuals and organizations are looking to pay down cultural debt by embracing a DevOps approach. Case studies are emerging that demonstrate proof of concept - silos are breaking down and people are talking to each other. Tools are enabling automated tasks and deployments are happening faster with fewer defects.  Dev and Ops are starting to embrace a common set of practices and accountabilities.  Best of all, DevOps is stemming the rate of future technical and cultural debt  - and that’s a win for everyone.

Scrum Gets Things Done

Scrum is the most prominent of the Agile frameworks.  In many instances its concepts and vocabulary have become synonymous with Agile.  Why?  Because the Scrum framework brings to life all of the values and principles promoted by the Agile Manifesto.

What is Scrum?  I particularly like this description from Scrum.org:

Scrum is a simple framework for effective team collaboration on complex projects.  Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

Scrum is often mistaken for a method just for building products. Nothing could be further from the truth – it is a methodology whose primary objective is to get things done – first by defining “done” and then by steadily progressing the forward through short increments known as “sprints”.   Each sprint burnsdown a backlog of work until the entire project is "done".   

Other beneficial aspects of Scrum include:

•       Good planning and review

•       Agreed user stories

•       Small self-organizing teams

•       Improved communication (daily standup)

•       Better workflows and fewer bottlenecks

•       Reduced work in progress

•       Improved responsiveness

•       Measurable accomplishments

•       Shorter feedback loops

Scrum is deceptively simple, yet difficult to master.   Is Scrum the only Agile framework?  No.   The use of Kanban is also rapidly growing – giving rise to another emerging framework called Scrumban.    Stay tuned to future blogs for more on this.

I strongly believe that everyone in IT should learn about Scrum.   Let’s get things done!

The New Jayne Explains - Let's Talk About Agile, Agile SM, Lean and DevOps

For several years  now, I have been blogging about updates in the ITSM industry.   “That’s interesting, Jayne” some of my followers have recently said “But what we really want to know is what the next generation of IT and ITSM will or should look like.”   OK - I may have an opinion or two about that.

It’s taken a while, but the trends are becoming clearer.   Individuals and organizations are starting to  look at complementary frameworks, methods and movements such as DevOps, Agile, Lean, Agile Service Management® and others in order to take their IT and ITSM efforts to the next level. 

What does that mean?  Are ITSM processes no longer going to be relevant?  Of course not.  It means that we will have to  build on what we have already accomplished by doing it faster.   It means we will have to break down some pretty significant silos.  It means we will have to integrate the best of Dev and Ops’ processes, practices and vocabularies into a universal system that spans the entire IT supply chain.  It means we will have to actively reduce bottlenecks, waste and work in progress.  It means we will have to accept automation as a member of our teams.  It means that ITSM processes will have to be more agile, more lean, more “modern”.    It means we have to learn and share and assimilate all good ideas into a custom framework that specifically fits the needs of your business.  A little scary?  Perhaps.  Exciting? Definitely.

Let’s embark on this new knowledge journey together.  Some of the frameworks, methods and movements mentioned do not (yet) have definitive bodies of knowledge but good practices are starting to emerge.  I will now use Jayne Explains to share my observations, insights as well as bits and pieces about what I learn along the way.    Hopefully we can also use this blog as a forum to engage interesting discussions and help shape the future of IT learning.  ITSM Academy’s  introductory DevOps Overview course is already available with more detailed DevOps Fundamentals and Agile Service Management courses on the way.  Stay tuned.   

The future is here - welcome to NextGen ITSM®

What Does it Mean to "Be Agile"?

It seems like the term “agile” is surfacing everywhere lately.  While originally intended for software developers, the term has permeated our IT culture and become part of our vocabulary.   While the word is commonly used, do we also have a common understanding of what it means to “be agile”?  Particularly in the context of service management?

Agile is primarily a state of mind that is reflected in a set of core values and principles.  By itself, it is not a framework, standard, set of practices or methodology.  It is more of a perspective than a prescription.  Agile values are embedded  into and brought to life through approaches such as Scrum, Kanban, DevOps and Xtreme Programming.  The concepts reach way beyond software development.  Agile is now recognized to be equally relevant to other domains such as service management or business process management.

At the heart of Agile is the Agile Manifesto – the output of a set of frustrated developers in 2001 whose collective goal was to refocus their community to what really matters.    

The Agile Manifesto is supported by a set of twelve principles that further elaborate on the core values.  The Manifesto and its principles can be viewed here.

At first glance, the Agile Manifesto may seem to diminish or obsolete everything we have taught and worked so hard to achieve in service management.  Nothing could be further from the truth.  The authors acknowledge that they do value the items on the right, they just value the items on the left more.  Don’t we also? 

In order to “be agile”, we may have to refocus our community too.  Refocus it to be more business-centric than it-centric.  To refuse to prize flowcharts, documentation, tools and plans over successful business outcomes.  To collaborate with our customers and ensure that we understand and are delivering ongoing value.  

Mostly, we need to do JUST ENOUGH of the items on the right to deliver the items on the left consistently.   Agile doesn't negate what we do and teach in service management, it actually lightens our load and allows us to be true business enablers.  Awesome!

What would an Agile Service Management Manifesto look like?  Here is my vision:

This is certainly not perfect. I hope it is a starting point that opens a forum for healthy discussion and collaboration.   Let's do what the developers did - agree on a set of core principles that focus on what really matters.   

ITSM Academy recognizes that being agile is and will be an important aspect of the next generation of rapid innovation.  We have created a line of training for Agile Service Management  and are introducing new Agile and DevOps courses that marry agile values and frameworks to service management practices.   We are already actively delivering Certified ScrumMaster,  Certified Process Design Engineer (CPDE) and DevOps Overview.  Coming soon:  DevOps Fundamentals  and Agile Service Management: Essentials.  Stay tuned!

Ten Years Later

This week, ITSM Academy will celebrate its tenth anniversary.    Our whole team will be in Fort Lauderdale at our annual “all hands” meeting. We will use this time to draw on each other’s energies, ideas and capabilities to review the past, assess the present and prepare for the future to ensure that we continue to deliver value to our customers and to each other.

Ten years ago, many organizations were unfamiliar with ITIL or service management.  Awareness was slow and mostly at the large enterprise level.    There was not a lot of ITIL education available in the US.  The primary areas of focus were Incident and Change Management. Lisa and I helped found the 9^th itSMF USA Local Interest Group in South Florida. 

Things have certainly changed.  Here are a few of my observations:

• ITIL is no longer just for the Fortune 1000 organization.  The need for service management programs and practices has transcended every vertical market including government, non-profit, global and local organizations.  This is a very positive indicator about scalability and the fact that you do not need a million dollar budget to manage your services.
• Service Management is shifting the focus from apps to services.  The definition of “service” is still not as business-centric as it should be but we are closer than ever before.  Service Catalogs are more common and are being used to request and understand services by both the business and IT.
• Service Management programs are maturing and moving beyond Incident and Change Management.  Today’s roadmaps include processes such as Problem Management, Demand/Capacity Management and Service Portfolio/Service Catalog/Service Level Management.
• More organizations are interested in implementing Service Management Offices (SMOs).
• While ITIL is a great service management framework, it is not perfect and cannot stand alone.  More and more organizations are integrating their service management practices with frameworks such as Agile, Lean, DevOps, Project Management and Cobit.
• Interest in organizational change concepts is increasing.  Change the way people think and you are more likely to change the way they behave.
• Mobile computing, the cloud, BYOD and other influences are forcing IT to move faster and be more efficient.   Traditional service management will need to upgrade to Agile Service Management and leverage methodologies such as Scrum to improve velocity and workflow.
• DevOps is revolutionizing the relationship and flow between IT development and operational teams. Organizations will have to assess and improve culture, automation, measurements and sharing (CAMs) in order to compete.
• The future is now.

Technical innovations over the past ten years have been remarkable – from desktops to laptops to smartphones, tablets and beyond.   The next ten years will be an even wilder ride.  We are getting ready - are you?