Category Archives: Agile
A common concept discussed with lean is setting up work in a value stream and not functional silos. This means getting people from cross functional areas to sit and work together in a work cell. An example would be someone from customer service, credit check and order writing all sitting together to make the work of order taking flow.
This allows for the handoffs to occur immediately and increased communication between the functions resulting in reduced lead time and better quality of work.
Agile is a great example of putting the work cell concept into action.
An agile software development team brings the business partner, software developers, data managers and quality assurance together in one room. This allows for quick turnaround discussions when someone is stuck getting to a resolution quicker and moving the development along.
There are many other aspects to agile but the work cell is a instrumental component to allowing many of the other concepts and tools to work so well for an agile team.
Work cells are not just for the manufacturing floor. They are applicable anywhere you need to bring cross functional teams together in order to drive a quicker more efficient process.
Lean thinking is about creating flexibility in the manufacturing process in order to deliver the value that customer wants at that time.
In agile, this is also true. The beauty of using agile to develop software is the work can be prioritized on a daily or even more frequent basis. As the development team completes a requirement and it moves to the “complete” pile, the product owner can determine which of the remaining requirements is the most important to complete next. The product owner is closely linked with the customer of the software so they are the voice speaking directly for the customer.
If new requirements come up during development, no problem. Add that requirement to the back log on the kanban board. The next time it is time to pull a new requirement the product owner can prioritize the new story at the top or not.
This creates a lot of flexibility in the development process that a waterfall process does not. Usually, with a waterfall development process all the requirements have to be determined up front and then frozen because adding any after that can cause issues. Then the customer doesn’t see anything until the development is completely done. The agile process allows to release pieces of functionality as it is ready.
This increased flexibility allows the team to deliver more value sooner to the customer, creating a happy customer. Which is what lean is about. Customer first.
In an earlier post I mentioned the similarities in agile and lean from a problem solving perspective. Lean and agile are also the same when it comes to the learning cycle.
One of the principles of lean that I have learned is Create a Learning Organization through Learn-Apply-Reflect. This principle helps drive home the importance of reflection. Many people and organizations do a great job of learning something new and then trying to apply it. Where most people and organizations fail is forgetting to reflect. The reflection step is where all the learning and applying comes together to understand how what was learned can best be applied in the organization. What worked? What didn’t work? What should be kept? What should be changed?
A sign an organization is doing this well, is the reflection is planned and not a reaction because something went wrong. The reflection is part of the project plan and will is scheduled upfront with no agenda but to learn and improve.
Agile has a methodology and a term it uses for this reflection and learning. It is retrospectives.
Agile uses planned retrospectives, usually once a week, to take a time out and gather the team to understand what is working and they should continue doing. As well as what is not working and should be changed or thrown out. It takes a monumental act to cancel a retrospective. These retrospectives are ingrained in the methodology and help the agile teams continue to improve on their process and work.
This is a great of example of Lean-Apply-Reflect. The agile team takes the learnings from the week, apply them and then have a planned reflection time a week later. The agile methodology does a great job of fostering the principle of creating a learning organization.
Do you have any examples of planned reflection in your organization?
I have been learning about agile as of late. I know how agile has gotten its roots from lean thinking as it is applied to software development. It has been very interesting and fascinating to learn.
One common thread problem solving and agile have is making it important to break down the issue.
Good problem solving breaks down a large problem into smaller and very manageable problems to solve.
Agile does the same. It is important to break an epic story (or very large story) down into manageable stories that can be built and tested in 2-3 days.
This is just one similarity between lean and agile I saw as I was in my class. Seems simple but it really takes team to master to bet able to break stories and problems down to the appropriate sizes.