If you read articles on the current thoughts on project management, it appears that traditional project management and agile project management are at odds with each other. A good project manager pulls from both frameworks to help ensure that communications happens. Processes need documentation to allow a clear discussion with stakeholders. Understanding the mindset of transparency, values and people in Agile and leveraging just enough process steps creates a success environment. (Dr. Dobbs, Survey Says…Agile Has Crossed the Chasm Scott Ambler, July 02, 2007)
How does Agile Project Management Fit?
Agile project management methodology gives developers a direct connection to the customer. Companies using agile project management and the scrum methodology deliver value to customers through building products within a fixed budget and time. Customers and designers work together discussing the product requirements ensuring that a common understanding exists between the teams. By producing working interim deliverables, customers offer guidance to the next iteration, reducing project failures.
Is the Scrum Methodology Agile Project Management?
The scrum methodology represents one of the dominant frameworks used in North America to apply agile principles. Product managers and teams find the framework readily adaptable across a broad array of projects and products. Everything from software development to catering customization benefits from using the scrum method. The word scrum was borrowed from the rugby analogy given by Professors Takeuchi and Nonaka in their paper The New, New Product Development Game (Harvard Business Review, 1986).
Who is on a Scrum Team?
Let’s look at the players in the scrum methodology framework:
Product Owner(s): The product owner gathers requirements, organizes features and deliverables – all prioritized by business value. The product owner consolidates client requirements into prioritized sets based on market value. The product owner also determines the deliverables release plan as well as accepts and rejects the work results. The product owner must be different from the Scrum Master. The Scrum Master and product owner need to be able to express differing opinions. The Scrum Master’s primary role of removing roadblocks usually means negotiating with the product owner on the ranking of features. If one person holds the role, the scrum team suffers.
Scrum Master : The Scrum Master helps the team resolve issues and improve productivity through enabling close cooperation between roles and functions and ensures the interests of the product owner are preserved. The Scrum Master also protects the team from outside distractions thereby avoiding delivery delays. Scrum Masters do not manage the teams, nor are they product owners. Good Scrum Masters work to resolve issues and help the team be as successful as possible. On smaller teams, the Scrum Master could be a team member who splits their time between their regular role and that of Scrum Master.(The scrum framework doesn’t need a project manager role. The traditional project manager responsibilities reside in the three scrum roles. Scrum Masters may be former project managers, but there is a major danger doing this. The person has to recognize the fundamental difference between the traditional role and the new role.
Scrum Team: The team selects the goals and work results. They self-organize and show work results to the product owner. The team also provides the product owner with ideas and inputs to the final product.
Stakeholder: The stakeholder helps the product owner define the project goal and vision. The stakeholder is actively involved in plan meetings, as well as in helping team members regularly prioritize components.
I understand who the Players are, but how does the framework WORK? The Scrum framework utilizes sprints that are restricted in time. Usually a sprint is limited to a month in length. The product owner starts the project by collecting requirements and identifying product features and making a prioritized list. The Product owner sets the highest value lowest cost feature first and then ranks the features to the lowest value highest cost feature at the bottom. The product owner routinely updates the list based on customer, team and stakeholder feedback. Rather than talk through a project, let me put it into a 7 step action program.
Step 1: Conduct a planning phase where the product owner defines the goals. The product owner describes the product vision that eventually evolves into a list of product features.
Step 2: The team works directly with users to understand and write user stories in the user’s own words. The user stories are simple written descriptions for planning. The most important part of user stories are the discussion of what the user meant. Each user story goes to the product backlog. Think of the product backlog as a list of prioritized features representing everything that could be done by the team to the project.
Step 3: Create a high-level design where components are prioritized and valued. The product owner finalizes the high level architecture of the product, outlining general design criteria for the stakeholders. The product owner assigns a business value estimate to each item, usually with the help of the Scrum Master. The team, Scrum Master and product owner estimates how many features could be included for the release, by factoring effort, uncertainty and complexity that could be accomplished over the sprint. If the team has run multiple sprints, they have a good understanding of how many features they are able to build during the fixed time frame.
Step 4: Hold the sprint planning part 1 meeting. The product owner, Scrum Master and team review the high priority items that are part of the release backlog subset. The group also approves the definition of done for each feature. The focus of part 1 planning is on what product owner wants.
Step 5: Hold the sprint planning “part 2” meeting. The focus switches to how the team will construct the items. The team owns the process. They commit to complete the items selected from the product backlog by the end of the sprint. Teams complete the highest value work first and work their way down the product backlog until all work is committed for the time of the sprint. This key difference makes scrum work. The team commits to delivery and not have requirements dictated by senior management. The product owner and team approve the release backlog subset for the sprint.
Teams may choose to use web-based tools or bulletin boards. Teams running some of the best sprints have used the simplest tools. Experienced teams usually create realistic estimates of how many features to include in the sprint.
Step 6: Run the Sprint. During the sprint, the Daily Scrum meeting helps focus team members on three important aspects.Daily Scrum Agenda
- What did each team member carry out since the last daily scrum meeting.
- What does each team member plan to finish by the next scrum meeting
- What blocks or issues could prevent team members from achieving their goals.
The daily scrum should never be longer than 15 minutes. Preferably, the team should be standing and the meeting should be high energy and fast paced. Do not include management or others who could be perceived as authority types. The team succeeds when the daily scrum reviews the three key points. Anything else will undermine the self-management of the team.
The burn down chart shows what work remains compared to the planning standard established during the planning meeting part 2. At the end of the sprint, the work is assumed to be 0. Most teams post the burn down chart with the backlog board in a central place for all members to see. If the blue line is above the green, then the work is behind schedule. Each team member adjusts their delivery to meet the needs of the sprint. If blocking issues arise, they are discussed during the daily scrum.
Step 7: End the sprint and review the results. The focus of the review meeting is on the product. Sprint duration cannot be extended. If the sprint finishes early, the team may need to adjust their estimates for future sprints and take on more backlog. If the team over-committed, some of the product features will need to be returned to the product backlog for the next sprint.
Step 8: Hold a sprint retrospective. The focus of the retrospective is on the process. This is critical in helping team members grow and improve. Team members give feedback to each other completing the self-management circle. Simple facilitation by the Scrum Master focusing on what worked well and what could work better usually results in a productive meeting and process improvements. At this point, the team created a working model for the product owner and stakeholders to use, try and to make adjustments to the backlog.
Some projects end with one sprint. The customer likes the product as-is and the company delivers another successful product. Other projects have multiple sprints where features and user stories are added, tweaked or rebuilt based on customer and product owner inputs. User stories are considered and prioritized. Before the next sprint, the product owner re-prioritizes the sprint backlog to merge feedback from stakeholders on the product. If new user stories result, the team prioritizes the user stories with the product backlog.
Agile project management allows stakeholders, developers and customers the opportunity to work together to create a successful product.