Tag: process

Scrum Transformation Journey

As one of the CSTs – Certified Scrum Trainers – I’ve got a unique opportunity to travel around the world during the last two years and teach Scrum at a variety of businesses, organizational environments, and very different cultures. I must admit that Scrum is awesome as it is universal. You can apply it to software, hardware, marketing, HR, executive teams and be rapidly successful, significantly better, change the way of work and become the best of the greatest. The flip side of the coin is, that despite the easy way how Scrum is defined, there are still companies, teams and individuals completely failing to understand what Scrum is and therefore failing to implement it.

I draw this picture to illustrate that becoming Scrum is a journey. You can’t just do Scrum, you have to embrace it. You have to become Scrum yourself first. It’s often not that straightforward as we’ve been got used to the traditional processes throughout the history, but at the same time, this is the very best strength of Scrum. Once you master it, it becomes the part of your life. It’s not just a process, it is a way of living.

Scrum Transformation

 

Technical Scrum

First, let me say explicitly that “Technical Scrum” is not Scrum. It only pretends to be Scrum. It’s a camouflage. However, it might be the necessary first step in certain organizations to move to the real Scrum. How do you recognize Technical Scrum? People “do” Scrum. They are looking for ways how to remain the same as they used to be. They are eager to get checklists of practices which need to be done, in order to do proper Scrum. Therefore Technical Scrum is all about estimations techniques, burn-downs, measuring velocity. The very important metric would be individual utilization, so they usually insist on time task estimates, capacity calculations, and time-sheets to be filled. They have identified new roles, but in reality, they just renamed the traditional roles and didn’t change the behavior. Scrum meetings are usually long and felt redundant. Managers use Scrum to micromanage.  The overall team focus is on “how”. The team is not any team but a group of individuals working on similar items. The individual accountability matters. They are looking how to split responsibilities instead of how to collaborate to achieve the goal. Product Backlog is usually a to-do list where most things have to be done.

Scrum Mindset

In the real Scrum, your team understands the mindset and they are “living” Scrum. They take it as the way how to focus on customers, how to innovate, how to collaborate. The estimates, efficiency, and utilization become quite unimportant, as they focus on delivering value to the customer and overall long term results. The first step here is usually “Team Scrum” where the development team becomes a real self-organized and cross-functional team which works together. The team creation process produces a huge trust internally among the team members but also externally to the organization. It’s the first tiny ‘snowball’ which afterward starts the whole transformation and creates forces to change how we run our business and how the organization itself is structured.

The “Organizational Scrum” builds on top of the values we experienced at team level – openness, transparency, and trust which leads the organization to be more business driven, flexible, and open to innovations. The business slowly starts to be picking up and the organization has to follow the rest. At this time, the snowball is big enough to attract the rest of the organization. At that time, you are truly Agile.

Such transformation can take years. It’s not uncommon that companies are falling back and restarting the whole initiative again. It’s hard. To succeed you need a good reason for change and courage. Eventually, every company has to change as the word is getting more complex and fast. The same way as industry revolution changed the way we were hundred years ago, the complexity of our current life is changing us now. To succeed in a long term, we have to be more flexible and dynamic – more Agile.

APPENDIX: Top Agile Experts

(as many people ask about who to hire for agile transformation and the quality of Agile Coaches, here is a short paragraph about this)

There are generally two groups of experts in the Agile world. Trainers and Coaches. Each group focus on the same field but from a different angle. The most recognized are Certified Scrum Trainers® (CST) and Certified Enterprise Coaches (CEC) both linked with Scrum Alliance. Both groups represented top world experts which are proved by highly prestige certifications issued by Scrum Alliance.

The CST – Certified Scrum Trainers deliver the certification training such as CSM – Certified ScrumMaster, CSPO – Certified Scrum Product Owners to name at least two most well-known certifications. They are experts on agile transformation, and very often they are experienced coaches.

If you are looking for a Certified Agile Coach (CAC), make sure you are looking at the Scrum Alliance CEC and CTC’s which are the second group of agile experts. Together with CSTs mentioned before, Certified Enterprise Coaches – CECs are a great help for your organization on your Agile transformation journey while the CTCs – Certified Team Coaches are a great help at the team level. They are all top-notch experts with deep Agile and coaching experience. The ScrumAllinace’s key mission is sustainable agility and keeping the quality bar high is one of the most important aspects they take care about. Any of the above certifications (CST, CEC, CTC) are the great choice for your agile transformation.

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 6)

And finally, to finish the agile adoption story, even though the team is after all able to find their way to communicate, share knowhow, learn from each other, and cooperate, there is another obstacle. Surprisingly it’s not outside the company but in the business unit internally.

Company doesn’t need to change

The company doesn’t need any change. It used to be working good for many years, and if we had observed any problems, they were indeed located in the ICT, so why should we change the business unit? Isn’t Scrum called software development methodology?

Oh, yes, Scrum is business driven, but here are the requirements, so take them as they are and if you need to make any User Stories out of them, sure, feel free to do it. But we are not really interested in your internal processes so don’t bother us. However, we expect you to finish all this work on time.

So the teams are desperate again. Unless they got Product Owner, who is willing to become part of their team, and share the risk and success with them, they can’t proceed with real Scrum. They can’t take all responsibility and gain success in return.

Unfortunately, some get frustrated from the lack of business support and still complaining “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.

Agile Adoption Story – Common Mistakes (part 5)

So what happened next in the agile adoption story? John starts to be really frustrated. Is all agile just a rumor? Or did we make any fundamental mistake?

It’s just a process, follow it!

So he went to the team, be really strong and say “It’s just a process so follow it”. They were weak in following the practices; they abandon most of the particular practices. So somewhere there must have been the problem. If most of the companies reporting agile works great, why agile shouldn’t work for us.  That’s because they are still complaining, asking for some change… They have a team fully allocated team now as they requested, so what would they need next? Let’s make a brainstorming in our management group and find out how the individual practices are supposed to be implemented. Then use them and make sure they are not adopting them according to their preferences. Let’s make sure Scrum Master controls all the activities, is strong enough and able to decide instead of the weak team. Let’s make him personally responsible for the team ability to deliver, quality and overall team health. We can put it into his KPIs.

However, the given process, regardless how good it was invented, could not ever bring any commitment, understanding and responsibility. The people just pretending they are following it and keep finding some sideways and complains. Finally, when you asked them, they keep 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.

 

 

Agile Adoption Story – Common Mistakes (part 2)

To continue with the agile adoption story…  John is sitting in his office, waiting for the measurements and results and looking forward to the great results of the new process called Scrum.

We can use just a few practices

But what happen in the team meanwhile. They started to read all the books and blogs, get known some theory. And get a few practices to follow: Standup meeting, Product Backlog, Sprint Backlog, Customer Demo, Retrospective, User Stories,… but what actually happen. The retrospective didn’t seem useful enough to be made part of their process as they know each other well and even if they have some problem they feel they are solving it right away. And, more than that, they have the lessons learnt. No one is learning from those, but they still believe they are useful. So why should they do any retrospective, right?

Making a Product Backlog is a strange thing as well, as the business people don’t have any time they can ever spent on such activity, their only concern is to get all they want to as fast as possible without the necessity to described it well in front. They are quite happy to hear the team is making a commitment and deliver all they promised on time. As a result of that, team is not willing to take any responsibility and prefer the technical tasks instead of user stories.

So finally Standup is the only one practice which preserved in the team. They meet every day, talking about what they had been doing, who they had been talking, but usually missing any day commitment and description of any finished work.  As they don’t understand the reason of the followed Scrum practices, they don’t like them and felt the time is spent completely pointless. “The Scrum is just about meetings, we should better work than follow those useless practices“.

As the time goes, they abandoned most of the practices, but still they have those huge expectations of high efficiency, flexibility, improved customer satisfaction and team health. But apparently, no one of those can be seen within a team.

Finally, when John asked how the Scrum goes, he is surprised to hear that “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.