My organization is moving to Agile development, and I have a question on how change information is communicated downstream. I a manage a customer service organization of 2000+ agents. Currently we have a monthly deployment and schedule a monthly 1.5 hour training for agents. I cannot fathom how I can keep everyone trained and up to date with releasing happening at any time on any thing. Does anyone else face this issue and how do you manage the delivery of change information to end users?
I’m a scrum master on a large agile team at a large financial services company. Right now our area is running classic scrum (4 teams with separate backlogs) but we’re going through a transformation to move to a single joint backlog shared across teams.
My question is, how would the team structures need to change to support a single backlog? Would we create cross-functional teams, pulling from each of our 4 current scrum teams, or would a different arrangement potentially be more advantageous? Im thinking maybe the 4 teams could be:
Use case enablement
Any thoughts on potential choices for team structures, or good resources we could leverage? Thanks so much!
I am doing a project for school about agile management. I researched a lot about the theory but would like to know how it actually operates in companies. Warning: please let me know if I can use your comment as a quote/source. I will ask you if needed. In what field/company do you use agile management /seen it been used? What some struggles you faced? What do you like most about agile manament? Why did you choose agile management? Already thank you for your response. Thank you in advance.
This is mainly a question for experienced Agile teams who are comprised of both business analysts and dev/qa teams like we are.
We're on sprint 3 of this new process and although it's going well overall, the sprint planning sessions are painful and LONG. We have professional Agile coaches helping us out but we're still struggling with this bit. They are advising us to have everyone estimating each story/task using "planning poker" (we're using fibonacci numbers). The problem is that the analysts don't know how to estimate development or testing, and the developers and QA people don't know how to estimate documentation work. So for each and every story we have to spend 10 - 20 minutes explaining what the story/task entails so that everyone can give at least a semi-educated estimate. Which then means that in an hour planning session, we only get about 4 - 5 stories/tasks estimated and assigned to the sprint, and then have to schedule another freaking planning meeting to finish up.
Is this normal for teams that are just starting out, and we should schedule 2-3 hour planning sessions for a while? Is there a way to make this easier and less drawn out and painful? Is it because of some other reason, like too large of a workload for the headcount? (We have about 3 developers, 2 QA people, 3 analysts, a product owner and a scrum master.) I'm one of the analysts and I've been analyzing this process and I can't figure out what the problem is or possible solutions.