days
0
3
hours
1
3
minutes
3
4
seconds
2
3
search
Shhhhh!

Simple secrets to a successful Agile process

Gleb Bryksin
Agile
© Shutterstock / Victoria M Gardner

Not all Agile implementations are done well. How can you tell that your team has done it right? Here are Gleb Bryksin’s six signs that a company has a successful Agile process.

Agile can either help you work with no hassle or weaken your development team. Although the Agile principles are reasonable and trustworthy, their implementation often doesn’t work out in the real world. How do you know that your team incorrectly applies the Agile approach?

You should pay attention to several key indicators that confirm Agile isn’t working for your team. We’re going to list problems with Agile implementation and explain the steps you can make to solve those problems. In the end, you’ll know what you can amend in your team to make it agile and successful.

When Agile isn’t properly adopted

The “Agile isn’t properly adopted” statement is very vague. What this statement actually means is that your development team wasn’t truly ready to work according to Agile. That is to say the team had insufficient preparations for implementing Agile best practices. When Agile is already used by your team, it’s best to determine the main problems in your team’s workflow and tackle them right away.

Here are a few key indicators that prove Agile doesn’t work:

  • Incompetent scrum masters
  • No testing
  • Infinite standups and no retrospective meetings
  • Story points considered as success points
  • No feature planning and no product releases
  • No done criteria and clear requirements

Let’s now talk more about the listed issues.

SEE MORE: Agile banking needs a new core

Incompetent Scrum Masters

Scrum masters can be considered the glue that holds development teams together during each iteration (the development process must be divided into iterations, usually one- or two-week periods). A scrum master must not only create and maintain the list of team’s tasks, but also think of how to resolve emerging difficulties. If a scrum master knows about a problem but still assigns responsibility to the team member who told about this problem, then this scrum master isn’t properly doing their job.

To address this issue, you may find another scrum master with real-life knowledge of how the Agile process must be managed. It’s equally important to explain in details how a scrum master must actually work with the development team.

Infinite standup meetings and skipped retrospectives

Your team shouldn’t chitchat at daily meetings and it certainly shouldn’t skip retrospectives. (Retrospectives are comparatively long meetups at the end of sprints that help team members to determine issues and suggest solutions.)

First, when daily meetings last for 20 minutes or longer that’s a sign of poor time management. Daily meetings are necessary to help team members structure their work. Each team member must tell only three things: what they did yesterday, what work they’re going to complete today, and if they require any help to do their job. Simply put, keep daily standups short and to the point.

As for retrospectives, they help your team to summarize a sprint (the last iteration). During a retrospective, you should analyze the team velocity and problems that prevented the team from being successful. At the end of each retrospective, each team member should suggest  how to improve team workflow.

SEE MORE: IBM software engineers: “We needed to be more agile”

Story points as success points

Story points are often used to gauge team progress instead of estimating the development work to be done. Your team shouldn’t rely on how many story points another development team can earn in a two-week iteration.

When a scrum master or a product owner sets the target “do 40 story points in two weeks and no less”, your team will probably fail to deliver a product if it can do only 20 story points during a sprint.

The true idea of story points, however, is to help you determine how much effort the current team must put into a user story (a description of an individual feature).

Bad feature planning and no product releases

Product owners often want to create an ideal product with all bells and whistles before delivering it to users only to find out that most functionalities aren’t needed anymore. There’s another problem that happens during sprints: “We don’t need this feature right now. Let’s work on this one instead.”

Too long backlogs with too many tasks to complete and “urgent” tasks seriously hamper your team’s productivity. According to Agile, your team mustn’t work on each and every feature until all of them are developed, and only after that deploy the app. Your team mustn’t drop development of a feature before it’s definitely complete. Otherwise, your team won’t be able to deploy a new app version with new functionality after each iteration (a sprint).

But how can you make sure that the team delivers a product after each iteration? Planning features for each sprint lets your team be productive.

Instead of working on the product in huge chunks, the product owner and you should determine the core functionalities and break them into small sets of features to be implemented in a sprint. If suddenly a product owner wants to develop a new feature, you need to reschedule development of a new feature for the following sprint.

Deploying your application each two weeks will let your team test new functionalities on real users and react to market changes more rapidly than when an app is fully developed during a longer period. Besides, your team won’t leave the work half-finished after a sprint.

SEE MORE: How Spotify does Agile

Criteria and requirements

When a set of features to develop is established, it’s time to figure out how to determine if the features are truly developed. In other words, you need to define the done criteria, for example:

  • I can subscribe for the website.
  • I can view my subscription details in my profile.

We listed a couple of very concrete criteria that prove that the task is fulfilled. You should always specify what exactly the product owner wants. Having succinct descriptions of when a functionality is considered complete will help the product owner and web developers genuinely understand each other.

No testing is failure

Any functionality must be tested. Development teams must cover the codebase of their apps with automated (unit) tests. Only when the team writes test cases does it truly implement a working feature. When proper tests are done, your team can be sure that:

  • Removing bugs won’t be the main task for the following iteration.
  • Bugs won’t compile into a huge heap for the last sprint.

If a product owner asks your team not to write automated tests, you shouldn’t yield. It’s true that at the beginning product development will be faster without tests. But in a month, your team will waste time trying to figure out what exactly doesn’t work. Testing ensures that you can focus on rapid development and release an updated app in a long term. In fact, your team is truly agile only when it writes test cases.

We’ve mentioned six chief reasons why Agile doesn’t work for many teams and how to resolve emerging issues. Once you solve the mentioned problems for your team, they’ll be able to deliver successful products.

Author

Gleb Bryksin

Gleb is a technical copywriter at RubyGarage, a web and mobile development company. He likes writing on topics related to software development and digital technologies. Gleb has been in the industiry for over 2 years.


Comments
comments powered by Disqus