Posted

Many teams are doing Agile activities and using the language of Agile approaches, but they haven’t truly embraced Agile ways of working.

Here’s how to tell if your Agile team isn’t really Agile.

You Are Not Responsible For All Of It

An Agile team is cross-functional. You have the Product Owner, Scrum Master, testers, developers, analysts and whoever else is required all part of the same team. There are no handoffs to other teams: deliverables don’t get passed out to a testing group and then arrive back on your desk.

If your team doesn’t have the skills to be responsible for everything necessary to deliver a requirement of value, then you aren’t a truly Agile team. That doesn’t make the way you work wrong! Handoffs between departments can be efficient and effective, and a fantastic way of delivering software. It just isn’t Agile.

Your Team Doesn’t Meet More Than Once A Day

Truly Agile teams talk. A lot. It goes beyond the daily stand-up meeting. Often successful Agile teams are co-located, so they can lean over and ask a question of a colleague, or quickly gather for a huddle to review a piece of work. Distributed teams rely heavily on webcams and sometimes don’t take their headsets off all day so they can easily dial up a colleague.

If your team members work virtually, but they aren’t constantly on the phone or instant messaging each other, then the chances are they are working perfectly well, but it isn’t Agile.

You Assign Work To Team Members

One of the best features – Agile teams would tell you – of working in an Agile environment is that there is no one to assign work to the team members. On an Agile team, individuals pick what to do next. The only criteria is that it has to be relevant to the user story at the top of the list. That means you can’t decide what to work on in three months’ time because the Product Owner might have reprioritized the backlog by then.

The benefit to this is that individuals can play to their strengths or develop skills they wish they had in a self-managing and supportive environment.

If you know what you are going to be working on the way into the future, and have meetings and dates in your diary relevant to particular deliverables, you aren’t working in a truly Agile team.

You’re Not Ready To Launch

Agile teams rarely miss deadlines! The way Agile approaches are structured means that each piece of work stands completed and connected to others but in a way that means it is entirely usable at the time of launch. There is no need to wait until other pieces of the puzzle are put together before you can deliver something working and ready for the customer.

If you can’t get ready to launch at short notice, delivering the work that is already completed, then you aren’t managing your work in an Agile way.

Again, that isn’t wrong. While Agile projects are put together user story by user story, other projects are delivered successfully by creating layers upon which new functionality sits. There is nothing incorrect in organizing your releases like that; it just isn’t Agile.

You Haven’t Delivered Anything Valuable Recently

Incremental, value-add releases are the cornerstone of Agile and the purpose of a sprint. Customers (internal or external) should regularly see what you are working on. They should provide detailed and useful feedback enabling the team to shift course if necessary to adjust to the changing needs of the client.

There’s a reason for this: if your customers aren’t happy with how things are going, it’s better to find out early in the process.

Non-Agile teams can also heavily rely on customer or user input. They should also be capturing feedback and lessons learned throughout the project life cycle. What makes an Agile team different is that they deliver working software, or something usable and of value on a regular basis – far more frequently than non-Agile teams. So if your team hasn’t shipped anything that customers can use in the last couple of months, you aren’t Agile.

Your Team Doesn’t Pitch In When Required

Finally, a big differentiator of Agile teams is the culture of collective responsibility. You don’t hear an Agile tester saying that it isn’t their job to elicit requirements. The team knows that they have collective responsibility for the output and for hitting the end of the sprint. There’s a sense that if you have spare time, you pitch in and help someone else out. The team doesn’t carry dead weight, and often Agile team members have a main specialty and then something else that they are competent at doing and can step up to do when necessary.

There tends to be a greater delineation of roles in non-Agile teams. This works well when individuals have multiple projects and there is no end to the stream of incoming work. Agile teams have a sole focus so when work in one area is light as the activity shifts to a different specialty, they need to act accordingly so that they aren’t sitting around waiting for more work to come in.

Whether you are looking for Agile specialists or more traditional team roles, Triumph Strategic Consulting can help. Get in touch today, and we’ll work with you to find the perfect fit for your team.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.