In reading Dave Snowden's article on a sense of direction, I was reminded of my experience several years ago working as a Patient Care Tech at UAB. I had started volunteering there and then took a part time job to gain some clinical exposure and decide if I wanted to make a career change into nursing - turned out I did not.
Anyway, I worked in the Emergency dept. which was a level one trauma unit. A trauma call is a complex thing. Injuries are often hidden and severity can vary wildly even with patients that present with similar injuries and histories.
There are some basics of course. Airway, Breathing, Circulation - if you don't get those right it does not matter how well you set the bones or if you stitched up the cuts in a way the won't leave a scar.
There are some corollaries in the world of Agile. They could be Build, Test, Deploy - if you can't build, without breaking stuff, and deploy it for use - the color selection and button placement don't matter. Like, at all.
After a patient is breathing reasonably and holding their blood in, a team can worry about things like blood chemistry, organ and brain injuries, broken bones and abrasions.
Similarly, when a team can routinely and safely deliver software for production use, they can start worrying about what features to deliver, in what order and how to manage that work.
Scaling the management framework might be kinda like taking up a new hobby after a full recovery.
Monday, January 15, 2018
Friday, January 12, 2018
My guideposts
When I talk about Organizational Transformations or Agile Transformations, I am talking about the engagements as I usually see them. Some company - often a market share leader in their industry - wants to be more like what they imagine Google, or Facebook to be. They talk to their consulting supplier of choice or maybe several and decide on a framework to become Agile and awesome.
By the time I come along, there's usually a project plan - sometimes disguised as a backlog - that includes milestones and payment triggers etc. There will be planning meetings and a sorting of the workers to become agile teams of one type or another, decisions about whether a particular function should use scrum or kanban, whether we should use Jira or Rally, how many columns to represent todo, doing, done etc.
What's often missing is the universal understanding of why we're doing this and what we hope to accomplish. This often leads to dark scrum and a general sense that the people in charge and the consultants they've hired are full of shit.
I assume the point of these engagements is to become capable, high performing, learning organizations that delight customers and take all the market share from their lesser competitors. The goal of the exercise is not to become good at performing the ceremonies and practices of any framework or method - methods and practices are probably necessary, but are not sufficient.
Here are some things that I think are important:
Thanks for reading - Mike
By the time I come along, there's usually a project plan - sometimes disguised as a backlog - that includes milestones and payment triggers etc. There will be planning meetings and a sorting of the workers to become agile teams of one type or another, decisions about whether a particular function should use scrum or kanban, whether we should use Jira or Rally, how many columns to represent todo, doing, done etc.
What's often missing is the universal understanding of why we're doing this and what we hope to accomplish. This often leads to dark scrum and a general sense that the people in charge and the consultants they've hired are full of shit.
I assume the point of these engagements is to become capable, high performing, learning organizations that delight customers and take all the market share from their lesser competitors. The goal of the exercise is not to become good at performing the ceremonies and practices of any framework or method - methods and practices are probably necessary, but are not sufficient.
Here are some things that I think are important:
- Increase capacity/capture value everyday - any day might be the last day for the project.
- We should never be one-deep in a skill or position - people should be able to go on vacation or take a promotion without leaving a gaping hole.
- We must be able to make a simple software change to production in one day - shorter is better.
- Teams must be capable of independent action - if three teams are required to make a change to your three tier app, you gotta fix that.
- Teams have discretion and authority for their work - keep friction and approval processes down
- No out-of-band reporting - the natural by-products of the activity must tell the story.
- You must always know what your apps are doing - I never want to learn from a customer call or twitter that our website acting weird - same for internal apps.
- Every component or activity must fight for it's life - extra is extra if it's dumb get rid of it.
- We should always minimize complexity where we can - Keep your stack short.
- No resume driven development - we'll make time for learning and playing.
- Keep up with the tech - play with the cool stuff enough to know if/when to adopt it.
- Working here should make you more marketable - learn and grow, I'll help.
- Behave - nobody wants to work with a jerk and they don't have to.
- It's not OK to suck - if what we do sucks, we have to fix that.
Thanks for reading - Mike
Thursday, January 11, 2018
More thoughts on Organizational Transformation
My post yesterday generated some good criticism and discussion on Twitter. One of the common misunderstandings was the idea that I advocate the cascading of explicit goals down the organization.
This is exactly what I was trying to avoid. I am questioning now my proficiency in the language...
Anyway, when I said goals at each level inform the goals at the next next level, I created confusion. I'll try to clear things up a bit with some examples below.
I might have a goal (desired outcome) of reducing the company's travel spend by 50%. If I think I have all the answers, I could ban all travel for a period of time or create an onerous approval process. Both options that reveal my lack of regard for others in the organization and my arrogance.
Alternatively I could broadcast the goal - we need to spend half as much on travel - and some visibility into current spend vs. the baseline. After that I would leave it to those spending the money to figure out how to reach the target. They might prioritize travel, book flights earlier, use AirBnB instead of the W - lot's of options for most companies to spend less especially in the short term.
I have a goal that I want a simple software change to go from identified by the business to safely in production in half the time it takes today. I could specify Scrum, require unit test coverage, and demand a CI/CD pipeline - or - I could broadcast the goal and let the people closest to the work decide how best to reach it.
There might still be problems with this approach and it may be useful only in an ordered system - but I want to at least dispel the idea that I advocate passing detailed requirements or squishy objectives down through the layers of an organization.
What I want to do is increase the amount of information about organizational direction while also increasing self-organization and autonomy.
Goals or vector signalling will be vague and often frustrating for the people doing the work - that lack of detail coupled with a measurable outcome leaves room for creativity and discovery.
Thanks for reading - Mike
This is exactly what I was trying to avoid. I am questioning now my proficiency in the language...
Anyway, when I said goals at each level inform the goals at the next next level, I created confusion. I'll try to clear things up a bit with some examples below.
I might have a goal (desired outcome) of reducing the company's travel spend by 50%. If I think I have all the answers, I could ban all travel for a period of time or create an onerous approval process. Both options that reveal my lack of regard for others in the organization and my arrogance.
Alternatively I could broadcast the goal - we need to spend half as much on travel - and some visibility into current spend vs. the baseline. After that I would leave it to those spending the money to figure out how to reach the target. They might prioritize travel, book flights earlier, use AirBnB instead of the W - lot's of options for most companies to spend less especially in the short term.
I have a goal that I want a simple software change to go from identified by the business to safely in production in half the time it takes today. I could specify Scrum, require unit test coverage, and demand a CI/CD pipeline - or - I could broadcast the goal and let the people closest to the work decide how best to reach it.
There might still be problems with this approach and it may be useful only in an ordered system - but I want to at least dispel the idea that I advocate passing detailed requirements or squishy objectives down through the layers of an organization.
What I want to do is increase the amount of information about organizational direction while also increasing self-organization and autonomy.
Goals or vector signalling will be vague and often frustrating for the people doing the work - that lack of detail coupled with a measurable outcome leaves room for creativity and discovery.
Thanks for reading - Mike
Wednesday, January 10, 2018
Thoughts on Organizational Transformation
My current thoughts on Organizational Transformation wherein I propose a simple repeating pattern of self-organized, autonomous, independent teams at every level of the enterprise under change.
We’ll start with some definitions to aid in subsequent discussion:
Before starting any transformation it’s very important to understand and articulate the desired outcomes of the effort.
Because so many of these engagements are IT driven I’ll use a IT example:
With a clear goal in mind we can bring together the team to determine:
The services and capabilities listed at each level in the organization are usually decomposed at the next level down until they are actually implemented.
This provides alignment from the top level transformation goal, through the intermediate goals of each department all the way to the individual contributor executing a task.
Team members at one level are likely to support a team at the next level. So a VP on the CTO’s team at the IT department level has a team of directors and managers that decompose an IT function such as security or cloud infrastructure into smaller pieces for their teams to implement.
Each team, regardless of level, is self organizing, autonomous, and as independent as possible. They are also intensely customer focused whether their customer is another team using their product, a business function requesting new or changed software, or a Director trying to understand and align with executive guidance.
Thanks for reading - Mike
We’ll start with some definitions to aid in subsequent discussion:
- Team - any group of people working together toward a goal or set of goals
- Goal - a desired, measurable outcome resulting from the work of a team or teams
- Product - a tangible artifact produced by a team to be used by consumers
- Service - a process carried out by a team at the request of a consumer
- Consumer - a person or team that uses products and/or services
- Outcome - Movement in a business metric or situation
Before starting any transformation it’s very important to understand and articulate the desired outcomes of the effort.
Because so many of these engagements are IT driven I’ll use a IT example:
- Enterprise X wants to compete and win in our industry.
- IT strives to eliminate friction for product teams using IT so they can quickly, safely and economically design, develop and support business capabilities through changes to existing systems and creation of new systems.
- Marketing will improve on our our ability to...
- HR must make it easy for...
With a clear goal in mind we can bring together the team to determine:
- What services and capabilities to provide?
- What activities to continue or start?
- What activities to stop doing?
- Who are our customers?
- How will we measure the outcome?
The services and capabilities listed at each level in the organization are usually decomposed at the next level down until they are actually implemented.
This provides alignment from the top level transformation goal, through the intermediate goals of each department all the way to the individual contributor executing a task.
Team members at one level are likely to support a team at the next level. So a VP on the CTO’s team at the IT department level has a team of directors and managers that decompose an IT function such as security or cloud infrastructure into smaller pieces for their teams to implement.
Each team, regardless of level, is self organizing, autonomous, and as independent as possible. They are also intensely customer focused whether their customer is another team using their product, a business function requesting new or changed software, or a Director trying to understand and align with executive guidance.
Thanks for reading - Mike
Subscribe to:
Posts (Atom)
