In this paper we will describe the use, in a real context, of Kanban and Scrum agile methodologies combined with some practices of Extreme Programming. In the scenery of the agile methodologies, Scrum has certainly gained a position of clear dominance in terms of adoption and obtained successes. This remarkable result is undoubtedly due to its peculiarities to know how to answer to the agile’s values and principles in a revolutionary way, and of fostering a very pragmatic approach.
Moreover, its characteristic of not being prescriptive with regard to technological aspects, allows a Scrum team to integrate eXtreme Programming practices to agile skills with a great success through their gradual introduction.

As also shown and described in my article “Lean Agile Adoption – an Enterprise war story” Scrum can scale to enterprise-level and can be used to guide the transformation process itself of a company into an agile one.

Our real-world experience, based on principles of continuous experimentation and adaptation, soon led us to devise and use a form of merging Scrum with Lean methodologies, and in particular with Kanban. The purpose of this short paper is therefore to share the direct practical experience of teams led by me, in order to help others in their process of adopting agile methodologies.

I used the Scrum methodology since 2002. For years I had the opportunity to adopt this powerful process tool for the realization of important agile projects (like the website and the CMS system of RAI) in a context that I can describe as “Scrum Orthodox“. Of course we used to add extreme programming practices, such as Test Driven Development and continuous integration, as real differentiators and catalysts of the quality and delivery’s speed of products.

Later, when I started driving the transformation of entire agile companies, context’s needs led me to successfully integrate the Scrum methodology with aspects of Lean Software Development [4] [5]. So, after years of experience I believe that this type of process fusion is an extremely interesting way for the adoption and practice of agile methodologies.

For the sake of clarity, I give a brief description of Scrum in terms of its philosophy and historical principles. Jeff Sutherland created the Scrum process in 1993. He borrowed the term “scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review.
In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams. Ken Schwaber formalized the process for the worldwide software industry in the first published paper on Scrum at OOPSLA 1995. Since then, Scrum has become one of the leading agile development methodologies, used globally by fortune 500 companies.

Scrum is one the simplest Agile, iterative and incremental framework for projects and product or application development. It structures development in cycles of work called Sprints. The Sprints are timeboxed – they end on a specific date whether the work has been completed or not, and are never extended.

In a Sprint, the Team takes work from a prioritized list of items called a Backlog. The items developed first are of highest value to the customer. It’s very important to consider that Scrum is not only a concrete set of practices – rather, and more importantly, it is a framework that provides transparency, and a mechanism that allows “inspect and adapt”. Scrum works by making visible the dysfunction and impediments that are impacting the Product Owner and the Team’s effectiveness, so that they can be addressed. Scrum does not solve the problems of development; it makes them painfully visible, and provides a framework for people to explore ways to resolve problems in short cycles and with small improvement experiments.

Once a Scrum Team is comfortable with their progress and agile mindset, it is customary and encouraged to improve, adapt and change their particular practices as needed. Only the Scrum Basics need to remain unchanged: three roles, three activities, and three artifacts.

Although the concept of Kanban has been around for years, it’s use for agile software development is relatively new compared to Scrum. Kanban is a simple yet effective control system that can be easily introduced and adopted in various production environments; it is a concept related to Lean and Just-In-Time (JIT) production.

Coined from the Japanese word kan which means “card”, and ban which means “signal”, kanban is simply described as a system for “pull” production control. When we talk of “pull”, it is more of a control measure to release materials into production “only when they are needed.”. Moreover, we should define Kanban as more than a signal, but rather a signaling methodology that is a key component of Lean.

Scaricate le slide della presentazione Scrumban – a methodology fusion.