Category: Kanban

Embracing Change and Dotcom Operations

“The Only Thing That Is Constant Is Change” – Heraclitus

Change is necessary in business, technology, and in our personal lives. For me, these past couple of months I have had a lot of change in my life. From moving to a new home to starting a new consulting assignment, change has been abundant. While change can be unsettling, it’s necessary for growth. This brings me to latest consulting role, working in Dotcom Operations.

The picture above shows the monitoring screens located across from where I sit. As you can tell, it’s no small deal. Keeping a live production website running which handles thousands of transactions per second is no small ordeal. To do so, while also adding changes and enhancements, requires talented operations teams.

In my view, operations teams don’t get the credit they deserve. The people I’m working with in web operations are some of the most technical folks I’ve worked with. They are also good people. They are infrastructure engineers, coders, and they work with the latest DevOps technology.

It’s fun learning about the latest technology they’re using in Web Operations. Infrastructure built in the cloud using tools like Jenkins, Chef and Splunk has given me a broader perspective on IT. It’s taken me back to my days testing software in QA, but things have changed. The technical systems for web operations are more advanced than they were five years ago.

Technical systems are always challenging to manage, but what’s more challenging, are the human systems. People need to collaborate and communicate with each other, and this is where I come in to help. The effectiveness of operations teams relies heavily on communication.

To help with communication and the constant influx of work coming in, the teams use Kanban. Kanban uses a pull system to make process better. Below is an example of what you may have seen with a Kanban board.

The core practices of Kanban are as follows:

  • Visualize Workflow – Using Kanban, teams can see the whole visual representation of their workflow.
  • Limit WIP (work in progress/process) – Teams should experiment with WIP limits, which will help improve focus and increase throughput.
  • Manage Flow – By paying attention to how quickly work is getting through the process, teams can begin to improve flow management.
  • Make Process Policies Explicit – Teams should set their own policies on how they can best do their work and improve flow.
  • Implement Feedback Loops – This is about continuous improvement. Just like in Scrum, Kanban teams need to measure their effectiveness and continuously improve.
  • Improve Collaboratively, Evolve Experimentally

Kanban comes from manufacturing and the TPS (Toyota Production System). The below quote is from Taiichi Ohno, creator of the TPS:

“There is no magic method. Rather, a total management system is needed that develops human ability to its fullest capacity to best enhance creativity and fruitfulness, to utilize facilities and machines well, and to eliminate all waste.”

Eliminating waste was a major rule of the original TPS. TPS identified seven types of waste in manufacturing. They are Transportation, Waiting, Motion, Defects, Inventory, Overproduction and Extra Processing.

Years later, Mary and Tom Poppendieck defined the following seven categories for waste in software development.

  • Partially done work
  • Extra processes
  • Extra features
  • Task switching
  • Waiting
  • Motion
  • Defects

An effective way of identifying waste for is through creating Value Stream Maps. Often the biggest bottlenecks occur after development and testing are complete.

Summary

Over the past few years I’ve managed a broad range of IT projects. From working in the insurance industry, to reverse logistics programs, to Web Operations. While this work has commonalities, Web Operations is different. Tackling a constant flow of work is a change for me, and change is good. The change to Web Operations has provided me with two key opportunities. The first and most important, is to provide value and help a talented team of engineers. The second is to learn a different aspect of IT and business.

Are you embracing change in your business and in your life? If you work in software development, are you continually trying to reduce waste and follow lean principles?

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

 

 

 

 

 

 

Kanban vs Scrum – What You Need To Know

Kanban vs Scrum

If you are familiar with Agile you know about Scrum and Kanban. While these two Agile frameworks have similarities, they are also very different. Their differences go way beyond stickies on boards. In this post I’ll describe the two frameworks and their history, as well as their benefits and differences.

Scrum OverviewScrum is by far the most used Agile framework. Credit for the framework goes to Jeff Sutherland and Ken Schwaber. Scrum got under way back in 2001 after the creation of the Agile manifesto.

Scrum is great for complex software delivery projects. In Scrum, there are defined team roles which are Product Owner, Scrum Master, and development team. The Product Owner creates a backlog of user stories that define the scope of a project. The team then completes the stories in short iterations called “sprints”. Sprints usually last 2-4 weeks. Sutherland was influenced by his days as an Air Force pilot. He relates the team sprints process to coming back from short missions and landing the plane on time.

The goal is to have working software, approved by the Product Owner, at the end of each sprint. The stories worked on in the Sprint should be done (all testing completed..etc). The key metric used in Scrum is Velocity. Velocity is the average amount of points a team can complete in a Sprint. Within Sprints, change to work is discouraged.

The stories completed in each sprint represent part of the total project scope. The team repeats this cycle of sprints until all stories in the backlog are done, in which case the project ends.

Kanban Overview  – “Kanban” get’s its origins from the Toyota Production System. Back in the 1950s, Taiichi Ohno created a pull system for Toyota. The idea was first sparked by his experience in American supermarkets. He was fascinated by how shoppers would walk down the ails pulling only what they needed from the shelves and putting it into their shopping carts. Shoppers usually had a list they carried which told them what they needed.

In Toyota plants, “Kanban” are instructions in clear plastic that communicate information needed at work stations. In a sense, a Kanban is like a grocery list. When an order comes in, a Kanban would be used to pull the whole car creation process together. Each item needed for the Kanban is ready just in time (JIT). This enables minimal build up of inventory. In a lean system, the goal is to reduce waste. The build up of inventory is the worst form of waste according to Taiichi Ohno.

The principles of the Toyota Production system were emulated in lean software development when Kent Beck created XP (Extreme Programming). The goal was to use the JIT principles and limit work in progress to the teams capacity. Beck also implemented a test driven development (TDD) process that improved quality. XP can be considered a different Agile framework from Scrum and Kanban. In my view, XP has more of relation to Kanban, since Beck based most of the practice off of Ohno’s Kanban method.

Unlike Scrum, Kanban is usually not the framework of choice for software delivery projects. Projects have a clear beginning and end, as well as a defined scope. Kanban works well for support teams, where work will be ongoing.

Teams will use a Kanban board, like the board a Scrum team would use for their Sprint. There are no Sprints in Kanban, the work is a continuous flow. There are also no defined roles in Kanban, like there is in Scrum. Cycle time is the key metric used and unlike the Sprints in Scrum, in Kanban change can happen at anytime.

Some of the benefits of Kanban include flexibility in planning, increased throughput, fewer bottlenecks and visual metrics. Kanban also compliments continuous delivery.

Below is a grid that Dan Radigan from Atlasssian put together, which displays the differences between Kanban and Scrum.

                                          Scrum                                                             Kanban

Cadence Regular fixed length sprints (ie, 2 weeks) Continuous flow
Release methodology At the end of each sprint if approved by the product owner Continuous delivery or at the team’s discretion
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach.
Key metrics Velocity Cycle time
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time

Summary

Scrum and Kanban are two different Agile frameworks, but both have many benefits. In my view, Kanban is more aligned with lean development than Scrum. The area where Scrum gets into trouble with lean is the idea of having a team create and work on a large backlog. Lean experts, like Mary Poppendieck, cringe when they hear the word backlog. This is because it goes against the principles of JIT and low inventory. At Toyota, I’m sure the plant manager would freak if they had a large backlog of orders piling up. They want to have low inventory and good throughput. While Kanban works great for a repeatable process, my view is that Scrum is the best framework for complex software delivery projects.

If you enjoyed this post, check out The Top 10 Influencers of Agile.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

Powered by WordPress & Theme by Anders Norén