Or, the Not So Immediately Apparent Connection Between Agile Development (Scrum) and the Manufacturing Quality Revolution of the Latter Half of the 20th Century…and, Why We Should Care.
(How about that for a title!)
Here’s a shorter one: How QQ Solutions Develops Quality Software — Fast!
In my blog post today, I thought I’d take a departure from talking about insurance marketing and technology, and instead, take a little excursion to write about how we develop and continuously improve leadership software products, like QQ Catalyst.
For QQ, generating customer delight — by delivering great products and excellent value and by continuously improving quality — is key to our growth and success. But what is “quality”? People will generally interpret quality in different ways. But, let’s define it here as the perception of the degree to which a product or service meets customer expectations.
A few years back, I was dusting off my collection of business books, and came across the classic, “Kaizen: The Key to Japan’s Competitive Success”, by Masaaki Imai. Kaizen literally means good (kai) change (zen), and now usually translates as continuous improvement. After a really good dusting off, I re-read it. In revisiting the book, I discovered that there is a real and meaningful connection between Kaizen, as applied to “lean manufacturing” practiced by the best manufacturers (e.g., Toyota, Sony, IBM, Apple, Flextronics, Honda, HP, Nokia, Cisco, Canon, Ford, to name a few) and “lean” software development with Agile, as practiced by QQ.
Now, this is really important: “lean” considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. The “lean” concept has general application to continuous improvement, as we’ll see.
One of the tools that Kaizen teaches, and is widely utilized in lean manufacturing, is known as Kanban. Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a “pull” production system, invented and developed as part of the Toyota Production System (TPS). Kanban’s aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. “Pull” means that the downstream workers withdraw or pull the parts they need from their upstream processes. Kanban has all information on what to do and makes production autonomous in a non-centralized manner and without micro-management. Basically, it breaks up work into manageable bits, exposing causes of variation and defects and therefore provides candidates for Kaizen (i.e., continuous improvement). Kanban cards look like this example from Toyota:
Toyota Kanban board
If you’ve ever visited our headquarters in Deerfield Beach, this board may look a little familiar. We have a room with several planning boards with lots of little Post-it notes all over them, each of which represents a “customer story”, or detailed feature/requirement. An Agile software development planning board (or “Scrum” board, in this case) can look like the one in this example:
Kanban board used in Agile software development, specifically SCRUM
When I discovered this, I immediately realized that the two boards were essentially identical! I was intrigued. So, I did some research into the possible relationships between Kaizen, Kanban, lean manufacturing and Agile. As it turns there a strong relationship indeed! In fact, Agile was originally based in no small part on Kaizen theory and Kanban! And, for many of the same reasons that Kanban is deployed in “lean” manufacturing: it provides for “lean” software development — faster, less waste, reduced costs, improved visibility, adaptability and better quality. In fact, the planning boards used in Agile development are sometimes referred to as “Kanban Boards”.
More About Agile
In 2001, a consortium of 17 software development leaders, who were already using methods that differed from the traditional all-in-one, heavy up-front design, or “waterfall” model, met at the Snowbird ski resort in Utah, formed the Agile Alliance and composed the “Agile Manifesto”. I’m going to list the 12 points of the Agile Manifesto, as its principles are so applicable to our commitment to continuous improvement:
The Agile Manifesto (with my commentary)
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Let’s not forget that the goal of software development should be the development of software. Not everything in the product requirements needs to be completely defined up front before we start building software. An incremental, continuous approach to development seems to work much better and is more responsive to customer needs.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Whether we like it or not, requirements will change throughout a development project. Traditional “waterfall” software development adds processes designed to prevent/reduce scope creep; but when you think about it, these are often really change prevention processes, not change management processes. Agile developers embrace change and instead follow an Agile change management approach, which treats requirements as a prioritized stack (a.k.a., “product backlog”) that is allowed to change over the life of the project.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequent delivery of working software provides all stakeholders with the opportunity for feedback and to provide improved direction for the development team, by making the current status of the project transparent. We’ve found this to work brilliantly with our new QQ Catalyst agency management system.
4. Business people and developers must work together daily throughout the project. A project could be in serious trouble without regular access to its stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation (e.g., Sprint demos, User’s Group meetings, etc.), and adopt inclusive tools and techniques, which enable stakeholders to be actively involved.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. It’s best to build teams from people who are willing to work together collaboratively and learn from one another. They have the humility to respect one another and realize that people are a primary success factor in software development.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For a software development team to succeed, its members must communicate and collaborate intensively and effectively. There are many ways, in which people can communicate together, such as face-to-face communication at a shared planning board (e.g., our Scrum Room) and “daily Scrums”.
7. Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software that meets the changing needs of customers, rather than just the delivery of documentation or the holding of meetings.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Steady, intensive development rhythm is most sustainable.
9. Continuous attention to technical excellence and good design enhances agility. It’s much easier to understand, maintain, and evolve high-quality code than it is to work with low-quality code. Therefore, Agile developers know that they need to start with good code, maintain it, and take a test-driven approach so that they know at all times that their software works (SQA). Agile developers also adopt and follow development guidelines, in particular coding guidelines.
10. Simplicity–the art of maximizing the amount of work not done–is essential. Agile developers focus on high-value activities, and strive to maximize stakeholder’s return on investment, and either cut out or automate the drudgework. In other words, lean development!
11. The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the Agile movement and can produce the most innovative, high-value results. It works for us!
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This is essence of Kaizen!
Underlying the Agile Manifesto is the idea that it is too difficult (some would say impossible) to accurately define up-front all customer requirements and associated software design for a software product when its complexity goes beyond the basic levels. This difficulty can lead to a variety of problems including delays in product releases, decrease in software quality, and an inability to respond to changing requirements. To remedy this, Agile principles prescribe, among other things, an iterative approach to building software, one small increment (i.e., Sprint) at a time and recommend the assessment of the work done in each cycle in order to improve the process and better meet customer expectations.
Agile (i.e., the Scrum version of Agile in our case) involves breaking up product requirements into individual user stories, which are collectively referred to as the “product backlog”. Those little pieces of paper on our Scrum boards each represent a user story. One or more user stories are worked on in relatively short “sprints” providing opportunities to better identify problems and areas of improvement and thereby facilitate Kaizen—continuous improvement.
Connections
Just like Kanban in manufacturing, the Scrum planning board keeps a simple view of what needs to get done in front of the whole team. The user stories and sprints in Agile/Scrum are analogous to the parts and work-in-process in manufacturing. Teams are less apt to have too many in-progress tasks open, as it becomes quickly apparent when this happens. This helps reduce errors and improves quality.
We can, therefore, think of developing and testing software in incremental sprints as being just like Kanban in lean manufacturing. Both help to reduce time and waste, achieve higher quality and to deliver products that meet customer expectations. And, just as Kanban and lean manufacturing facilitate Kaizen, our adoption of Agile is allowing us to build quality into our products and to really practice continuous improvement.
Wrap-Up
Agile, like Kaizen, is all about continuous improvement. It introduces to software development the same philosophy and analogous processes that drove the quality revolution in manufacturing. It provides a process for producing differentiated software products that will be accepted by mainstream buyers as meeting/exceeding their requirements and offering compelling value and quality. QQ Solutions practices Agile development, enabling us to rapidly deliver leadership products to the insurance agency community and respond to the needs of our customers.
