Archive for Scrum
Planning
Posted by: | CommentsI really appreciate that amount of time we spend in planning for a sprint. For a two week sprint we spend one day in planning. I know in the past that teams that I worked with thought this to be a “waste” of time. They wanted to start programming. My new team is developing a habit of doing sprint planning which will be very beneficial.
We are tasking our user stories with a high level of detail. Most tasks are not more then 4 hours in length. This is helping the team to better understand what needs to be done. During the planning session yesterday we moved some user stories to the backlog because the product owner was not clear on the requirements. In the past this would have lead to development churn or wasted time during the sprint. It is much better to discover this at the beginning of a sprint through sprint planning.
Planning for the two week sprint also helps the team to understand inter-dependencies. Having smaller sprints gives the freedom to move stories to the backlog.
Team vs Team
Posted by: | CommentsI have been thinking about teams and teamwork. Every company I have worked for will say that they have teams of developers working on a project. But what type of team are they working on?
Growing up I participated in teams sports. As I reflect on my high school years there were two types of teams I played on. I participated on both a track team and a football team. Let’s look at these teams.
Track Team
On a track team each team member has their own specialty and tried to excel at it. We as individuals tried to finish high in our event so that we could get points for the team. The team that had the most points in the end won the meet. When I ran the two mile run it was up to my performance in how I finished. During training I would get suggestions from others on technique but individual performance was key to creating team success. No real collaboration was need when we participated in the meet. The only place you saw collaboration was in the relay races.
Football team
I also played football in high school. This is a team sport where collaboration was critical. We had a play book to memorize. Each team member had to know their position on the team and usually several other positions in the event someone got hurt. We huddled together, heard the play and then we executed. Practice during the week focused on the execution of the plays in order to prepare for our game on Friday night. We worked on perfecting our “product” so it we could have a good “demonstration” for our “customers”.
In my experience most teams in a large organization are like a track team. The teams are made up of highly skilled developers with very little collaboration between the developers.
A Scrum team is more like a football team. We have a play book we must execute against. Our understanding of the play book and our role on the team is important for success. Also, being able to learn other roles and assist where ever needed is important for a team.
What type of team are you on?
Self organizing as a team
Posted by: | CommentsHave we paralyzed our workers so they do not have any initiative? I recently started forming a new team and ran into several issues. We defined a product backlog and tasks to be done in this sprint. When the planning was finished the tasks that an engineer thought he was going to work on were removed from the sprint. Mind you there is enough work to do in this sprint to keep the team busy. This engineer though he had nothing to do because his tasks were removed. Then the resource manager was upset because they had put the member on the team and they had nothing to do.
This is prime example of the individual not thinking as a team member. This individual must realize they are a member of a team whose goal is to produce a successful product. We need to adjust to the needs of the team.
Community of Practice
Posted by: | CommentsAgile practices are built around cross function teams. The team members may become isolated especially if they are specialist such as user interface developers, testers, etc. Companies should encourage Community of Practice.
Community of Practice are groups of people who share a concern, a set of problems, or a passion about a topic and who deepen their knowledge and expertise in this area by interacting on a ongoing basis.
p. 263 – Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
This allows a developer to interact with other developers so that they can keep their skill sets current.