Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you do if members of your team are not cooperative during scrum meetings?
They either provide a very high level definition of what they are currently working on, ("working on feature x"), or go into extremely irrelevant details, in spite of being well educated in SCRUM methodology.
This causes the scrum meeting to be ineffective and boring.
As a scrum master, what are your techniques to getting the best out of people during the meeting?
Edited to add:
What technique do you use to stop someone who is talking too much, without being offensive?
What technique do you use to encourage someone to provide a more detailed answer?
How do you react when you find yourself being the only one who listens, while other team members just sit there and maybe even fall asleep?
First of all... make sure folks are standing up... and not even leaning on the wall or a desk.
At a high level, I would say that, whenever you face issues on the team, the best response is to ask the team for solutions. However, here are some of the techniques I've used for the issues you're facing.
Talks too much
have him/her stand on one leg
have him/her hold the scrum "speaking" token in an outstretched hand while they speak.
Add a flip chart to the scrum to list tabled issues... when someone gets longwinded on a topic that is not scrum-meeting-worthy, interrupt and say "Hey - great point. I'm not sure everyone needs to discuss this, how 'bout if we park this for a follow-up discussion?" A key to making this successful is to actually follow-up afterwards and get the side conversation scheduled. Alternatively, the speaker may just say "Not necessary... I'll be working with Joe this afternoon on this" or something like that, which accomplishes the goal of reducing the windedness without the need to schedule the follow-up.
Need more detail. Is this for the scrum master's benefit or the team's?
wait until afterwards to ask the individual more detailed questions. If you think the team also needs to know them, coach the team member by conveying (in your after-scrum questioning) that "this is the sort of thing that I think Joe Smith would be helped in hearing from you, what do you think?"
Team doesn't listen.
Ask them on an individual basis. "Sally, I noticed that you don't seem to be getting much out of the Scrum. How can we adjust it to make it valuable for you?".
Post questions to others during the scrum. Like if Sally says "I integrated with Bob's code yesterday", ask Bob "how'd that go?" (I'd use this sparingly... to guard against scrums taking too long).
I've found that sometimes team members tend towards old habits by looking at the scrum master or project manager when they speak. When this happens alot, I alter my gaze to look away, which almost forces the speaker to gain eye contact with other members of the team, which may help the other members of the team to pay attention.
If time management is your problem. Get a timer and have someone buzz when you run out of time. Make sure tasks are broken down to an adequate level of granularity - any task should be anywhere between 4 hours to 2 days.. max 3 days. Anything above that break it down further before people signup to do it.
I think the three questions are:
What did you do yesterday?
What are you going to do today?
What obstacles do you see in your path?
Granular tasks (post iteration planning) should cater to bullets 1 and 2. The third actually depends on environmental conditions. The timer should over time subsconsciously jolt the members into thinking about their problems and framing short sentences. Focus on concrete obstacles instead of explaining why or preconditions or whatever. If you are talking to a single person for over 5 mins about something that only is of relevance to both of you.. stop, make a note (have a talk later at their desk) and move on.
Update: Also make sure everyone understands that 'rehearsing' before the Scrum meeting would save everyone's time. Think about what you would like to convey instead of just walking into the stand-up.
They should be saying what they achieved not what they worked on, and if they achieved nothing then what stopped them achieving.
The questions that are asked could be phrased differently
What have I completed since the last meeting?
What will I complete before the next meeting?
What is in my way (impediments)?
also it is important that the meeting is not the team reporting to the scrum master, but the team keeping in check with each other.
If people are talking straight at you the scrum master there are techniques to move the focus. Make sure you don't look at the speaker, or even move back so the sight line changes and they are forced to look at team mates as they talk. Do it subtle though :)
EDIT:
I cribbed that from
http://www.implementingscrum.com/2007/04/02/work-naked/
How do you react when you find yourself being the only one who listenes, while other team members just sit there and maybe even fall asleep?
Hmm, are you actually having stand-up meetings? It may sound hokey, but aside from making it harder for people to fall asleep, it also helps foster the feeling of a quick huddle to rather than a leisurelymeeting.
One thing that I have seen lead to an improvement is the use of a "talking stick" (we actually use a soft ball). It provides some additional focus on who is currently speaking, and makes the transition to another person more obvious.
How do you react when you find yourself being the only one who listenes, while other team members just sit there and maybe even fall asleep?
If I have already heard what the others have said I would ask a question of someone who is not paying attention about how it this might affect what they are working on. Very school teacher like, however it is enough so that they respond and engage with the meeting again.
I also agree with Kief
for your team to participate they have to see value in it, not just do it because you told them to.
The Scrum is a standup meeting, and the concept of a talking stick is an excellent point.
The key here is not that you have one or a few uncooperative team members, but is IMO, a more fundamental problem: the scrum team is supposed to be self managed, and the scrum meeting is to keep the team informed. If the other team members are not asking for clarifications and calling out the uncooperative members, then a re-education on scrum needs to happen.
Remember, the scrum master is not being reported to, s/he is just the person who removes blockages to the process. This does include facilitating the scrum meeting, but the team does have a responsibility to understand and demand clarification independent of the scrum master.
Ask for the specific details you need. People won't be aware of stuff you are interested in.
Also try to put forth some guidelines for better and effective presentation before the meeting.
Talk to them outside the scrum meeting and tell them how others may perceive their way of presenting what they are currently working on. I assume they are not deliberately non cooperative, but just not accustomed to the exact level of detail scrum meetings should have.
You may also ask them how much information they expect from others during the meeting.
By "scrum meeting", are you referring to the daily "stand up" meeting? If so, I believe those are usually timeboxed at about 15-20 minutes. So divide that time equally among everyone, and once someone uses up all their time, they can't talk. It might be harsh, but I believe that's how it's supposed to go down.
Scrum is a bottom up process, so in principle every team member should support the process.
How is the team put together? By organizational tradition or because of a common goal?
Not everybody buy into the Scrum idea, and we should respect that. Perhaps the best for all is that these members are not part of the Scrum team?
Some people just don't understand what is required. You can try to guide the conversation by using some key phrases.
If someone is giving too much detail then you can try to cut them off with a "What else". This will hint that they are done on that point. Or you can try the "OK, can we discuss that offline" type direction.
For people who don't buy into it, ask them questions about what they did and what they are going to do.
For the sake of arguement, let's say someone really has something they need to tell the team and it is going to take some time. Do you have an appropriate place, time or method (email, other type of meeting, lunch time) to do this? Just interupt the person and let them know the stand up meeting isn't the place.
Also, what problems during development does this create? If there is an error because of lack of communication, people need to be confronted on why they don't mention these things during the standup.
You can plan a maximum average time to explain what you did and what you gonna do.
About the people that are not willing to speak too much, I guess is responsibility of the scrum master to encourage that people to be a little bit more clear about his tasks.
If still people dont share what they´re doing a radical solution is use a canvas board where there people of the team have to move the task that they´re doing to his respective area(In development, ready to validation, in code review). Then you can know for sure in which task is he working.
After every daily meeting remember to ask for impediments or whatever kind of issue, sometimes people don't remember to say in his time or don't want share their issues.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are acting Scrum in our department now. But the up level management structure is traditional, such as Project Manager(PM), Development Manager(DM), Team Leader(TL) and Test team leader(TTL).
Team Leader act as a Scrum master, he controls all the things in our team: communicated with PM/DM/TTL, development management... Our PO's responsibility is just maintaining PBL.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum, and they said some Scrum rules are hidebound.
I act as another SM, I want to change the current status.
But I haven't any headship, just is an ordinary developer in our department. Does anyone has this kind of bother too?
Thanks in advance!
I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
I also recommend Mary Lynn Manns and Linda Rising "Fearless Change". This will help you to work out who else could help you.
Finally, I will echo #sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
"I act as another SM, I want to change the current status"
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
"Team Leader act as a Scrum master, he controls all the things is our team"
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
So we start Scrum today and start going over story points estimates.
The first story that comes up is a new screen that needs to be developed. It has 1 sentence to describe the screen and 3 user acceptance tests.
This starts a fight between the development team and the product owner.
Product owner says that stories do not need to be speced out and they will just be fleshed out during the sprint.
We say that the story needs to be completely speced out for the sprint.
But now I am starting to be unsure about who is right....
Any good articles on this that I can send to the team about how defined a user story has to be?
What happened during sprint planning?
It appears that you did not review the sprint plan to see the stories in advance of starting the sprint.
That's okay.
Stories are fleshed out during the sprint. That's the point. Relax.
Flesh out the story quickly, build quickly.
At some point, the one sentence story may become rather complex. If that's the case, break it up into something you will finish during the sprint, and stuff you will not finish. It's okay to have some stuff that was not known and did not get built.
Relax.
Do not overspecify everything. Do not specify every nuance of the story before the sprint. Just build something that will work. As quickly as possible. That's why it's called a "sprint".
Don't build everything you imagine. Build enough that the story can be performed by the user.
The point is to build something that works on schedule. If you have to adjust the scope of the story, that's okay.
Any good articles on this that I can send to the team about how defined a user story has to be?
A story is typically made of one sentence based on the following template: In order to <benefits>, as a <role> I want <action> (and I like to add "how to demo" steps that help to understand the story and to build acceptance tests). The idea is to capture the essence, not the details. Details are captured using face to face conversation during the sprint (and may be added as high level notes to the story). But a user story is not a contract, it's a promise for a conversation (about the scenario for which the story is the title). If you need some guidelines, following the INVEST model has worked well for us.
PS: No offense but the development team seems to react very defensively (asking for full speced things sounds like "hey, we did it as it is written", i.e. CYA). A user story leaves some space for creativity. Isn't that nice? If you need more details, take your responsibilities, go gather them. And if for any reason you can't get required clarifications or details, raise an impediment and have your ScrumMaster work on it. Personally, I enjoy having some space for creativity.
IMHO fighting is not good - Product Owner, Scrum Master and Development Team form the Scrum Team so they need to work together. They want to achieve the same thing - building a great product.
To me the question is how important it is for the Product Owner how the end result looks like. If he says: "We hired the best people on the market, you're the experts, whatever you come up with is fine with me as long as the user need is fulfilled", then I'd fine with the PO statement. But of course he can not complain afterwards that he does not like the look or the colors!
Another point is that the team needs to be confident that they can commit to this story. Usually teams estimate story size with planing poker so if the development team can not estimate, you need to invest time before that you can estimate (e.g. talking about the story before, spiking and negotiate with the PO about the story). Sometimes the designer/UX guy needs to work ahead and create mockups for the upcoming user stories.
It's always about finding the balance between planning and doing :-)
fs
I believe Martin Fowler's blog post on Conversational Stories probably answers your question best. You really don't want to be in a situation where the Product Owner is required to spec out everything in detail. You've got a team of smart, creative people that are perfectly capable of making good implementation suggestions as well as asking the right questions as they come up during the sprint. You don't want to lose out on that creativity and input by locking down requirements up front.
The story should be clear enough that the team understands what the feature is and small enough that the team can complete it in one sprint before it is added to the sprint backlog. The rest of the details should be handled via conversations during the sprint.
In our practice we do internal investigation of tickets for the next spring before planing with stakeholders. We usually find a lot of questions to clarify. If we don't answers before sprint starts we can't estimate it. If we found new issues/question during sprint we inform stakeholders and usually such story will be transferred to the next ticket.
So, my answer will be: the story don't need to be completely speced out for the sprint. But team need to know all answer to questions required for implementation as well as business decisions.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I work with scrum about 2 months and don’t have all the experience I wish, so I would like to hear some inputs about it.
My concern is people never say about drawbacks for the two sides; company and workers.
I know the benefits of a cross-functional team but which are the drawbacks? What is hidden beside the amazing Eden Garden?
I'm confused because as a company benefits of replaceable people, for the team is good because the opportunity of having knowledge and share experience (besides all teamwork benefit).
Again, I know all the benefits but I want explore the drawbacks just because in the middle there are the ordinary people.
Normally these people dedicate heavily to gain knowledge. They buy books, courses, attending seminar and so on.
In every company when someone knows much more than everyone else, people and managers get desperate wishing or even demanding that these ordinary people share all their knowledge.
And that’s strange.. Because these are communism thoughts and we live in capitalism society and since I was born, everything was so competed and now people say about collaborative.
Can Scrum and Lean principles ruins (or making hard) the professionals' life?
Scrum and Lean, in and of themselves, cannot ruin anybody's life. Nor can they, alone, make your life.
The culture of your organization will always be a far more dominant factor than the particular product management or development management method in place. Scrum can be misused. Lean can indeed make workers feel replaceable and pressured to perform all day, all the time.
On the other hand, both tools (they are just tools) can be used to create high-performing teams where all members value each other and each others' contributions. Being on a team that delivers consistently good results at high velocity feels great.
You will also find every result in between. It depends much more on culture than process.
I believe that culture flows from the top. Therefore, look at how the company leaders treat each other, their subordinates, their vendors, and their customers. That will tell you much more about what your life will be like than which methodology the company follows.
I'm only going to address your comments about sharing knowledge reducing your own value. In an ideal team culture, knowledge itself isn't as valued as someone's ability to acquire new knowledge and solve problems they haven't seen before. When I think about the star engineers I have known, it's not because they know this or that, it's because it's obvious they could be on nearly any task, on nearly any team and they would both begin to solve the problem and raise the level of the entire team.
There are a few things I've seen from agile methodologies which I'd put against it when you're weighing it up.
From a developers perspective there are two things:
1) The short sprints often lead to short term decisions - which is as intended but can be frustrating for some developers. While delivering "just enough" is great for the project, asking a developer to do something that they know that they're going to have to very heavily refactor, if not rewrite, two sprints down the line can be demotivating.
2) Where you've got opinionated developers (and is there any other sort) I've seen conflict over prioritisation. Adding not only what should be done but how important it is and therefore when it should be done brings on a whole other level of disagreement. In theory the developers don't have a say here but hard delination never works.
From a management point of view they don't like the uncertainty. "When's it going to be ready?" "No idea, when we get to the point you say you're happy". Essentially for them it's a leap of faith - if they do it once then generally they're sold but getting them to do the first time is hard.
I will assume, that as one commentator suggested, you meant to ask: "What are the drawbacks of Scrum?"
I think that the biggest problem with Scrum is that it is easy to understand - but very difficult to implement properly. Scrum, like XP, like most methodologies is not built on individual atomic practices, each capable of improving an existing process.
Scrum requires a shift in the organizational mindset. It requires a shift from ego-centric to communal behavior. The entire organization should focus on bringing the most value, constantly, and do so over perceived self-interest.
For example, a cross-functional team member may be required to do things out of his comfort zone (the flip-side of being able to experiment with new interesting tasks), because it needs to be done by somebody.
Team Leaders and project managers need to relinquish authority when they are called to take on the role of servant-leaders, and when they are asked to stop telling team-members which tasks to pick, instead relying on the team to manage itself.
Stakeholders are forced to face the reality that they can't eat the cake, and have it whole, when they are forced to choose between having all of the scope they want or having it by the date they want it done (this is always true, but Scrum is really in-your-face about it).
Most of all, the drawback of Scrum, is its tendency to disillusion beginning practitioners. This comes from people expecting something from it that it can't deliver: A solution to their problems!
That's right! Scrum does not solve an organizations problems. It highlights them. It is up to the organization to step up to the bat and do something about them. Incidentally, this is done with what I consider to be the single most important ceremony of Scrum - The Retrospective! If you do nothing else in Scrum - do the retrospective:
Find out what you did well, and continue doing it.
Find out what you need to improve and do something to improve it.
Rinse and repeat!
In a presentation by Ken Schwaber to Google on Scrum, he once said that Scrum isn't necessarily good for the organization. It could tell you early on that your project is doomed to fail. If you avoid Scrum, you may have a few more months of ignorant bliss to prepare you for the day you lose your job. Funny, but true. Think on that.
Hope it helps,
Assaf.
I'm no expert in any particular methodology (Agile, Scrum, etc.) but I empathize with your feelings. One of the biggest issues I've seen is that a team that really isn't interested almost unanimously in the methodology will tend to have problems. A few outliers isn't a problem, but if 1/3 or more of the team isn't interested, it becomes a nightmare. Writing good software is important and a company should hire professionals that help them meet that goal, but if the team is forced to meet that objective without finding the experience rewarding the quality will soon drop off.
No, I don't think it will ruin your professional life, but it can be pretty miserable if a company is pig-headed and doesn't realize that they need an environment where their workers are finding rewarding work.
I'm not totally sure of the question because it was kind of hard to follow.
Basically... no? I fail to see how an agile principle could 'ruin a professionals' life'... if implemented incorrectly it could waste some of their time, meaning a small lack of experience gained. Other than that, if the methodology fits the business and is implemented correctly, then is is a powerful tool that is useful to everybody.
Any methodology only works if the people are competent.
Silly question imo.
I've certainly seen things packaged as Scrum and Lean make the development process more difficult. Usually the result of managers picking and choosing the aspects that support their purpose, without buying in to the underlying spirit. Any process can work if properly applied, and process can fail if applied poorly.
Cross-functionality isn't a means to make people replaceable. It's a means to solve flow bottleneck problems that decrease productivity.
Cross-functionality doesn't mean that everyone can do everyone else's job, it means that people are capable of assisting with the work step that come (immediately) before their work or (immediately) after their work.
A better term for this is "Local Generalization", or "Special Generalization". And again, the goal has nothing to do with making people more removable from the organization. Creating the kid of people who can use Local Generalization to their advantage costs a lot of money in teaching and guidance. Once an organization makes such an investment in a worker, they're even less motivated to remove them. And organizations tend to only make such investments in people that they already want to keep around.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My organization has been experimenting with the introduction of more "Agile" methods. We've been trying the Scrum approach for a short while, and most of the team has, more or less, adapted to it. I like it as a whole, but I'm concerned about one potentially severe impact of the methodology: as teams are consistently focused on features and backlog items, and testers are more integrated with the overall development process, it seems like skill sets are becoming blurred, and people are sensing less respect for their individual abilities.
Some of our developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other, but they are certainly different.
Is this an inevitable result of the Scrum process? Since everyone on the team (as I understand it) contributes to satisfying the next feature/requirement, backlog item, or testing goal at hand, the underlying philosophy seems to be "anyone can do it." This is, in my experience, simply not true. Most engineers (developers, testers, etc.) have a particular skill set they have honed over the years, and the Scrum methodology, in my mind, tends to devalue those very abilities they were previously respected for.
Here's an example for clarification:
If a sudden change of technology occurs on the server-side data provisioning, and every item on the to-do list for the sprint is based on this new change, the GUI developers (who likely haven't had time to become acclimated with the new technology) might not be able to contribute to the sprint. At the very least, they will need to invest time to get ramped up, and then their code will be suspect because of their lack of experience.
I understand the need for rapid development to discourage "role silos" but doesn't this discount one fundamental reality: people develop skills in accordance to necessity, their interests, or their experiences. People seem to be less motivated when they perceive their position is one of "plug-ability" (e.g. we can "plug" anyone in to do this particular task). How does Scrum address this? If it doesn't, has anyone addressed this when adopting the Scrum methodology?
The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer.
:-)
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go
Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time.
Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
I think Scott Ambler addresses this issue very thoroughly in http://www.agilemodeling.com/essays/generalizingSpecialists.htm...
His concept of a Generalizing Specialist is exactly the thing Collective Ownership / Scrum Team calls for, and makes total sense to me.
Its hard to achieve in real life though ;-)
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
This is still a scheduling problem though.
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.