Family Kanban

Over the last year I’ve had some great experiences applying kanban for my clients at both the strategic and tactical level. There is something inherently powerful about categorizing work into various homogeneous work types, creating a risk, size and value profile for each work type, and then attaching target performance ratings, work in progress limits and other policies to manage the flow of work.

I recently attended the Advanced Kanban Course by David J. Anderson and Associates, and David made a quick comment around how our locating work in progress to various work types/categories applies to real life as well. A certain amount of time should be spent on various "categories"; examples of categories could be investment/education, grooming/hygiene, entertainment, etc. Certain archetypes of people, do not balance these categories of life activities, and while these people may be deemed "successful", that might not always be the most pleasant people to be around, and certain gaps become painfully aware. David gave a great example of professional athletes, who often spend very little on "daily hygiene" (take a look at a professional athletes apartment) but will spend a lot more on their long-term investment categories of work.

With this in mind my wife and I (at my behest) decided to create our own "family" kanban. We’ve traded a couple of "lifestyle classes" which include the following:

1. entertainment planning (including vacations)
2. family related
3. maintenance (both House and personal)
4. medical
5. investment (including education and long-term saving

We aren’t taking work in progress limits too seriously, but have set anything that’s in progress to approximately 9 items, we also have specific work items that we have assigned to specific days permanently, which will mark as done at the appropriate days.
We also don’t plan to be putting together a service-level targets like cycle time or failure in cake or anything like that. I just want to see if limiting working progress and visualizing work to help in terms of one’s personal as well as professional life.

.

Setting up an effective agile team room

It's Week 2 of our agile project and thought it would be neat to share an agile team room that we have put together for our current project. There is always a bit of thought that needs to go into making the workspace "effective". The room needs to support a project of ~20 resources by facilitating a daily stand-up of "walking the board", parallel analysis and design sessions of small groups 3 - 6 people and provide instant visibility into key project artifacts. We have decided not to co-locate the developers into this room and instead looking to bring in 1 - 2 desktops with environment access for pairing, spiking and design collaboration sessions. Still waiting for the desktops right now.

Here's a play by play of the room during Week 0:

We just threw everything up against a large wall and we didn't have much artifacts at that time, just a system context, story map, CRC cards, and a high-level value stream (on the right).




 
 
Shortly after, we moved into a dedicated room and we put some effort into thinking about the 5s from lean to help optimize the workspace.

Our full end-to-end Kanban board is operational and running now with an issue escalation board to the far right.

Rapidly growing story map with system metaphor diagrams (state machine, process flow) below it for easy accessibility during analysis and design sessions.

Low-fidelity system context mapping exercise, planning to soft copy this into something more elegant once it stabilizes.

Similar set-up for the CRC card modeling. Again we are sticking to low-fidelity design. Notice the handy bin of cards, stickies and other physical items that are easily accessible during modeling sessions.

Finally, a table with all the current "big upfront requirements documents" provided by the business. Unfortunately, this is a necessary evil as we have yet to transition the business into the agile/lean culture of doing requirements. Notice the difference in "information radiation" between these docs and the rest of our "agile artifacts" around the room.


Overall, looking forward to seeing how this room continues to evolve.

Lean Delivery - Business Benefits and Commitments

A client of mine asked for some help in explaining the business impacts of using lean approaches for delivering IT solutions to his ministry stakeholders. (my client is a director of IT in the public sector)

After a couple of hours of work I put together this illustration. It shows a pattern that I have found myself using on a separate project. The pattern involves using a solution analysis work cell to filter and transform ideas into roughly same sized work packages.( or MMFs or MRFs or whatever)

This solution analysis work cell isn't meant to do thorough analysis, rather it does quick pattern matching between the problem domain and existing IT capabilities and systems, breaking and structuring work as required so that these packages can be routed to the right solution team.

Supporting Delivery with a three tier Kanban

After a full day session creating a Kanban with my client we ended up with not one, not two, but a 3 tier Kanban. (I warned my clients this was a really complex option, but they are willing to give it a go and throw out a tier if it warranted)

The three tiers consisted of:
1 - MMFs, a release with a common theme, with business value, or some measure of delivery progress

2 - Testing Packages - a cohesive collection of delivery stories that are teased as a unit as part of package testing 

3 - Delivery Stories - classic agile units of work that go through analysis, development and developer testing
 
As soon as we completed our first standup my mind started turning towards a better structure to manage the flow and multiple level WIP limits that my client wanted.

It was certainly a struggle to come up with a Kanban design that reflects this relatively complex value stream. I hope I have done it justice. I do have a couple of concerns.


1 - complexity, this board may become hard to manage and it's complexity may make it hard to walk, I also hope visibility os not obscured.

2 - it feels like this board is holding a lot of WIP, if necessary I'll start removing buffers and collapsing states between analysis and development if they aren't adding any value.

3 - I'm new to using WIP at different tiers acting as control points for each other, in this board user stories can be blocked by a lack of movement from testing packages and testing packages can get blocked by a lack of progress with MMF related activities. It will be interesting to see how this works.

4 - I'm unsure how defects will affect the board. Both MMFs and testing packages have dedicated slots, if there is a bug do I create a new dedicated slot for a testing package containing a defect, do I move the whole testing package back, or maybe I should just have dedicated lane for defects 

Operating the Agile PMO - Month 1

Last week I posted an initial panorama of an "agile PMO" where I have been working with a team of solution owners and subject matter experts to operate a software application management and analysis function. In plain english, we are using agile and lean methods to set up and manage a delivery program, providing requirements analysis, architecture modeling, infrastructure and resourcing capabilities. Here’s some of the things we’ve managed to accomplish in 4 short weeks.

One of the first things we did was start to analyze the requirements work that had been done to date. We pulled requirements, features, business rules, etc. from these various artifacts and organized them using a story map. The story map covered the majority of an entire wall, using flip charts and sticky notes, we created a hierarchy that started at the top with business goals, and the bottom level being a collection of requirements line items from the various requirements documents. This approach allowed us to add sequencing, structure, and context to individual requirements line items, supporting our ability to do downstream analysis on collections of requirements organized by stories represented in the map.

Fans of Alastair Cockburn’s work will notice that this story map bears a striking resemblance to the use case hierarchy described in his use case books, it is basically identical, but we use the term story map as it has a more "agile" connotation.

What interesting to note is that early on in this process we relied exclusively on these requirements artifacts to help build the map, but as the team is gaining more and more confidence, we are finding that we are building the map from scratch, and then going through the requirements artifacts just to make sure that we didn’t do anything that was inherently in conflict with these requirements.

As we were creating the story map, we annotated stories within the map with issues such as conflicts, questions or obvious errors, as well as things like pre-existing services, specific systems, and the like. Different colored stickies represented different kinds of data, what’s interesting is how visually rich story map has become over time.

once we understood enough of the story map to understand the business problem, we also started doing "minimal system analysis" on individual items within the story map, we wanted to get a order of magnitude understanding of what systems had to speak to each other as a result of implementing a specific user story. We were especially concerned if a system change meant that a piece of work would have to be allocated to a different team. This system allocation analysis also help us understand complexity of the potential story within the map.

Once we felt like we started to get a good handle on what the story map should look like, we defined the overall objectives, scope, and purpose of a number of Minimum Marketable Features. We then "walked the story map" to create workable, user stories for the minimum marketable features that we wanted the delivery team to start implementing. In effect, we went through the bottom layers of the story map, determined if a particular story map should be part of the next Minimum Marketable Feature, broke the story up into a smaller unit of work if necessary, and then estimated it using planning poker (made famous by Michael Cohn).

As a rule, we urged the group not to take the estimation too seriously (which was challenging :-)), what was more important in our minds was the useful conversation, ad hoc modeling and dialogue that was generated as a result of the estimation itself. We actually hope to be moving towards a more kanban style measurement approach in the future where tracking average cycle time will trump estimation, but have found the planning poker approach invaluable as a way of encouraging good dialogue.

At this point we are able to start involving developers, architects, and testers more intimately. We grouped these resources into a "story analysis" work cell responsible for doing "just enough" analysis to ensure that it was ready for delivery. Story analysis included Class Responsibility Cards (check out a great overview by Scott Ambler), Behavior Driven Development style scenarios and acceptance criteria, user interface modeling, and external interfaces for other systems. We also reserve the right to "perform any other modeling" as necessary to help prepare a work ticket as "development ready".

In parallel with doing this analysis, we worked with the team to come up with a preliminary value stream and associated Kanban (invented and made popular by David J. Anderson) to track not only the operation of the agile PMO, but also the work done by the delivery and testing teams.

we included the majority of team members in this process, including developers and testers (as opposed to just their bosses who were involved up to this point). we have also been careful to point out that this is just a preliminary kanban being suggested, and that it would likely have major changes in the next several weeks.

As you can see below, the team elected for a three tier value stream & kanban. While I did stress that many not be that right level of complexity to start off for a Kanban board, I have to say I am working with an incredibly intelligent and sophisticated group, and they were able to articulate a rationale for wanting the three levels. I will go into another post discussing exactly how the kanban and value stream is intended to work, but want to give it some time to actually run before I do so :-).

Kanban is also being used to track the actual work of the agile PMO. We have graduated to (after several weeks) dedicated some lines for questions that need to be answered, explicit modeling activities, analysis with external parties, infrastructure and tooling, and internal design/analysis/planning sessions.

Last I looked into this group, members were individually completing both the enterprise and story analysis function on their own. I look forward to watching this flourish and continue to coach what has so far been a very rewarding and exciting experience.

using the agile modeling method and kanban to run an agile PMO

Myself, along with Alexis Hui have been helping set up an ambitious new business venture for a client with hours. We are synthesizing numerous requirements and design documents into a comprehensive story, breaking the working a minimum marketable features, and doing quick planning poker style estimations.

We have also set up a pulmonary value stream map for delivery, as well as a dedicated value stream map & kanban to manage the work of the "agile PMO".

An associate of mine who is helping us took a great panorama of the PMO war room. I think it shows a great job of how we are leveragingsimple collaborative tools to both model and plan for what promises to be a very exciting initiative.

Kanbanimation

Check out my animated kanban, created of course from my iPad.

Using the Class of Service Concept To Optimize Flow, Manage Risk, and Increase Predictability

I’ve been re reading David J. Anderson’s excellent book on Kanban, it’s an amazing text, full of great thinking that transcends both the agile and more heavy weight process camps. I’ve created a few diagrams in order to better internalize some of the concepts in the book.

one of the key themes of David J. Anderson's book is to categorize work by risk type and then associate it with a specific class of service, allowing software delivery professionals to manage risk, flow of work, and improve predictability of work output.

The idea is that not all work should be treated the same. Implicitly I think that most teams don't treat all work the same. Work being competed to handle an emergency is handled differently from regular features, which is treated differently from capacity upgrades. Organizations will try to prioritize this work differently,and try to allocate capacity as appropriate. The problem is that for many teams and organizations, these rules of work management are implicit, not well understood, and can oftenfollow the "work for the stakeholder who screams the loudest" anti pattern.

David, in his book on on Kanban, recommends that you:

• categorize the existing demand on the software delivery organization, at a minimum given understanding of the various risk and demand profiles of your work
  

• determine how much demand is allocated along each work type/risk profile
  
• have some simple policies in place that match types of demand to specific classes of service, with each class of service having a explicit work flow policy, and WIP limits, some examples include:
  

• compliance related work must be completed before regulations goes into effect (fixed date)
• emergency defects must be completed ASAP, dropping other work, and overriding WIP limits if necessary (silver bullet), typically very few silver bullets are worked on at the same tim
• training, and refactoring work have the lowest priority, and can be dropped to handle fixed date or silver bullet items (intangibles)
• ordinary new features and bugs are finished in a first come research bases (regular work)
  

• model your system of work, otherwise knows as a value stream , determining hand off points, queues, co location of teams, and types of inventory
  
• Set up an input cadence where an input queue for all new work will be refreshed by the business. Likewise setup an output cadence determining the timing when all ready work will be released to production
  
  
  
  
• set target completion SLAs for each service class, for instance a silver bullet item might have a target of 5 day completion 100% of the time, a intangible might have 60 day completion date 50% of the time.
  
  
  
  
• Connect your class of service policies and work types to the value stream, letting the policies dictate how work flows through your system, don’t be afraid to experiment with class of services, wip limits, and other policies, you won’t get it right the first time!
  
  
  
  
• measure actual performance of the system, as well as demand over time. How are you doing compared to your targets? How much regulation vs emergency demand is coming through your system
• 
  
  adjust targets, hopefully for the better over time, but at the beginning you may need to go backwards to reflect the reality of capacity

While the above may seem daunting, in terms of overhead, and management complexity, I would ask readers considering this should take into account the amount of overhead that goes into management of software delivery using traditional methods. Also a significant amount of overhead in managing large-scale agile project when you have multiple teams trying to coordinate with each other. IMHO taking the time to model, manage and measure the system of work is much better stand of "process overhead" and can provide real insight into how could can optimize how work is being completed.

.

Meeting Unique Challenges for Delivery Faster and Smaller in IT

One of the first principles in lean is delivering faster and in smaller batches of work. Delivering faster means we learn quicker (more information) and releasing in smaller batches helps us get more predictable and minimizes a lot of complexity. More information, more control and less risk. All good things.

However, despite these benefits I often encounter clients that are skeptical whether this is realistic with the real world challenges they have to deal with. The domain my clients (IT) tend to live in are often large enterprise organizations that spend most of their energy maintaining legacy systems or modernizing them to newer platforms. Enabling the business is their purpose. Unlike product vendors that focus on pushing out new products for others to instantiate, IT has to transform and integrate products into solutions that work with their business (people, process, technology). This tends to bring out a set of unique challenges specific to IT that is often not discussed in detail in the agile and lean communities. Some of their typical key challenges when trying to deliver fast and release in smaller batches are:

• Data Dependencies - enterprises tend to deal with large amounts of data (often with strict regulations), need to guarantee integrity and carry data with them as they evolve (data conversion is a big task and cut-over planning is essential)
• Integration Dependencies - systems don't sit in isolation within enteprises and often there is a large sprawl of integration between systems with inflexible interfaces (often point to point with legacy techniques and not documented) resulting in a complex network of dependencies
• Enterprise Governance - running a large enterprise is complex and CIOs often want to instill some sense of order in how things are implemented and governance is one way of doing that which often becomes a significant transactional cost when running through the SDLC process for every small release
• Infrastructure Provisioning - often the infrastructure group is detached from the delivery teams resulting in a silo-effect where the request process for environments is long, inefficient and error-prone (project start-up and iterative scaling is hard in this environment)
• Change Management and Training - fast system releases means the business users need to deal with frequent changes in their business process and this results in the training teams needing to deal with an increased workload and a business culture that needs to integrate changes into their BAU (business as usual)

While these are all tough problems to solve and are largely dependent on context and environment, I think there are some good potential solutions out there. Too often the first response is to give into the challenges above when the answer should be "yes we recognize the real-world is ugly" and "let's figure out how to better manage our dependencies and be more efficient and streamlined in how we work". Reduce dependencies and reduce transactional costs. Based on some of my real-world experiences, readings and thoughts here are some potential solutions I have cobbled together from various sources:

• Domain Driven Design Team Patterns - this is probably one of the most powerful ideas in Eric Evans book that still hasn't penetrated into the general IT vocabulary and is one of the first tools I use when dealing with integration dependencies
• Lean Governance - one way of removing the bottleneck of enterprise governance is to focus on "enablement" and "flow" vs "command and control"/"endorse, review, approve" and "policing", some folks like Scott Ambler have written some articles on this topic but additional effort in this area aligning agility and lean with some of the other more traditional groups (e.g. TOGAF) out there would be interesting
• Platform as a service (PAAS) - one easy way to move infrastructure provisioning along is to move away from providing "boxes" and "wires" to offering end-to-end dev/test/prod application environment stacks to delivery teams using shared environments, some organizations are offering this externally as a business (e.g. Amazon) and internal IT shops should look at how they can bring their own variant of this into their infrastructure groups (my current public sector client is doing this today)
• DevOps - another common problem is the silos between operations and development and there is an active community looking to solve this by pushing the DevOps paradigm (development + operations) and making it work in their environments, some organizations (e.g. Facebook) have really pushed the boundaries here and merged the roles into one with "developers" actually implementing patterns in their code (e.g. Gatekeeper pattern) to help solve release management challenges
• Change Management and Training - there is an increased awareness today that usability experts need to be engaged in the delivery process early on and getting them to work in an agile and lean way is something that is starting to be discussed but good usability can only go so far and there has been little discussion about how to embed change management and training resources in the team and getting them engaged in the iterative release process, new releases without users doesn't deliver much value to the business at the end of the day

Agile Adoption in the Banking Industry

I was organizing my email today (large backlog as usual, need to put in a policy where I purge things after 6 mths) and came across a summary I had from an agile adoption survey a few of my colleagues conducted with several large banks. This is by no means a scientific survey, just one that was conducted with senior leaders from several different banks. Thought it was interesting to share. Here are the key findings:

1) Banks are using agile in tactical ways

2) Their usage is largely limited to applying two practices “iterative development” and “co-located teams”

3) Architecture is not interested

4) Business and development are interested with QA on the fence

5) Compelling reason is reduce time to market

6) Main barrier is cultural, looks like there is a strong culture factor against it

7) Key challenge is estimation, they are unable to apply it within their current budgeting model

8) Key success factors are executive sponsorship with appropriate coaching

This aligns with a general observation that I have noticed as well. The movement is largely developer driven with business wanting to get in but challenged by their budgeting model. Architecture and QA are largely not bought in.

Value Stream Mapping Session Gone Awry

During one of our lean client engagements, we conducted half a dozen value stream mapping sessions with various groups and project teams from the client organization and this session was an interesting exercise. The session involved a large cross-functional team responsible for maintaining a very large-scale system and we wanted to get representatives involved from each stream / discipline (PM, BA, Dev, Test, Training, Architecture, Service Management, Infrastructure) to get the holistic picture. We ended up with a group of ~20 people and one of our facilitators (i.e. Jeff Anderson) decided to facilitate using a decentralized approach and handed out stickies to everyone and asked everyone to come to the wall and map out their specific processes in the value stream. This is what we ended up with:

Needless to say, I am having a "fun" time transcribing this into a visio diagram (we promised the client we would capture the value stream and give it back to them as a deliverable). Next time we have such a large group, I think I will use a different approach (lesson learned).

Architect Police vs Architect Leads

A classic problem I encounter in various IT organizations is the massive divide between Architecture and Project Delivery. Most organizations today have recognized that architecture is important to the organization and as a result have established some form of Enterprise Architecture Governance (Architecture Review Boards, Advisory, etc). This is a good first step, as having a central body that can provide holistic and strategic oversight and advice can help consolidate the maze of systems and designs that has been inherited from past bad behaviours and move organizations towards a rationalized portfolio.

However, in an effort to provide "independence" these governing bodies often suffer from the classic ivory tower syndrome and have evolved themselves into a "policing" role. As a result, project delivery teams looking to deliver cheaper, faster and better for their clients find themselves at odds with Architecture which they look at as a speed bump to their work.

This "architecture policing" anti-pattern tends to produce the following results:

• directing scarce and valuable experienced resources into producing conceptual and logical architectures that provide little value to delivery teams
• emphasizing "policing" over "advising" and "leading" resulting in architects that are out of touch with the client requirements, project context and implementation decisions
• mandating high ceremony checkpoints with heavy documentation and review that slows down project delivery while adding little value to the team and clients
  

Instead of playing the role of police, architects can provide much more value to an organization by decentralizing themselves back into project delivery roles and taking ownership of delivering solutions to clients. During my attendance at the IBM Impact Conference 2010, there was a great success story with a Leading Canadian Bank that delivered an enterprise wide service bus architecture and framework with working code led and owned by their architects. The organization established Framework Architects that were responsible for designing and evolving their ESB framework and assigned responsibility to channel and business facing Solution Architects to extend the framework for their specific client needs.

I am hoping to see more organizations continue to follow the approach of embedding architects in delivery and leading the development of core frameworks and assets for reuse / extension by the organization. Architects leading by "doing" is always a good thing.

KANBAN Overview - created on my iPad

Upon getting my iPAd the first thing I did was create a mock up of a Kanban board using the omnigraffle diagram software. The board is based on several chapters of David J Anderson's great book "KANBAN - successful, evolutionary change for your technology business. I think the results turned out pretty well. Feel free to use and reuse, btw I highly recommend getting David's book, it's a game changer IMHO...
















- Posted using BlogPress from my iPhone

Getting to Lean Principles

I had the opportunity to work with some IT execs who wanted to look at Lean thinking as a method to improve the way they were delivering value to their business customers.


Lean ideas was certainly not something that was embraced by the org, and certainly not all of the execs were bought in to Lean ideas, or even had a real understanding of how lean thinking could even be applicable to their problems. In preparation for a one day visioning session, our team sent out a questionnaire asking the execs to match specific organizational objectives to various possible activities.

Here is an example question:

The IT organization should manage process changes through:
- a specialized and dedicated process governance group
- empowering people on the ground doing the work
- assigning process change authority exclusively to middle management
- Senior executive oversight

While the "right" lean answer ( in quotes because no answer is exclusively right) may seem obvious to most readers of this blog, I thought it was important to test the beliefs and opinions of this group to see if anyone would be challenged philosophically about lean thinking.

All to often I've encountered belief systems that make it really difficult to have even a cursory conversation of how lean can help IT liver better value.

I was pleasantly surprised about the answers I received. While they weren't unanimous, the majority of responses indicated an intuitive affinity with a Lean way of thinking amongst most of the execs. With a little bit of grammatical restructuring we were able to take these answers and use them as the basis for a set of transformation principles that would guide this organizations journey to a different way of doing work.

Below are the principles, which I think are good ones for any org looking to adopt elements of lean thinking..


Empower process changes through: people on-the-ground doing the work

Leadership and Management should: coach, empower and enable

Manage priorities and requirements by: partnering with the client and collaboratively defining product roadmaps for each LOB

View automation as: a priority across all projects and applied to all aspects of the delivery lifecycle

The key measure of team success should be: client satisfaction of value delivered vs. time to deliver

Handle work based on: structuring work into small batches that can be released quickly

Build value through delivery by: getting resources working collaboratively and in cross-functional teams throughout the process

Approach quality: by investing early on and building in quality

How-to Conduct a Remote Agile Daily Stand-up

Physical objects tend to help teams perform, communicate and operate more effectively. We've seen this trend with iteration planning boards, kanbans, continuous integration orbs etc. So, we thought how we can make daily stand-ups with a distributed team more effective? Here's our answer.

My Take Away from the Lean Software & Systems Conference 2010

Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge

I expected that when I went to lssc10 I would learn some interesting case studies, how tos, and general advice on how to implement various aspects of lean within the software delivery domain. Instead my primary take away, (and I think something that resonated with the entire conference) was a call to arms to move beyond the traditional lean metaphor and concepts taken from manufacturing, and to start opening our minds to other domains, other bodies of knowledge and other areas of expertise. Clearly leaders within the LSSC feel that we all have many more questions than answers, and that a open-minded, humble attitude is required to continue growing as community of practice and knowledge. A common feeling among everybody I met at the LSSC was that "our" brand of lean really represents an open ended philosophy, one that emphasizes intrinsic motivation, dedicated to building a measured but learning systems. You could almost see the thirst for new, provable knowledge among the attendees at the conference. I saw very little patience for dogma be it agile, lean, or otherwise, and was told by a couple to open my mind up a bit (thx siraju).

Many of the Ideas from Lean Are Toxic to Our Practice

I think the keynote presentation on the 1st day says it all. Don Reinerstein started off by saying that lean is just the next peak of the mountain that we can see, and beyond that mountain lies something else. This point (IMHO) is that it was time to stop looking at lean as a source for all of our ideas and ways that we can improve our practice. According to Don, we are leaving a lot of great thinking on the table by being overreliant on the lean metaphor. He then went and listed all the kinds of lean principles that were actually toxic to a learning system.

• Eliminating Variability- variability is essential to product development, you are always dealing with something new, if you have no variability you actually have no value

• Eliminating Waste - an over focus on eliminating waste misses the point, idle time is one of the key areas that are of concern
• 0 Failure-failure is actually a good thing in learning systems, as this is one the most information is generated, so we actually want ways of generating an appropriate ratio of failure to success, if we have too much of either the system is not generating enough information to properly learn
• 100% Defect Prevention - preventing defects has a cost, we need to weigh that cost with defect fixing
• Complete Customer value focus - the customer is not always the sole or return value, there are plenty of case studies where businesses have gone under because they provided more and more features to high-end customers, and ignored innovations. (In fact this is the key point of the innovators dilemma)
• One Piece Flow - one piece flow doesn’t make sense for human systems passing information round, we need to balance transaction with holding costs

The Internet As a Metaphor for Human, Learning, Product Development Systems

What really caused the crowd to get excited, was when Don urged the crowd to consider another metaphor for distributed services/learning-based systems, the Internet. The Internet is a system that is of extremely high quality, deals with variability, and can scale quickly without problem. Don went to then describe how different aspects of the Internet could be used to model the next generation of knowledge work management systems

• dynamic routing of work in progress based on congestion in the network, routing conditions are updated sometimes many times an hour
• work in progress constraints are determined just-in-time, based on load, as capacity changes the system probes the network and adjusts; dropping packets and lowering wip as necessary
• small batch sizes are used to raise speed, efficiency and quality, but some batching is also required
• there is a balance between deciding the optimal route (upfront quality) and allowing the system to reject and resend failed packets (think test after)
• throughput is managed by doing rate matching with the sender and receiver
• resources are bound to problems at the last responsible moment

You could practically feel the electricity in the room as Don describe how a human network could emulate the Internet to predict a failure condition originating from too much work being introduced in the system, in response the system would immediately reduce allowable intake, in order to ensure maximum flow. I don’t think I was the only one in the room who’ s internal gear started shifting on how to actually design and run such a system. One algorithm Don suggested was to raise the acceptance criteria of any new projects within an enterprise portfolio as the enterprise portfolio got more and more full.

After getting everyone excited, Don then proceeded to pour water on the whole metaphor, the problem he stated, was with fungibility, i.e. in a human system resources are very tightly coupled to the kinds of work they are doing. In the Internet any node is equally capable of bearing work. For a human system, adding value to information requires very specific skills, a .net developer is not to be able to do much with an SAP problem.

Don encouraged all attendees at the lssc10 to start looking at other bodies of knowledge for the next generation of ideas that would inspire and take this community to the next level. These included:

• queuing theory
• os design
• economics
• traffic flow theor
• maneuver warfare

Stop Drinking the Kool-Aid

Don’s finally urged all attendees to stop drinking the lean cool aid, and continue to look at multiple domains for synergies, patterns and practices that can help to dance the state of our practice.

While there are many other extremely powerful examples of this philosophy that was demonstrated throughout the conference, (I will talk about some of the other great aha moments in later posts) I certainly want to thank Don for perhaps one of the most inspiring professionally related presentations that I have attended. The more I get involved in the lean community, the less I feel that I know, and the more excited I get about increasing my understanding.

Misadventures Of Trying to Apply Learnings from LSSC

After a great week of learning at the Lean Software Systems Conference I was eager to apply a key theme, intrinsic motivations trump extrinsic ones.

Our neighborhood was having a yearly clean up of our back alley way. And the local kids ( aged 5-7) had it in their mind that they wanted to play union, and were demanding more pay to continue helping, a strike was coming.

The kids parents started to offer incentives like ice cream and what nots, to properly motivate the troops. Inspired by one of the great talks at LSSC I immediately stepped in with a different approach.

I told the children that if they worked well I'd get them their own clean up tools with super hero stickers attached. This worked to great effect, the children started immediately going back to work with gusto. After an hour I set out to buy some kiddie tools and stickers as promised.

This is where the misadventure begins.
1)Because I was super busy over the last couple of weeks, doing too many things at once, i'd misplaced my bank card without replacing it the previous week.

2)Because I had no bank card, I couldn't get the kiddy tools I wanted for the kids. (the local dollar store didnt take mastercard)

3)I then borrowed my wife's bank card, but because I was in such a hurry, I didn't enter in the appropriate bankcard combination, which caused her bank card to be frozen.

4) Because it was saturday I couldn't get a new bank card even though I biked all over the city looking for an open branch.

5)Because I couldn't provide my workers with the reward of better tools which would actually get them to do more work, I went to the local toy store ( that took MasterCard) bought a bunch of action figures and provided my workers with an extrinsic reward which had the effect of making the workers happy, but all work also stopped as the kids went to play with their toys.

My lessons:

- the extrinsic reward was way more expensive, didn't encourage work over time, and actually stopped work for awhile.- properly providing an intrinsic reward requires just a little organization.

- Bad organization breeds extra work, which causes more bad organization, which causes more extra work
- Management needs to slow down, get organized, and focus on motivating workers, an investment is required, but the payoff is huge.
- It's time to start using things like managing work in progress, and slowing down to speed things up in my personal as well as professional life.

Marvel Superheroes and Kanban the Ultimate Crossover!

The Team Started off Using a Kanban Board...

There is a wealth of advice on how using concepts like a Kanban board will help teams to better manage software projects. The idea is that publicly wall sized boards (or other information radiators placed in an area that can be seen in use by the entire team) can be used to highlight and set limits on work in progress, limiting work to capacity, and allowing resources to focus on completing dedicated units of work with a limited amount of multitasking. The Kanban concept allows software development teams to start out using the Kanban board to represent an already existing software development process, one that the team is already familiar with, and gradually adopt more agile or not agile practices as necessary to address specific blocking issues. The idea is a simple one, let problems, typically manifested as blocked work, dictate what practices and methods are adopted by the team.

one approach to starting out with kanban is to develop a initial value stream for the delivery process. Often various team leads meet and conduct a preliminary value stream mapping exercise. A value stream maps allows everyone to get an idea of how value and work items would be completed and passed between different teams and competencies. Once complete the entire team can set up a Kanban board based on the value stream.

But Managing Work in Progress Can Still Be Exceedingly Difficult!

Despite best attempts, many teams just can't manage work in progress properly. Requirements work takes too long to get into the development funnel, development teams and the development team leads can constantly get interrupted by "emergency" request (which were being tracked on the board), specialists (like testers) are nowhere in sight, the development work in progress (WIP) overflows with technical based stories, and work clearly exceeds the WIP limit set for the team.

Clearly not all teams have the skills to make Kanban successful on their own, but what is the solution...

Marvel superheroes to the rescue...

The immediate solution isto replace the typical ho-hum avatars that are used to identify who is doing what kind of work on the kanban board with avatars based on the iconic members of the Marvel superheroes family. Clearly by using these avatars, one can magically imbue our team with all the necessary superpowers to support a delivery process characterized by a steady and constant flow, using a visible, pull based system, supported by the values of a grassroots, problem solving culture.

Choose the right avatars based on issues that your team is experiencing...

Almost any of the mighty Marvel avatars can bring immediate benefit to your project, it’s important to select the right ones and assign them to the right team key members depending on the issues that your team and project are experiencing. Here’s an example of some of the really useful superpowers that the mighty Marvel avatars can bring to your individual team members to better support flow, a steady cadence of delivery, and short cycle times.

Spider-man

Despite the best efforts of our team, work was still being pushed through the system in large, and uneven batches. Use good old Spidey to support the pulling of work. With the aid of his trusty web shooter, Spidey is able to pull work that is in the "ready" state from a previous processed queue. What makes assigning Spiderman to one of your team members even more powerful, is that your friendly neighborhood wall crawler is able to stick to doing work that is actually on the kanban board. When asked to do new work, emergency or otherwise, Spiderman makes sure that work is put onto the appropriate queue as dictated by the policies of the Kanban board (FIFO, high-priority, blocking issue, etc.). This ensures that the delivery of work is executed using a systematic set of rules.

Power man

When requirements just aren’t coming fast enough to feed the downstream development and testing team, assigning power man to one of your team members will give him the strength to literally beat the requirements out of your stake holders. Power man will also muscle everyone to use the kanban board with consistency. In all seriousness, power man’s thick, unbreakable skin allows him to tough it out when it looks tempting for the team to consider going back to the bad old ways of software delivery. Power man will help your team persevere by sticking to his guns and coaching the team so that they continuing to take the time necessary to develop the kanban board, and make sure that all work in progress is being tracked on the board, that the board is kept up-to-date, and that the team stays the course. The benefits of kanban take time to be realized, and only through patience and endurance can lower cycle times, better quality, and other improvements be realized.

Galactus.

Galactus, known as the "Devourer of WIP", will empower your team consume any work in progress that is in excess of the limits put in place on the kanban board. Assigning Galactus to a member of your team team will remind them that work must be finished before new work is started. Galactus’ hunger for excess WIP is legendary, and teams must do their utmost to limit work in progress due to actual capacity of the team lest Galactus mercilessly consume any of this excess inventory leading to a complete waste of work.

Rogue

Using kanban supports the use of highly specialized resources, and frees the teams from the agile dictate that everyone is responsible for everything. That being said one of the critical principles of kanban is that workers should focus on moving inventory through the entire process, rather than exclusively working within their own skill set. In other words, if a particular process is accumulating too much wip (e.g. testing) than the rest of the team should start helping testers with their work, rather than starting new work within their particular domain. Rogue is the ultimate pinch hitter, she’s able to absorb the super powers of workers from others competencies simply by working with Them, asking intelligent questions, and showing the initiative and willingness to learn from those around her. Rogue is not intimidated by doing work outside of her job description, she’s focused On the success of the entire product, not just a particular phase within a process.

Mr. Fantastic

One of the biggest benefits of the Kanban board is that you can use simple metrics and measurements to quantitatively define how well your team is doing. Taking the time to measure the cycle time of all work, and the proportion of work that is categorized as technical, business value, or emergency, work introduced by defects versus new feature requests can give the team and management dramatic insight into what’s working, what’s not working, and where improvement efforts should be focused. Applying the Mr. Fantastic avatar to one of your team members, will ensure that your team takes the time to write the appropriate data on the kanban board. While individual members will always feel rushed to focus exclusively on the work, taking the time to make sure that all work is categorized according to the appropriate policy, and start dates and end dates are captured will provide a rich set of data that can show if the team is getting better at what it’s doing. Mr. fantastic is a master of taking this data and providing simple dashboards and cumulative flow diagrams that can give insight into which areas of the software delivery value stream is experiencing issues.

There Are Many More Mighty Marvel Avatars to Help You Successfully Adopting Kanban on Your Project

The above is just a sampling of how the appropriate Marvel avatars can apply the right super powers necessary to applying the principles of lean software development and kanban to your project. Focusing on the work, short cycle times and a steady flow of progress has been shown to provide demonstrable improvements on software development projects. Combining kanban and Marvel superheroes is an excellent way to educate your team on the most effective use of the kanban board.

.

An Overview on Value Stream Mapping for Software Delivery

Value Stream Mapping (VSM) is a Lean process tool that can help teams to get an understanding of where some of their biggest problems are. When done correctly, value stream maps are produced by collaborative, high touch, low ceremony session that can lightly apply a structured method to identifying organizational waste and potential areas for improvement.

When conducting these sessions, I tend to focus on 3 lean tools. (It should be noted that Alexis Hui created all these fancy graphics

• Value stream maps


• 7 wastes as identified by Mary Poppendick


• 5Ys approach to root cause analysis

Value Stream Mapping

Value stream maps can be used to map the flow of work from the start of the delivery process (ex: client request) to the end of the delivery process (ex: system delivered to the client). They are similar to process diagrams, but meant to be much less detailed, but getting things into process areas.

There is lots of advice from the manufacturing world discussing how to do Value Stream Mapping in non-IT delivery context. Many of the examples have complex notations, lots of symbols and icons that may, or may not apply to the software delivery context. Folks like Mary Poppendick, Alan Shalloway, and even Kent Back recommend taking a much lighter approach, using a much simpler notation. During our session we focused on using for simple icons preprinted on sticky notes. We also asked the group to focus on giving their opinion on a couple of key metrics for each of the icons

7 Wastes of Solution Delivery
While value stream maps are being drawn, very as participants in the session will recognize obvious inefficiencies relating to bureaucracy, delays, people being too far away from each other etc. As these wastes are recognized participants can apply them to the various process boxes or inventory pieces. Shown below are the 7 wastes as identified by Mary Poppendick her book Implementing Lean Software Development: From Concept to Cash

5 Whys

As errors are identified by participants in the value stream mapping sessions it’s important to reflect on the underlying issues of these problems. In his book, Agile Software Development: Achieving Enterprise Agility, Alan Shalloway recommends using a simple but powerful tool known as the 5 whys to do root cause analysis.
While our experience has been that strictly following the five whys is not necessary to get the heart of all problems, it’s A good way to kickstart conversations when progress is stalled, and it can help apply some structure to participants who sometimes can descend into too much detail or go off topic.

Structuring the Facilitation

while the sessions are meant to be applied with an open approach, we have found that lightly applying some structure to the value stream mapping sessions makes it much easier to get newcomers who have never done by Stream mapping before the start.
The process that we used involve the following steps:

• identifying and categorizing various families of value streams


• mapping the various identified value streams into various process areas and inventories


• measuring things such as cycle time, value generation time, and waste for the various value streams


• performing root cause analysis on the areas with the worst ratio of value to non-value-added activities, performing the five whys as necessary


• developing homework for members in the sessions to immediately act upon

Categorizing the Value Stream Product Families

We asked participants in the sessions to come up with unique value streams based on attributes like

• solution size


• new builds versus enhancements


• legacy versus more modern platforms such as.net


• distinct business lines

it should be noted that in this organization these attributes cause very different processes to kick in, certainly not an ideal situation but an obvious candidate for improvement, i.e. simple standardization where appropriate.

Developing the Current State Value Maps

During our session we asked participants to map out the value streams, and I have to say despite assertions from noted and respected experts in this field, this was by no means a simple 10 to 15 minute exercise! While we tried to keeping high-level there was significant redundant processes and activities that could only be discovered by going into a reasonable level of detail.
We try to make sure that we are holistic and covering the end and process flow, from business goal setting all the way to operations and support and everything in between.

Measuring the Value Streams

After mapping the value streams, we then solicited participants to put simple measurements where they knew them, writing down on sticky notes things like cycle time, actual effort and size of different inventories. We then flagged areas where there could be significant problem areas. Problem areas could be identified by looking at things such as large backlogs, and long lifetime of inventories, processes were the wait time was large, and really large/complex process flows.

Analyzing Potential Problem Areas

We then used a combination of the seven wastes and the five whys to identify problem areas and do root cause analysis on potential solutions.

Looking at Tactical ways to Implement Improvements

At the end of the session we took a overall look at all the different various value streams, and started identifying common problems across all of these value streams. What was interesting is that even though individual value streams used very different processes, they all suffer from the same pattern of problems. These were

• an architecture gating process that was perceived to be bureaucratic, cumbersome and contained a lot of duplication


• infrastructure group that had very high turnaround times for what was perceived to be very simple requests


• an extremely long project charter/project initiation timeline, which value activities being measured in hours or days, and delays and waste being measured in weeks and months

Conclusions
the sessions were IMHO fantastically successful. Participants were eager to point out new solutions, and the opportunity allowed individuals from different organizational departments to actually collaborate together to come up with new ways of working together. I think the big differentiator between lean continuous improvement tools versus other approaches is that lean encourages the use of approaches that anybody can learn in a couple of hours or days. "Sophisticated" techniques are replaced with mechanisms that allow workers to look at and improve their own processes.

.