Contact me: mailto:[email protected]
What to do before starting Sprint-1 for a LeSS product group? The answer is situational of course, but i can share guides and patterns to help. 0.5 - 1 day.
Go to: Story Mapping Workshop
In Lean Thinking, an important practice for both managers and lean coaches is to physically go to gemba (the place where value is hands-on added in the eyes of the paying customer, such as where developers are programming), and to start to grasp the real situation by being there and working with regular workers. This is the practice of Go See (genchi genbutsu). It is especially valuable for me to do this when I start working with a new group adopting LeSS, so that I can grasp what is truly going on at gemba... which may not be the same as what senior people believe is going on ;). I may do this by randomly pair-programming with developers, and/or do some product management activity with product managers.
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.
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?
What is the role of leadership and other managers, in a lean enterprise, or in a large-scale Scrum context? Responsibilities include:
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 improvement 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."
Scrum, and especially Large-Scale Scrum, involves a deep change in the organizational design. For example, there is no project or program manager role, no single-function or specialist groups (and thus no managers of those groups), no team lead role, no 'commitment' by R&D to complete the 'contract' of some project, no directing of development by project or R&D managers, and many more changes
In this workshop, I help the group by first analyzing and mapping out the current state of the organizational structure, and then explaining the future-state design for Large-Scale Scrum. This workshop is similar to early parts of the Organizational Change and Impediments Backlog Workshop workshop, but does not include the detailed change-action planning and Impediments Backlog creation.
Over the years, I have created, delivered, and set up teach-the-teacher large-scale education programmes involving the education of thousands of people within a few enterprises. For example, at Xerox and JPMorgan. Here is one example programme: Lean and Agile Software Development Education Programme
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
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.
(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.
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):
|Agile Release Planning Workshop||1-5|
|Initial Product Backlog Creation Workshop||1-5|
|Product Backlog Refinement (grooming) Workshop||1-2|
|Agile Modeling Design Workshop||1-5|
|Agile Architecture Documentation Workshop||1-2|
|LeSS Sprint Kickstart||5|
|TDD Bootcamp||5, 10|
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.
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.
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.
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.
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.”
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.
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-8 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.
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.
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.