Do you implement scrum in true sense ? Is collaboration a myth in practical scenario ??
In a sprint, when multiple developers are working on different work items which are most of the times un-related, I find it's nearly impossible for the team to collaborate or self-organize. By collaboration what I mean is - :
a. In daily scrum discussing how we can achieve the sprint goal
b. Helping each other
c. Taking interest in what others are working on and would they be able to complete their work ? If not, how can I help ?
I have come to below conclusions- :
1. You can't implement scrum in true sense with "any" team. You need team members with proper mindset. If you have development team members who just want to finish their work and not willing to take on additional responsibility , you just can't do anything . Coaching , guiding can help but only to certain extent. You as a scrum master are helpless beyond certain point.
2. In your sprint if your stories are un-related (Which is the case 90% of times) , the situation becomes even worse. In this scenario, the most important functionality becomes sprint goal. So, even in daily scrum I tell the team not to forget sprint goal, you need to achieve sprint goal, other 4 developers whose stories are not a part of sprint goal cares a damn. Also, when you have un-related work multiple developers work on multiple unrelated items and each one cares about his/her own work.
In my team I am facing below issues:
A. If having additional time, some team members are okay to help other developers but they are reluctant to create a task (and own it).
B. Suppose a story has 4 tasks. 3 tasks are assigned to story owner itself. I came across situations where story owner does not care about progress of 4th task which is assigned to some other developer. It's like- the task is assigned to you , now it's your lookout.
C. In backlog grooming, some developers do not give attention when grooming of those stories is going on which they are very much sure are not going to come to them.
I would really like to know, if you have also observed the same in your team and how to deal with the same.
Vishal, this may have been mentioned previously, but unfortunately you are not in a situation where Scrum is being practiced (working group instead of Development Team, multiple PO's, unfocused sprint work). Because of this, you are experiencing the pain of "poor" Scrum.
From the Scrum Guide:
"Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum."
One word of advice I can give you is to explore Kanban as an Agile framework instead of Scrum. You don't have item synergy within a sprint. You don't have a Sprint Goal. Your "team" has a preference for working in silos. Kanban can help improve the way you work, regardless of your starting process.
Don't try to jam a square peg into a round hole.
@vishal Rajadhyaksha, What you have described above is resonates so well with my experience too. Unfortunately, what is being practiced is not Scrum. It has all the events of Scrum, but the purpose is not understood and is just being followed blindly because someone said so (most likely upper management)
Despite its simplicity, it may be very hard to implement Scrum, but it is not impossible. It however requires a shift in the mindset of the individuals doing the work, the management and also the organization as a whole. It would also require properly aligning the teams that constitute the development of the specific product (value stream).
This reminds me of the famous Office Space quote of Peter Gibbons “It’s not that I’m lazy. It’s just a question of motivation”.
At the very heart of Scrum is the concept of a team. This simple, but commonly misunderstood, construct of a team is what delivers value (it’s not the backlogs, reviews, retros etc) and to create a team there needs to be shared reward and sanction: no single winners or losers.
In many professional organizations groups of people are classified as a “team” but they are not; they are a group and you can quickly tell the difference between groups and teams if individuals are willing to sacrifice comfort or reward to help others.
So I’d look to check on the health of the team - call it the teamliness. This may uncover a few reasons why some don’t want to share.
Katzenbach and Smith is a good reference point to start (https://www.praxisframework.org/en/library/katzenbach-and-smith) but don’t aim for High Performing Teams (HPTs) as they can only form naturally and can be unstable.
So, even in daily scrum I tell the team not to forget sprint goal, you need to achieve sprint goal, other 4 developers whose stories are not a part of sprint goal cares a damn.
Why are those developers working on stories unrelated to the Sprint Goal before it has been achieved? Is the Goal so unambitious that joint effort and teamwork is not required?
Thanks everyone for sharing your view on this. After a lot of thought as John mentioned even I came to the conclusion that the basic of all the scrum is "TEAM". If your team members don't feel to work as a team, you can't implement scrum.And this is what you can't teach to individuals beyond certain extent.
Why are those developers working on stories unrelated to the Sprint Goal before it has been achieved? Is the Goal so unambitious that joint effort and teamwork is not required?
Because we don't create compound sprint goal. Our sprint goal is made up of one or max two stories. We have 4 developers. To achieve sprint goal we need to complete one particular story. To complete that story we need just one developer. So, rest of the developers work on other items instead of sitting idle.
Hi Vishal ,
Do you really have an answer why the organization chose to be Agile ?
If yes, then I have a feeling that team might need a coaching on Scrum or a proper on-boarding. They seems to be unaware of Scrum or any other Agile frameworks. If this has been done before may be still do it again and gather their feedback. What , why , how Scrum ( or any other Agile framework) can benefit the organization and also optimize their work.
In backlog grooming, some developers do not give attention when grooming of those stories is going on which they are very much sure are not going to come to them.
Why they are sure that these stories will not be developed by them ? To me it seems like there is cross functional team which needs to be cross skilled. It also raises the questions how your acceptance criteria for stories and DOD for an increment are satisfied. How other developers are not aware of the tasks and still review and test?
As per guide -
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
I sense there is lack of ownership as a team for Sprint Goal. As i mentioned before may be they are not on-boarded in a way they should be on Agile.
What , why , how Scrum ( or any other Agile framework) can benefit the organization and also optimize their work.
Just to be clear, i don't mean only Agile can make your organization better. But by having these answered you might know what framework is best and why ( be it Agile or non Agile).
Because we don't create compound sprint goal. Our sprint goal is made up of one or max two stories.
The Scrum Guide says:
The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
Do the Sprint Goals you currently agree with the Product Owner provide sufficient coherence?
So, rest of the developers work on other items instead of sitting idle.
Vishal, is there awareness within your organization that this is called "premature optimization" and is a wasteful practice?
To put another way, it is irrelevant how busy individuals are, if you are not delivering the greatest value and delighting your customers / end-users.
To put it even another way, when you purchase software off the shelf, are you concerned about the quality and functionality of the product, or are you concerned whether those who worked on the product stayed busy?
The focus should always be on the work, and moving the work forward, and not on the utilization or idleness of individuals.
@Vishal I have lived, and to some degree am living, your situation. As everyone, including you, have said Scrum is only successful with a TEAM. A group of individuals does not a team make. @Timothy suggested that Kanban might be a better fit. I think that it would worth exploring that. But I would also say that you investigate other agile ways. It might be that you need to create your own hybrid. Remember that the Agile Manifesto for Software Development does not specify any specific way of working. It was in fact crafted by practitioners of many variations of work methods. There are frameworks that align themselves with agile but there is not a definitive way to do agile. I have listened to interviews with Jeff Sutherland and Ken Schwaber where they state that Scrum is not for everyone. It can work in situations where the product is complex but it has to be appreciated in the form described by the Scrum Guide.
I have worked with groups of individuals that found some agile practices useful and actually were able to improve their work products by using them. But those practices came from many sources and a few were homegrown to aid in agility based on the corporate organization that they worked within.
You have posted here many times and my opinion from your posts is that you have all the right intentions and knowledge. Where you do not have the knowledge you actively seek it. That is to me a great attribute of an agile practitioner. Scrum can be a passion or preferred methodology but in the end
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
Help your organization determine if Scrum is actually the choice they want in order to become agile. If not, act as an Agile Coach and help them find a solution that works.
Do the Sprint Goals you currently agree with the Product Owner provide sufficient coherence?
Nope. But it's not possible for us to create one coherent sprint goal . We can only create coherent goal if our story 1, story 2 , story 3 ... story x all are for one large common functionality. But as I said earlier we are working on multiple un-related stories in a sprint because our business requirement is like that. We don't have one large functionality like shopping cart purchase section development from which we can easily create sprint goal. What we have is multiple small un-related work items. Example- Search of website based on tags, branch location search based on region, useful links section development , some UI development etc.
@Timothy suggested that Kanban might be a better fit. I think that it would worth exploring that. But I would also say that you investigate other agile ways. It might be that you need to create your own hybrid.
I would check for sure if this particular oganization gives this much freedom. In that case I am more than willing to explore kanban. Thanks.
To put another way, it is irrelevant how busy individuals are, if you are not delivering the greatest value and delighting your customers / end-users.The focus should always be on the work, and moving the work forward, and not on the utilization or idleness of individuals.
Hi Timothy, Our focus is on moving the work forward only. We have only one option ---Multiple developers need to work on multiple un-related stories.That's what we do and deliver business value.
Do you really have an answer why the organization chose to be Agile ?
Nope. Scrum is meant for complex software development. But ours is not complex work and in my opinion scrum is not required for this project.
They seems to be unaware of Scrum or any other Agile frameworks. If this has been done before may be still do it again and gather their feedback. What , why , how Scrum ( or any other Agile framework) can benefit the organization and also optimize their work.
Done this multiple times but it remains only till training room. After that back to square one.. But what's harm in trying again?..will conduct one more session. But have you really seen this happening ??--> Team members working on multiple unrelated stories and just because of scrum taking interest in other's work ? collaborating and taking shared responsibility ?? Have you seen this happening in real ??? I am curious to know.
Why they are sure that these stories will not be developed by them ?
Let's say particular developer has done analysis of some complex functionality. Then when development of that functionality comes in next sprint, development team decides that particular developer will only work on it as he has already worked on the analysis. This is how they get to know. Also, once story is assigned to particular developer, he knows that more work won't come to me as this story will occupy entire sprint. So, while discussion is going on for other stories in grooming meeting, he ignores.
But have you really seen this happening ??--> Team members working on multiple unrelated stories and just because of scrum taking interest in other's work ? collaborating and taking shared responsibility ?? Have you seen this happening in real ??? I am curious to know.
How many product does you team work on ? Does all these unrelated stories you mentioned are part of different products or 1 single product ?
If team is working on a single product then how do you think there is no relation between them ?
Let's say particular developer has done analysis of some complex functionality. Then when development of that functionality comes in next sprint, development team decides that particular developer will only work on it as he has already worked on the analysis. This is how they get to know. Also, once story is assigned to particular developer, he knows that more work won't come to me as this story will occupy entire sprint. So, while discussion is going on for other stories in grooming meeting, he ignores.
Does the team discuss the outcome of the analysis done by the developer? Do you think your PB is ordered enough? Why team is assigned with stories and why not pulled by them in a sequence the PB is ordered?
Why developer believes that a story will occupy the entire sprint without starting the work on it? is your Sprint backlog transparent enough ? Does the team communicate well enough during their daily scrum?
How many product does you team work on ? Does all these unrelated stories you mentioned are part of different products or 1 single product ?
If team is working on a single product then how do you think there is no relation between them ?
Single product. All user stories are small but un-related functionalities. For example:
1. Search branches by regions
2. Search articles by tags
3. Automation testing
4. Create "Useful Links" section
Now, how can we create a SPRINT GOAL out of these 4 functionalities ?
Does the team discuss the outcome of the analysis done by the developer? Do you think your PB is ordered enough? Why team is assigned with stories and why not pulled by them in a sequence the PB is ordered?
Yes. We do order Product backlog. Stories are pulled in sequence only.
Why developer believes that a story will occupy the entire sprint without starting the work on it?
That particular story was so complex that the developer has done technical analysis of it in a sprint. That's the reason he knows in coming sprint it will take entire sprint.
is your Sprint backlog transparent enough ? Does the team communicate well enough during their daily scrum?
Can you elaborate more on this ?
Can you please let me know - :
have you really seen this happening ??--> Team members working on multiple unrelated stories and just because of scrum taking interest in other's work ? collaborating and taking shared responsibility ?? Have you seen this happening in real ???
Can this be our sprint goal - : To provide tag based article search and US residentship wise branch search functionality to user.
This has been said repeatedly in this thread, but perhaps it bears repeating.
It is unfortunate Vishal that your organization believes it's work processes are a good path, but it is not Scrum. It is simply a disjointed, unfocused group of tasks and initiatives that your organization seems unwilling to prioritize in any order.
As a Scrum Master, it is incumbent upon you to make the negatives of such practices and approaches as visible as possible, along with backing up any suggestions or proposed experiments with concrete data (subjective, objective) on why they may improve how your area is currently trying to get "stuff" done.
Good luck.
Or maybe "Improve search".
"have you really seen this happening ??--> Team members working on multiple unrelated stories and just because of scrum taking interest in other's work ? collaborating and taking shared responsibility ?? Have you seen this happening in real ??? "
Yes, I have. But it requires trust. When there is trust a team member is not afraid to say that he got stuck on something and ask for help. Other team members then evaluate what is more important for sprint goal: "their" work, or helping colleague (improves collaboration in future sprints - sustainable pace), and act accordingly. But, as said, it requires trust of not being ridiculed for asking for help, and courage to ask for help.
Now, how can we create a SPRINT GOAL out of these 4 functionalities ?
What features you consider to be the most important for your team & stakeholder to get done ?
But Its more important to understand what do you infer from the term 'Sprint Goal'. It can be different for me and you. For some it can be predicted business value, benefits for the customers and stakeholders , efforts needed to deliver over sprint/sprints, MVP to achieve it. No matter if the features are related or not but all of them formulates as a part of one goal.
Example - Banking website improving payment options, CRM and the homepage UI for one sprint. What do you think about the relation between them ? What do you think what can be the goal?
What features you consider to be the most important for your team & stakeholder to get done ?
That's what we do currently. Sprint goal out of the most useful functionality out of all the functionalities that we are going to deliver in a sprint. But this is not the ideal way to create sprint goal I feel. Because, the people working on other functionalities do not feel to be a part of sprint goal.
Example - Banking website improving payment options, CRM and the homepage UI for one sprint. What do you think about the relation between them ? What do you think what can be the goal?
I feel like in this case goal can be Improving user experience. But how really useful such goal would be ?
it requires trust of not being ridiculed for asking for help, and courage to ask for help
Can't agree more.. But would like to add one more thing- Trust, Courage and "Willingness"
What is the implementation effort of the items the team typically works on? How long does it take them, on average, to complete their 'sprint goal' items?
If the items are large, taking the development team member multiple days to get it to done, then why are other development teams not helping him/her to get it done faster?
Have you tried using a WIP limit to stimulate collaboration?
That's what we do currently. Sprint goal out of the most useful functionality out of all the functionalities that we are going to deliver in a sprint. But this is not the ideal way to create sprint goal I feel. Because, the people working on other functionalities do not feel to be a part of sprint goal.
What do you think can be the problem here - Sprint Goal ( comprises the benefits/ROI ) or developers does not feel part of the Sprint Goal ?
What do you would be a better approach - would you change a Goal to make the team focused or would you make team focused towards the Goal?
I feel like in this case goal can be Improving user experience. But how really useful such goal would be ?
How useful you think it would be for user , team and for organization ?
What is the implementation effort of the items the team typically works on? How long does it take them, on average, to complete their 'sprint goal' items?
If the items are large, taking the development team member multiple days to get it to done, then why are other development teams not helping him/her to get it done faster?
For complex stories, one developer takes entire sprint (10 days) .
Other development team members not helping is because of 3 reasons:
a. It's very difficult for the developer to jump in between and start helping other developers regarding the code he has no idea
b. The other developer is busy in his/her own work
c. The developer originally working on that work also says it would be confusing for him if someone else also starts working on his code .. They prefer to work in silos.. They told me sharing a work is not a good option.
Would you change a Goal to make the team focused or would you make team focused towards the Goal?
As our current sprint goal does not comprised of all stories, I would like to change sprint goal . It's impossible to make the team focus towards xyz sprint goal in which they don't see their own work. They should see their own work as a part of sprint goal. That's the kind of motivation. Next challenge is creating a sprint goal out of all the items which are not part of single large objective. They have their own small objectives. So our sprint goal would be really long.
would you change a Goal to make the team focused or would you make team focused towards the Goal?
I don't see it's useful at all apart from saying- Yes..We have a sprint goal !
For complex stories, one developer takes entire sprint (10 days) .
Other development team members not helping is because of 3 reasons:
a. It's very difficult for the developer to jump in between and start helping other developers regarding the code he has no idea
b. The other developer is busy in his/her own work
c. The developer originally working on that work also says it would be confusing for him if someone else also starts working on his code .. They prefer to work in silos.. They told me sharing a work is not a good option.
A full sprint of one development team member. How much faster could it be done if the whole development team would contribute? I imagine quite a bit, what do you think?
I think you have a nice opportunity here as a Scrum Master to coach your team.
Regarding A: Why is it difficult? Based on reading it seems that the other developers have no idea because they don't collaborate. The solution then isn't to use that as an excuse to collaborate even less. How can the team get more of an understanding about the most important work? Have they ever tried pair programming for example?
Regarding B: Why would a developer work on non sprintgoal items while the sprintgoal currently takes a full sprint to complete (if it even gets completed)? You can help the team to think less about being busy, and more about delivering value (sprint goal related items).
Regarding C: This should be something you as a Scrum Master can coach the team on. What reasons do they give for sharing work not being a good option?
What is really at play here?
The more I read your comments the more I am sure that your organization should admit that they are not doing Scrum. What you are doing is working from an ordered task list and introducing time-boxes for the activities. Since you have not mentioned the Sprint Review, Retrospective at all I question if the time-boxes are even necessary. Your organization would be better off just admitting Scrum is not practiced and probably never will due to the fact that no one (but yourself) is willing to make the changes needed to implement it. As a Scrum Master you should be willing to admit it and take this to the management team. If they really want to do Scrum you have an opportunity to coach the entire organization. If they say "what we are doing is working" then they have admitted that they do not want Scrum. You have said multiple times that any training you have attempted failed since they left the room and did nothing to change. So I would even question if management said that they really do want to Scrum. Ask them for time to discuss Scrum and how change is needed in order for it occur. Do not attempt to train them, have a very open and uncomfortable conversation with them. Facilitate the discussion and keep the focus going towards the decision of "Are you willing to change the organization in order to implement Scrum or not?".
As hard as it is for a good Scrum Master, sometimes it is best to admit defeat. You seem to me to be a person that really embraces the Scrum values and are passionate about implementing Scrum. My opinion is that you are working for the wrong organization.
As our current sprint goal does not comprised of all stories, I would like to change sprint goal . It's impossible to make the team focus towards xyz sprint goal in which they don't see their own work. They should see their own work as a part of sprint goal. That's the kind of motivation. Next challenge is creating a sprint goal out of all the items which are not part of single large objective. They have their own small objectives. So our sprint goal would be really long.
Vishal , as highlighted in bold. I see the real problem is - 'Individual Sprint' . If as per you the current Goal does not bring the focus and collaboration within team , how do you think the new formulated Goal would help ? I mean real problem might still exists.
As mentioned in above threads why developers choose to work on other task before even completing the Goal? Do you think splitting the one big task which is part of your Goal into small granular tasks might fix the problem?
Vishal, I concur strongly with Daniel's observations, as well as other viewpoints in this thread questioning whether your organization truly supports Scrum.
From the Scrum Guide:rule.
The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
It sees your current team practice directly contradicts this Scrum rule. You can cherry-pick some of the Scrum Guide practices and rules, but the end result is just not Scrum.
Keep in mind also that one of the Scrum values is Courage. As someone who is a Scrum leader in your organization (and sees all too clearly what is and isn't Scrum), you may need to demonstrate the courage necessary to make any violation of Scrum as clear (transparent) as possible.
Good luck.
Come on. Sometimes having every single team member doing work exclusively directly connected with a Sprint Goal is next to impossible and would contradict the spirit of agile. I would also not see a reason to spent excessive amount of time to come up with a Sprint Goal that encompasses everything the team forecasts to do. I think that a well-functioning team based on trust could live knowing that in this sprint, only 60% of Development Team will directly work on sprint goal, if the team has decided that the sprint goal can be achieved using such plan. This sprint someone doesn't get to work on sprint goal, next sprint it might be a different person. There is no "own work", there is a work the team plans to accomplish, and some things will be less important than these connected with the Sprint Goal - but that does not mean that developers should not care about what everyone else is doing - they are supposed to work as a team, helping each other in every possible way.
@Filip has a very realistic approach. Often real life is very much different than academic. But notice that he says that all of the team should be communicating and trust each other. "I'm still working on my story" isn't really the type of communication beneficial to agile.
I really think you have gotten a lot of good opinions and recommendations in the thread. I have learned from it, I hope you have too.
A full sprint of one development team member. How much faster could it be done if the whole development team would contribute? I imagine quite a bit, what do you think?
@Jeroen, Not practical though sounds good to hear. Code writing cannot be divided amount multiple developers and it adds confusion as well as told by our developers.
Regarding A: Why is it difficult? Based on reading it seems that the other developers have no idea because they don't collaborate.
Collaborate how? about what ? These things are easy to write than to do. I am talking about complex story. Code is also complex and so many things to consider. Just by "Talking" the other developer won't understand anything. Pair programming is good option. So that at least one other developer can get the idea of the code. For some reason our developers don't find it useful ..somehow I need to convince then to at least experiment for one sprint.
What reasons do they give for sharing work not being a good option?
The sharing in our team means both the developers work on parts of code related to same story but on two different systems and not in pair programming. I don't have answer to this question but will check with them.
Do not attempt to train them, have a very open and uncomfortable conversation with them. Facilitate the discussion and keep the focus going towards the decision of "Are you willing to change the organization in order to implement Scrum or not?".
As hard as it is for a good Scrum Master, sometimes it is best to admit defeat. You seem to me to be a person that really embraces the Scrum values and are passionate about implementing Scrum. My opinion is that you are working for the wrong organization.
Thanks for the kind words. I attended two days agile workshop by my parent company in which also the agile coach said the same thing to all. In some old post you mentioned about how we can combine multiple stories in one sprint goal. So if suppose we have six stories in a sprint, all six stories should be a part of sprint goal ?
As mentioned in above threads why developers choose to work on other task before even completing the Goal? Do you think splitting the one big task which is part of your Goal into small granular tasks might fix the problem?
First thing first. There is a lot of confusion about sprint goal. Some experts say sprint goal can be made out of most important functionality from business value standpoint while others say it should comprise of "ALL" work taken in a sprint. So, I am asking the same question which I asked to Daniel above. if suppose we have six stories in a sprint, all six stories should be a part of sprint goal ?
Currently, our sprint goal is made up of one or two most valuable stories from sprint backlog. We have 4 developers. We cannot assign 4 developers for sprint goal (which is just one user story in our currently going sprint). Sprint goal is V IMP. Agreed ! No doubt. But , there are other imp stories also. So, rest 3 developers work on other stories.
First thing first. There is a lot of confusion about sprint goal. Some experts say sprint goal can be made out of most important functionality from business value standpoint while others say it should comprise of "ALL" work taken in a sprint. So, I am asking the same question which I asked to Daniel above. if suppose we have six stories in a sprint, all six stories should be a part of sprint goal ?
Vishal , as per me you must understand there is no straight exact answer ever for any situation. Will be a blessing if we all get that. :-) You yourself have to try and find out. Experts can guide you but its you who has to discover. As mentioned above for some teams its MVP that forms part of the Goal, for some its based on business relevance , user experience etc. What do you have ? What does your PO think about it ? what value does team think they can bring by delivering the increment ? Does all items taken in sprint backlog for any particular sprint will give you this value you expect or only some does ?
Currently, our sprint goal is made up of one or two most valuable stories from sprint backlog. We have 4 developers. We cannot assign 4 developers for sprint goal (which is just one user story in our currently going sprint). Sprint goal is V IMP. Agreed ! No doubt. But , there are other imp stories also. So, rest 3 developers work on other stories.
I again highlight some words which creates a doubt whether team/organization is ready for being Agile. Many above have already highlighted this question. Or may be its just the unintentionally used words. :-)
Anyway, how does the team collaborate on making the stories done ( which are part of your Goal) ? Is the entire work started and completed by one developer or other contribute in different phases depending on your DOD ?
Sometimes having every single team member doing work exclusively directly connected with a Sprint Goal is next to impossible and would contradict the spirit of agile.
Filip, unsure if that comment was directed towards my feedback or not. If it was, I think you either misunderstood what I said, or I wasn't clear.
I will agree that there exists the Scrum framework by the book, which sometimes runs up against real-world practices. In my opinion though, we should not automatically call it Scrum because they are "close" or they make a good effort.
As in Vishal's situation, teams attempting to support multiple products not only make adherence to Scrum challenging, but also dilutes the value of crafting and working towards a Sprint Goal. It is inherently difficult, if near impossible, to identify coherence in the face of extreme variability.
It has been suggested that Sprint Goals can be crafted as a summary of a number of items forecast in the sprint. There are a number of concerns with this approach:
- Lest we forget that, in Sprint planning, we should start with a Sprint Goal, and then identify the PBIs that can support it?
Is it apparent that, when teams attempt to work backwards from the approach identified in the Scrum Guide, that this task becomes increasingly more difficult?
Is it clear that crafting a Sprint Goal is made even more difficult when we're trying to work backwards and the items forecast have little if any coherence to each other?
Is it transparent to everyone that trying to "sum up" such a variety of work into a single statement really doesn't provide any value to the PO, Development Team, or organization? You're basically just reading your "list" of items into a single sentence
- Personally, I see it as a red flag whenever I see a Sprint Goal containing a conjunction (like "and", or "or"). To me, it is indicative of a lack of focus, and represents some of the "list" approach cited previously. Also, when you have such wide-ranging "run-on" Sprint Goals, does it mean that if you only delivered 4 of the 5 items listed, you did not meet your Sprint Goal?
- I am not advocating at all that the Sprint Backlog must be 100% dedicated to the Sprint Goal, and that everyone on the Development Team must contribute to the Sprint Goal. The 60% Sprint Goal guideline proposed by Filip is one way to go - bottom line, we should support however the Dev Team chooses to self-manage around the work.
I will say though that the opposite approach (doctoring a Sprint Goal statement to encompass all of the variability in a Sprint Backlog) is a poor practice.
I think that a well-functioning team based on trust could live knowing that in this sprint, only 60% of Development Team will directly work on sprint goal, if the team has decided that the sprint goal can be achieved using such plan. This sprint someone doesn't get to work on sprint goal, next sprint it might be a different person. There is no "own work", there is a work the team plans to accomplish, and some things will be less important than these connected with the Sprint Goal - but that does not mean that developers should not care about what everyone else is doing - they are supposed to work as a team, helping each other in every possible way.
Seems practical approach. 50-60% team should work towards sprint goal.
I really think you have gotten a lot of good opinions and recommendations in the thread. I have learned from it, I hope you have too.
Indeed.
Vishal , as per me you must understand there is no straight exact answer ever for any situation. Will be a blessing if we all get that. :-) You yourself have to try and find out. Experts can guide you but its you who has to discover.
Noted Harshal. Very useful.
Anyway, how does the team collaborate on making the stories done ( which are part of your Goal) ? Is the entire work started and completed by one developer or other contribute in different phases depending on your DOD ?
They help each other if someone "explicitely" asks for help. But they are least concerned if other developer will complete the work. Work is started and completed by one developer only. Other developer is not aware about code someone else is working on. So, even he cannot help.
They help each other if someone "explicitely" asks for help. But they are least concerned if other developer will complete the work. Work is started and completed by one developer only. Other developer is not aware about code someone else is working on. So, even he cannot help.
What do you think of extending your DOD ? May be include code reviews from other developers and testing.
This will make all developers aware about codes , also might help in cross skilling.
Not practical though sounds good to hear. Code writing cannot be divided amount multiple developers and it adds confusion as well as told by our developers
I have heard that many times in the past because the developers want to be the "one that owns" the code. They think that If no one else knows anything about it they are too important to be fired. They see it as job security and actively work to avoid sharing any knowledge. Breaking that believe is not easy but to get teams instead of groups of individuals, they have to learn to think differently. Is there a "best way to do it"? Not that I know of but there could be a best way to do it with your teams. You will have to find it for yourself.
Despite what I have said above, I completely agree with @Timothy's last comments about the Sprint Goal. The Goal should be crafted before the Sprint Backlog is formed. That Backlog should be formed in such a way to support and accomplish that Goal. I suggested the goal represent all stories in the Sprint Backlog because it has helped me get the teams to appreciate the purpose of it. As they start getting comfortable with it, I then nudge them to start creating the Goal earlier and then build the Sprint Backlog. By this time, with some considerable coaching, the teams have started to focus their Goal to the most important items in the Sprint Backlog. Nudging them to create it earlier doesn't mean they have to craft it differently, they just do it at a different time. Then again overtime they become much better at defining a Goal and supporting Sprint Backlog. I suggested it for you because at the point you are I felt it would be easier for you to convince your team of that method than going full blown academic Scrum.
Sprint goal is V IMP. Agreed ! No doubt. But , there are other imp stories also. So, rest 3 developers work on other stories.
This really sends up a red flag for me. It could symptomatic of multiple things.
- The Product Owner might not be ordering the backlog appropriately in order to optimize the value that the Development Team delivers. Having a number of unrelated stories at the top of the backlog is a signal to me to work with the Product Owner.
- The Development Team may not trust the Product Owner to do his job of ordering the Product Backlog and are instead taking in stories from the backlog in the order that they choose. This becomes a team building exercise focusing on trusting others to do the right thing because no one intentionally wants to cause damage.
- Is this really a Product Backlog or a list of stuff that someone wants the Development Team to do? The Product Backlog is an ordered list of items that need to be done to a Product. Not an ordered list of a bunch of development tasks.
What do you think of extending your DOD ? May be include code reviews from other developers and testing.
This will make all developers aware about codes , also might help in cross skilling.
Currently also review is happening and is very much part of DOD however only architect and senior developer does it. As you correctly pointed out we will change this practice and any developer should be able review the code written by some other developer.
@Daniel,
Noted !
Is this really a Product Backlog or a list of stuff that someone wants the Development Team to do?
No comments ..:)) .. You got it right :D