Enabling enterprise kanban transformation through lean startup techniques


Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I wantedto start the session by providing some contexta roundWho I work for The type of work that I doAnd the kind of clients that I work for
  • first of all, I work for Deloitte. Providing change management services to IT organizations that want to improve the performance and change their working culture.This detail is important, providing these kinds of services while working for afor a large, conservative management consultancy brings about its own particular context and set of challenges.Our clients tend to be conservative, and have a more traditional mindset is not always friendly to agile thinking
  • my mission in life for the last 3 years or so has been to provide IT transformation and change management services to the executives, management and staff working in information technology departments, by happenstance more than by design these organizations tended to be serving public-sector organizations. Think anybody who’s spent any time in IT would agree that this picture reflects the current state of many IT organizations. Despite the critical importance of technology to the success of enterprise as of today, IT does not receive the care and feeding required to make it successful.To make matters worse, when executive does decide it’s time to take a look at improving IT performance the thought process is often so flawed around how to get there that the journey and the organization in a worse state than it was before.Most folks who I’ve talked to who’ve gone through some kind of IT transformation typically described it as useless at best, and massively disruptive at worst
  • So for the last several years I’ve been convincing both the folks at Deloitte as well as my clients that the things you typically would find in IT transformation, items likeProcessToolingRole descriptionsOrganizational structure changeEtc.Are completely insufficient if you want to actually improve the way IT workers work.What’s really required is a deep and sustained change in the way people at all levels of the organization think.
  • There are some corporate and public-sector executives who have the clarity of sight to understand the inherent dysfunctionality in the way things currently work.Unfortunately, executives who do take action, take action using a traditional mindset. A change initiative vision is put together, a detailed target model is created, followed by a very detailed plan.Progress is then evaluated against success against the plan
  • Of course I probably don’t have to convince very many people in this audience that this is a flawed approach. People are probably the most variable component in any system. And when your plan deals with changing people you can pretty much expect your plan to be wrong.When a top-down command run method is applied to a domain that has systemic variability I like to break it down into two real problems:The first is that you’ve built in systemic resistance into discovering a better solution
  • 2. The second is that people seem to put on blinders, making it impossible for them to see when their assumptions were wrong, this is especially devastating when you are trying to change people’s behavior
  • So working for Deloitte, it’s extremely challenging to completely avoid the “design it upfront, plan driven change” paradigm.But what I am a team had been successful in doing over the last several years is integrating well call big bag change with Kanban.
  • Again, probably most of the audience is pretty familiar with Kanban, but I’d like to call what I find are the most compelling aspects of this change management approach.The first is that change agents are responsible for applying any kind of targeted change. The primary focus is putting change tools into the hands of the employees of the organization. It’s then up to the employees to go change according to their own instincts.t This allows can change in an evolutionary mannerThe second interesting thing is that as Kanban systems are applied to various functional departments or teams, it starts pointing out weaknesses in surrounding departments and organizations. This creates a bottom-up pressure to spread the Kanban system out to other areas of the organization giving it a viral aspect as well.
  • Now the challenge is Kanban, as they can take what seems like an awfully long time to take effect. My experience is that progress is also not linear. It seems to take forever for the first couple of groups to start running well with Kanban, and then it seems like there’s this groundswell of pressure as surrounding areas within the organization instinctively resist the feedback that the Kanban system is giving to them.It has been my experience that once the organizational barrier has been breached, it feels like a whole bunch of Domino pins are falling one after each other,I would never argue that the Kanban approach is definitely a better way to institutionalize change within an organization.Unfortunately it actually clashes with the culture of the organization they work for, and more importantly clashes with the culture of most of my clients. These clients tend to want dramatic results, and they want these results quickly.
  • I’ll be the first to admit that some of this impatience is simply due to the culture and personality of the folks involved.But there are also a number of external factors, extremely dramatic events, sometimes extinction level that drive and organizations desire to transform in the first place.I have not had the privilege of being part of an enterprise tITransformation involving kanban methods where time was a luxury.Typically the IT department was already facing some other dramatic events such as major restructuring, outsourcing, or a fundamental shift in the supporting business group
  • This made it challenging to present an option where a slow, gradual approach to change was the only method that we would use.On a previous engagement that we completed last year we started by following an approach that makes Kanban with the more plan oriented model.We wentthrough many of the activities you typically expect in a planned driven change. Current states, target states, roadmaps, assessments etc. were all involved.But knowing the inherent limitations in plan drivenmethods, our team was also careful to include the targeted application of Kanban systems in areas that were undergoing the most change and that we felt had the most severe impact of not getting things right.
  • So Kanban really get a good job of telling us when we needed to course correct. The simple act of helping our clients set upKanban systems and on boarding individual work tickets provided us with way more insight into the operational workings of our clients organization than our current state design and process mapping design activities did.
  • That being said, we were completely unprepared with how mismatched our designs were with the culture, capability and working relationships that were currently in existence in this organization. We had anticipated that Kanban would provide us with performance data around which aspects of the transformation were working from a process perspective and which were not.Our clients are actually for the large part incapable or unwilling to operate Kanban systems that represented even a pragmatic target state model. We then switch to creating Kanban systems that reflected their current state, and were shocked at how unfeasible our targets state recommendations were.Now the positive side here is that Kanban really provided value to this transformation, at the end of the day we were able to react to the information we are getting, and Institute successful Kanban implementations across 75% of the 200 person plus organization.My most eager adopter has made massive performance improvements getting up to a 300% improvement in throughput
  • On the negative side, many of our stakeholders were not able to react and change their opinions around the goals of the transformation as quickly as we were.A large number of the transformation leaders are still convinced that your original target model is one that they should follow. As a result significant confusion still exists within the organization with different folks really following a different thinking model.
  • The major shortcoming of our approach is that we tried to integrate two largely incompatible methods. What we needed was an approach that would allow us to create a transformation plan without sacrificing our needs to be responsive, and make dramatic shifts in the overall vision if necessary.
  • I got a change of pace for a couple of minutes here and give a very high-level overview of the Lean Startup method.
  • Just at this transformation was starting to wind down, I came upon this book completely by accident.I was actually looking for ideal topics and speakers for the track that we are all attending today, and wanted to make sure that I reached out beyond just the familiar faces that we typically see within the lean agile community.I started reading this book, and to be completely transparent I felt a little ill. My first thoughts were, and people can feel free to disagree with this, was that using agile and even Kanban methods without Lean Startup is a lot like driving a a really expensive car without a steering wheel.While the book was certainly not directly applicable to change management, Eric Ries took pains to mention that a startup “is any human institution that needs to operate under conditions of extreme uncertainty” and explicitly pointed out change management as an example…
  • The Lean Startup approach in a nutshell is all about minimizing the amount of time it takes to learn about the viability of a particular business in a highly volatile market.The idea here is that you perform some action that impacts your customer in some way, you can measure their behavior, and try to elicit meaningful learning from the exercise.While the notion of taking an idea, coding it, and then measuring adoption is not 100% applicable to change management, my opinion was that the loop is largely applicable.
  • the key concept that I took away from my reading of the Lean Startup book with the notion of a minimum viable product.Basically all activity executed by Lean Startup is grouped into these minimum viable products. There’s a lot of misconception about what a minimum viable product actually is, and that’s because people confuse it with the notion of the first minimum marketable features set you might want to produce before releasing something to your customers.In actuality a minimum viable product is much smaller than that, the first sequence of these MVPs typically do not require any coding. An MVP is anything that can elicit customer behavior to serve the purpose of learning
  • The other really interesting aspect of the Lean Startup approach, and there are many other interesting aspects, but I want to keep this description brief, is that folks following the Lean Startup approach are very careful to articulate their product vision in terms of a set of assumptions that must be tested.This mindset makes it possible for people running startups to make dramatic changes to their vision when the MVPs they implement show point taken correct assumptions.These dramatic changes are known as pivots, your product vision has to stay grounded on one dimension, and completely change on another
  • Finally, there’s this notion of accelerating. The traditional product development approach as organizations scaling out there marketing, operational and other functions usually following some preset plan.The Lean Startup method has a very different philosophy. Using the Lean Startup approach you need to take care not to accelerate until your MVPs are telling you that you have a problem your customers care about, a problem that they are willing to pay for, that you can build a sustainable business solving that problem for your customers.Accelerating any sooner results in disaster.
  • Now that everybody is an expert on the Lean Startup method, I’m going to switch back to enterprise transformation.Our team was extremely fortunate to be asked to help another IT transformation improve their working culture right on the backs of our previous engagement.Despite our challenges on our last engagement, we had some very good results in application of the Kanban method, Our success provided us with this new opportunity.This time around I was determined to adapt the Lean Startup approach to support this transformation.
  • Our Lean Startup 4 change method could be described as follows:Like all change management engagements we had a vision describing a high level where we wanted to goLikewise, this vision was supported by a number of strategies. Examples of strategies included using Kanban, application of agile methods, and the setup of a centralized quality management office that would be responsible for bringing coaching services to the rest of the organizationUsing the Lean Startup method is an inspiration we broke up our strategies into numerous adoption campaigns. An example of an adoption campaign would be executing an agile style pilot, another example would be setting up Kanban within a functional department visualizing their work completely as isAssumptions were listed for each adoption campaign and where possible provide a measurable hypothesis for each assumptionWe then started to design minimum viable changes. The express purpose of these minimum viable changes was to validate (or invalidate) the feasibility of a particular adoption campaignIf our minimum viable changes showed our hypothesis to be correct we would continue to pursue these tactics, and facing a number of successes accelerate adoption of a particular componentIf our MVCs continued to show that our assumptions were not correct, we need to be ready to pick it and make some kind of significant change in a campaign or strategy or even the vision itself
  • WSIB which stands for worker safety information board, is a public-sector compensation organization responsible for providing insurance against worker related injuries.WSIB, and the supporting IT organization, known as business technology services or BTS for short,is unionized, conservative, and old-fashioned. Many of its employees have worked their 20 to 30 years, and have never even heard of agile, Kanban or other modern delivery methods.Recently a new CIO was put in place who asked me to form a team to help transform this organization. This is how a selection of the framework looks like instantiated for WSIB.(Over a selection of the material )
  • Now that we’ve talked a little bit about the Lean Startup for change method I want to describe exactly what we mean by minimum viable change
  • Figuring out how to actually create these MVCs, what size they should be, and how to measure them was actually a pretty daunting task for our team. In point of fact, our first pivot involved a dramatic overhaul of how we should manage these MVCs.At first we went out we were measuring the performance impact of a particular type of process. I.e. let’s go see if test driven development will provide better performance improvements that no test driven development. This proved to be completely impractical in reality. These kind of tests require successful adoption first.And successful adoption was really our biggest risk, so we quickly pivoted and redesigned our approach to validate whether we are actually changing the way people think.
  • So again what are we really measuring here?We are measuring people, their behavior as it is now, and their behavior as it is after we introduce some kind of change the organization.With this in mind our team to find a minimum Bible change as:the smallest unit of changecapable of providing validated learningabout the impact of our transformationon employee behavior.
  • so of course, when you get a team of geeks in a room together to try to figure out how to actually measure behavior you don’t always come up with the simplest solution firstWhile we did was design a transformation participation engine which allowed us to model employee behaviors into a structured taxonomy.Basically we did our best to categorize our transformation into major themes, examples being lean and Kanban, agile methods, etc.We then decompose these themes into particular tracks, again for example being able to operate a Kanban board would be one track, while being able to act as a designer/inventor for a Kanban system would be another track,.Finally, we broke these tracks into explicit skills, and further describe the skills as a very explicit set of behavior.Behaviors were important, these are the things that we could see people were going, as our minimum viable changes were introduced in the organization we would then watch the reaction to capture them as explicit behaviors. As behaviors were completed by different employees, they would acquire skills.
  • Here is a real concrete example of how we designed a minimum viable change. Each MVC was designed to test an assumption within a particular adoption campaign. In this example we created an MVC to test the effects of setting up a Kanban system for particular functional departments. Our hypothesis was that employees within that department would be over effectively visualize their work and enable better collaboration commitThis hypothesis would be deemed valid if a certain number of management and staff were able to effectively participate in standups, hand off tickets across knowledge workers with minimal delay, as well as visualize blockers, defects and other problemsThese different behaviors were represented as functions of the skills that were targeted for this hypothesis.
  • Now we understand what makes up a minimum viable change, I thought it’s been a couple of minutes talking about how these minimum viable changes fit into our overall Lean Startup 4 change method
  • First of all, our transformation participation engine made it possible for us to visualize the progress of every employee within the organization using a Kanban system.Using this approach every employee within the organization was modeled as a set of work tickets.Every transformation theme was given a discrete swim lane, and then further broken up into explicit swim lanesfor each track of skills. Progression through tracks was not necessarily linear, our team elected to model each skill as a particular state within a track. If somebody was completing more than one skill at a time when simply clone the ticket representing the person.Finally, we assigned a transformation progress state for each skill. we use this as a very coarse indicator of overall progress. Employees were also represented as work tickets within a overall progress swim lane, As an example (read the example)
  • We are then able to largely abandoned a fixed plan for our transformation. Our alternative was to simply express our plan as the projected number of staff who were able to reach a particular level of overall progress.
  • Here is an example of a funeral flowed diagram based on our actuals as a couple of weeks ago.Aside from the fact that we are for the most part completely beating plan, this perspective is allowing us to revise our stakeholders with a view of progress without getting stuck in the details of hardcoded planning and design.
  • Of course, we managed our lean 4, which was responsible for helping us affect Kanban driven change, by using a Kanban boardour backlog is represented as a set of campaigns visualizing light yellow squares. We visualize the decomposition of Kanban’s into minimum viable changes using the green squares with a little annotation to show relationships.Once a week we work with our stakeholders to populate the next column, and then pull to get into the “prepare” state based on capacity.During prepare we would design our MVCs including projected changes in behavior, and also be very clear to let our stakeholders know what impact it would be on them, when we need to meet with them, etc. Would also build out any transformation support material necessary i.e. training material, workshop material etc. Before leaving the prepare state but also careful to set a target date for when we should explicitly measure behavior. We do not want our MVCs lying around for a long period of time.We would move the MVC into the introduce state as soon as we were ready to make first contact with affected employees. Once initial coaching was completely would move it over into the watch state, where it would stay until either the target date had been met, or it became clear our hypothesis was incorrect.Interesting point about this approach, is that we began to quickly follow a pattern of introducing MVC, putting it into the watch state, noticing that our tactics need to be modified. And then moving to take it into measure, and quickly introducing a new MVC based on our learnings.Finally we would measure, and once a week with the retrospective, and placed tickets into a purse, pursue with modified tactics, or pivot zone helping us to inform any big changes were needed
  • So just a quick recapWe organized a transformation into a set of strategies, and attempted to introduce the strategies to the organization using a set of adoption campaignsAdoption campaigns were validated using minimum viable changesEach minimum viable change was designed to measure the change in employee skill,And measurement was facilitated through observation of behaviors, employees would be awarded skills with a mixture of behaviors were observedFinally, we visualize this using Kanban and cumulative flow diagrams, freeing us from the need of a fix plan
  • So while this hasn’t been implemented in our transformation yet, we are thinking ahead. One thing we want to do is to actually gamify our transformation, visualizing individuals progress in turning it into a sort of game.
  • We’re calling this the gamification campaign, and the first MVC will beto create a manual leaderboard and place it outside of a standup and see what the reaction is, hopefully people won’t throw stuff at us, and if they do will be three haven’t invested too much effort in the approach.
  • So now I’d like to use our remaining time just to show you some of our minimum viable changes that have been executed so far at WSIB.
  • For those that like a moderate amount of agile with their Kanban we have set up 3 Kanban/agile project pilots.We’re using this to cast the organization’s ability to adopt familiar agile methods such as story mapping, agile estimating and planning, iterative development, and agile modeling.Again each specific component of the pilot is being modeled as a separate minimum viable change.
  • Another campaign that we are running is the “as is” Kanban campaign.This is exactly what it sounds like, we’re going to various functional departments and visualizing their work warts and all. We’ve created explicit minimum viable changes for each board to effectively track behavior independently of each other.Right now there are detailed boards going across eight different departments, and work is going onto synchronize these boards with the overall project board.
  • Perhaps our most successful campaign has been the creation of an enterprise can then board responsible for visualizing projects and large sized enhancements for the entire organization.This is a massive 16’ x 9’ Kanban system, dedicated to supporting the work of 200+ people. There are zones for almost every process within the IT organization, including procurement, change management, security, software delivery and integration etc.A set of 20-30 executives, managers, and representatives of projects you have issues meet in front of this board three times a weekYou can see at the bottom to set a minimum viable changes that we introduced the organization to help make this board effective, and to change our tactics when necessary.
  • I think there are two really important messages that I want to share with this audience…One is that the Lean Startup approach mixed with Kanban has provided some huge benefits to our enterprise transformation initiative. I really think that this Lean Startup approach has overwhelming applicability outside of the familiar stereotype of kids working in their parents garage.The second is the Lean Startup for change approach is in its infancy, we are really only just getting started, and I fully expect that we will make significant changes to how we are using this approach down the road.
  • Enabling enterprise kanban transformation through lean startup techniques

    1. 1. Enabling Enterprise KanbanTransformation throughLean Startup TechniquesManaging Change Initiatives throughValidated Learning
    2. 2. Some ContextProviding traditional change managementservices to our clients
    3. 3. IT could use some love and care…
    4. 4. Real benefits require true transformation… … we need to rewrite corporate DNA, changing the way people think
    5. 5. The prevailing mindset is to rely on fixed plansto drive change efforts…
    6. 6. And prevent the beauty of discovery fromtaking place…
    7. 7. Outcomes are anything but beautiful…We required a means to validate the assumptions behind the adoption we wanted touse help our clients adopt Lean and Agile Methods
    8. 8. KanbanSupplementing big bang change with agradual, evolutionary approach
    9. 9. Kanban provides change relief;an evolutionary, viral approach to managing changefor knowledge workers
    10. 10. Be prepared for a long journey… … Patience is not something that many of our executive stakeholders are known for
    11. 11. Transformation is often motivated by the need toreact to an external condition… … time is not always a luxury
    12. 12. Our original solution – support planned change through targeted application of Kanban
    13. 13. Kanban will tell you when a course correction isrequired
    14. 14. Prepare to be shown how wrong most of yourassumptions were…
    15. 15. Your stakeholders won’t shift their perspectivesWe required a means to validate the assumptions behind the adoption we wanted touse help our clients adopt Lean do Agile Methodsas quickly as you and
    16. 16. Successful organizational change requireswanted to We required a means to validate the assumptions behind the adoption we alearningclients adopt Lean and Agile supports just in time use help our framework that Methodsplanning
    17. 17. The Lean Startup MethodA five minute primer
    18. 18. “A humaninstitutiondesigned tocreate newproducts andservices underconditions ofextremeuncertainty.”
    19. 19. A prescriptive approach to learning allows you toabandon prescriptive planning
    20. 20. Minimum Viable ProductCollect the maximum amount ofvalidated learning about customerswith the least effort• Coding not required• Must result in actual behavior in the market• Hypothesis > measurement >learning
    21. 21. Product vision is articulated as assumptions… … a Startup will pivot when those assumptions prove to be incorrect
    22. 22. Scaling out the business takes place after underlyingassumptions within the business model have beenvalidated…
    23. 23. Introducing Lean Startup 4Change Management
    24. 24. All enterprise transformation initiative are startups according to the Lean Startup definition Vision Define Strategy Adoption Campaigns Assumptions Hypothesis Validate Pivot Build Most optimal coaching methods? Big A agile pilots? MVC Incremental & evolutionary Kanban Learn Measure change? Pursue Staff versus managers? Specific practices to use? Measurement Framework Accelerate Best way to introduce them?
    25. 25. we are currently implementing Lean Startup 4 Change @Worker Safety Information Board To be the Best Public Sector IT Organization in Canada Vision How? Agile Kanban Quality Management Office Strategies Kanban Kanban / Agile Kanban Visualize Kanban 4 Training Campaign Pilots As Is Work Executives Champion / Self Curriculum Starter Pilots Teams can effectively Qualified people will Executives will lead Hypothesis visualize work coordination of work volunteer to participate (Functional Kanban (Kanban Champion Kick- (MVC) (Executive Board) Boards) off)
    26. 26. Defining a Minimum ViableChange(and how to measure it)
    27. 27. Transformation success means changing theway people think
    28. 28. We are measuring people, the behavior of people, and the capability ofpeople to change behavior, resulting in true enterprise transformation Who me? Minimum Viable Change: The smallest unit of change… capable of providing validated learning… about the impact of a transformation… on employee behavior.
    29. 29. Our team created a Transformation Participation Engine to model the behaviors thatwe want to measure with our MVCs Behaviors Skills Tracks Adoption Tracks Kanban and Lean Kanban Skills Improvement Operate Invent Manage Own MMF and Feature Decomposition Participation Optimize Analyze Synchronize Transparency Enhance Direct Align Agile Modeling Relay Design Facilitate Strategy Domain Driven Design Flow Steer Partner Pinch Hitting Innovate Clean Code Improve Behaviors Test Driven Identifies investment / improvement work Development Lead Provide value during an improvement event Brainstorm Escalates blocked work and actively resolve from Pair Programming follow up with senior / decision-making party Perfect Complete an investment ticket Continuous Integration and Deployment
    30. 30. Planning for a particular MVC involved validating the impact that a particularchange would have on behaviors and skillsKanbanize As Is Work – MVC1: set up an initial Kanban board for each functionaldepartmentCampaign: Hypothesis: Functional departments can effectively visualize work bybuilding a functional Kanban board and onboarding the work as-is today Targeted Tracks Targeted Skills Current Projected Actual Participation 10 +45 +22 Transparency 5 +30 +10 Flow 5 +15 +0 Operate Relay 0 +5 +0 Pinch Hitting 0 +2 +1 Improve 0 +5 +2 Manage Direct 5 +3 +1Outcome: Functional teams set up systems, and visualizing their work. Development &Test functional teams are collaborating between their boards and attending each othersstand-ups. Team member still need to be chased after to update the board. Majority ofparticipants not comfortable raising blockers.Pursue with modified tactics
    31. 31. Visualizing Our ProgressUsing Lean Startup 4Change
    32. 32. The transformation plan is expressed as the number ofstaff who who demonstrate progression to a particularstates of behavior at a particular date
    33. 33. Transformation status is expressed as a function ofprojected versus actual progression Actual # of Staff (this period): Forecast # of Staff (this period): Trained: 206 Trained: 90 Introduce: 96 Introduce: 38 Mental Model: 22 Mental Model: 23 Practice: 22 Practice: 15 Skill: 19 Skill: 7 Expertise: 11 Expertise: 5 Prowess: 3 Prowess: 3 Master: 1 Master: 1
    34. 34. MVCs are managed through a validated learning cycleusing Kanban (of course)
    35. 35. A recap… • campaigns are broken down into tracks, then skills • skills are demonstrated through explicit behaviors • MVC validate assumptions in individual campaigns through tracking changes in behavior and skill • progression in behavior state forms the basis of planning and management Transformation Learning Strategy Tracks Operate Sample Skills Measure the maturity of the organization Invent Participation Staff Maturity Kanban Innovate Transparency Level Manage Pinch Hitting Introduce over time Own Relay Mental Model Requirements Flow Practiced Analysis Improve Skilled Domain Driven Enhance Expertise Agile Pair Optimize Prowess Programming Direct Master Test Driven Development Facilitate Clean Code QMO Coaching
    36. 36. A side effect of our approach - the Gamification ofKanban/Agile transformation Alexis Hui Kanban and Lean Improvement Lead Operate 15Analysis Participation Transparency Relay Flow Pinch Hitting Brainstorm Improve Lead Perfect 15 Invent Build 15 Optimize Enhance DesignValidate Manage 15 Analyze Direct Facilitate Steer Lvl Transformation Own 15 Specialist 1500 Change Points Synchronize Align Strategy Partner InnovateBadges MMF and Feature DecompositionMissions Hierarchical Scenario Based INVEST BDD BDD Automation MMF Definition Agile ModelingRecent ActivityAlexis leveraged MVP approach and gained 64 chg pts Participation Structured Modeling Iterative Modeling Domain Driven DesignAlexis designed and built new kanban system andgained 32 chg pts
    37. 37. MVC 1 – a manually created “leaderboard” to test thereaction of applying this concept to a transformation
    38. 38. Illustrative examples of ouradoption campaign tactics(and the Minimum Viable Changes usedto validate them)
    39. 39. Agile Kanban Pilot ProjectsSetting up cross functional teams using a mixture ofstory mapping,CRC modeling, planning poker alongsideKanban systemsKnowledge workers will…• MVC 1 – successfully decompose work if introduced to story mapping and BDD• MVC 2 – work with fine grained units of value if coached using Kanban techniques• MVC 3 – collaboratively estimate it introduced to planning poker• MVC 4 – facilitate collaborative design sessions if introduced to model storming
    40. 40. “As Is” Kanban -Setup of each functionaldepartment board tracked asa separate MVC…
    41. 41. Enterprise Kanban A dedicated, project level Kanban system for managers and executivesManagers and executives will…• MVC 1 - visualize work if we set up a board• MVC 2 - engage in issue escalation/resolution if we provide standups and process• MVC 3 - limit WIP if we provide a simple sizing/capacity model• MVC 4 - improve adoption if we provide a “concierge” support service
    42. 42. Our experience is only several months old, furtherchanges to Lean Startup 4 Change method areanticipated