Hello, I’m Veronica
The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.
-
Lean Presentations
As I prepare today to create a training course that I will be presenting on how to demonstrate ROI on BPM projects, I found Tom Perry’s post timely. In it, he applies lean concepts to creating presentations. Among his suggestions:
- Splitting large things up into small batches for focus
- Applying the “5 Whys” to drill down to the important details requiring the attention of the audience.
- Applying 5S: Shine, Sort, Standardize, Systematize, Sustain (go read his explanations.)
Thanks Tom. Now off to my presentation.
-
Amazing Adventures of Kanban
OK, I couldn’t stop laughing at Jon Miller’s post taking a creative look at the 60 year history of Kanban. It is as instructive as it is funny. To get a flavor, here’s an excerpt:
Kanban Gains Superpowers
Pokayoke has the power to prevent mistakes. Jiodka frees people to run machines intelligently, rather than be run by them. Heijunka has the power to take choppy demand and smooth it out. Kaizen has the power to make infinite small improvements. All of these players and their many friends bring order and harmony to a production system. Yet one stands above them all: kanban.
Kanban was endowed with three major powers. First is the the power to instruct the production of goods. Within the Toyota Production System and its imitators, only kanban has the power to cause things to be made. Second is the power to instruct the movement of goods. Like its first power, kanban can cause things to be moved. Third and perhaps most important, kanban can motivate people towards continuous improvement by reducing its own size. Within a kanban system, the less kanban there is, the more improvement is accomplished. Like a true hero, the power of kanban increases as it diminishes its own presence. Amazing.
-
Ten Practices for Applying Lean Agile to Other Knowledge Work
Dean Leffingwell has a great post up with the above title. His approach and conclusions fit well with my Laws of Agile. Here’s a summary from Dean’s great work which is very practical:
He offers that by replacing the word ‘software’ with ‘solutions’ in founding agile principle statements, they can apply broadly to other knowledge work like: training development, IT infrastructure administration, marketing communications, HR management, and strategy.
He also recaps lean concepts from manufacturing that apply more broadly such as:
- focus on value,
- reduce work in progress,
- reduce cycle time,
- build in quality,
- cell based work, and
- continuous improvement.
He then suggests the following ten practices for broad knowledge work application:
# 1 – Develop and empower, self-organizing, self-managing teams. Energize with vision, mission and time pressures. Provide requisite creative chaos, care and support.
# 2 – Plan work in short (one or two week) iterations. Teams plan together and commit to value delivery objectives in these increments.
# 3 – Focus on value delivery. Apply user story form (“as a <user role>, I can <do something> so that I can <business value>) to help assure value delivery.
# 4 – Develop, single prioritized backlog of work for the team. Establish product owner (or product owner team equivalent) roles to manage and prioritize backlog.
# 5 – Apply, daily 15 minute standup meeting as a primary form of communication and commitment. (What I did yesterday. What I’m doing today. Whether I am blocked or not.)
#6 – Minimize work in process to increase productivity. Develop work in process limits to task and stories. Minimize multiplexing within time boxes.
#7 – Plan for delivery of larger enterprise initiatives in larger (release) time boxes. Engage stakeholder in periodically (approximately quarterly) planning, visioning and commitment setting. Make vision, objectives and commitments visible and public.
# 8 – Provide total, real time visibility. Build big visible chart to show work in process and individual and team responsibilities. Speak directly to facts and issues. Publish iteration and release objectives.
#9 – Develop shared knowledge. Institutionalize knowledge by pairing on tasks, projects and stories. Avoid over-specialization so work force can flex to backlog and resource bottlenecks.
#10 – Apply work physics and agile planning. Estimate and track time completion by story and task. Establish and apply team velocity (capacity of work achievable in a time box).
I’ll briefly comment on this list:
The most obvious thing I think he has overlooked as a practice is applying continuous improvement and reducing variability. Scrum uses the retrospective which could easily be added as a broad practice perhaps to #7.
He combines two concepts in #6, limiting work in process and reducing variability of job functions or multiplexing. Addressing each of these head on might uncover additional value.
I also believe the use of Kanban for #6 as a method for accomplishing the work in process reduction, a lean tool, is overlooked and should be considered for more multi-disciplined work. Instead he suggests a more agile approach of iterations in #2 with story point limits through a backlog and PO in #4 to limit work and time boxing in #10. Kanban would add an alternative approach.
-
Invest in Growth, Savings or Risk Reduction?
ABPMP Denver put on a great panel discussion on Tuesday evening on the topic of the state of project work in the current economy. First thanks to the great panelists for sharing a collective generation of great insight: Bill Gilbert, EVP and COO, Statera; Donald Davidoff, Group VP Strategic Systems, Archstone; and David Neitz, VP Solutions and Innovation, Fiserv Investment Support Services.
I’ve been ruminating on a lot of the topics covered, but the one I keep coming back to is the answers to the question ‘what are companies investing in in today’s economy.’ The answer from the panel was basically, ‘It’s all about risk mitigation in 2009.’ While I get that, it seems like conventional wisdom perhaps goes against best wisdom in this case.
Conventional wisdom states that:
- In good time, companies invest in growth
- In bad times, companies invest in savings
- In really bad times, companies invest in risk reduction
I suggest this should be turned around:
In good times, irrational exuberance suggests that companies might spend more time and effort looking for their blind spots and focus on reducing any risks that could displace what is working today or could work against them when tides turn. Especially the recent history of Enron and Leman Brothers has shown that blindly chasing the greatest new ideas can be catastrophic.
In really bad times, companies have the luxury to investigate new opportunities more rationally. They can take their time in developing, and perfecting new offerings, and take advantage of lower costs and more resource availability to grow. There is a lot of recent buzz about great companies founded in recessions.
In all times, companies should be able to use well justified business cases to invest in savings and continuous improvement of current business processes.
-
Lean, Agile – Kanban, Scrum
David Anderson at Agile Management has two new blog posts that got me thinking. The first is How to Start with Kanban which lays out how to implement Kanban for software development in 10 easy steps (I like its simplicity.) The second is Blogosphere Buzz about Lean & Kanban which is a comprehensive review of blog articles coming out of the Florida Lean & Kanban conference. All this Lean Kanban talk got me thinking about what really is the difference between all these terms. My conclusion in summary is: Lean and Agile are concepts that allow for more flexible, lower cost development or production – Kanban and Scrum are two approaches for implementing these concepts for software development.
My Laws of Development try to show how Lean (and Six Sigma) are the foundation for Agile and are adopted from the first book I studied on lean and applied in my early consulting days, Factory Physics, Foundations of Manufacturing. When first introduced to Lean as a software development concept more broad than Scrum through Mary and Tom Poppendieck’s book and an Allan Shalloway conference, my reaction was something like: yes, but both use the same concepts at different organizational levels. The fact that lean concepts extend into the scrum cycle by ensuring that there is a limited amount of focused work at the development team level is often overlooked. My reaction to Kanban has been similar over the past couple years as it has gained popularity. While Scrum and XP use story points or ideal man days to limit WIP, Kanban borrows a more direct tool from lean manufacturing to accomplish the same objective through the Kanban (simply meaning ‘card’ in Japanese) itself.
Agile and Scrum, while while they can be more broadly applied, have grown primarily as a result of lean (originally manufacturing) concepts being used to improve software development. Kanban will always be more broad than software development; though, there appears to be movement to capture the term specifically for software development.
I guess, I still go back to the founding principles of lean. If we understand the principles, it allows for adoption to specific needs across a wide spectrum of verticals and organizational levels without taking sides on the latest terms and tools to emerge from applying them.
About Me
The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.
Follow Me On
Subscribe To My Newsletter
Subscribe for new travel stories and exclusive content.
Horizon Line Group 