Tag: team

Over self-organized teams

Self organization is one of the key agile artefacts. It’s all about self-organization we tend to say. The team should decide. The idea is great. It says that people who are doing the work can solve 80% of their problems themselves. It also implies that the team itself in it’s mature stage can freely decide on their internal processes, meaning how they organize themselves to atchieve the given goal. There is nothing said about changing the goal, not even about changing the external arrangements (i.e. roles and responsibilities of people outside of the team). The self organization is supposed to come with responsibility in hand. It cannot exists without it. And it’s not any easy task. 

But every good idea can be misused and so more and more often we are observing over self organized teams who just don’t get it. Such team believes they can decide on anything you can imagine, the managers should not interfere, they are useless and not allowed to visit or even observe team meetings. They are redundant to their opinion. The same usually happen to the Product Owners who are surprisingly not anymore the ones who decide on priorities and functionalities. Sometimes the same happen to Scrum Mastes as well, who are for such team not any team members so they are not allowed to do anything either. Very strange situation indeed. Despite on how different such teams are, they have usually one thing in common. They believe they are doing great, but the rest of the organization should change. And becaus the “self-organization” they are trying to force them to do so. And where is the responsibility? No, no, no, it’s not ourfauls, theya re bad…

I have a couple examples. We have played our new Tulming Travel game a couple of times, and almost always someone from the team suggested they as a self organized team decide on priorities as they don’t like their Product Owner decision. And surprisingly to us, the rest of the team agree with the argument. Yes, that’s right, we are self organized so stop to tell us what shall we do. Second example is comming from real kind of startup company. We had a team of 7 developpers, one scrum master and one business & marketing team of 5 people including Product Owner doing research at markets at South America. They’ve been all located at one spot in Europe, the business team was quite matured, they know what they need and why, they’ve been willing to explain all that all over again to teh development team so they understand real customer needs. However, the team somewhere read there is a scrum and self organization and there was no force to stop them beleive they can decide on whatever. So they in the name of self organization changed basic Scrum pracsices, and pushed their business people and Product Owners away as they “don’t need” them to decide what to do. And in addition they did the same to their manager, as they are now Scrum so he is not allowed to tell them what to do anymore. There was no chance to stop them as they didn’t listen at all. They believed they are great despite they never delivered the Sprint Backlog.

The last example is from a corporation where they decide to bring fresh air into their agility. Their coaches got a generaly good idea I guess, that the managers should let the team to be self ogranized, but instead of starting at both team and management level, they pushed to the other side and forbid them to do anything with the team. They are not allowed to enter team meetings, coach, facilitate, give feedback, nothing. They are supposed to be “eavel managers” who are not capable enough to do their roles in agile world. For some it might be true, but there is huge number of others who are now struggling to do their job. And that’s not what we wanted to atchieve with self organization. We need mutual trust. Within a team, and otside i.e. to the manager as well. Otherwise there is no agile company and no self organization either. Just some group of small kids trying to shout to others without any purpose.

Agile at Saigon, Vietnam

I had an opportunity to spend some time with teams in Vietnam. Explain them Agile and implement Scrum process, bring in the understanding of it, and help them to apply it. It’s always good to travel for your work to some nice places, and Saigon is indeed very nice city. Very friendly people. How was it? Quite different. The way of explaining things needed many detail examples, however there were fewer problems with having people accept the whole idea.  The most difficult part was I guess to explain the agile mindset, implement agile culture. They always used to be organized by strict hierarchy. Who reports to whom. And now we had a cross functional teams consist of both developers and testers, so who do I report now? Who is going to assign me new tasks? And all those questions. If you for some reason put one person out of the teams as a shared resource, he immediately stop working and did just management decisions from that time. When we asked why, it’s because only the team members are here to do the work. And I’m now more important. So I don’t do any usual daily job. On the other hand, once they understood the process, they follow it. They don’t discuss if they should or not, no complains that they are corporation with specific habits so why they should change them.  Once you explain it so they understood they do their best to make it working.

Agile community

I’ve always tried to meet with local community while I’m traveling. It’s fun. They sometimes reply and you organize something together, sometimes there is no response at all. Agile Vietnam was a surprise; they have extremely active Facebook community. I’ve sent an introduction and in a few seconds I’ve got several replies. So already the first night at Saigon I’ve met with a group of people to talk about startups. Small group, not really from IT environment, but trying to learn new thinks, improve English, it was nice evening.

The next day I arrived on Barcamp. Huge event with 3500 people registered, kind of unconference where attendees are voting for presentation to be presented. I was talking about agile implementations, some British lady about bringing Broadway Theater to Saigon. You can talk about anything. Audience is deciding whether it is interesting or not.

The last event I had there for the community was free Starting Scrum workshop. One afternoon the organizers of Agile Vietnam invited everyone to Saigon Hub. And we had two hours to try basic Scrum principles. I introduced a game where the teams were building a high tower from marshmallow and spaghetti. It was fun. The very good think is the game was working well even in this different culture. They did a great job, and learned a lot about how Scrum process works with respect of the delivery of PSP at the end of every Sprint, communication to the customer, team development.

Back home

So to summarize my experiences, I would love to come back to Vietnam or another interesting country for work. It’s different, it’s fun, and it’s working. The training itself will not make any big difference to them. To change their way of working and mindset you have to be there, you have to spent time and help them understand and apply the theory. This is something which I as an agile coach can help them.

Agile Adoption Story – Common Mistakes (part 4)

But John still feels we should continue with agile adoption process started in previews articles of agile adoption story. It’s not going well so far, however, we just spent some money on training so we should give it a try. The project manager even if he is now called Scrum Master is keeping the common practices; we had still the same allocation system and organization structure. So when the Scrum Master got one-one meeting with John, he must admit Scrum process adoption has some issues ant it’s not really successful so far. But as John needs any improvement, he finally asked: “ok, so what needs to be changed in order to make Scrum working in our environment?”  And the Scrum Master selects the most crucial thing which bothered him – the allocation of the people.

Group of people makes team

Scrum is based on team cooperation and collaboration, so how should we use Scrum in the current conditions where we never know in front what time we got resources, people are allocated in front and took out of the project without any in front notice. They are sitting somewhere in the office matrix without any direct connection to the project. So let’s imagine they are just because of Scrum process moved to one shared place and from that time they are called “team”.

How this could work? Starting from the university, those highly specialized engineers were learned they are good enough to work individually on their tasks; any help offered there was called cheating. And now, they should work together? Even more in the company where were built strong silos called development department, testing department, and so on. And those silos have different managers with different goals. Those managers usually don’t like Scrum at all, as they had to delegate their responsibility and got less direct influence on the individuals.

However, the particular engineers happen to be sitting together in one room, having a Scrum Master, who is trying to sell agile to them. In a reply, he is often hearing questions like why do we have to talk so much, why should we select what are we going to finish? Just tell us what to do and keep us working. We are specialists and so we can’t lose our expertise in sharing knowhow.

So finally after some time, the Scrum Master is in John’s office saying “Agile is not for us”. We are different, we have too complex product, we are too big/small to implement agile. Our customers are like this and that, and you know, agile is great, just for a different company.

 

Being Agile

For already some time I’m struggling about the definition of agile. What is it really about? What are the key parameters and how do you recognize you are agile? I spent in agile environment more than 7 years, and had met hundreds of team. But surprisingly, that doesn’t make it any easy. Every team was different. Every team had adopted different practices, implemented different processes. Can all of them be called agile? After all, I would say yes. There are many agile ‘fanatics’ who would be saying you are not agile because for example you don’t release every sprint, have fixed price and time model or just don’t follow enough practices.

For me, agile is a culture thing, it’s about the way you are addressing things, how do you approach problems. It’s a philosophy, rather than fixed process you can just follow without understanding. You must appreciate it, and live it. Otherwise you end up blind – following some practices you’d never really understood. Agile is about team cooperation, about sharing experiences and helping each other. It’s about transparent and open communication.  Identifying problems and risks fast enough. Agile is about fast feedback loops, where you see what went well and what you can change or improve. It’s about the ability to accept change in your daily life. Don’t be complaining the world around you is changing, be a change yourself. It you succeed, you are agile, despite of what everyone else is saying.