At my current client, we are trying to make a change to focus more on flow than on resource utilization. This is harder than it sounds because much of the current ways of working, structures, roles and rewards are built to support another mindset.
One of the things that lately have popped up for me are the words we are using to describe the roles we have in different parts of the organisation. This heavily prevailing in the IT-industry and maybe agile actually has helped to cement a few of these (an excellent keynote by Michael Feathers put me onto that idea).
This also ties into a great quote from David L. Marquet and his excellent Turn the Ship around book
There’s no they on Santa Fee!
Let me try to explain.
On the sub
When David Marquet was the captain on USS Santa Fee (a submarine, read the book it’s awesome) one of the things that he saw as a limiting factor was that there was a lot of complaints about what others should have done:
- we are waiting for delivery of X
- X is not done yet - not much we can do really
- This is out of our hands, loading crew should do that. They really should get going too - now we are all late.
At some point in time he got enough and just blurted out:
There’s no They on Santa Fee! You cannot use that word any more
It also happened to rhyme and stuck immediately. And the difference in taking responsibility for the whole was changed too. He relates a story shortly after where a seaman said: ‘Captain, we will be late in leaving the dock today.’. When David Marquet asked why the seaman caught himself mid-sentence:
The… … … we have not delivered the torpedoes on time
He left and started to fix the problem by reaching out to the torpedo-delivery team and offer his teams help.
In the office
There are many voices in the agile community now being raised to do away with the notion of “Projects”. As in a software development effort that we start at some point in time and then end - handing over whatever we produced to a governing organisation.
- At my current client, we are bouncing ideas about not having “Developing” and “Maintenance” as two separate roles. All we do would be “Developing”. Or “Maintenance”. Or work plain and simple.
- Still to this day I, also, hear people talking about work being handed over to “Testing”. As if the work is now someone else’s problem and that quality can be fixed, magically by testing really good. Quality is (should be) built into the product from the start.
My own personal pet-hate is the divided between “The Business” and “IT”. Here’s my understanding of the setup:
There is someone that apparently is expected to know everything that other bunch of people should do and then feed them that in bite-sized chunks. We have decided to call these people “The business”. They are doing business - that’s why we call them that. How they find time to come up with things for us to do is very hard to understand, and often they don’t have that time. We might have a “Business proxy” that translate what they need for the people that are doing it. It is something that the business need. Not the customer, but the business to business away.
Then there’s another sorry bunch of people whose brains are set in making mode. They are “IT”. They “IT” stuff. ITing away. Their customer is called “The business”. Most of the time the things we get handed is well defined because if it’s not we will have to “go back to the business” and ask for clarifications. This is troublesome for both IT and the business.
And interesting enough agile has pushed this divided from the get-go. One of the principles says Agile Manifesto ‘Business people and developers must work together daily throughout the project.’ And both Scrum and XP have roles that specifically spells out the difference between the team and the product owner and customer proxy. In all honesty, one of the values is spelling out the need for Customer collaboration. Even more, in all honesty, the agile manifesto was written in 2001 so it would be a tall order for it to keep up for that long time.
Ok … I’ve calmed down now. Rant is over. Let’s be a bit more solution focus.
What if we had “No they on Santa Fe” in our office
As you noticed above I can sometimes get worked up over these terms and even more how they are hindering us from progressing to a better future.
Let’s play a game! It’s called “You cannot use the term _” and see what happens. I have nothing particular against these words (ah … well ….) but just for fun and profit; what would happen.
Below is me playing this game on myself. What did you come up with?
| You cannot use ____ | This sentence would then | become this: |
|---|---|---|
| Maintenance | There! The development project is over now - it’s now handed over to maintenance | There! We have done features and improvement for a while, and will continue to do some more features and improvements |
| Testing | I hope they don’t find a lot of bugs in testing. The timeline is tight! | I hope we find a lot of bugs early, before working in working with code. The timeline is tight |
| The Business | The Business has called a meeting - They have decided new directions for how the product will be developed. I wonder what it can be? | We have a workshop later to decide on the future for the product. Exciting! I have a few ideas since the last couple of tests I wrote. |
| Ops | Oh Lordy… I need this out now - but the ops guys (or the devops ladies) are busy. Doh! | Oh Lordy … I need this out now. Better get going writing a deployment script myself, I guess. We are all Devops now. |
There are so many things that cast a light on the strange practice to divide our work up in phases, and even more so roles connected to that phase. I think it’s a left-over from the Taylorism-era where each task was reduced down to it’s smallest parts and then we had people executing that single task as fast as possible.
That might have been a good idea if you wanted to build many of the same (“They can get whatever car they want - as long as it is a black T-Ford”, is a famous quote)
Conclusion
I think we should continue to challenge the names that we have for roles and see what happens with how we view work then. Maybe we will learn something new
My personal favorite story came from a little gallup I ran on twitter the other week. There’s a Swedish word called “Förvaltning” that, as it is used in IT, doesn’t easily translate to English. It’s somewhere between “Maintenance” and “Governance”, but a role in singular (The Governance). I’ve met people that introduce themselves as “I’m a maintainer” (“Jag är förvaltare”).
So I asked for help to find a translation:
Jag kallar det Continous Improvement. Går hem också I stora förvaltande organisationer.
— Ingrid Domingues (@ingriddomingues) October 6, 2018
I tested this with my client and they jumped on it right away. I suggested that we would change the name to “Förbättring” (Improvement). So far it’s just done informally but I wanted to leave you with a few conversations that be flying around the office that shows the strangeness in having Förvaltning (or developing of course) as a separate role and phase.
1: Ok, the development project is soon done, so the system will soon go into … Improvement
2: Improvement?! What did you do in the project then?
Item 36, that is an … improvement-task. Hey?! What are these other tasks? Are we not all doing improvements all along?
Well, soon our budget for … improvement is just about over. I guess that we should stop improving then?