Consulting and Education
From Craig Larman
Contact me: mailto:firstname.lastname@example.org
Deep-Dive Agile or Lean Management Q&A Workshop
Impact Mapping Workshop
Systems-Thinking Workshop for Executives: Exploring Assumptions, Thinking Deeply
A theme of the MIT Learning Organization research is that people in executive management weaken their organizational designs due to unexamined assumptions about system dynamics, the psychology of motivation, and their ladders of inference. In this challenging half- or one-day workshop the leadership team practice seeing and examining the complex system dynamics in their organization through agile modeling with causal models, and by developing high-inquiry skills into the ladders of inference. We also examine recent management research (from Stanford University, Harvard, and other management research centers) that challenges traditional assumptions about measurement, motivation, appraisal, and reward systems.
Value-Stream Mapping PLUS WIP and Queue Analysis Workshop
In lean thinking, understanding the value stream and improving it (for example, by reducing waste) are key improvement goals. And improving the value:waste ratio is a noteworthy KPI. In this workshop, we retrospect on a completed release cycle of a product, and create a value-stream map, to understand the value stream and estimate the value:waste ratio. Attendees need to include people with knowledge/memory of a completed release, in detail, so that we can create a retrospective value-stream map of the completed release cycle. Supplies? We need several very large whiteboards, or the whiteboard cling sheets as described here. Pre-work? A VSM workshop includes defining the current-state VSM, and that requires detailed information about *all* the fine-grained activities and their average cycle times (and rework rates) for finished release. The workshop will be quicker and more useful if participants collect as much information as possible all fine-grained activities of a prior release, and their characteristics, *before* the workshop. For example, what are *all* activities? What are the average cycle times? What are the average queue sizes of WIP items before each activity?
Organizational Change and Impediments Backlog Workshop
What is the role of leadership and other managers, in a lean enterprise, or in a large-scale Scrum context? Responsibilities include:
- identifying a target organizational design
- communicating the vision and new design
- hands-on teaching/mentoring people in systems thinking and lean thinking
- hands-on teaching/mentoring people mastery of techniques (e.g., in product mgmt, programming, ...)
- doing "Go See" to develop trust with delivery people, and learn their impediments
- removing impediments that inhibit the flow of value, cycle times, and the work of the delivery people
In this workshop, we move from knowing to doing, and identify the next-step org design goals and SMART actions towards them. And for the last point, it is necessary to form an impediments backlog and decide, as a management team, how to handle the backlog. In this workshop we form the backlog and plan how management and delivery people will work with it.
This is especially important when large-scale Scrum is first introduced, as there are many organizational elements and other "rocks" that need to be changed or removed so that value can flow to the customers without "pause or impediment."
Self-Designing Teams Workshop
Adopting the Scrum framework involves structural changes. Key among these is forming real "teams" in Scrum: dedicated, true cross-functional and cross-component teams of about seven people who are multi-learning and multi-skilled and can independently perform all the tasks (analysis, development, testing, etc.) to deliver completely "done" end-to-end functionality. Before adopting Scrum, the organizational structure may be primarily single-function groups (business analysis group, development group, test group). Further, developers may be subdivided into single-software-component subgroups with "private code ownership" in each component group (rather than "internal open source").
Therefore, as an early step in Scrum adoption, the department needed to reorganize the existing groups into new teams — true cross-functional and cross-component (Scrum) teams.
What does it communicate to the people if managers say, 'We are going to adopt Scrum, Agile principles, and self-organizing principles,' but then managers decide and tell people what their teams are, and who their ScrumMasters are?"
Therefore, an alternative is the self-designing teams workshop, in which all the people from the prior groups get together in a large room, and then with me acting as facilitator, they go through a structured process to design their own teams, and then interview and decide ("hire") their own ScrumMasters.
This workshop takes about 2 hours. Details on how the workshop runs can be found here: How to form teams in Large-Scale Scrum: a story of self-designing teams
Go See and Help at the Value-Adding Place
Some background will help explain my assessment approach when I start to work with a group: In lean thinking (the Toyota Way), the lean consultant or coach is expected to practice genchi genbutsu at gemba — “go see and help” at “the place where value is added”. And a lean consultant is expected to be a master of the hands-on/brains-on work. So, in contrast to traditional “PowerPoint consultants”, I start a new client engagement by spending at least one day doing real work (pair work) with several operational people; usually one day with product management (for example, prioritizing requirements) and one day with engineering (for example, pair programming) — or for short engagements, perhaps a half day with each. This quickly gives me high-density information about the true nature of the organization, in ways that are hard to grasp — or are unintentionally obfuscated — by only meeting with people. I use that insight to more effectively inform the subsequent engagement with leadership.
Keynotes and Executive Seminars
(see Courses for examples) I frequently speak with conference and executive management groups on topics related to large-scale product development with lean or agile management systems.
Facilitating and Coaching Scrum or other 'Agile' Events for Skills Transfer
I attend your existing Scrum initial Product Backlog Creation workshop (Release Planning workshop), Sprint Planning (part one and two), 5% Product Backlog Refinement Workshop, Sprint Review, and/or Sprint Retrospective. I facilitate these standard Scrum events and share skillful practices and heuristics so that the teams gain increased value from these activities.
I also coach other whole-team Agile Workshops (or elaboration of above):
Lean and Agile Transformation Leadership
I work with management teams to help understanding and adoption of modern lean and agile processes. My focus is large enterprise transformations, such as at Alcatel-Lucent, Xerox, UBS, and Nokia Siemens Networks.
Agile Architecture Documentation Workshop
Your problem: There is a large system and the overarching existing design is not clear to many. This also inhibits evolving the design for the future. In this 1-2 day workshop, I facilitate the group to create architectural views and technical memos in a highly collaborative hands-on workshop using vast whiteboard spaces, to sketch out the existing product architecture, and also capturing Q&A sessions on video. The output is not only the many architectural view sketches (logical, process, data, deployment, security, ...) and technical memos, but a shared understandings amongst workshop participants in the existing design, using lightweight and fun methods that transform "documenting the architecture" from a boring low-value activity into an interesting high-learning high-value event.
This workshop can also be combined with the definition and organization of a self-study plus Q&A mentoring system for new hires to your company, to speed and improve the architectural knowledge of your staff.
Self-Designing Teams Workshop: Forming the new Cross-Functional Teams
Your problem: You have single-function groups, such as a testing group, UX group, DB group, architecture group, client-side programming group, server-side programming group, platform group, and so forth. To flip the organizational structure to Scrum, we need cross-functional and cross-component teams of multi-learning team members who can do (or learn to do) everything end-to-end without depending on any other group. So we need to re-organize the groups into new Scrum Teams. How to do this? One (not recommended) approach is for a separate manager to decide the new team structure. But what does that demonstrate, when your organizational is ostensibly adopting Scrum and Agile principles, which include self-organizing teams (and no command-and-control top-down management) as a core principle?
So a better approach exists: the Self-Designing Teams Workshop in which all the people from all groups (e.g., 200 people) get together a a large room, and over a 3-hour period, they go through the self-designing teams process in which they themselves decide their new (cross-functional, cross-component) teams. I facilitate this fascinating event that demonstrates management commitment to walk the talk of Agile principles, based on past experiences of how to run this workshop effectively.
Lean and Agile Org Design, Coaching, Curriculum, and Programme Design
You are involved in or are responsible for a transformation toward lean product development and/or agile development (perhaps with large-scale Scrum) involving tens of thousands of engineers and managers in a large product development organization, perhaps spanning the globe. How to proceed? What coaching? What curriculum? What should the programme be? I have both led the design and been closely involved in the design and execution of several large enterprise transformations.
Agile Mini-Sprint (Iteration) Kickstart
This kickstart is a highly structured coaching of Sprint/iteration-1 (or later) for your product. I serve as ScrumMaster and facilitate all events: Sprint Planning Part 1 & 2, Product Backlog Refinement, Daily Scrum, Sprint Review, Retrospective. This can be for up to 3 teams in parallel, as long as the teams are co-located so that i can quickly move between them or bring all teams together for informal quick sessions. Novice internal ScrumMasters will also attend and observe (to learn the art of ScrumMastering). During the events I introduce/coach many concrete techniques: specification by example, impact maps, wide-band delphi, and so forth. In between the events I may introduce/coach many engineering techniques: continuous integration, test-driven development, agile modeling design workshops, pomodoro, and more.
Splitting and Prioritizing Product Backlogs with Large User Stories: A Workshop
You have a Product Backlog of large items. You wish to express these as user stories, and perhaps as some quality stories. These are large items, where one item may involve 100-500 people for over a year. It is not clear how to split these items; nor is it clear how to prioritize them. In this workshop, we will learn these skills and solve this problem.
Forensic Consulting and Expert Witness
I serve as a forensic investigator and expert witness in legal disputes involving software projects. One lawyer described my expert witness report for his client as “the best I’ve ever seen.”
Hands-on Coaching: Acceptance TDD
Your Problem: You want to not only do automated acceptance testing, you want to move to acceptance test-driven (or test-first) development. Your people need coaching in how to do this from both a process and technical perspective. Probably using ATDD tools such as Fitnesse, Robot Framework, Cucumber, or JBhehave.
I meet and explain to the Product Owner and the Teams how to schedule or do ATDD from a process perspective, and connect this to the practice of Specification by Example. And then I sit with a pair of people for 2-4 hours and show them how to do ATDD and create good tests, using your ATDD tool of choice. I rotate across all the team members and give feedback, over several days or an entire Sprint.
Hands-on Coaching: Legacy Code - Breaking Dependencies and TDD (C, C++, C#, Java, Python ...)
Your Problem: A ton of legacy code (perhaps for an embedded system) with lots of entanglements and dependencies. You want to break these dependencies, unit test the old code ("bring it under test") and also do TDD in the context of legacy code.
I sit with 2-4 programmers for 2.5 days (minimum -- usually sufficient to solve the big problems and educate the developers) and show them how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code.
Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.
Hands-on Coaching Agile Development, Agile Modeling, Design Patterns, TDD, Breaking Dependencies, and Refactoring
In this coaching/consulting engagement, I work directly with engineers (through pair programming and short technical design workshops) to show them how to do agile software development, agile modeling, test-driven development, and refactoring. And better design with appropriate use of design patterns. Usually in the context of legacy code, where there are challenges in learning how to to test the system or units in isolation. I usually do this with development groups working in C++, Java, C#, or C.
A repeating theme in this coaching is helping people learn how to break dependencies so that they can test elements in isolation.
Hands-on Coaching Agile Software Development, Breaking Dependencies, and TDD for Embedded Systems (C, C++, ...)
I have spent years working with large embedded systems (typically legacy C or C++ applications). In this coaching/consulting engagement, I work directly with engineers (through pair programming and short technical workshops) to show them how to do agile software development, test-driven development, and refactoring in the context of these domains and technologies, and in the context of lots of old legacy code that people do not think they can test in isolation.
A repeating theme in this coaching is helping people learn how to break dependencies so that they can test elements in isolation.