Many teams are able to produce significantly better and faster software with Scrum than with other development models. Let’s take a look at the components that make up Scrum’s DNA to find out why.
The Funnel Focus
The product backlog defines the product vision, the release backlog defines the release goal, and the sprint backlog defines the detailed and granular tasks for the current sprint. With this divide and conquer strategy, teams are able to focus on small, concrete tasks at hand during the sprint without getting bogged by big-picture complexity. At the same time, however, the big picture is always clear and is never out of sight.
User stories are an excellent way to capture the requirements into product backlog. They not only capture what needs to be done, but also capture who will use it, how, and why. Likewise, shorter time boxes and acceptance criteria keep up the time and result focus. The team’s awareness, interaction, and collaboration help focus on software creation, which enables the teams to use lightweight processes and documentation. Additionally, one of the ScrumMaster’s responsibilities is to eliminate distractions that get in the way of team focus. These elements come together to allow the human brain to deliver more, with greater focus and with manageable complexity.
Ownership and Autonomy
During the sprint execution anybody can pick up any task they like. This provides an excellent learning opportunity for team members when they choose tasks beyond their comfort zone. Since the whole team participates in task breakdown and effort estimation, everybody contributes and learns from each other to make a wiser team day-by-day. As a result, the feeling of ownership and autonomy gives team members much more commitment and passion towards project execution.
The Team Attitude
Scrum believes in cross-functional and self-organizing teams. It’s an approach that respects a person’s individual capabilities and skills, but at the same time does not brand team members with labels like “quality-person,” “database-person,” “UI-person,” and so on. It expects team members to play on each other’s strengths and fill weakness gaps as they arise.
With Scrum, teams strives for a common goal -- they all win or lose together like a team sport. Victory is not possible without collaboration and trust. When political pressures arise, they are balanced and addressed within the context of Scrum roles and responsibilities. The Product Owner owns the requirements roll-in and cares for maximizing the value of team’s efforts. The Team cares for execution, delivery. and quality. The ScrumMaster cares for running a healthy scrum and solving impediments.
Scrum turns a group of individuals into a team with a mission.
Sprint information is not embedded in a set software tools --it’s on physical scrum boards placed in public places and the tasks are touchable cards. The scrum boards have all the information the team needs consolidated in one place and typically include sprint status (tasks planned, in-process, done), the burndown chart, the number of open issues, the obstacles, the status of the done criteria, leave plan, etc. With this method, the actions/deliverables of the team are visible to the team (and everybody interested).
Daily stand-up meetings provide a good forum to build healthy peer-pressure, ask for help, or gauge the need for help. Good scrum meetings bond the team and sharpen the focus towards the sprint goal. Additionally, the sprint burndown chart gives a very good picture of how the current sprint is happening, while the release burndown chart provides a higher level picture of how development is coming along in relation to the release goals. They offer timely and excellent opportunities to ‘Inspect and Adopt,' the core principle of scrum. The Scrum method offers constant visualization of physical progress, and other information widgets are have much more impact than their softer counterparts!
It is wonderfully motivating to see software being shaped brick by brick and provides a great sense of achievement to individuals and the team with every passing day. Scrum meetings offer team members the opportunity to talk about the group’s progress every day and it’s not uncommon to see teams applauding an extraordinary achievement during meetings.
The sprint review meeting is a platform to showcase the product to customers, stakeholders, management, and other interested groups. Direct customer usage and feedback on the product during and after the sprint provides immediate and constant verification of what is being done. Nothing motivates individuals more than immediate recognition, appreciation, and feedback from people that matter.
Retrospective meetings provide an opportunity to identify and solve the most critical issues facing the team. It also forces teams to think harder and uncover less obvious issues before they become monsters. Short sprints allow experimentation and the chance to try things that, on the surface, seem absurd but later turn out to be wonderful solutions.
The Fun Factor
Scrum uncovers the otherwise hidden joy of building software. For instance, the Planning Poker component of Scrum is as much fun as it is effective and efficient. Celebrations at the end of a sprint are surely warranted after a lot of hard work. Work hard, party harder, because if we enjoy what we do, then we’ll do it better.
Management and Customer Viewpoint
The Scrum method offers management good visibility and predictability about the software under development. It inherently motivates people and builds ultra-productive teams. Conversely, customers benefit from the method because they can see, touch, and feel the software each step of the way. It’s much easier to take a look at the running software and decide on requirements along the way, rather than try to imagine all of them upfront. Since customers give concrete feedback during development, requirements can be added and changed anytime into the product backlog, no one cribs!
As you can see, all the strands of Scrum's DNA are equally important. It's a method that works because it is built around the nitty-gritty of the two complex things that matter most when it comes to building great software -- the software itself and the humans who build it.