I’ve been a working Scrum Master for a number of years now; having also been a developer for 18; and in that time I have helped create a number of new Scrum Teams, generally with team members that have never worked in Scrum before. In that time I have come across a number of issues in these teams but I would say the biggest 3 have to be
So, lets take a little look at these in more detail and how to move your teams forward with these issues.
With software development in the past; many of use have used something such as Waterfall to design and develop projects and software. This involves doing all the design up front and then working on all the project until it is finished. We may break down components in to separate executables but we generally didn’t break down into small sections.
The engineers I have worked with that were moving into Agile and Scrum have always worked in this way. So; getting them to think smaller can provide some challenge. The idea is to break down items into the smallest possible stories; so even (if you wanted) down to a single button if it provided value to the release. Engineers that have only ever worked on delivering complete and runnable executables sometimes have difficulty seeing smaller deliverables that the complete solution.
It takes time and effort to show them that you can break down items. It also takes time and effort to show them how they can go smaller and smaller. Start with a complete shell and move down in size until you can get them creating stories which are small enough to deliver in the minimum effort - but which still have value to the deliverable.
Another issue is sizing. Many engineers in many software development projects size in time; days; weeks; months and so on. So, to get them to use story points where no time value is associated is very alien to them. Most seem to find it difficult to size in story points which relate to complexity without assigning a time frame. They also find it difficult to grasp the idea of team capacity based on these story points.
The easy solution at the beginning is to allow some loose times/days against story points; at least until they feel comfortable in sizing in points only. Over time they grasp the idea; and when capacity is stable they see that days and times are irrelevant. A sprint is a sprint (never changing in time) and a capacity is a capacity so they will grasp the sizing in complexity. Just remember to always fine your smallest story point (1 point) item first.
The third thing I find the teams have problems with is Scrum Events (or meetings as they are). Many say that they never had so many meetings before Scrum and that its taking more time away from their development.
This again is about educating the team. Many seem to thing that the purpose of going Agile and using Scrum is to release items faster; which is not the reason. The reason is two fold. Firstly; its about iterative release so that you release in small complete sections and these go to the customers that are feeding into the project; so that an changes can get fed back.
The second reason; and I feel most important; is about improving the quality of the release and the team. This is where the scrum events are invaluable. A good scrum event (meeting) will identify issues early one. They will help improve the team; the quality of the product and eventually create a great self organising team that release software with fewer issues up front. This is what you need to show the team.
The listed above items are things I have found during my Scrum Mater days. Do you agree or disagree? If so then please leave me a comment. If you want to know more on the subject then please check out the link below. this is to a Udemy course I have produce on the subject of Creating a new scrum team. By using this link you can get this course for just $9