Tag: agile

Agile Prague Conference 2015

Agile Prague Conference 2015 – Sep 14-15, 2015 got awesome speakers for this year. We were able to get unique experts from all different areas of Agile and Scrum. We have talks on Agile Product Management, Scaling Scrum, DevOps, Test Driven Development – TDD, Behavior Driven Development – BDD, change and improvements.

This year we continue with 2 full conference days – every day we plan for 2 parallel tracks and one additional workshop/game/open space track in the afternoons at open area.

So far you can be looking forward to the following keynote speakers:

– Jurgen Appelo | selected by Inc. “100 Great Leadership Speakers for Your Next Conference”

– David Hussman | author of the Dude’s Law

– Joshua Kerievsky | protect people by engineering anzen (“safety” in Japanese) into workspaces and code bases

– Bas Vodde | creator of Large-Scale Scrum (LeSS), a framework for scaling agile development

and talks from:

– Vasco Duarte | improving estimates for software with #NoEstimates

– Andrea Provaglio | speaking at AgilePrague for the 5th time

– Jutta Eckstein | enabling Agile development on the organizational level

– Senta Jakobsen | enables distributed development

– Cliff Hazell | at Spotify we aim to build shared views and models to reduce unnecessary ambiguity

– Oded Tamir | DevOps is taking the Agile to the next level

– Pawel Brodzinski | the missing bit is almost never a tool or a method but sort of myth
and that’s indeed not all.

Those wonderful speakers are just beginning of our list. In addition you can be looking forward to games, workshops, case-studies, and last but not least an Open Jam session – believe it or not, for most of conference attendees the open space is the most valuable part of every conference. How it works? Bring your idea/question/theme to discuss and run a session yourselves. Or join any group where you are interested in the subject and share your experiences and hints. Or just listen. It’s an awesome opportunity to get insights from each other.

Looking forward? Have a look to Agile Prague Conference web site, full program and register now!

 

Is Product Owner part of the team?

When you ask this question in the companies, you find out that about 30% of teams believe that he or she is not. If you ask why not, you find out that they feel their Product Owners are far away from them, they don’t help them, and they don’t understand them. And I’m not talking about physical distance now. So where is the problem? In many companies, at the beginning of their Agile transformation, they simply move team to Scrum and the Product Managers to Product Owners. What happens? They don’t have a time to be Product Owners as they are responsible for several huge products. Luckily they understand the product, but they have no time to share their understanding at any higher granularity than general ideas or epics. And that’s indeed not enough. Such teams are having a Product Owner Proxy, or Tactical Product Owner who is in reality acting like real Product Owner and don’t miss their business Product Owner. Why is that usually not good? We are missing the “one PO voice” and we are losing the business driven approach in favor of technical point of view. In such environments we are as well missing the push to “maximize work not done”, which is one of the Agile Manifesto principles. That is indeed not good for either team or product.

Then we have about 50% of companies where they believe the Product Owner is part of the team, but he is not responsible for writing User Stories. Why not? Usually because he or she doesn’t understand the technical aspects, so how can he possibly do that? They usually don’t invite him or her to the retrospective either, because… well… he is a team, but retrospective is for development team only. So it’s kind of unclear.

The remaining 20% take their Product Owner as their member. They invite him to the retrospective, they trust each other. If that’s possible, they sit together. If not, they speak with each other often. Such Product Owner relationship is very helpful. Not only for your team, but the product as well.

The future of Agile and Scrum

A few weeks ago we’ve been hosting a board meeting of Agile Alliance here at Prague. And the last question at the local community event with board members was the future of Agile. You can have a look at what they said here:

I would say that I fully agree with what they said. In the future, we will not use any Agile or Scrum any more. It will be already overcome, but until that time, Agile and Scrum are the best methods we know and they are very useful. From nowadays perspective, Agile and Scrum is a Ferrari car or Lamborghini, TGV train, or an A380 airplane – depending on your preferences. Nevertheless, in the long run we would be looking at Agile as Scrum the same way as most of us feel about traveling on horse wagon. With some feeling of nostalgia, but pretty much happy it’s already gone. And the new method would have another cool name like “Queguer” or any other you can imagine and will be much better. But that’s a problem with evolution, you need many, many years to understand the backbone principles, do research, inspect, and adapt. It can’t be made faster.

I believe “Queguer” will be very much change responsive. It will be even more collaborative, going out from the specialization of an individual person to the team sharing knowhow. It will be focused on fast learning and very good at adaptation of whatever is around. But it will not be an ideal method. It will again create lot of pain while Agile teams would be passing through the “Queguer” transformation. It will not be any easy. And last but not least, sooner or later there will be another method which would overcome the “Queguer” and the evolution will continue. But until that time, let’s enjoy using Agile and Scrum.

Agile Prague Conference 2014

It’s time to invite you to the 4th year of Agile Prague Conference. . It is in September and we have wonderful speakers this year. You can have a look at the full program, but if it’s too long to read it through, here is my personal recommendation:

Linda Rising is the person I like; no matter what the topic is it’s always one of the best talks. This time she starts a conference with a keynote The Power of the Agile Mindset.
Are you bored or struggling with estimates? Then Vasco Duarte will share with you his thoughts about #NoEstimates.

This year we have several speakers talking about scaling Agile and Scrum. One of the keynotes are from Dean Leffingwell and Scaled Agile Framework (SAFe).

We have speakers talking about Agile Architecture, Kevlin Henney is having a pre-conference tutorial on that topic. We have several speakers sharing their experiences about development, testing and practical case-studies.

And last but not least, we have several short workshops in the afternoons, for example my workshop – Coaching starter for Scrum Masters, a networking party where you can discuss and meet other people and an open jam session where you can share ideas.

See more details about speakers and talks.

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 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 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.

 

Agile Adoption Story – Common Mistakes (part 3)

To continue with my agile adoption story… The company started to realize that Scrum is not any silver bullet. It’s much more complex than that. But John is really upset. He did all what he could to make it better. But maybe the people inside his company are not good enough to make it. And it’s so simple, just follow the process and keep the practices. What’s the point? But even John must admit he doesn’t know answers to all the problems his Scrum Master is putting on the table, so he finally agreed to give it a next try – let the Scrum Master to get a certification.

Let’s make a certification

So next week the Scrum Master is sent to the Certified Scrum Master Course, CSM, to become an expert. With high expectation from the training he supposed to understand all the difficulties of Scrum from that time and he should be able to adopt the Scrum methods in a way the company needs. Nonetheless in nine out of ten cases the Scrum Master understand the theoretical ideal case of Scrum implementation, get some idea of how is should be, however, when he try to apply it in the company or even change outside company environment he must admit 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.

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.

Agile Adoption Story – Common Mistakes (part 1)

Companies have different reasons to move to agile, some are good enough, and some will never work. Some believe that agile is a silver bullet so they start without understanding; with high expectation all their problems will be solved by using for example Scrum. It’s not always any idealistic dreamers, they are well educated managers, with many years of ICT experience. But they are very upset hearing they must put some effort into the system in order to get exceptional output. They have to change and change is difficult, exhausting, long-term work.

I’m not saying you saw just the following mistakes around you, but those are the most common, and to some point of view the most critical from all I’m seeing in the companies around me.

Agile is new and cool, let’s start!

First type of the problem I’m facing in the companies is someone who is very enthusiastic about agile. The person, John for instance, is not any expert on agile, has no personal experiences, no close friends or colleagues using it, but he heard somewhere that agile is more efficient and flexible. And he saw those problems on the projects. The company is struggling from poor efficiency and inflexibility already for couple years. They already tried pretty much everything. They changed the project managers, make their processes strict and well described, implemented ISO, sent some project people to do PMI certification, and still got no real improvement. And yes, last year, they changed the bonus structure and made the fix salary low and high bonuses. Still no improvement; surprisingly it’s even worth it used to be few years ago.

And then, John discovered there is agile, which is supposed solve all problems they are facing. Isn’t that great? So what shall we do? Let’s read about it and start. Agile means Scrum. And Scrum, that’s just a few practices. So let’s start using them. And make sure you don’t bother me with any real change inside our company. Keep the organization structure as it is, keep all our processes, and keep the roles. Just give the business opportunity to say what they want to and then make sure you deliver it on time. And take care you are more efficient as you were, as I’m going to compare the mandays spent.

How it usually ends? John, and everybody else, is frustrated and 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.