Last month, we hosted a webinar on Challenges and Successes in Agile Implementation featuring BlackLine’s Greg Burns and Ron Ben Yosef. So far, we’ve covered five of six questions from webinar viewers, including developer to tester ratio, and agile acceptance criteria. For this last question regarding Agile Velocity versus Non-Agile Velocity, we got both Greg and Ron to weigh in.

Question: What if your non-agile teams get stuff done faster than the agile teams? xbosoft logo-knowledge center

Ron: I highly doubt they can, because a non-agile team requires a long, detailed document that covers a lot of aspects. That takes time to produce; moreover, in a non-agile team we don’t have the stakeholders involved as much as in agile. Our stakeholders take part in our process, participating in sprint reviews every two weeks that allows them to give feedback about our output and better guide the team toward the stakeholders’ vision and the client’s needs. The alternative is developing a solution which is not necessarily aligned with the stakeholders’ needs. Overall, reaching the right solution has proven to take longer in a non-agile team. That being said, if we can deliver the right solution faster in a non-agile methodology we will switch to that. We are constantly challenging our methodologies and process and encouraging everyone to experiment with other solutions.

Greg: It’s hard to say without understanding what methodology is being used in the place of agile, and what phase the company is in.  I believe a team can work faster without agile if they don’t have a use for (or don’t care for) the “benefits” such as the ticketing, visibility, priority management, documentation, and responsiveness to clients.  I know I may sound facetious, but I don’t mean to be.  I’ve experienced start-ups that put process aside altogether because the teams were incredibly small and nimble.  I would argue though, that at scale, if a non-agile process is working faster, there’s probably something wrong, perhaps with the agile implementation or elsewhere.  I would also caution people to analyze what “faster” means by using metrics.  For example, there may be the perception that features are being delivered more quickly, but how are the quality metrics?  How many times are you having to revisit or abandon features because they do not match your clients needs or are not being adopted?

When looking at agile teams and non-agile teams, the best indicator to determine quality work is by looking at the metrics you are using. Agile teams are essentially meant, in method, to deliver the end product faster than non-agile teams, so when a non-agile team is faster than your agile teams, this might be reason to double check the quality of the non-agile team’s process.

Check out the rest of the BlackLine Q&A series with Greg and Ron: