Author: Zuzi Sochova

Measurements are dead, let’s measure

During my career as both Director of Engineering and independent Agile Coach, I’ve been hearing still the same grumble from managers: “We can’t get rid of measurements and KPI’s. How else could we know if the person is performing well, how can we compare people?” and at the same time, grouching from the team members: “We don’t like the individual based KPI’s and measurements, how are we supposed to be a good team when our managers can misuse that against any team member?” It’s surprising but no one likes individual metrics, they all admit they are useless, but they are all afraid to try anything else.

So if you have a bit of courage, you may try this: It’s based on coaching relative scale and is team oriented: 1 stands for 🙁 and 9 stands for 🙂 and it’s great if you add a reason for rating lower than 4 and higher that 6. Firstly, let the Product Owner give a team his number how he is happy with the team.

As a second input, ask Scrum Master to give a number to every team member how much he is happy with this person as a team player. Let them discuss it, but make sure the discussion is not about “why I’ve got 5 instead of 7”, but is focused on future development of that person discussion “what should I do differently so that I’ll get 7 next time”.

And last number goes from the team members. The best you can do for this part is to ask everyone to divide 100$ to all team members except himself. You may worry that they can agree with each other and rotate all the money one by one, or distribute them equally, but that’s not common in real life. The great think on this evaluation is that the team members are giving a feedback to themselves. So every team member gets an answer to the question how do you value my contribution to the team? And if you find out the other team members don’t see any value in your work, you would most likely be very much concerned about that situation and asking how can I do differently so that you value my work more.

Combining those three inputs you will learn much more than from traditional metrics, regardless the company size and culture. It’s working just awesome, but you have to have courage to give it a try.

And when this is just normal for you, you can take it one step ahead. The fully Agile companies are using such tool as the only one appraisal tool across the company. No other bonuses than those distributed by employees to the other employees. So in such company, if you feel you would like to appreciate the receptionist, give her some part of your bonus sum. The other one can be for your colleague, another part for a developer from a different team who helped you with some issue. And when you are afraid it’s too crazy for you, I would like to remind you that we are only talking about bonus distribution, not the whole salary. When you do so, you will increase team cooperation over individual heroes work, and openness and transparency over politics and gossiping. And it would be fun. If you still don’t know, start with Appreciation cards. Make them available and encourage people to give them to each other. Even by that you will learn a lot about yourself, your team and the whole organization ecosystem.

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.

Product Owner Development Model

What is the difference between requirements, use-cases and User Stories? I’ve been struggling with that question a lot. On one hand it is easy. It’s something completely different. On the other hand, that’s not anything which would help people to understand the difference on their way to implement Agile.
After some time working as Agile Coach, I created this Product Owner development model. It’s focused on product creation and Backlog item definition process.

Level one: User Story is just a special format of a sentence

At this basic level of understanding we are very close to the requirement-like specification. We keep the backlog in the Word document, as we anyway wrote very long sentences and extensive document chapters about the functionality. There is often huge mix of current functionality we want to keep, and new functions. The only change we do with that requirement document is to change/add User Story sentence instead of general name. So we get something like “As a MyCompany, I want new tariff, so that my customers are happier” followed by 2 pages long text description what the “tariff” exactly means. Such User Story may survive at team board for several Sprints without getting done. Surprising, isn’t it? We wrote User Story and it didn’t help!

So this stage is about documents. We create PowerPoint presentations to describe product goals and vision, we use complex roadmaps to define timeframe and we have written long specification documents to describe functionality. The more we write, the better product we have. The understanding of the role of Product Owner is very limited, decisions are often taken as a board of people without real product success responsibility.

Level two: We have ‘bigger fish to fry’, than write User Stories

At this stage we already understand that we have to describe our User Stories better. The team needs higher granularity and detail. But we don’t have time to write User Stories, so that we delegate that unimportant work to some administrative position called business analyst, business requirement specialist, business delivery manager, development team or whoever else is around. We don’t have a time to write such ‘technical’ details. It’s not important for us. Just make sure you will deliver it on time. We have bigger fish to fry. We have to talk to the customer. It’s more than enough to discuss our product ideas and high-level visions. We are responsible for Backlog, and yes, we prioritize it. However, the level of Epics is just about the right level of details.
So this stage is about big high-level decisions and quantity. We already have a Product Owner position, although that person is not often seen. Instead we have the army of people, who are willing to help official Product Owner with creating as many User Stories as you can imagine. What if we need that functionality in the future? Let’s describe all we can possibly do. And if we cover any potential functionality, it must be successful.

Level three: User Story is use-case

Here we finally got it. It’s about functionality slice, it should be INVEST. We have to make it concrete, understandable, and testable end to end functionality. Isn’t that easy? It’s like a use-case, isn’t it? Well, unfortunately, sorry to say that, no. There is a huge difference between use-case and User Story. So what’s the difference? Use-case is end to end functionality which defines what user does and how he is using the product, while the User Story defines only a new/changed functionality. We don’t repeat the current functions anymore and we focus on the changes only.
This stage is already user focused. We start describing different roles. We focus on functionality end to end. However, it’s still not simple and not clear enough. And it’s still not what we expect from the Product Owner.

Level four: We will design one big User Story and copy-paste the rest

This stage looks already pretty good. We have understood that every User Story has three parts – Who, What, and Why, and we think about all three of them. However, we haven’t still understood that every single User Story has its unique value, and it makes sense to invest an energy into individual detail User Story creation process. We are now spending energy describing Super User Stories (smaller and much more concrete pieces than Epics are, although nor small enough to be done in one Sprint yet.) We have great tools, which unfortunately offer a copy-paste feature. So we heavily use it to save our time.

This stage is about User Stories which already create some picture in your head once you read or hear them, but they are very similar to each other and hard to be recognized. We already have spent some time to investigate reasons ‘why’ for bigger chunks of functionality, and we are very happy about it, so we use it at every detail User Story which we create from it – just copy and paste.

Step five: Understand of business value and impact

Finally, we understand that it is worth of investing our time to every single User Story. And we are even looking at it more than once. We reprioritize individual User Stories and not only big Epics. Every User Story has a special role or persona. We have spent time and energy defining every one of them. We encourage ourselves to throw away or postpone User Stories already written, if they don’t match our product/release charter (vision, goals, success measures, timeframe).

We focus on business value and “maximizing work not done” which is one of the core Agile Manifesto twelve principles. We keep our product simple. We try to visualize business value for every User Story in the “Why” part of the formula, so that it helps us to decide on Backlog priorities.
Furthermore, we compare every new User Story with product/release charter and discuss how that User Story contributes to the defined goals and vision. Before we write the complete functionality, we try to measure impact, i.e. if the goal of Epic1 is to limit the traffic through the component A, than individual User Stories may propose different solutions how to filter that traffic out. In traditional management we finish most of them if not completely all. In this stage of this model, we try first to measure the impact by identifying of the percentage of possibly filtered traffic by each solution proposed. And then implement just the ones which have real impact with respect of our goal to limit the traffic. We may identify many great ideas, but we stop implementing as soon as the goal is achieved. At that time we don’t need any other functionality and we can move on to the next important area.

This final Product Owner Development model stage is about business value and impact. The less is more. Product Owner is feeling strong ownership and responsibility over the Product Backlog and individual User Stories. There might be people to help him as Product Owners rarely works alone, nevertheless he understands the importance of his role in defining even the small functional slices as User Stories are. Finally, in this stage the Product Owner is here to shrink possible functionality to the minimum which brings just enough business value. Product Owner must negotiate the functionality and focus more on understanding the customer real needs than all their wishes to come true.

Summary

To summarize it, Product Owner Development model is useful tool which helps you to understand where you are with your Agile Product management and product ownership. It also shows you the way where you shall continue and which areas you shall focus. Theoretically you don’t have to go through this model one by one, but it is very likely you will pass all next layers from the one where you are now even if you stay at that one just a very short time.

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.

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.

Forgotten practices: The Backlog Priority Game

Backlog prioritization is one of the most difficult parts of Agile adoption for many companies. So, what is the right way to do it? Are there any recommendations or methods, or is it just enough to let Product Owners decide? These and similar questions are often raised.

When it comes to backlog prioritization, the most common scenario is that the company starts by objecting that: “We’ve always done requirement prioritization and it has worked somehow in the past, so why should we change anything?” Once you dig in and try to understand their practices, you find out that the reality is usually not at all harmonious. The team has a very low understanding of the business value of individual functionalities and usually has freedom to choose the order, since it all has to be done anyway. All the business is interested in is whether they are delivering the release on time. So, starting Agile, the user stories usually have three types of priorities: 60% of them have priority “1”, standing for functionality that must be included; about 30% have priority “2”, standing for functionality which also has to be there; and the remaining 10% have priority “3”, standing for functionality which should most likely be included as well. Maybe ‘prioritization’ is the wrong term, and it would be better to use the word ‘order’. However, all expressions can be misunderstood, so we cannot blame the name for our troubles. Teams affected by such dysfunctional Product Owners have a few options for making it work. One of them is to create the role of Product Owner Proxy who tries to overcome the gap and grasp the missing business context as quickly as possible. Another is to push back to the Product Owner and simply tell him it is his responsibility to choose the priorities for the next Sprint and if he does not we might simply just deal with them in alphabetical order.

Having backlog ordered in this way, and presenting it back to Product Owner with thick red line at the position counted based on real team velocity to visualize which functionality is going to be delivered  with the release (above the line) and which most likely not (below the line) usually brings Product Owner back to prioritization process. Such a picture usually creates strong enough pressure to make the Product Owner take action and start to consider changing the actual priorities and functionality. That is the time to play the “Relative Weight Game”.

Let us say you are a product company

In such a case, the key to prioritization is as simple as that. Focus on business value and its cost. If the ratio is high, invest in that functionality. If not, take some actions to improve it or remove the functionality from your backlog.

The following method will support you in this approach. It is not new, but not many teams know about it. The method is based on relative weights, following the same principle as the relative point estimation often used by Agile teams to size the user stories. The idea is simple. Because most of the power of Agile methods comes from teamwork, we start by building a product team. The Product Owner can actually play this game alone, but then he is missing other people’s points of view and the lack of discussion means he might run into unexpected problems while dismissing important aspects of the business value. The team structure many differ depending on your product, company structure, and roles. In a company producing a box product with some level of customization, the Product Owner would usually involve business analysts, the user experience person, SW architect, or manager. At some point he may also involve the consultants or customer representatives in the discussion. The decision as to which priority the particular user story is given still remains with the Product Owner. However, the discussion among the parties involved is often very valuable and allows the Product Owner to make a much better quality decision than if he were to decide on the priorities by himself.

The Product Owner is still the key person in this process. He organizes the meeting; facilitates the discussion; and takes responsibility for the decision making, overall functionality, and, thus, the success of the whole product. The role of the user experience expert is often underestimated in companies. However, such experts are crucial to successful products and their point of view on business value might be the one which is missing in most of the final products. Experts like these help the Product Owner to simplify functionality while retaining business value. The next proposed role for such a team is that of Business Analyst. The role itself is quite controversial, because it is usually missing the connection to ROI, trying to make functionality as extensive as possible to satisfy all potential customer requirements. This is particularly noticeable in formal environments where everybody sticks to their own role and where the competencies are formally divided among parties. In this case, the Product Owner has the high level vision and strategy and does not care about the detailed level of the particular user stories. Conversely, business analysts lack the context of the customer relationship and environmental specifics. So, creating a single team out of them with a common goal is actually a good idea and can be quite helpful even on its own. Another suggested role could be that of Software Architect who can prevent the Product Owner from taking technical risks, e.g. if the team has no experience of using the expected technology, it might be wise to spike around the problem and build some prototypes, or deliver one user story to burn that risk. After all, it is the architect’s role to be in touch with the customer as much as possible and propose solutions that not only make sense from the technology perspective but are worth investing in for business reasons. The group is not limited to above mentioned roles, so feel free to invite anyone who might give you a valuable opinion.

Business value estimation: Relative Weight Game

Once you form a product team, the game can start, with the point being to estimate business value. Because the discussion is the most significant part of the point estimation process, the same applies to the business value estimation game. You, as a team, are going to estimate two independent values for every user story in your backlog (which, by the way, directs the discussion). Because the team is formed of various kinds of people, all the different aspects are considered. The first value you are going to estimate is “Benefit” – meaning how much you weight the value of this functionality. The second value is “Penalty”, which stands for the weight of the loss if you do not implement that user story. Each estimation value is relative to each other of the same kind. Usually we estimate in a range from 0 to 100 for both of these values. For example, the user story which represents the functionality everybody else on the market has, and is therefore expected, might be given a very low Benefit value, close to 0, and a Penalty of around 100. Conversely, a user story that is a differentiator from the competitors and really makes a difference to users might get a Benefit value close to 100 and a Penalty value of 0, as no one expects anything like that anyway. The key stories might be given 100 and 100, but most of the features will be given a value in between. Do not forget that Benefit and Penalty are independent of each other. You can play Planning Poker or do Magic Estimations to get the values, but remember that, to get good estimates, the numbers are just a side effect of the discussion, so do not try to cut it down to get the results faster. You need to take a business point of view, so you should be looking at the estimations from the customer’s viewpoint. You might say that this is not very different from what you usually do, but the need for the two different perspectives of Benefit and Penalty will make sure you do not omit any important aspect. Most prioritization done by companies  only uses intuition, usually just considering the Benefit side and only reflecting on the Penalty in very significant cases, if any at all.

As soon as you have those values, you can add up the estimates and the result stands for Business Value (BV):

Benefit + Penalty = BV

The numbers will be somewhere between 0 and 200. You could simply mark it done and just prioritize your backlog according to the business value, and it might seem to be right. However, in many cases, you need to play a bit longer and let the team estimate Complexity so you can compare the ratio of the cost of business value for each user story. The result of the calculation is the priority of the backlog item:

Priority = BV / Complexity

You will see that the “quick wins”, where the cost of business value is cheap, are escalated to the top of the backlog, while the extensive and difficult features with limited value are moved to the very end. Note that these are just numbers, so if you do not like the result, feel free to change it. However, you might consider having a closer look at it and recalling the discussion once more. Usually you will find that the Benefit and Penalty were not estimated correctly as independent values or, even more likely, that the user story must be split into smaller stories to improve the ratio, as Business Value and Complexity are never distributed equally over the functionality. You will find out that there are some elements which are delivering value and might not be so difficult to implement; while there are other elements which have only a limited business value and these might be the ones that are pulling the feature down. For example, drawing some data in a chart with a few pre-defined filters might be enough to satisfy the user requirement, but enabling customers to create the filters might be the difficult part. Do not forget that, according to several studies, about 60% of successful projects are never or hardly ever used. It is hard to cut the functionality, but if you involve customers in the prioritization process and explain to them the cost of the feature they might quickly come on side.

The Relative Weight Game is not very well known by the Agile community, but it delivers very good results in any product-oriented development. More than that, it is easy to implement and fun to play as well.

The article was published in Agile Records No14, May, 2013

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