Khushboo SinghProject Manager| Envestnet|YodleeBangalore, Karnataka, India
Our organization is slowly planning to move to Agile practices.
There is a full-fledged Product Management Team which acts as Product Owner for specific Features.
We need to create a defined Agile Team and in today's discussion we came across a conflicting thought.
There is a defined Development Team with 30 cross-functional developers.
Testing team with 7 testers.
Conflict-
As-Is scenario: Championed by one of the senior managers
1. As and when requirement comes from Product Owner, resources are being provided by both Development and Testing teams.
2. When the requirement is released, the team is dismantled and they are rested/utilized in other requirements.
3. As the team is rebuilt, there is no co-ordination/trust between these folks and ping-pong happens very frequently.
To-Be scenario: Proposed by another senior manager as part of Agile adoption
1. Create defined teams with specific skills with testers, Product Owner, Scrum Master.
2. As requirements come, it should be verified and validated to which team it should go and allotted to that team.
3. As these would be permanent teams, friction issues would be less and there would not be any need to dismantle and recreate teams time and again.
I would like to know what Agile Best Practices suggest here - to have defined team and allot work to them or create teams as per the inflow of work.
I would need to show any authorized/relevant PPTs, industry practices, use cases etc to prove which one would be the right path in the course of adopting Agile.
Please provide your input and few sources where I could get such use cases or best practices to suffice the thought. Saving Changes...
Long-lived, product/service/value stream-focused teams are generally more productive and exhibit higher levels of trust and psychological safety than traditional short-lived teams, but the decision to structure an organization that way needs to consider the longevity of the product/service/value-stream which the team will support.
No single model is foolproof - in long-lived teams, there is a higher potential for groupthink so it is a good idea to have some sort of a rotation process to add in "fresh blood" on a periodic basis.
No such thing as a permanent team. But as Kiron said, rotating every so often freshens the team, and lessons the risk for complacency. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
The 'to-be-scenario' would be the preferred if only one of the two were the options to choose from. The teams are best served co-located and long-term.
Ideally, if implementing Scrum, there would be Scrum teams created around specific focus areas, for example, within our organization, there is a similar exercise whereas the are teams for claims, small commercial, micro, PRS, etc. Each Scrum team is comprised of a Product Owner, Scrum Master, and Development Team. What is needed as part of the Development Team is dependent on the specific needs; UI, Testing, and Developers. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
What is an Agile Team? is about people that runs faster than stakeholders when things go wrong? Agile something does not exists. That is the first thing to understand. All related to create a team from a group is the same no matter the envionment in terms of culture and other type of things. For example, I am working with Agile with highly distributed, virtual teams with people that belongs to 65 countries around the world. We are using methods in some cases (Scrum and DSDM) and Agile principles to gain in agility into our owns methods. So, when you read some papers and books regarding the situation I am diescribing you could find that is imposible to work with Agile in this type of environments. Impossible is nothing. My actual work place is an example. But you have to understand what a team performing in quit different envionments is. Saving Changes...
Agree with Sergio. There is no agile team. What you need to strive for is a team that has an agreed and joint working culture and mindset. They need to know theie strength and weaknesses and how to collaborate. The team need to understand the importance of communication, feedback and continuous improvement. The team also needs to share an ageed understanding of accountablity and courage. An agile framework like Scrum can help to establish such mindset and behavior. Saving Changes...
Construction of your team depends on amount of work you have in your product. Do you have stories defined in your product, which you may want to implement. If that exercise has been done, you have a sufficient information to form a balanced team to accomplish certain number of stories and move on.
If this team size helps to grow and support your product have it for some time and define sprints and deliver.
Tester, Developer, Product Managers will all fit in their roles respectively, when you have stories on board. Saving Changes...
Khushboo, have you reviewed any of the following sites?
- scrumalliance.org
- scrum.org
- agilealliance.org
With regards to a defined team, it is recommended to have a defined team if you want to be able to consistently define the team's velocity. Velocity is something that you can't know the first time you run a sprint, and the more a team works together, the more accurate you can become at determining it. If you change team members, you may need a few sprints to recalibrate. Velocity, however, presents a bit of a conundrum in some organizations.
Velocity is not the end goal of the team; delivering a usable product is. But, there are several variables that affect a team's ability to deliver usable product. Velocity is not actually one of them, unless your team has been tasked to deliver specific functionality by a specific date. If you're given a hard date and hard requirements, you have to know your velocity to determine if you can meet the date.
One critical concept that all involved need to understand is that switching to Scrum does not guarantee you will be able to deliver finished product faster. There's no magic. In theory, you can deliver something functional faster, but not necessarily everything.
Here are some additional links you may find useful:
(disclaimer: I'm not endorsing any of the above companies, I'm just sharing potentially pertinent information) Saving Changes...
Khushboo SinghProject Manager| Envestnet|YodleeBangalore, Karnataka, India
Thanks for all the response!
I agree there is no fixed pattern/way to set up a team and it all depends on the team members on how they become self-sufficient.
But what I feel, this can be achieved after the teams come together; realize the benefits and become self-sufficient.
My points was when an organization starts to adopt Agile practices; a set pattern/structure would be useful. Post that teams would be in a position to define what should be needed and what not. And when we start what should be the best practice/way.
...
1 reply by Sergio Luis Conte
Dec 13, 2017 4:46 AM
Sergio Luis Conte
...
The same no matter the environment you working on.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Dec 12, 2017 11:15 PM
Replying to Khushboo Singh
...
Thanks for all the response!
I agree there is no fixed pattern/way to set up a team and it all depends on the team members on how they become self-sufficient.
But what I feel, this can be achieved after the teams come together; realize the benefits and become self-sufficient.
My points was when an organization starts to adopt Agile practices; a set pattern/structure would be useful. Post that teams would be in a position to define what should be needed and what not. And when we start what should be the best practice/way.
The same no matter the environment you working on. Saving Changes...
Community Champion
