RSS
formats

Agile Adoption Story – Common Mistakes (part 6)

Published on June 12, 2012 by in Agile and Lean

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.

 
Tags: , , , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
2 Comments  comments 
formats

Agile Adoption Story – Common Mistakes (part 5)

Published on June 5, 2012 by in Agile and Lean

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.

 

 

 
Tags: , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Quo vadis, Agile?

Published on May 29, 2012 by in Agile and Lean

Agile /ˈædʒaɪl/ adj. able to move quickly and easily

[My internal retrospective of the recent XP2012 conference]

Why there are so many consultants, coaches and mentors, who seem to have forgotten what agile really means. I call them the “agile purists”, people who fly around the conferences and talk a lot about following the guidelines to the last letter, using the same format of burn down charts everywhere (regardless of the actual situation) and not accepting anyone without the proper certificate. Rings the bell?

The agile purists are usually easy to recognize as they tend to use the same phrases like ‘distributed agile doesn’t work’, ‘managers are evil’, ‘if you don’t implement agile my way, you are not agile’. I even saw and heard those, who would consciously recommend that you would be better off quitting your job and entering the monastery, just because you work for a corporation and “everybody knows that these are a global evil that will never adopt agile in proper [read: their] way” … oh, wait a minute, REALLY?

What if the world has turned a bit and reality is completely different? What if you need to be able to adopt more than you used to be? What if agile in corporations in not an oxymoron?

Having worked for a corporation that decided to move to agile, I can today fearlessly state that it is possible. It “just” takes the hearts and commitment on many levels of the organization to make this change happen. It is hard, it takes time but it is possible. However you, as agile evangelist, coach, mentor or even a member of the team in a large environment, you need to be able to adopt, change and mainly: THINK. Agile at large scale is completely different than agile in a start up and who is saying the opposite, had most likely never worked in any of those two.

If you want to implement agile at a large scale, the good start is to be open minded and apply your knowledge wisely in the right moment. Beliefs that you can change the whole corporation to fit your bullet-proof-standard-agile-schema proved to be wrong most of the time. Sticking with your memorized set of best practices is no good either- at the end of the day, these are just practices that worked for one team under their particular circumstances. These practices are a good start, but need to be adopted to large scale – simple solutions may not work that easily across multiple time zones (as an example).

To start completely open-minded and be ready to adopt and change in a large corporation is a tough job. No surprise that the “agile purists” don’t even attempt to scratch the surface and rather prefer to talk routinely about the evil-corporations, who don’t understand agile at all.

We adopt agile at a large scale, no matter what they say or think. We face obstacles, solve them creatively, use agile principles described in the manifesto and we ARE agile. The million dollar question:  ARE you agile too, “purists”?

Just to finish my Bible paraphrase from the subject, I personally hope that one day agile will find its destiny and returns to its roots and true beliefs that it can help the teams and organizations become better – no matter of their size.

 
Tags: , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
2 Comments  comments 
formats

INVEST into a good Agile story

Published on May 12, 2012 by in Agile and Lean

During the various workshops and trainings somebody asks: “how do you know that story is well written and ready?”. The first reaction from other attendees in the room is usually something in the following lines: it depends on the team, their familiarity with the product, the work needed to be done as well as maturity of the product owner.

True, but what if there are some characteristics of a story, some elements that all good stories should have to survive the implementation team’s scrutiny? In our company, we tend to follow the INVEST model. As usually in the IT world, the INVEST is an acronym for:

Independent

Negotiable

Valuable

Estimable

Small

Testable

It must be noted here that this model is known across the Agile community and it is not invented by our company, we just find it very helpful and follow this simple model wherever we can. Lets have a closer look at each of the characteristics…

Independent

Ever found yourself in the backlog dependency hell, where you had high level stories (also called epics) and a bunch of interdependent stories that made the planning and estimation a complete nightmare? That’s exactly why the stories should be independent of each other as much as possible. If you have too many dependencies between the stories, try to think out of the box, regroup the stories in a different way, join them into a bigger one or slice them differently into smaller and different chunks. This effort to remove the dependencies will pay off big time, when you start the planning and estimation.

Negotiable

Users, customers and the implementation team need to be able to negotiate and agree on all details of the story. The “negotiability”of a story can be rather hard some times, especially when you work on software close to the operating system, without a UI or direct interaction with the users. It takes a lot of explanation and negotiations why exactly this story is important in the whole picture, but be ready to do that – your software is worth it.

Valuable

One of the key elements of agile is that everything you do needs to bring a value to the customers. Its good to include the value part in the story description, so agile team members who will work on the implementation actually know why it is important for the customer, what value it brings. Surprisingly, knowing “why” many times significantly influences the implementation of the story and the developers take a different approach compared to the situations, where they code “blind”.

Estimable

The team members need to be able to estimate the story, at least in ballpark numbers. If you have a nicely written story, but the team members don’t know what to do and how to implement it, such story turns out to be useless. Try to create small enough, self-contained stories that are within the domain knowledge of the implementation team.

Having worked on not so common platforms such as mainframes, missing domain and product knowledge is many times a killer of good estimation. If you work in such environment, try to find creative solutions on how to estimate, use experts, pair programming, estimate reviews or whatever will work for you in your context. Your goal is to have the stories estimable in the team that will implement it and not estimate by some external experts. If your team is missing a domain or product knowledge, help them to gain it, so they can estimate the stories themselves and be able to commit to the estimate.

Small

This aspect is closely connected to the “Independent” and “Estimable” characteristics above. Big stories are hard to estimate, increase a risk to your sprint accomplishments and you can’t really monitor the progress of the story at the burndown chart, as the story will have an effect on the line only when its complete. Again, we follow a simple rule: if the story will take more than half of a sprint to implement, its too big. Such story needs to be revisited and broken down into smaller pieces.

Testable

Finally, all stories needs to be tested before they are accepted by the product owner (of course depending on your acceptance criteria). The cross functional team needs to be able to implement, test and document the story within one sprint, so it is a good idea to include any testing consideration in the story description. The quality assurance people need to  understand how the story will be tested, what are the non-functional requirements and if there is any impact on the existing tests.

 

That’s really it. Well-written stories are the key element and a cornerstone of all successful agile implementation. Such stories will save you tremendous amount of time during the backlog grooming, planning activities and the estimation. While at the first look it seems to be an overwhelming effort to create such story, everyone will get used to it quickly and you gain a lot of time and clarity across the teams and stakeholders.

So are you ready to INVEST into your stories?

 
Tags: , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Agile Adoption Story – Common Mistakes (part 4)

Published on May 5, 2012 by in Agile and Lean

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.

 

 
Tags: , , , , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Agile Adoption Story – Common Mistakes (part 3)

Published on May 1, 2012 by in Agile and Lean

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.

 
Tags: , , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
2 Comments  comments 
formats

Agile Adoption Story – Common Mistakes (part 2)

Published on April 20, 2012 by in Agile and Lean

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.

 
Tags: , , , , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Agile Adoption Story – Common Mistakes (part 1)

Published on April 15, 2012 by in Agile and Lean

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.

 
Tags: , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Being Agile

Published on April 1, 2012 by in Agile and Lean

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.

 
Tags: , , , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
1 Comment  comments 
formats

About this blog

Published on April 1, 2012 by in About

After some time, we had decided to share our experiences and start a blog. As everything is changing, we expect the focus may change as the time goes, but for now, we try to share all we know about Agile and Lean. So stay tuned :)

 
Tags: , ,
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
© Tulming 2012