Skip to main content

What do I think is a good way of working?


Prologue:

One of my most important roles currently at work includes responsibility on improving our ways of working. Yet when I am asked by someone on what I believe is a good way of working - I have trouble answering in a simple manner. Below is my attempt to answer it. 


What do I mean with "way of working"?

A way of working consists of at least:

  • values and beliefs: The themes that form a basis on everything else
  • practices and behaviours: What sort of high level methods create better outcomes
  • processes and routines: Actual things done by people or tools inside the system.
These together with the people on the team creates a culture that further on effects to the ways of working, which again further on to the culture. So kind of a loop where everything affects to each other. 

I have never really fully grasped the systems thinking school of thought, but I guess this is a system of a sort. Which I think also means that you can't kind of understand, evaluate or change it for the better by just looking at individual parts of it. 

How to change things

Hard to discuss about way of working, without discussing about how to change it.

I think to change a system you should first understand it. Smarter people can maybe do this with just external analysis, but for me the way to do this has always been to become part of the system. Based on my experience things rarely are as simple as they look from the outside and it can take months to get really embedded into the culture. 

After the understanding is there, you can start doing small changes to it, while evaluating if the changes are for the good or bad. Small because the bigger the change, the harder it is to evaluate what are all the actual effects of the change, and also if the change is for the good or bad.  

Also to really change anything, the people in the system need to agree on the change and the goal of the change. Or even better, let the people inside the system decide the changes. I think often an "ok" change from within results into better long-term changes than a "great" change pushed from outside.

So to summarize: continuous improvement, realizing one can never become best but always better, is a core thing in my values and beliefs.

Other core values for me are

Team work

I believe in people, and especially on people working together. So team work is a strong value, and very commonly an important aspect to drive my thought of "better". If a change increases or improves collaboration and communication - it is good. If it decreases them - bad. 

This is also based on my experience, where working together with wonderful people and in wonderful teams has shown me how excellent results can be achieved, how much you can learn, and how fun it can be to be able to work in a great team. And then also how doing big things alone does not produce similar results nor feelings. 

Ownership and shared goals

I some time ago heard a funny sum-up on often leading discussion point of board meetings and principal consultants that is: "How can we get our employees to take ownership, without giving them ownership?"

That one always makes me laugh. To say, I am not totally sure if actual ownership (as in stocks or bonuses) produces better results as I have never really experienced that. But I think it might be a simple solution to seemingly hard manager dilemma :D 

But what I do know and have experienced is that for a team to produce great results having a shared understanding of what great means for their product is very important. It affects to what goals get decided, what is built to achieve those goals, and how those things are built. It also affects to how customers are viewed by the team, and how problems for them or in production are handled. So having a shared understanding of the goals the team wants to achieve, is a crucial thing for me. Not least, because it also enables to autonomy and improves planning.

Autonomy

It is the people doing the work who know best how to get the work done. Having the freedom and responsibility to make decisions, to do the things needed to be done, to use the tools and methods best suited for the current work are all huge enablers for continuous improvement. To which it always comes down to.  


Practices and behaviours


I've experienced quite a few different methods for RnD work and naturally read of many many more. If I would have to pick one of the many out there, I would go for extreme programming. The practices it lists are quite excellent, with some adaptions and modernizations (which I think is natural as they are quite old). And a nice place to borrow some of the adaptations could be Continuous delivery which I feel in many ways is an iteration from XP, and in general just a spectacular thing.  

After experiencing several very difficult buyer - vendor projects (working on the buyer side), I also really loved the values of and practices of agile manifesto. But I would not refer to those as often as I would to the ones of XP. And I do consider the ideas around modern agile to be a big leap towards the right direction.

Scrum is a bit too descriptive to my liking, but a huge takeaway for me from it has been the value of retrospecting. Not necessarily a retrospective meeting at the end of iteration - it can be a bit more adhoc. But the process of looking back and forward and coming up with small experiments, is golden.

Kanban and kanban board, is certainly my go to tool for tracking the work that is being done. 

I also draw a lot of influence from the product management field, from practices like Impact mapping and OKRs, and people like John Cutler and Teresa Torres. 

And with my strong testing background, of course a shout out goes to exploratory testing, and Maaret Pyhäjärvi. 

These days I also think more and more about the soft skills and behaviours that enable teams to grow, the role of empathy at workplace, and about effective communication. Aki Salmi being my main inspirer to learn more on these topics. A team and team members that treat each other and their stakeholders with kindness and respect is a must have to enable trust and safety.

One specific behaviour I love to see and try to live by myself is helping others, and in general prioritising the need of a fellow team member above what ever you are working on. 

But even with mentioning all these things I think the amount of "agreed practices" should be kept to minimum. Allowing people to work the way they feel is best for that particular situation. Because people are smart, and especially when they have the shared understanding on the goals of the team - they will work it out. 

Processes and routines

Coming down to the level of processes and routines, these things are too many and too context specific to start writing down. Maybe to say in general that if those can be aligned towards the values and practices - it sounds like you are in a good path.  


Epilogue:

I really did not know what I was going to end up writing, but what I did sounds quite alike the rambling answer I usually have to the question "what do I think is a good way of working". It is still all around the place and also quite long. But I think it is continuously improving ;) 

Comments

Popular posts from this blog

Periodical retrospectives are lame

  "You got nothing, not a single thing?! Well lets just end this here then." I remember well when I said this, being very frustrated. About ten years ago I had been working as a Scrum master for a team some months, and putting quite a lot of effort into planning our scrum teams sprint retrospectives. Lot of work also because I felt we were not getting too much out from them; not very good discussions, very few actions, and even the few actions we did come up with did not stick.  And then it happened: a retro where none of the participants came up with anything to say about the sprint. Regardless of the retro topic boxes, reading of books on retrospectives, getting inspiration from tools like retromat.org, having them in different places, using all kinds of different formats and rainbow coloured post-it notes. Not a single thing. Blank.  So then I said the words, out of frustration, mainly to myself. Why couldn't I get this thing everyone is so hyped about to work? After t

I don't report bugs

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.