10 Signs That Indicate Your Team Is Moving Away From Agile

1. Long Daily StandUps

Daily standups are always timeboxed. So if you are seeing that standups are taking hours then it should be understood, its not the daily status/commitment/collabaration thats being part of the standup but we are trying to either micro manage each aspect of work or discussing and revising plans for the sprint on the fly. Most of the time impediments gets discussed for quite a long time in standups and much annoyingly to some team members, an impediment for one member need not make entire team wait for an hour of discussion. They can definitely be raised/shared and resolved seperately if need be.

2. Team Relies On Being Managed Than Self Manage Agile teams are expected to self manage in an ideal world or atleast the member has to be able to manage his own work. Should you see a particular person or a role influencing or managing the team instead of working collaboratively, then i guess you are dropping away from agile.

3. Team Recognizes and Operates in Hierarchy Agile teams are teams with core competencies to deliver a piece of work. It works best when teams initiate, own, collaborate, assist each other than follow a hiearchical structure. If you see such structure in term of defining and dictating work along with loads of approvals for your work to go through….hey remove the tag “Agile” from the team.

4. Team Grows To More Than Expected Size (20 to 30 in some cases) A typical agile team is good when it has less than or equal to 10 members. If we are executing agile based development with over 20/30 members than you are better off breaking that team to smaller size. A typical scenario is where teams start with smaller number but eventually end up growing in size and hence the complexity to manage, deliver and track deliverables. This also complicates effective collaboration and focus on value added delivery.

5. Teams Less Receptive To Change Agility is all about how good you are to progress when there is a sudden change to what you do. If your team is less receptive to take changes or understand the Product Owner perspective of why things have to change on a continuous basis then there is a need to educate the team. One of the core reason to switch to agile is to be able to accept change and plan in time in short cycles.

6. Requirements or Design Docs Becomes Pre-Requisite To Develop Agile Manifesto encourages working software over comprehensive documentation. While i can understand this does not mean “No” to documentation but certainly would like to emphasize that we dont want to end up having a “Requirements” or a “Technical Design” document for each of the backlog story before development begins. You would probably end up doing something called WAGILE a hybrid of Waterfall and Agile.

7. Sprint has Analysis/Design/Dev/Test Phases A typical statement from some teams “We moved from Sequential to Agile based delivery” and what we see is every iteration has analysis/design/development and test/release phases. If you see such phases creeping into your teams plans then you may have managed to move back from agile. Any story that is not clear in a particular sprint on what and how to implement then it is better to take it up in the next sprint.

8. Excuses To Build Code Atleast Once A Day or Worse a Week Continuous Integration is a key aspect of agile based development, however i get to see teams building code once a day or two days and in some cases once a week. The common excuses being “Our code base is very complex and cannot be built every now and then”, “We have dependency projects and if we build then rest of the teams will get impacted”. I must say there are wonderful tools to handle all such scenarios, instead we are better off allocating our time to explore one of these tools which can resolve our issues.

9. Stories Are Treated COMPLETE On Test Environments A story in my own mind is said to be complete once it has delivered the expected value. However many teams deliver the stories to test environemnts, complete acceptance tests and consider them as closed. Please note that unless the value is delivered a story cannot be treated as complete or approved. There is every possibility that the story delivered to test environment is hi-jacked/overwritten by others before it is released and benefits realized like Santa in the image who is hijacked :).

10. Sprint Goals Does Not Stack Up To Anticipated BUSINESS VALUE Agile identifies itself with “Valud Added” delivery rather than defining a set of requirements and delivering them in a particular order. If a team is delivering sprints continuously and successfully but without definitive end goals based on business value, time for the product owner to identify this crack and ensure every sprint has identified goals and has business value associated to it. If it means to change backlog regularly so be it.