A big obstacle with Agile is that the business has to relinquish responsibility for project delivery and hand it to the team. Yes, that rabble of long-haired, bearded techies is your key to success.
Agile is something many companies like to talk about doing, but it’s not quite as simple as that. To be properly Agile in your projects you need to set your team up with the tools, skills and responsibilities required to perform to the best of their abilities. Agile does not start and end with a daily standup!
Authorise the team
The team is your key project tool. Without that tool, you cannot develop and deliver the software or digital services that you’ve promised your customer. Because you’re truly
Agile you also cannot expect to manage the project in the way you’ve been used to as a traditional project manager.
For a Scrum team to operate efficiently it needs to be given the authority to make decisions and deliver as they see fit. Of course, they will be given direction by the Product Owner but only on objectives and values.
Use the team’s skills
The Product Owner is responsible for giving direction, managing the priorities in the backlog, understanding what will deliver the most value, reviewing the value delivered in each sprint and protecting the team from the wider business. Input into the project from the business must only be done via the Product Owner.
A real Agile or Scrum team needs to have the power to make decisions as a team. The team has the skills and experience to develop the solution that’s been described and needs to be allowed to develop in their own way. The decisions they make will include their approach to the build, the architecture and the functionality.
A user story describes what the user expects, and the team will use their knowledge and understanding of this to implement the best solution. When writing user stories, it’s important to have a clear understanding of user requirements so these are accurately reflected in the stories and in the work.
Set clear objectives
Key inputs for the team in ensuring accurate delivery are clear objectives, well-written user stories and ad-hoc input from the client.
It’s no use just telling a team to deliver something. They need to know why they’re delivering a particular story so that they can identify improvements, provide better solutions and benefit the project with the quality of their skills and experience. A development team is not like labourers on a building site who just have to build what someone else has drawn out — they are highly experienced experts who can really contribute to the architecture and design to give the project the best possible result.
There will be times on a project when something becomes unclear, when the need for a feature or the solution to a problem is not obvious. This is where the Scrum Master and Product Owner need to be available to help the team by clarifying the objectives, user requirements and parameters.
Let the Scrum Master empower the team
The role of the Scrum Master, in this case, is not to provide answers but to create the environment in which solutions can be identified by the team. The Scrum Master should be there to ask the right questions and provoke discussion so that the issue is talked through thoroughly and the solution well-considered.
The Scrum setup is far more pressured and stressful for development teams compared to traditional project management methods. However, when delivering great products, the praise belongs to them.
By giving responsibility to the team under Scrum — having them make decisions, giving them the platform to demonstrate the results of their hard work and experience the delight of the customer — we create a real team cohesion that strives to produce quality deliverables.
Good for the team, good for the business
On the whole, most team members are much happier in their Agile role, provided they’re properly supported, and the results benefit everyone involved. In my experience, teams are better aligned and more driven to produce results. There are no occasions where a member of the team sits quietly at the back of the group not contributing.
Everyone wants to play their part, there’s no place to hide and the results drive them to want to continually produce better and better. This focus on quality is a benefit to all involved.
This approach to working does go against the corporate grain and can be difficult to make happen in an environment where there isn’t trust in the staff or suppliers. But it’s worth working hard to build that trust in because only by truly working in an agile way, on a foundation of trust and respect in each other can you really get a healthy web project. It really is in the best interests of the organisation to let the team take charge of its own work.