Show
Destroy
An entry
Get it down. Make it good. Share it.
Title
Text
One of the hardest parts about getting started with organizational transformation is Getting Started. I was working with an organization about 10,000 people in the central experience office. Where to start? This implies prioritization. <br> This implies data. <br> This implies several different types of data. <br> This implies agreement amongst stakeholders about terms and definitions. <br> This implies agreement amongst stakeholders about business value. Those are only some of the forces that exist to overcome organizational status quo. In order to begin moving, let alone create a sense of motion, movement, and momentum in an organization, actions must begin flow toward the desired state. So, in the spirit of lean (no waste) and agile (embrace uncertainty) and kaizen (continuous improvement) - we decided to start by making work visible. Making work visible is a fundamental tenet of kanban, and many of the organizational difficulties we had faced would be wholly or partially mitigated by teammates making work visible and well-defined. I encouraged individuals and teams to use a kanban tool (GitHub Projects, Trello, Asana, etc). It is clearly painful to begin. The habit of making work visible can make one feel vulnerable. Putting ideas out for others to see can be intimidating. It can reveal gaps in our thinking. Think about how many times you've spotted a typo immediately after pressing Send. Subjecting our work to others does a few key things: * builds trust through transparency * improves communication by standardizing in a few key ways, more people can stay informed and contribute; the surface area for participation is greater * reduces coordination costs that scale from the individual and team, all the way up through the organization. understand work that is being done, get a sense of where work is not moving or blocking up. Backlogs must be tended to, like a conveyor belt - it functions best when moving. #### Visible work * can be viewed * can be questioned * can be commented to * can be connected to other work * can be connected to other resources * can serve to inform and educate #### Well-defined * can be understood from the user's perspective and the business' perspective (including 3rd or more users) * can be clearly understood as to when a task is done * can be understood to advance the goals of another task * can understand the preconditions and behavior of a system/process --- ## Answer business questions What is the business looking to know? <br> Once known, what is the theory of action for making use of that information? <br> Does that projected action actually occur? On multiple occasions, I've seen organizations embark on large software projects ($500k +) (often CRMs) to enable some business development questions to be answered in an **automated** fashion. This assumes many people will magically decide to do things they didn't do before and aren't incentivized to do. The way forward here is to answer those business questions **manually** at least once, to intimately understand what is required for the answer, and moreso, to expedite learning in the organization - as to whether or not answering those business questions was an existential bottleneck in the broader value stream of "insert mandatory growth-oriented business objective here." Any process worth automating is worth doing manually, to start.
Status
idea
draft
release
personal
Series
Bitcoin
On Work
Phoenix Trello Tutorial
Civics
Re Email Address
Tags
kanban
×
agile
×
lean
×
work
×
transformation
×
GTD
×
×
+
Slug
Url
Image 1
Image 2
Image 3
Visible
Date