When workplace sucks

No wonder that big companies are proud of their workspace and show it to the world. The workplace is one of the most important reasons to join a company. Workspace might connect you with company culture, because it expresses what you do not hear from people you inhale it and it gives you a feeling that creates assumptions. But I don't want to write about culture, I want to write about workspace. I want to write about what I've seen and what I've felt in different workspace and what is important to me at the workplace.

First things first

Let people decide about their workplace and they will give it back a thousand times. Overrule people about how their workplace might look alike and you ruin your connection to them.

Walls are peoples walls and not owned by any furniture police or management. There is no room for discussion.

Pigs and chicken at work

The workplace is where the magic should happen, if you got a workplace that does not hinder you to work. Not free in decision and slaved to a workplace overcrowded and interrupted by noise, a lot of workplaces are harmful. A pattern many agile transitions are heading for is colocation. Let people sit together if they are on a team. Sure colocation is powerful, but please ask the people how they want to sit together: one room, two rooms, how many people a room, whatever. As a chicken don't overrule them and put them together like pigs in a stable. Trust the people to get the job done and tell them the constraints.

Separation, fragmentation and casual interaction

Much harm is done if you separate people on a team. If people are disconnected from each other their work interactions might suffer, and usually they will. What will definitely get lost are their casual interactions. These interactions connect them to each other and create trust. You loose a lot if you do not let colocate them. Also dispersed and distributed teams create a lot of waste. If you are able to avoid them - avoid them.

Separation is harmful, but fragmentation is even worse. Let people work on more then one project, product or whatever leads to people that are barely focused and are widely unable to work without interruptions. They are struggling all the time, because they cannot keep track of their human interactions and therefore are unable to fall in a flow state. Before they finish one thing a time somebody else is pulling them out. It is like a formula one car forever in the pit stop: a lot of power but always changing parts. This very common workplace scenario creates more waste than value.

Silence and flow state

A flow state is a state when people perform easily and without noticing effort too much. Usually it takes some time to get into a flow state and during a flow state people are really doing the work. To get into flow state you need concentration and silence, because this is usually the a precondition for concentration. If you do not know what people need, ask them and they will give you a very good suggestion about what they need to get into flow state. Be humble and support them to create a better space. Colocation also helps if you want to get into flow state: people of the same team tend to quiet down at the same time, so there is usually less interruption. Again, think about what fragmentation does. Fragmentation finally leads to no quiet time at all.

Of course and ...

For sure, what I've wrote is nothing new, but far too often overheard. Most times it is not that management is unable to adapt these sometimes new concepts, but is hard for them to forget the old ideas, like John Maynard Keynes said.

Are you stuck in defined industrial processes, lined up in dependencies while working on an undetermined goal? Do you need to try out what works and what does not because your goals are too fuzzy? Do you need to learn as you go to prove your theory with data?

In science you do experiments. This means you observe something, then you make a guess about it and formulate a hypothesis. To prove your ideas you experiment and see if you can validate your ideas - you gather data: hits and no-hits. If it sticks, you keep it - if not you formulate another hypothesis, experiment and observe the result again. It is like: "Oh, the apple falls to the ground. If I toss a stone, it will fall to the ground. Toss the stone. Yes, stone falls to ground."

So a scientific method works like this: Observation, hypothesis, experiment and back to observation - closing the cycle in iterations.

Observation

Observation is the start and endpoint of any experiment. You gather insights toward your work and the decisions which were made from the data you have collected. You measure, interview and study the work you are doing or the experiment you have done.

Hypothesis

Once you observed the environment you want to improve you assume what might be the next right step to follow. Formulate it and set it as a goal. This kind of goals are rather fuzzy than predictable. Your goal needs to be proved. So you stop talking and start doing.

Experiment

Experiments are about exploring your ideas. Nothing is perfect from the start, so you have to gather insights. You start with an idea of what the world could be and check out how wrong and right you are. Important insights are discovered after the start. Exploring is like: Build, break it, build it again and tweak it - that's the way solutions are discovered.

Iterations

Use small iterations to experiment different hypothesis. Adjust your hypothesis as soon as you got real data and reiterate to your goal. Go for fast feedback from your customers and users to generate insights.

If you are looking for this kind of approach: Agile, e. g. Scrum uses this scientific approach.

Mistrust is closing doors

Mistrust is not an option, because it does not create options, it only destroys them and narrows your decision space. On the other hand trust is key to the options behind closed doors. Trust creates options in the future which were unlikely or unattractive without trust, because it reduces complexity - says Luhmann.

This sentences hits the truth - it is worth to read it over and over.

Connecting with trust

Of course it is obvious, that if we trust we are able to decide between more paths to go - and also we might be able to go the paths which were unlikely but very attractive. Here is one small example where I had to deal with trust today:

"Today I cleaned our van - we came from holidays and had a lot of stuff in it and laid it on the floor outside. When I turned to go inside to clean something, our stuff was still laid outside. On my way inside an unknown paperboy arrived. In a fraction of a second my favorite 'door' - go inside and clean it up - was closing and I was thinking about staying outside to take care of our goods. I stopped for a moment, then I decided to trust this guy and went in."

Such kind of examples happen over and over, day after day. I think we rarely reflect them, because they seem unimportant to us, on the contrary I believe they create the baseline of our behaviour. Why not try to learn from it through reflection and not only from it because experience is connecting the right wires in our brain. If we don't recognize and handle our behaviour, it will handle us. Action and ongoing affirmation also known as experience will give us the strength to connect with trust, it should be easier if we capture the essence of what we do while being aware of it.

Reduce complexity with trust

To get things done on the job, it is important to trust other people. If you do trust others then you do not have to interfere with their work. You do not have to think about how it has to be done, what checkpoints you have to set and that you've got to control all the stuff. Trusting means you've create the option to deal with your own stuff, to create the option to get things done by others. It breaks down complexity because you do not have to think about every detail upfront and let people and yourself learn on the way. And sure, trust is the most important part about starting work.

Goals and Setting

Personally debriefing is about reflection, learning, transfer and sharing experience, for a group it is about conclusions, decisions and action.After an exercise people might reflect on their own - to support them, debrief your session and summarize what was vital to them, what they want to share or they intend to do next.

Debriefing takes some time at the end of your session, so reserve 5 to 15 minutes. How long it might take depends on the method you choose, the number of questions you ask and the amount of people who attended your session.

Questions

What to debrief is about asking questions. Before you start your session select the questions you like to ask. Here are my favorite questions:

I recommend you take 3-5 questions to ask. Questions should be chosen in context of the exercise. Chose a mixture of emotion, observation and learning. People react different on same questions. People differ in observation, emotion and conclusions might lead to further insights and confusion, which both is good soil for learning.

Methods

How to debrief is about the method you select for debriefing. Usually you should give people a short break. I like to give first individual exercise before people share with the group. These are my favorite methods for debriefing:

a) Open keyword format: ask the questions to the participants and document the answers to the questions on a flip chart. Usually people need to share their experience. A few people talk a lot, you might need to stop them. Watch for silent peoples signs that they want to contribute. You could ask them, so that it is easier for them to share.

b) Closed keyword format: prepare a starfish retrospective flip chart and use your debriefing questions instead of the starfish questions. Let people write down their experience on notes. Give them 1-2 minutes to write it down, maybe you want to limit the number of notes per question to 1 or 2. As soon as finished the first person stands up, sticks the notes to the flip chart and says one sentence about it.

c) Lighting talk: every person gets 1-2 minutes to talk about their experience. Provide the questions before they start and give them a short break before you start to reflect.

A few words

People might be disappointed if they are unable to share their experiences, so close the topics you've started. Debriefing is all about learning opportunities, so take it serious.

A common question about definition of done is - "When should we do which activity?" A definition of done is usually about:

Done when the story is done

Done when the sprint is done

Done when the release is done

Usually you should strive to be done as soon as possible with the most activities, so do the most stuff at story level except there is a reason not do. Here are several why you might scale your activity from story level to sprint or even release level.

Transaction costs, synergy or no demand

The result of adjusting focal distance while taking the picture. By B166ER at the German language Wikipedia GFDL or CC-BY-SA-3.0, via Wikimedia Commons

Some activities should be done for all stories and it is cheaper to execute them together, usually activities for non functional requirements fit here. Take for example performance testing or testing with data from live systems. If you do it once a sprint it might be enough. Moreover, there are different opinions about how much e. g. security is required per story, this happens per stakeholder. Sometimes there might be no demand to do the activity per story.

Minimum viable product and experiment

Sometimes you want to experiment functionality. You develop it without making things nice and layout it the way it fits into the GUI design. This approach is fairly okay, because you want feedback, you wanted to test your idea. This is often when you go for a minimum valuable product. You might run a few sprints with making it run and before the release, after you said - "this is it" - you make it nice and fast.

Low performance, too many restrictions or impatient stakeholders or customers

If you spent too much time with developing one story and you cannot get enough features done. Then you might suspend some activities for later. This is also recommendable if you've got impatient stakeholders or customers. Show that it works and then make it nice and fast.

Enterprise, you want to go agile - sure you want?

If you honestly do so, ask yourself, as somebody in charge, the question: "Can we handle the effects of transparency?"

Then split the we and insert instead:

Management, people and culture

The effects of transparency spread wide but are deeply routed in your corporate culture. It is about how you deal with problems: Will you welcome them, will you deny them or even worse will you surrender saying: "That is like the way it works - accept it."

Furthermore it is about how long will it take to solve problems and when does frustration start how will your people deal with it? Key question still is: will you be able to learn how to improve fast enough, before your system gets to annoyed of transparency?

Some questions to sting yourself

The unsolvable problems will be addressed - will you spend the time and effort in making the impossible possible?

Will you take every problem serious that will be addressed?

How patient is the culture of your organisation?

How long will people wait before they get annoyed by all the problems perceivable?

What if your people are stuck, will they solve problems on their own?

What if people are stuck and get frustrated about the amount of problems every day?

What if your people fear or realize that they archive too little?

How will your culture handle and react when problems are addressed?

How will you react if people are part of the problem?

What if you as a manager are part of the problem?

Are your people comfortable being naked in business?

There is a lot more to ask, but if you do feel uncomfortable with this rethink your intend about an agile transition. If you do say, transparency is no problem at all, then you might have a great organisation or you've lost touch with the culture of your organisation.

The only thing I can highly recommend is: Go to the people who work, get firsthand awareness about how work is really done, ask for the problems and get a keen appreciation about improvements. Be humble and help them!

Some time ago I've read lamentations about story readiness and why is it bad because of it is destroying the intent of user stories. First I was amused, later on I was afraid that people will take this for sure. I do recognize that there is truth in this post, so far that people still miss using conversation - direct face to face conversation - and sometimes the concept of story readyness is taken for specifying user stories too far in advance and detail. Let me revisit this statement later on.

What is story readiness?

Story readiness is an artefact of the team. It is a contract and a visualisation about the what the team needs before starting in order to deliver working software within a sprint. First of all it is an activity: The team decides what parts are essential to work before starting it: "what should we collect to work on stories in a flow state, okay let's write it down." Now the teams knows the important parts to collect within their environment and this is the most important part of it - knowledge and visualisation as baseline for improvement. Using this artefact and sharing it with the other stakeholders is an act of fairness: We show you what we need to start (sure not everybody is interested in, but this is not the point).

Now we've made the rules and circumstances explicit, we know as a team what to ask, what is important to us, what are the cornerstones we have to get clear. The performance of any team is in exponentially proportional dependency to the state of the work you start and you should start the ready work. Using story readiness as a contract between product owner and team means you declare a last line of defence to deny work wich is not ready for development.

Revisiting it

The intent of a user story is face to face conversation about the why, the whereof the story. Story readiness deals with what should we talk aboutto get the story ready, what has to be in place, so that you can start. If you do not know what you need to talk about, the conversation might get cumbersome. As said an user story conversation is about the value the story should provide and a discussion about different ways of implementation the function part. Even if this happend perfectly, the team is all fine with the intention of the user story, defined functionality and everything they need to get the story done. What if the parts the team needs from outside of their circle won't be delivered in time? What if the last line of defence is breached, because the team took unready work into a sprint and is blocked - well you had a nice conversation, but still important stuff is missing and work won't get done.

A definition of ready is a tool to be used. For sure teams with a classic requirement engineering background tend to do much requirement engineering in advance than agile style, this might lead to waste, but not definitely. Sure a team might not feel responsible for making the work ready, then you might use the readiness to check what the team thinks it can contribute and work on the items which they do not consider under their influence. As a scrum master you got a nice tool to show your team and management where improvements can happen.

Still you as a team are responsible to get the work ready, you might use the story readiness as a contribution to your last line of defence, to deny work which is not ready for implementation and tends to block your delivery within your sprint.

The definition

A definition of ready is used to produce story readiness. A story which is ready for development needs to meet criteria. Thus criteria defined is required to accomplish a story. The definition of ready is an activity of the development team to state everything what's required before development begins. It is also a contract between development team, product owner and stakeholders. A development team has to contribute that the criteria is meet as far as possible. If criteria is missing from stakeholders or product owner the team should deny to start the work or close the gaps with own decisions and suggestions. The definition of ready is a tool to make explicit and transparent what is needed to start a story and can be used for developers as last line of defence.

The sprint

The goal of a sprint is to deliver working software in the state of done. The delivery is called potential shippable product increment also known as usable software ready for installation.

The battleground

To deliver a full working software due to your definition of done there are preconditions to be met before you can start your work. E. g. you might need several documents in advance like text, math and formulas, design and so on. On the other hand you as a development team need to specify which criteria has to be met to validate that you build the right software.

The battle and the sword

In order to complete a story within a sprint every part of the story must be delivered in time, otherwise the team might be wasting time with waiting during a sprint, will not deliver or will have to adjust the delivery later on. Furthermore, to avoid waste of specifying stories too early the timeframe of making work ready is set very close to development. To dissolve those contrary interests - that is the battle. Like in a shield wall you have to push forward and should not loose ground.

Cutting through dependencies in a tight schedule between preparing the work and implementing it is tough. On the one side you shield yourself against getting blocked and deny work which is not ready for action, on the other side you have to contribute to get the work ready and must be aware what is required to start. Both sides are the cutting edges of your sword.

There is often the question: Different projects in a sprint - does it work? The answer is either yes or no!

Yes, it works

When you use sprints, you might use Scrum. Scrum is a framework. You take it and put the work in that frame a sprint is offering you. Once your work is in that frame, you can work on it, no matter if it you are delivering for one project or serveral. You might loose focus because the projects are tearing you apart, but as long as you are able to stabilise the priority of you work during your iteration there is chance to succeed. And you still got a ScrumMaster to support you.

No, it does not work

It will not work, if you do not put all of your work into that frame. Leaving work out of your sprint will lead to distraction and waste. Usually while there is work happening outside that is pulling your attention, this work is not weighted against the work in your sprint. There will be waste through discussions about priority and unfinished work to resume. On the other hand when there is to much ad-hoc work you will run into trouble too. Ad-hoc work is similar to work which is not framed - and yet a little bit different. A sprint is also under policy: do not disturb the people working. If your workplace produces too much ad-hoc work the process you've selected will be under constant need of maintainance, so the system will need other desire paths than your process might provide, unable to heal itself.

There is still hope

You can learn about your environment and work situation. Just make your work visible, put your work on a taskboard and follow its flow from introduction to done. Visualize the problems and impediments you encounter and improve around all mistakes that happen. It might be a hard road and it is worth it. Usually this is true: "Only what is visible can be improved."

Different projects in a sprint - it's like juggling with knives, it might work or it might hurt...

A self healing system

We are good at setting standards, but do we take them as a baseline for improvement or do we end up in bureaucracy? Standardization means automation. We take our insights and wire them to procedures. Step 1 followed by step 2 in exactly the order we prescribed: entirely deterministic, but perfect?

What about when we are all wrong? What about if we build up a wrong standard? Good for us, but useless for our customers? What if they desire another path, perfectly sane, but our system does not provide it? Should we keep it with: "We are sorry, this action is not provided"?

Parks in Finland

In Finland, planners are known to visit their parks immediately after the first snowfall, when the existing paths are not visible. People naturally choose desire lines, which are then clearly indicated by their footprints and can be used to guide the routing of new purpose built paths. (Desire path, Wikipedia, 19th of June 2013)

A desire path (right) merges with a footpath (center) in Helsinki, Finland (Wikipedia)

Wrong standards are business bugs. Get over it! They do not meet customer needs, instead they show an opportunity to learn or worse - your ignorance.

So what to do now?

Automate less complex

Da Vinci said: "Simplicity is the ultimate form of sophistication." So if you automate a process, simplify it first. Do not blindly automate everything, question it. Prefer an simple implementation over one with lots of different scenarios. A simple scenario can go for itself - they can be healed, complex scenarios tend to be waste and difficult to use and exclude everything which was not considered by its builders.

Reconsider automation of systems with a lot of ad-hoc-racy. Determinism might lead to a lot of maintainance of the automation you want to provide.

Learn from existing data

You always got data - learn from it. Have a look at which way data is used, what behaviour is associated to it? What does surprise you while looking at it? What is fascinating? What interesting? Learn from the real world. Iterate, prototype, gather feedback from customers. You got no contact to them - step out of the door, insights are waiting:

"You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to." (Lord of the rings, Tolkien)

Ask your frontline staff

Whenever you have touchpoints within your service, you will have frontline staff who is in close contact with customers. These people know the paths who are unable to go and cannot be healed within the system.

How to enter a development bastion?

Still teams get stucked because the requirements they work on are not ready for development, because questions have not been asked, key questions not been answered, stakeholders not involved and the most ugly part: decisions not been made. So a lot of teams have to start with rather poor sprint backlogs.

To be productive and have fun with your work, you want no distraction from you work. You usually don't like to be blocked because of poor decisions or no decisions at all. As a developer you are standing in the last line of defence, because if nobody decides, you will make the decisions.

"In a fortification with bastions, the citadel is the strongest part of the system, sometimes well inside the outer walls and bastions, but often forming part of the outer wall for the sake of economy. It is positioned to be the last line of defence should the enemy breach the other components of the fortification system." (Wikipedia)

In the shield wall

Ivar’s shield wall had held, but I could well imagine the ferocity of that battle.

— The Burning Land, Bernhard Cornwell

Standing there in the last line of defence you as a developer take it as a bastion to defend your sprint from distraction and blockades. Ask questions, demand decisions, make decisions, share your insights and if planned work is poor, then reject unclear requirements or stories.

Sprint planning is a tool to be used. On the one hand it is about telling stories to get a common picture or to plan your collaboration, on the other hand you might use it as a shield to protect your performance. If you use sprint planning als shield and sword, then you show that there is a responsibility about making work ready. Remember you are involved in making work ready and you have to play your part.

You might try to add some components right in front your last line of defence:

Try to get stories small, because small stories are easier to understand.

Get stories ready for development for about 1 or 3 weeks before a sprint.

Use estimation or grooming sessions to ask key questions. Remind people about your questions constantly (as a scrum master, be a mosquito).

Make teams cross-functional or involve the people who can provide information.

Write down the essential parts of your stories which need to be solved before (make it explicit and visible). This might result in a definition of ready.

Reject stories in the sprint planning, to show that essential parts of your stories are missing (do that in a responsible manner).

Visualize at a wall which stories are ready for development. A product owner might suggest, but the team decides.