Cracking the Agile Project Management
Cracking the Agile Project Management
Although Agile releases people from the fear of investing too much on a stupid decision, it can be rather confusing to apply.
In this article, you are going to learn:
- Differences between Scrum and Kanban board
- Step by step guide on setting up Agile in your team
- Tips to avoid pitfalls in every step.
Agile project management differs from traditional methods for its emphasis on the short feedback loops and adaptive cycles. By constantly releasing increments, advocates believe the Agile process is more adaptive to customer value and need.
It was first introduced in the 1990s to replace the heavyweight waterfall methodologies. It promotes continuouse improvements. The early 2000s witnessed a milestone to Agile methods. As 10 prestigious practitioners, including Jeff Sutherland, co-presented the famous Manifesto for Agile Software Development.
Since then, many diversions have evolved. Scrum, Extreme Programming (XP), Feature-Driven-Development (FDD), and Test-Drive-Development (TDD) are just a few of those. However, regardless of names, the essential principles stay the same --> to "de-risk" the business by iterative development, shortened feedback loops, and adaptive planning.
Among all those frameworks, Scrum is the most popular. One complete cycle entails five stages: visioning, sprint planning meeting, daily sprint, shipping, and retrospective. This article will focus on Scrum framework.
What are the differences between Scrum and Kanban
Before the guide, let's clarify two commonly used terminologies:
Scrum is a framework, a process
An Agile framework designed for small teams to break their work into actions that can be completed within timeboxed iterations, called sprints, commonly two weeks. The team track progress and re-plan in 15-minute stand-up meetings, called daily scrums.
Kanban is a visualization method for tasks
A lean method to manage and improve work, by visualizing work items to give participants an overview of demands and available capacity. The collections of visualized items are called Kanban Board. The board is also utilized in Scrum.
Kanban and Scrum are two methods. But for the prevalence and effectiveness of Kanban Board, the Scrum frameworks sometimes adopt this tool as well. Apart from terminologies above, you can also check more Agile Glossary in AgileAlliance.
How to set up the Agile practice
Step 1: Preparing - Build your team
Typically an Agile team consists of three roles: the Scrum Master (SM), the Product Owner (PO) and the developers. The team size is around 7(+/-2): 1 Scrum Master, 1 Product Owner, and 3-5 developers.
Scrum Master is on the developer side to make sure the project goes smoothly, and hopefully quicker. S/He should be a mediator or facilitator as a standalone role. However, based on the team interest, the tech lead or QA works well as a part-time Scrum Master.
Product Owner is on the project and user side. Product Owner is the business people and customer representatives. Consequently, Product Owners are often product managers or marketers.
Best practice: Avoid serious conflicts
Collaborate but not compete.
Scrum Master and Product Owner have a different focus and can go into serious conflicts. But remember, teamwork should achieve things collaboratively. The purpose of having three roles is to make the team full-functioning. That is why everyone within the team plans together.
Step 2: Visioning - Prepare the product backlog
Product Owner is the primary contributor at this stage. S/he talks to stakeholders and synthesizes a product feature backlog. Stakeholders usually include the executives, the sales and support team, the marketing team, users or customers.
The PO has to groom the backlog and to prioritize the features. And from this giant backlog, s/he articulates visions and following goals.
Best practice: Avoid the tedious
Automate the laborious process.
Feeding the product backlog is sometimes a tedious job. Collecting and tracking procedures can be highly repetitive. For bug fixing, the PO can connect the backlog with a bug-tracking system. Comment tracking tools and a social media management platform are also helpful.
Step 3: Meeting - Hold the sprint planning meeting
The meeting brings forward clear sprint goals and sprint backlogs. It usually lasts for less than an hour and happens early at the sprint week(s). Based on product goals and product backlogs, the team works together on splitting backlogs into shippable increments.
Developers decide the appropriate number of story points, the way to break down the goal into tasks and hence the sprint backlog. At the end of the meeting, the team should be confident on the scope and desired deliverables of this sprint.
Best practice: Avoid vague goal
Give clear expection for the sprint deliverables.
The sprint goal is NOT just randomly one or two sentences, but gives stakeholders the expectation on deliverables. It works as a quick report for stakeholders about what the team is doing. A clear sprint goal paves the way for measuring the performance of the delivery.
Step 4: Daily Scrum - Check along the way
Daily scrum (daily stand-up) meeting is for project status updates. It is best to arrange the meeting at the same time and in the same place every day during the iteration. The daily stand-up demonstrates Agile's focus on face-to-face communications.
Scrum Master should address the impediments to facilitate the development process. If there is anything severely affecting the sprint goal, the PO has every right to know it at once. In return, PO withholds the temptation of changing the sprint backlog.
Best practice: Avoid long meetings
Keep each stand-up meeting under 15 minutes. Notice that the meeting is like information sync within the team, rather than problem-solving. It is better to leave the problem-solving in other processes.
Step 5: Shipping - Release and retro
The release of the team is demonstrated at the end of the iteration. Stakeholders, inside or outside the organization are in the review meeting. By comparing the overall sprint goal with the achievements, the Product Owner can measure how successful the sprint is.
After the review meeting, the Agile team holds a retrospective meeting to reflect on what should be improved and what should be continued. For novice developers, it is also a perfect time to revise the expectation of velocity and capacity.
Best practice: Never skip the retro
Even if nothing goes wrong, the team should never skip the retrospective. Confirming what is right alone is helpful to future sprints. If the SM wants, s/he can even launch a vote for improvement proposals.
What are the limitations of Agile
Advocates claim that Agile practices are a balance between micro-management and no-management. However, critics arise from the experience of adoption. Some empirical studies have found no scientific evidence for the agility of the team.
As Agile emphasizes flexibility, it takes a toll on continuous quality control. The shortened project length implies acting quick and lean. That often comes with a lack of proper documentation and resources. Projects tend to lack continuity and integrity, making the principle of quality focus almost obsolete.
Agile is not suitable for highly risk-averse organizations or industries, say, pharmaceutical. These long-established industries have their clunky, yet important conventions to follow. Changing procedures against traditional management is extremely risky, if not dangerous.
That being said, countless successful examples are evidence that Agile works. Although there are pitfalls, the ever-evolving Agile frameworks provide tools and techniques, say Continuous Integration (CI/CD), Automated Unit Testing, and Code Refactoring, to at least remediate the problems.
Agile process advocates fast iterations, continuous improvement, and rapid response to change. It mainly consists of five steps: visioning, sprint planning, daily scrum, shipping, and retrospective.
This method is aiming for balancing between traditional methodologies and loose management. Although it lacks strong evidence and has pitfalls, the Agile process has its points to succeed.
How about your opinions? Tweet me to share your lessons and tricks in applying Agile methods :).