Here is something I wrote at my previous workplace and that I think might be worth sharing nowadays.
The team I joined last automn grew quite a bit during the last year and continues to grow; is spread across three office and work on a lot of different things at the same time. At some point of some kind of reorganization I tried to give my point of view that has been influenced a lot by my previous work experiences and the books or articles I’ve read recently.
Scrum (or agile) people like to call the stage before that agile methodology saved their company, the chaos. It’s often described as world full of cow-boys and you can even hear an Egnio Moriconne theme in the background. There is no such things in reality, I haven’t seen them. It’s usually a place with a lot of individual skills, promising projects, great ideas and where people are working hard. But it misses the corner stone, a common understandings of “what are we doing?”
or I prefer “To where are we heading?”
.
Without that, it is so easy to see misunderstandings coming in; people redoing things over and over, solving the same old issues; people no able to say no because they have the feeling to accept something that is small or maybe because they aren’t the correct person to take that decision.
It often misses some glue between people, between things. A glue that helps keeping workers together focusing on the same common goals and having a lot of fun at it. The glue isn’t any kind of bureaucracy. At least, it shouldn’t be, I don’t see how it can work better with more paper work, guidelines to follow. It can be done with more visibility. The golden rule of UCD is make things visible.
More visibility can provide easy answer to that kind of questions: Who’s working on that project? When do we expect a new release, that particular new feature or this bug fix? Is the team happy? Is the customer happy? …
Before diving into the main dish, I tried to give a definition to some terms:
- a product is the result of things you do, a product can be in development (not yet release), live (release and used with bug fixing and/or active development) or dead (removed or deprecated or not officially supported.
- a project is something in the time; it starts, lives and ends. The goal of a project is to create, improve, adapt, etc. a set of products.
- a product owner is responsible for a product, to define it, to gather the feedbacks and to define the life of a product. He deals directly with the customer and no one else does.
- a project manager is responsible for a project, focusing on what has to be delivered, what needs to be done in priority and that the project member can work, communicate together efficiently.
- a team manager is responsible for a team, focusing on the people, what they need to work correctly, to make sure they are happy in their project(s) and that they share the same knowledge.
From that, I tried to explain what I wanted to see, what I still would like to see in a future working environment.
Knowing yourself
The bigger you are the more likely you’ll need a products dashboard. Such dashboard can have information about the state of the products. Is it alive? Who’s responsible for it? Who’s working on it? When do we expect a future release? Any major known bugs? List everything, the future products like the old and dead ones.
You can also create a list of the teams, which is a view based on the people and not on the products.
Transparence matters.
Knowing your peers
Never work alone! The golden rule of agile is to be together as much as you can. It doesn’t make any sense to do team building sessions if the people aren’t working together in a daily basis.
Being transparent, communicate a lot about what you’re doing, how you’re doing it. Trying to solve problems together is a path to follow. Asking for help shouldn’t mean that you’re not responsible for the solution taken. You have the final cut.
People matters.
You’re the expert
As a developer/qa/designer/whatever, you’re the expert in your field and are responsible for doing it right. You should expect to be respected and trusted in the way you are working.
If you don’t feel that you’re good enough, ask your team manager about it and he has to get you to that level.
Quality matters.
Being involved
You should as possible be involved from the beginning of a project. Everyone that will work on a particular project one day as to be part of every communication, meeting, etc. that happen regarding that project. Take the time to do some retrospective, to get to know how things are doing for everyone.
Communication matters.
Being happy
Everything that goes well, or bad as to be said, to be heard, to be written down. Good or bad news are just news and every news are important to the team to get better as a team and for the individuals too.
You matters.
I don’t want to show rules or a way of doing things, the only goal is to show different facets, a maybe different point of view. To look at the small, the individual to see if he’s happy; to look at a project and seeing that things are doing well and to look at them from the outside where you can see similarities, obvious mistakes, redundancies. I don’t believe I can do the three of those at the same time, but it’s good to stop the clock for 5 minutes and start inspecting our environment.
The perfection doesn’t exist because there is always something to improve, don’t focus on the perfection but take that little something you can improve, and improve it. It leads to the perfection.
