Distributed Scrum US/India
My manager has put me on a project where I am the scrum master. Below are the specifics to my work environment. My issue is really about the current process and what I can do to make a change to the current project. There's a lot of info below & I'm trying to be objective. Any comments, lessons learned, or 'red flags' you might have seen in the past would be appreciated!
Scenario
> I represent QA but do not do the testing work. My role is QA Lead & I am located in the US.
> My primary responsibilies is to ensure that everyone is using the Team Foundation Server properly.
> I created a TFS Process document. Both QA & Dev have reviewed this document and they agree on using the process as I have written it. The process document outlines working with artifacts such as User Stories (state workflow, story point estimation, ordering backlog), Tasks (creating, updating, closing & cloning), setting Capacity, working with Defects and a final sprint checklist. I follow this procedure closely and my efforts are known by the team since I make changes for QA & as well as request changes from development.
> Development & QA team are located in India
> The QA Manager, Project Manager & Product Owner are in the US
> My manager has told me verbally that I am to be acting as scrum master. However, this has never been announced officially by management to the team. My manager says that my role as scrum master is 'implied' to the team by the work I have been doing for the team.
> The User Stories are decided before the iteration starts. I make sure that all user stories, tasks & hours are input into the TFS system before the first day of the sprint.
<b>Issues</b>
> Capacity is not done properly. We essentially add the total number of work hours for a given User Story's tasks and divide by 8 and this is the story point calculation. Example: A user story that takes 36 total hours would get a story point of 4.5. We do it this way because it's easier to understand 1 story point = 8 hours (1 work day). However, in my process document, I do speak of the correct way to calculate points (ie., 'relative sizing')
> We do not have daily scrums. QA works directly with development for the requirements.
> User stories are not documented. They basically act as a container to link defects, test cases and tasks. We have another system for production that houses our production issues which get created in the TFS system. However, the specifics in the production system are vague. Development works directly with the Project Manager for any production issues or enhancements to the system.
> The Product Owner works primarily with offshore development
> We do not have a Business Analyst. QA works directly with development to write their test cases.
> For the most part, the Project Manager doesn't exist. We don't have any daily meetings or end of sprint sessions. The workflow is basically 1) Product Owner speaks with development about what needs to get done 2) QA works with development to get specifics for their test cases 3) Development delivers code to QA 4) QA tests 5) User Stories get closed out.
> QA is not involved in the Product Owner / Development planning sessions. QA did attend a couple of the sessions, but it's more about "so do you think we can do this?" or "what issues need to be resolved before we can commit to this enhancement?"
> Too many user stories are assigned to a given sprint. For example, we currently have 75 user stories assigned to the current sprint, about 20 will get delivered. 55 will carry over to the next sprint. This has been very frustrating because it throws off all our hours. The hours for the burn-down chart does a nose dive on final build day because everything moves to the next iteration.
> The sprint follows somewhat of a hybrid SDLC between agile & waterfall. There is code/test for 3 weeks and on that final 3rd week, QA gets a final "Build to QA" code drop. We have seen 80% of the user stories get delivered on that final day where QA gets slammed with a ton of work at the last hour. The we have 4 days to complete everything including our regression testing.
Final Comment
So, that's my brain dump on what's going on. I have not had any official scrum master training, only using the TFS tool daily for the past 2 years and then just taking over the management of the tool since the PM is absent. I would appreciate any comments, lessons learned, best practices, etc. My biggest issue is if it really is possible to pull this together given the distributed & dysfunctional arraignment of our team. Thanks in advance!
Leave aside the issues for the time being, after reviewed your Scenario just wanted to ask - "Are you sure you are doing Scrum"? Are you a pig or a chicken?
Dear Steve,
even from first couple of your sentences it is obvious that the situation is not easy. I have similar situation (not the same though). We are distributed team into the 3 different countries and one of them is India. I still struggle to apply scrum in all its power, but it is a process. Here are my thoughts on your situation.
First of all, not everything is bad. It seems that the Development and testing works together. That is very good starting point. If the team tries to have an increment every sprint (even it the quantity of items is not as planned) they are on a good track. It also seems that you are using user stories burn down charts and such. This will definitely help you to keep on track,
But now the other side. There are some "red flags" as you said, but I am sure there will be no surprise for you.
Are you or are you not a scrum master? This is very important to know. If not you? who? Does Development team has their SM? It seems that your organization would like to have the benefits of scrum but does not want to acknowledge the scrum roles, artifacts or events. That will not do.
The team must know who is the scrum master. And it has to be official, for them and for the management. It has to be TRANSPARENT. If roles will be not clear, problems will be bigger. Try to convince the management to make this clear or you cannot do the job they want you to do. On the other hand, if the project does not want scrum. they should specify more their expectation.
But for the rest let assume that you are a SM.
SM and the team should be together, how can you effectively protect them and improve their collaboration if you are not there? I know that you do not make this decision, but all people involved should be aware of the consequences. If you will be remote SM, you work will be very hard.
[code] Too many stories are assigned into a sprint. [/code] I do not know why it is that. I would understand for the first sprint where team has no idea about velocity and simply underestimate the work. But the next sprint they should plan more or less the same amount of work they were able to finish last sprint. This is not bad only for the team's morale but how do you plane release?
You should promote the daily stand up. It is necessary for the team to keep track on their progress during the sprint. So they they can adapt they way of work or inform others they will not finish what it is planned. You should be there so hear what prevents them to achieve what was planned. I also hope you do retrospection, but you should. Team needs the opportunity to look back and discuss to improve.
[code] User stories are not documented[/code] if you do not know the definition of user stories how to you know what to test? How the development team knows what to develop? Can you influence this? How the estimates are done if the user stories are not described? Maybe I misunderstood you here.
In general the fork-flow is very similar what we had in the beginning. It is not ideal and it has to change. Since the Scrum is new for everyone I always try to find the biggest pain point and change it and see.
It is important is to get testers on planning, even if they would only listen, they need to know the user stories and their interpretation from PO to start working on test cases as soon as possible.
Secondly, to get installers 3rd week is just too late. I do not know how much time you spend on the build deployment but you should start testing as soon as the first user story is ready to be tested so that mistakes can be corrected until the end of the sprint. We also have problem with it, now we are trying to improve automatic build deployment so that we do not lose that much time on it.
If you are indeed the SM of the project and it is up to you to explain Scrum to others, you should conduct some training, for you AND others. However, even more important is to read, read and read. There are many books out there and as soon as you will understand not WHAT is the scum (roles, artifacts, events, rules) but WHY scrum, it will be easier to explain to others.
I also recommend to check Scrum Master checklists or Scrum Metrics so that you know more what is wrong, it will help you to identify the root cause.
Most likely there are other things the project should do but does not to follow the Scrum, but it is important to start the change somewhere, at the point which is the biggest bottleneck now.
Good Luck
Have you read the official scrum guide?
Have you read at least some of the books mentioned under https://www.scrum.org/Courses/Professional-Scrum-Master/PSM-Subject-Are…?
Do you have a agile/ scrum CoE in your organization to rely on to help you out?
Any possibility to get an agile coach or a senior scrum master to get you and the team trained and coached?
Wow, there's a lot going on here :). Rather than type out a detailed response, I'll ask, would you like to connect on a video chat?
Email me at jason.knight@vitals.com. Let's set up a face to face conversation. We'll work through it together :).
Make it can help you: http://getscrum.com/remote-development-team/
The recommendations in the link have been tried and tested. Yes it works. If the principles are followed, the presence be it virtual or physical is secondary.
Hello Steve ,
I work in a distributed environment. We have adopted Scrum from a long time now. Yes , initially there were few troubles.
I am pretty sure you would be becoming a well organized fully matured scrum team in the future. I would recommend to understand the scrum guide well to understand about the scrum process first. Understand the process and make the team to know it well. I would say any training would not give you a practical experience no matter how professional it is. Implementation matters. Learning and adopting is the beauty of agile.
Being a remote SM you would need to stretch more than you usually do. Appreciate that.
Share your experience.
Thanks
> My manager has told me verbally that I am to be acting as scrum master. However, this has never been announced officially by management to the team. My manager says that my role as scrum master is 'implied' to the team by the work I have been doing for the team.
....
My biggest issue is if it really is possible to pull this together given the distributed & dysfunctional arraignment of our team. Thanks in advance!
Hi Steve,
I think you have stepped into my former position with my former manager :) I was in this identical situation. I would first start by letting your team know that your manager verbally told you that you would be acting scrum master, you can even do that with your manager present if you want. But they need to understand what you're doing and why. I would then get some working agreements down with the team on process (it sounds like you have done a good job of that).
Next, I'd start trying to work to those agreements and improve each and every sprint. Being a distributed team should not matter, but I'd highly suggest that you initiate some communication platform like instant messaging that gets you as close to "over the shoulder" communication as possible. Email can really move you back into waterfall. I understand you may have some time zone challenges with this.
Regarding the over commitment of stories each sprint, this is on your shoulders to coach up to the product owner and sponsors on why this is not desirable. It's hard. They may not buy into the benefits of seeing small increments each sprint. Do your best to shield your team from this chaos and frustration by having and honest discussion in your sprint planning on what is really achievable. Let them know this a problem you are trying to resolve but it's going to take a minute.
I would always ave a clearly stated sprint goal and get the team to decide the order in which to approach the stories so that the goal is achieved. This way, if you have stories you know you aren't going to get to because there are way too many in the sprint, at least you can achieve your sprint goal while working on your product owner and sponsors to get the sprints right-sized. If you don't strategically work the stories in order to produce an increment, you'll have a lot of things started and nothing finished. Does that make sense?
You're in a tough spot. It's a tough job when it's not a smooth running machine.
Good luck.
M.
I appreciate all the positive feedback. As an update, our entire R&D department is required to attend a 2 day Agile training event. This is for US, Canada and India. I'm really encouraged that my company has finally identified that this is a systemic problem and they are willing to move in a positive direction. I'll update as things begin to take shape.