ALM Adoption Success Story – Success Factor 2 – Visualize Your Work
Humans love pictures.
We have numerous sayings in our cultures about how powerful visualizations are.
“A picture is worth a thousand words“
“The drawing shows me at one glance what might be spread over ten pages in a book.”
“Every picture tells a story.”
One that the challenges with knowledge work is that for the most part, most of our work is invisible until it’s done. Only Neo can see bits and bytes which leaves the rest of us a little in the dark. If you’re building a building, or digging a hole in the ground, progress is obvious! For invisible work, progress is very difficult to monitor.
So we track work in some software system, but then we hide all of our knowledge in text and numbers! Our love of spreadsheets is epic in proportion. Status reports! MS Project files! All of this data!! For all intents and purposes, our work is still invisible! We often mistake this data for knowledge and understanding and the true insights are left hidden in the numbers.
On our project, we knew it would be very important to understand at a glance where we were in our workflow. We were doing something very novel for this organization and in order to mitigate the risk of heading too far in the wrong direction (which could be any direction at this point), we needed knowledge. We needed to quickly identify roadblocks to progress, which often included self-inflicted delays. We needed to engage with our sponsor in a meaningful manner.
So we started drawing pictures!
The most important “picture” that we have used has been our storyboard. This board is very important to us. It is a muster point for our daily stand-up meetings. It is a place on which to hang “adornments” that help us quickly assess our current state. It is a tool that promotes conversations. And it is always there, silently reminding us to be disciplined with efforts to visualize our work.
Our storyboard looks like pretty much like any other Agile teams storyboard in form, but this one is a unique work of art. Well, unique in that it is exactly what we need it to be at the moment. It represents our workflow. We have our WIP limits on it. And because we are fairly disciplined in maintaining the current state of all our work, it’s always up to date.
We also visualize our tasks and review these daily as well. TeamPulse has a story board as well as a task board for more granular visualizations.
We don’t have WIP limits enabled on the tasks boards, but again, the intent is to see work flowing through the system. And with an explicit policy that tasks should have a cycle time of 1 day, any time an item is discussed at 2 stand-up meetings, the team knows that the work isn’t progressing as expected and some sort of investigation and corrective action may need to take place.
Finally, we use TeamPulse dashboards to visualize our progress over the course of an iteration.
Everyday, we review the storyboards and the tasks boards during our stand-up, and then we review the dashboards to bring the entire conversation back to our progress versus our (the team’s) expectations for the iteration. These dashboards provide that high-level perspective that ties everything back together.
And all of this information is available on the web, to everyone on the project team, including the sponsor. There is no need to interpret numbers. There isn’t a report that needs to be compiled. And the information we want to present is immediately available in a very easy to consume and impactful format because a picture is worth a thousand words!
Going back to the first ALM Adoption Success Factor of Transparency, having something to be transparent with has been a key enabler of success for our team as we strive to deliver this project and continuously improve and get better as we do it.
Series List
- Success Factor 1 – Transparency
- Success Factor 2 – Visualize Your Work
- Coming soon – Success Factor 3 – Co-location
- Coming soon – Success Factor 4 – Invest In Your Tools
- Coming soon – Success Factor 5 – Retrospectives
Little’s Law – It’s not about the numbers
I was recently at the Kanban Leadership Retreat in San Diego, hanging out with a bunch of great people from the community and talking all about Kanban for three days.
This is an un-conference format event so we end up talking about whatever the group is interested in talking about, and one of the best sessions that we had (amongst a group of great sessions) was a session on Little’s Law that was hosted by Dan Vacanti (@danvacanti). Dan has been talking about Little’s Law at conferences for the last few months and the group was really interested in hearing this presentation as well as the interactive questions and answer that would happen throughout. It was during the interactive part of the session that “it” finally clicked for me!
Up until now, I didn’t understand why I would need to use Little’s law. I don’t want to use this blog post to describe Little’s Law and besides, Daniel’s presentation does an excellent job of that.
I’m really dumbing this down but in short (Sorry Dan), Little’s Law provides two things of interest for us Kanban practitioners:
1. allows us to derive one of three important Kanban metrics when any two of them are available to use in the calculation
2. allows us to understand/predict the impact of changes on one of those values to the other two
On the first point, for people running their work in kanban systems, normally all of the values are available if you’re managing your work well enough. Approx. Avg. Lead-time, Avg. Work In Progress, Avg. Throughput are relatively easily tracked or counted, and they can all be seen in a Cumulative Flow Diagram. Given I can observe all three in our system; I don’t need Little’s Law to help with that.
Note* – For planning purposes, we can use this relationship to understand what numbers
we might need in the future. Eg. Calculating required WIP based on an anticipated throughput and a proven capability (lead time) to establish resourcing levels
The second point is really interesting to us but is also where we stumble upon the gotcha and the false knowledge that often occurs on teams when they are using Little’s Law. It was in the interactive session that I finally had my epiphany around this second point! It isn’t (usually) about calculating the missing number or predicting changes in the numbers. It is about ensuring that you CAN use Little’s Law at all!! That’s the tricky part and in my opinion, the really powerful thing I learned at KLRUS.
See, in order to use Little’s Law and have it work as you’d expect, there are a number of really important assumptions that have to be true before you can use Little’s Law and it is in making these assumptions true in our kanban systems that we achieve the true benefit!
The assumptions are (for the period of time that is under observation):
- All measurement units are consistent
- Conservation of Flow which assumes
- Average Arrival Rate == Average Departure Rate
- All work that enters the system flows through to completion and exits
- System is “stable”
- The average age of WIP is neither increasing or decreasing
- The total amount of WIP is roughly the same at the beginning and at the end
All Measurement Units are Consistent
This one is relatively easy. If you’re measuring in weeks for Throughput, your Lead time should be in weeks. If your WIP is a User Story, your throughput is in User Story. We can’t have WIP as User story and Throughput as Tasks. We can’t have Throughput as User Story/week and Lead Time as User Story/day.
Average Arrival Rate (AAR) == Average Departure Rate (ADR)
This one is a bit trickier, but not too bad. One of the assumptions required, as described by Dr. Little, is Conservation of Flow and this metric is one of the ways that we measure this in Kanban. And the tactic we use to manipulate this situation is our WIP limits. If we only accept new work into our system at the same rate that work leaves our system, we are stable enough for Little’s Law to work.
All Work That Enters the System Leaves the System
Work that enters our system and doesn’t exit in a predictable fashion will disrupt the Conservation of Flow. AAR and ADR can’t be equal if this happens frequently in the system. We do have to watch out for work being “created” within the system that could mask abnormal termination of work within the system.
Average Age of WIP is Constant
Little’s Law also requires a “Stable System”, which I’m not going to explore deeply in this article. One of the two metrics that we can use from our kanban system though to determine if our system is stable is the average age of WIP in the system. Over the period of time being observed, we want this average to be constant.
Total WIP at Beginning and End of Time Period are the Same
The second metric we use to determine system stability is WIP totals at the beginning and end of the time period under observation. If our WIP is trending up or down, we do not have a stable system and predictions that we get from Little’s Law will be suspect.
So what does this all mean…
So we have a law that we want to use, but in order to use it, we have to fulfill the required assumptions for the law to work. The required assumptions are going to cause us to create specific and explicit policies that will describe how our teams behave. The effects of these policies are varied, but you will see improvements in prioritization and pulling of work, queuing, swarming, workflow/system design, and WIP limits just to name a few in order to effectively strive to satisfy the assumptions.
In Conclusion
The power of Little’s Law to Kanban teams is not its ability to predict WIP, Thoughput or Leadtime. The true power lies in its ability to influence team behavior with its underlying assumptions.
When Little’s Law is properly understood by Kanban teams, it will encourage those teams to strive to satisfy the Law’s assumptions which will result in improved predictability and a kanban system that can be “tweaked” to achieve whatever goal is required at the time.
Kanban Has Changed The Way I Think (or Creating Business Value out of Creative Queue Uses)
Queues are all around us. Policies are everywhere.
Can we use the two together in a simple fashion to create business value?
Note* – Once you get really interested in Kanban, these are the kinds of observations and questions
that just randomly pop into your head, so beware. 😀
I was sitting on a plane and luckily had a window seat and I was watching the baggage handlers loading the luggage onto the plane. They were counting the bags and starting to load them onto the plane and I looked away for a bit. After a few minutes, I looked back and notice they were almost done and that is when I noticed the priority baggage tag on the last bags being loaded. This is where kanban took over my brain.
Could a simple policy that was implemented by baggage handlers and a Last In – First Out (LIFO) queuing technique manage the priority baggage solution? It seemed to me that this would be a simple tactic to provide a value-add service to customers that they might pay for.
I’m sure it would be a little bit more involved than that (bag check tagging bags, people loading the conveyer belts that take luggage the last mile would need to use a FIFO approach) but basically with a simple policy change (it would have to be an explicit policy) and an understanding of how queues work, the airlines have created business value out of thin air!
Are there any simple policies or queues that you could use to create business value for your organization?
Thought-leaders – “Centers of Gravity” for Knowledge and Learning
I’m a consultant. I’ve been very fortunate to fall into this line of work and I really love what I do.
One of the hard parts of being a consultant though is “staying ahead of the curve”. A consultant is only as good as the skills he possesses and our industry is constantly (and successfully) striving to make our current knowledge and skillset obsolete.
So I do the things that most consultants do. I practice what I know and try new things. I read books. I surf the web. I have my favorite blogs. I use twitter lists to follow people who are aligned with particular interests of mine. And this has been a good tactic for keeping up.
At some point though, I started going to conferences and this is when my growth as a practitioner in my profession started to go to the next level.
I remember the first time I saw a industry luminary, Don Box. At the time, he was really ramping up SOAP, XML, Messaging, all that goodness of the early 2000s. The content of his talk was all available on the web or in books but that wasn’t what I really got from his presentation. In hindsight I’ve realized the true value I took from that experience was his passion for the topics and his stories! I came back from that conference pumped about those technologies and finding exciting new ways to use them! And boy is XML, SOAP and messaging exciting!! <smirk>
Fast forward a bit and now I’m a consultant who is trying to be better at helping individuals, teams and organizations be better and I’m doing this at an amazing time in our industry. Agile is going full steam ahead. Lean and Kanban are entering the process space and starting to make significant inroads. There is a lot to learn and discover, validate or refute. And this is where the thought-leaders come in.
This might sounds obvious, but thought-leaders are really interested in the things they are leading in! They are deeply interested in why “it” works or how they can apply “it” to a new problem. They want to break or validate their thoughts or have them refuted because they are passionate about making “it” better. It’s been my observation that they aren’t normally as interested in applying their specific knowledge to someone else’s problem like most of the rest of us.
It is this unique environment that thought-leaders create around themselves that presents an amazing learning opportunity to the rest of us.
Let me use an example that is fresh in my mind. I’m really interested in The Kanban Method. I think it has the potential to change the way that we all work. But there is a lot to learn and I also want to make sure I’m challenging the method and myself continuously. Enter David Anderson, Kanban thought-leader.
Now David is a really smart guy and he is passionate about his art. He’s a “center of gravity” in the Kanban universe right now. And the really cool thing about that is the attraction of all things Kanban, good and bad, to that center of gravity. If you put yourself in proximity to that center of gravity, virtually or physically, you will be exposed to so many ideas, good and bad, about Kanban. You’re also going to be exposed to the passion to evangelize and grow that David brings to the community.
When I became interested in Kanban I:
- Attended a leadership course with David
- Attended LSSC12 in Boston and Kanban Leadership Retreat in San Diego
- Started following a lot of people in the Kanban community on twitter, finding them because many of them followed David
- Started following blogs of people in the Kanban community, many found from being in the mix with that community
- Got involved in leading-edge questions and challenges with the method, many of which are being discussed by David
I had the same experience with Scrum. My perspective on Scrum was completely opened up by spending a couple days in a course with Ken Schwaber. His perspective on Scrum was so different than anyone else’s, he is very passionate about Scrum and it was such a great learning experience. I also started following @Scrumdotorg on twitter and recognized the value in finding an anchor within that community!
I had the same experience technically with CQRS, an application architectural design pattern. When I became interested in that, I started following thought-leaders in that space.
All of the “technologies” that we use have these centers of gravity that attract all of the good and bad. And there is so much learning to be gained from being in these environments!
So it’s my challenge to you today to go and find a center of gravity in a technology you are really interested in. Find a thought-leader on twitter or find their blog. Find a conference that they will be speaking at and attend. Ask them a question, or ask the community around them a question! Get involved with the communities that are swirling around these thought-leaders and take full advantage of the learning opportunities that will present themselves!
Agile Ramblings 