Tag Archives: Agile

The Power of Kanban

Posted on by

This is part of my ongoing series on Lean, Innovation, Lean Startup, Agile, and disruption.

Kanban is a tool in Lean which is used to help send messages downstream without needing to actually talk to each other. Which is powerful in a manufacturing setting as communication might be difficult depending on the environment. Kanban translate as card from Japanese and typically has information related to the number of items that need to be in a bin and what the item is that needs to be in a bin.

Example of a Kanban board on Trello

Example of a Kanban board on Trello

Some Agile practitioners have adopted Kanban to be a set of steps in the process for developing software. This could be as simple as Ideas, To Do, Doing, Completed, or as complicated as Backlog, Wireframe, Coding, QA, Testing, Integration, Complete. Ideally, simpler is better, because more bins make management of the lists much more complicated than if there are that many phases in the Kanban board, but this is really up to the preference of the team and whatever works best based on the Build measure Learn approach.

Even developing a Kanban system for software development the team should view it as another possible to learn how to work with each other better. This includes the information that’s required for a piece of work to be started. For example, determining what information is the minimum for a User Story is something that must be agreed upon by the team. Furthermore, the Acceptance Criteria can help reduce the number of steps on the Kanban board as these may simply be part of the acceptance criteria for a complete story.

Using stories and Kanban board can help with Innovation through creating bite size pieces of work that can be designed to reduce the environment of uncertainty the product is being developed in. Since uncertainty is the greatest risk to the project it is vital to write user stories and use the kanban board to maximize efficiencies with developing a new product.

The Kanban board is also extremely effective for ensuring that startups keep their energy focused on the most important thing. No work should be done on an item if the work is not on the Kanban board. If the work is vital to the startup, then it needs to be recorded and validated that it’s the right thing to be doing. Yes, it might slow things now, but the Kanban board is an effective tool to help people understand who is working on what and how those interact with other problems out there. This doesn’t meant that immediate issues shouldn’t be resolved immediately, but for development purposes no new work should be done without having an item on the Kanban board.

Agile and the Lean Startup

Posted on by

This is part of my ongoing series devoted to understanding the connection between Disruption Theory, Lean Startup, Lean product development, and Agile software development.

The Lean Startup is most likely the best example of how to translate Lean into software development directly. This set of management tools uses nearly all the Lean tools identified in the famous texts of Lean, such as Toyota Way, Lean Thinking, and Toyota Production System. In fact there are so many similarities between the two people have accused the author of basically writing a book about Lean and not adding anything to the topic. I, personally, don’t agree with this as the portions about pivoting is definitely not part of the Lean framework and is novel capability he introduced.

Furthermore, he’s had to translate a great deal of the language from manufacturing or office settings into a development setting. While there are similarities there are differences between a piece of finished goods and a completed piece of code. This difference is that the code can be pushed to “production” servers and active for users, while the finished good has to be purchased by a customer, which still may take weeks to occur (if the production system is linked to purchase orders and directly to customers). To that end Reis pushed to make as many changes to production as quickly as possible – not without testing of course, but as soon as testing was completed the change went live. This is an extreme case of single piece flow. One change goes through testing and pushed live.

Pushing in the “Continuous Deployment” model of course causes a lot of issues if you don’t have robust testing. You need the testing to be fast but comprehensive. It’s impossible to do this from the beginning so over time the team has to develop more and more sophisticated tests based on how the team breaks the existing piece of software as they deploy changes. This is where Root Cause analysis plays a key role. Do a 5 Why’s analysis (ask why 5 times until you come to an underlying root cause) fix that problem so it never happens again. In the case where you cannot prevent the issue then you need to be automatically testing for the issue to fix it before you publish the change.

Agile has similar concepts in that they there are short cycles of development called “sprints” these sprints can last anywhere from a week to a month. At the end of each sprint the goal is to have a series of features that are deploy-able (including testing) that a customer would be willing to pay for. These pieces of work are broken down into something called a “minimum viable feature” which is smaller than a product but not so small that it wouldn’t completely work. For example, an MVF of WordPress would be the “publish button” initially it would need to convert all the text in the text editor and turn everything into a viewable website and create the URL associated with that article. Over time new features can be added like the auto-tweeting capability that exist now.

One common theme between both approaches is the concept of minimum viable product, which is a set of features that makes up the product. The difference between the two approaches in developing the MVP is that the Product owner does this in Agile, while the MVP is determined through a great deal of customer interaction in Lean Startup (Ideally the Product Owner is doing a similar activity for the customer but typically acts as a proxy).

There hasn’t been a lot of authors that have looked into combining these two approaches. There are a lot of similarities as they both emerged from the Lean philosophy, which means they should be fairly easy to combine into a larger framework. The only book I’m aware of that has even attempted to tackle this is the “Lean Mindset” by Tom and Mary Poppendieck. Even in this book though, they have decided to go with a 4 step approach that has more phases than what the Lean Startup recommends. They propose the stage gate to help determine minimum levels of details. I believe that this is because of the typical levels of bureaucracies in organizations, where a Project Management Organization will require adhering to some sort of phased gate approach. The Lean Startup uses Pivots as a way to manage projects that are failing, but not with the same level of rigor or structure as the approach the Poppendiek’s recommend. Instead, the Lean Startup approach recommends setting goals and targets for metrics (non-vanity like number of views) determining when to pivot. The timeline has to be long enough to get a clear view of what your customers actually want.

Adoption of Agile compared to Lean

Posted on by

This is part of my ongoing series devoted to understanding the connection between Disruption Theory, Lean Startup, Lean product development, and Agile software development.

In many organizations the adoption of Agile software development techniques have been adopted rather quickly. For those unfamiliar with Agile software development, the point is to focus on user experience through developing software that is created through user stories (there’s a lot more to it obviously). Agile grew out of an understanding of Lean practices, where there is a strong focus on learning, daily standups, and understanding where and why things went wrong. This includes the use of the 5Whys which was highlighted in the Lean Startup. In away the company becomes a learning organization as there is a set meeting every sprint to reflect on the last few weeks of work. Agile was initially conceived around the turn of the century and has seen steady adoption over the past 15 or so years.

Many of these ideas came from Lean. While retrospective isn’t specifically called out in Lean, it happens consistently through a Plan Do Check Act cycle. Furthermore it happens through Root Cause analysis which happens on nearly a daily basis whenever issues arise. Much of the most ardent Lean practitioners are found in manufacturing, however it is making headway in other areas of the organization over time. Lean was Popularized in the early 90’s by the book “The Machine that Changed the World” but is much older than that and had been adopted by Toyota competitors as early as the 70’s.

So, then why, when Lean is the inspiration for Agile (as well as the Lean Startup), has Agile been heavily adopted while Lean has not? I do not mean to say that Lean isn’t used; it’s used a lot of places. However, it’s not used in the bulk of companies around the world or used uniformly throughout an organization. Agile has been adopted as a methodology across many industries and within many different types of companies. It is also not possible to say that one works while the other doesn’t. Both have been shown to improve processes and drive cultural change within an organization. I think that Agile has been more quickly adopted in broader corporate America than Lean because, similarly to Lean, it was made by and for the people that use it the most; Corporate IT. IT/Software development has owned the deployment of Agile practices which has made them much more successful at adopting them than those same corporations adopting Lean practices.

Agile has had the luxury of being successful in many organizations in a very public manner. Which has lead to a lot of top down support and required adoption of the methodology. This makes adopting specific methods for project management significantly easier for adoption of any given methodology. In fact, Lean and Six Sigma deployments are only successful whenever those deployments are attached to specific strategic initiatives. With IT any project that is funded for development is by definition strategic resulting in clear alignment between the Agile deployment and the execution of the project. Lean typically does not have this luxury.

Furthermore, Lean is not well regarded in many leadership circles as it is not typically taught in high level MBA courses. Agile on the other hand has made it into Masters programs for both IT and Computer Science. Meaning that the leaders responsible for owning processes and project results learned about how to deploy Agile in their education and it was a highly stressed practice. On the other hand Lean is part of Industrial/Manufacturing Engineering and to specific business niches. Which means that there’s a clear misunderstanding of Lean and the management practices that accompany the tools.

Coming to Agile from the Lean perspective, I believe that Lean practitioners have a lot to learn from the Agile community around adoption. Much of the actual practices are extremely similar and anyone with a strong Lean background will be able to transition into an Agile environment easily. The transition the other direction will be only slightly harder, mostly because of the broader range of performance metrics associated with Lean compared to a handful with Agile.

What should a manager manage?

Posted on by

Managers should not be managers of people, they must manage processes. Managers should be leaders of people not managers of people. Managing people by watching them closely is not typically a very effective method to ensure that work is completed. Micromanagement breeds mistrust between employee and manager. Through managing the quality of the processes the manager is able to increase the likelihood of success of their people.

All work is a process. Even if there doesn’t appear to be a process if the work is to be fully completed there are a series of steps that must be completed. It doesn’t have to be a good process, a repeatable process, or particularly effective but if the work is completed it followed a process. Furthermore, if more multiple people do the same type of work without a clearly defined process it’s likely that there will inconsistent results to their work. A manager owns the overall output of all the work of their employees. If the work is consistently subpar or employees have a difficult time picking up the way to do the work that is expected of them, this is the responsibility of the manager to address. It doesn’t matter how amazing the employees are, they could have been consistently excelling in a previous, if the processes are terrible those employees will not succeed.

Not every type of work can effectively be managed through traditional software. For example, software and technology development in both these are “knowledge” activities that unlikely would benefit from a highly structured process. In these cases there are two things that help manage the process. First creating a regular process of checking in, managing what work the developers should be doing, and working to eliminate roadblocks – in software this is Agile software development. Second you create a standard process to feed in consistent data into the truly creative process and consistent outputs so that the consumers of the work are able to use the output of the creative process effectively in their work.

To manage the processes managers need to equip their employees and themselves with tools to do root cause analysis, conduct structured problem solving, and rigorous process improvement. Managers need to take ownership of the end to end process, the data their employees use to complete their work, and the quality of the results. It is important that this becomes the norm as it will switch blame from people, who generally want to do the right thing, to the process and how work is completed.

This is not to say that whenever people deviate from the agreed upon process that the manager shouldn’t address that or if people still fail to meet expectations while working in the process that they can’t be fired. However, leading employees to identify broken processes, supporting them in fixing them, and providing tools to do so becomes the role of the manager rather than micromanaging their employees.

Businesses and Silver Bullets

Posted on by

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.