At one place I was at they were "Agile" and said they utilized "SCRUM" methods, but yet the PM's were running dev team meetings and really they were just status meetings that took a dev team of 3-4 people 30-45 minutes to get through, totally not the purpose in my opinion.
When I took over a team at that same company, I immediately took over the process and turned the meetings into roughly 10-15 minutes long where we announced roadblocks, issues and what we accomplished and were working on. If needed, we would schedule a separate time to discuss details of specific issues that needed more time. I still invited the PM's but didn't let them ask for status updates on each scheduled task or defect item. I would instead provide them a status update weekly as made sense, sometimes more often in the case of defects.
Personally, I have been part of a lot of environments even as a consultant and seen a lot of varied implementations. At least from my experience the ones that try to layer it with every possible role, and have separate scrum masters etc just aren't as successful. I personally think they miss the point. The idea is to remove layers of process to make all teams more effective, not just development. I have a feeling that the original scrum concepts were perverted by PM consultants and training courses which added back in lots of process and layers to something that is supposed to be lightweight and nimble.
IMO the ones I always see the most successful are when a technical lead is running the process, at the dev team level. And the PM or product owner is interfacing with only the team lead or maybe one person between the team lead and themselves. This removes unnecessary layers, keeps the dev team focused, and still gives great insight for the business into what is happening and makes the process pretty damn fast. It does mean that a team lead is not coding as much, they are instead focused on keeping the monkey off the dev teams back, but that is kinda the job role. In the one place, I was their Chief Software Architect (as a consultant) and I acted as the go between for team leads and the business, which worked well because the team leads stayed more heads down and I could articulate both architecture and schedule issues back to the business. That was really successful, but a little sole sucking for me.
So practically if in an environment we should apply a strict Scrum implementation, there is no role called Team Lead and the team lead can be seen as a senior team member in the scrum team?
In a strict Scrum implementation there is none. But there are team activities which are not governed by Scrum even in its best implementation - like vacations, business trips, performance evaluations, time and status reports for PMs or any other higher-ups etc. These things often end up as responsibility of one single person and then he is most often called a Team Lead.
I'm a team leader and my company is now migrating to an agile scrum organisation. It seems that the direction is to remove the team lead role and replace it by line managers and scrum masters. Can these 2 positions cover the team leader roles? Can we keep the team leader role in a Scrum organisation?
Strictly speaking, the closest thing to a "team lead" would be the ScrumMaster. In a scrum, all team-members are just "developers", there's no hierarchy or differentiation in status between them.
The ScrumMaster is less of a PM, and more a "Servant Leader"; their role is to empower the the other team members, get road-blocks out of their way, and keep stakeholders/product-owners from butting in during a sprint.
6 comments
[ 3.3 ms ] story [ 27.0 ms ] threadAt one place I was at they were "Agile" and said they utilized "SCRUM" methods, but yet the PM's were running dev team meetings and really they were just status meetings that took a dev team of 3-4 people 30-45 minutes to get through, totally not the purpose in my opinion.
When I took over a team at that same company, I immediately took over the process and turned the meetings into roughly 10-15 minutes long where we announced roadblocks, issues and what we accomplished and were working on. If needed, we would schedule a separate time to discuss details of specific issues that needed more time. I still invited the PM's but didn't let them ask for status updates on each scheduled task or defect item. I would instead provide them a status update weekly as made sense, sometimes more often in the case of defects.
Personally, I have been part of a lot of environments even as a consultant and seen a lot of varied implementations. At least from my experience the ones that try to layer it with every possible role, and have separate scrum masters etc just aren't as successful. I personally think they miss the point. The idea is to remove layers of process to make all teams more effective, not just development. I have a feeling that the original scrum concepts were perverted by PM consultants and training courses which added back in lots of process and layers to something that is supposed to be lightweight and nimble.
IMO the ones I always see the most successful are when a technical lead is running the process, at the dev team level. And the PM or product owner is interfacing with only the team lead or maybe one person between the team lead and themselves. This removes unnecessary layers, keeps the dev team focused, and still gives great insight for the business into what is happening and makes the process pretty damn fast. It does mean that a team lead is not coding as much, they are instead focused on keeping the monkey off the dev teams back, but that is kinda the job role. In the one place, I was their Chief Software Architect (as a consultant) and I acted as the go between for team leads and the business, which worked well because the team leads stayed more heads down and I could articulate both architecture and schedule issues back to the business. That was really successful, but a little sole sucking for me.
The ScrumMaster is less of a PM, and more a "Servant Leader"; their role is to empower the the other team members, get road-blocks out of their way, and keep stakeholders/product-owners from butting in during a sprint.
Hope that helps.
For more info, I'd recommend starting here:
http://www.scrumprimer.org/scrumprimer20.pdf
And then jumping into this book if you're really interested in the topic:
http://www.amazon.com/Agile-Project-Management-Developer-Pra...