Scrum is a method, agile is a mindset !
Agile methodology is an alternative to traditional project management, mainly used in software development. It provides opportunities to assess the direction of a project throughout the development life cycle through regular iterations, also knows as sprints.
Agile is something we are, not something we are doing.
The agile manifesto was written by a group of software developers at a time when delivering good software was hard. It helped to establish a way of working that favoured human interaction above swathes of documentation and tedious processes.
Like most of us, I also believe that teamwork is essential to deliver a great software. Nothing is more rewarding than sharing the adventure of building something that truly matters with engaged teammates.
Scrum is the most popular frameworks for implementing agile. It’s so popular that, many people think agile and scrum are the same. We can use many other frameworks to implement agile. At QPlay, we are following Scrum.
When it comes to adopting scrum. It is important for a prospective scrum team to know exactly what they are signing up for. Agile team is a cross functional group of individuals, who has the ability and authority. Which help them to define, analyse and build, in a short iteration time-box called, the sprint.
As such the team includes developers, tester, scrum master, product owner, and other resources such as UX, architect, sales and marketing. Scrum team have collective responsibilities to deliver the valued output which they commit to.
With scrum, the product is developed in a series of fixed length milestones, called sprints. By the end of each such sprints, the team must present a shipment-ready product increment. In case of waterfall method, the development team only gets one chance to get each aspect of the project right, where in an agile paradigm, every aspect of development including requirements and design are continually revisited thought the lifecycle of the project. Since the team re-evaluates the direction of a project every sprint (say two weeks), there’s always time to steer it in another direction.
A scrum team has three main roles, there are:
1. Product Owner
Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritising the work to be done by the engineering team accordingly.
Effective product owners:
- Build and manage the product backlog
- Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
- Give the team clear guidance on which features to deliver next
- Decide when to ship the product with the predisposition towards more frequent delivery
2. Scrum Master
Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimise their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.
Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.
3. Development team
Scrum teams are the champions for sustainable development practices. The most effective scrum teams are co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams approach their project with a clear “we” attitude. All members of the team help one another to ensure a successful sprint completion.
Since the scrum teams are cross-functional, ‘the development team’ includes testers, and designers in addition to developers.
Despite sharing common values, there’s no formula for the perfect agile team. Even though agile recommends co-located teams, sometimes an agile team might be distributed across geographies. Most agile teams possess all the required skills for the development of the particular project.
A sprint, as already discussed, is a fixed length milestone. Usually, a sprint can be 1–2 weeks long, based on the team, and project behaviour.
Agile meetings are an important part of development. There are four such important meetings, there are:
- Sprint Planning
- Daily stand-up
- Iteration review
Sprint planning has to be conducted at the beginning of a sprint. It requires the development team, the scrum master and the product owner to be involved.
It usually take an hour per week of iteration. So for a two week sprint, a two hour planning meeting is required.
Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritised product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
Daily stand-up meetings has to be conducted with the development team, the scrum maser, and the product owner. It has to be conducted once a day, before starting the development. It shouldn’t last for more than 15 minutes.
Stand-up is designed to quickly inform everyone of whats going on across the team. It’s not a detailed meeting, each team member has to answer the following questions:
- What did I do yesterday ?
- What will I do today ?
- What impedes me from performing my work as effectively as possible?
During the scrum, only one person talks at a time. That person is the one who is reporting his / her status. Everyone else listens. There are no side conversations. Our time is valuable, so we must be efficient.
Team members should not digress beyond answering these three questions into issues, designs, discussion of problems, or gossip. The scrum master is responsible for moving the reporting along briskly, from person to person.
Iteration reviews are to be conducted at the end of each sprint. It needs the development team, the scrum master, and the product owner to be involved. It should last almost an hour.
It is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedbacks. Remember, work should be fully demonstrable and meet the team’s quality bar to be considered complete and ready to showcase in the review.
It is to be conducted at the end of an iteration. As all other meetings, retrospective also needs to have the development team, the scrum master, and the product owner to be present. It should last around an hour.
Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn’t.
Retrospectives aren’t just a time for complaints without action. We use retrospectives to find out what’s working so the team can continue to focus on those areas. Also, find out what’s not working and use the time to find creative solutions and develop an action plan.
Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
Even if things are going well across the team, we don’t stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
To enable agility, decision making power and responsibility should be implemented at the lowest possible level in an organisation, ie. in a scrum team. If people are allowed to do what they think is best for the company, they will take ownership. Management steers only through communicating strategic priorities and (measurable) business goals. Scrum teams are trusted to figure out for themselves how to achieve these goals.
Just implementing scrum in our software development department is not enough to become truly agile. Many companies ignore the necessary changes in company culture, management style, processes and way of executing projects.
Agile culture starts with a basis of trust. Management trusts that the best solutions emerge from having the right people collaborate with each other. People are given the trust and freedom to autonomously explore ideas and solutions, without needing to ask for permission. It’s no problem if something fails. Failure and learning from failure is encouraged, because experimenting and failing are the prerequisites for innovation.