Go, Go, Go, STOP!!

When an organization decides they want to “Go Agile”, they usually go through a multitude of changes before they get into a rhythm of the method(s) they have decided to use.  Once a team gets into a rhythm of ‘going’, or just doing, they will most likely be so engrossed that they forget to look up and see where they are.  However, it is important that they stop at some point to examine how things are going overall in their Agile journey and whether or not their method(s) are working for them.

The most popular framework that teams choose when first moving toward being Agile is Scrum.  In order for a team to really grasp the idea of sprints and incremental development, they will need to do a number of sprints before stopping to examine themselves; one sprint does not give the full feel for the changes and mindset shift that occurs.  Whether they stop after 4 sprints or after 10 sprints, the team will usually feel one of two ways:  “Scrum seems to be working for us; let’s keep it up, using continuous improvement to get better, and examine again in another few sprints” or “this doesn’t seem to be working; let’s forget Scrum and just do the work”.

When a team feels that Scrum is working for them, they have usually tweaked the framework a bit to allow for their team to feel they are abiding by the Agile Manifesto the best they can to ensure value.  As teams work together, they will tend to work toward continuous improvement and look for ways to work with the customer to ensure their satisfaction.  They will strive to continue to tweak their process to be successful in being Agile.  This type of team is most likely tightknit and feels good in the rhythm they have gotten into—so much so that they may not want to stop to examine, but realize they need to.

The other feeling that comes out is the aforementioned “this doesn’t seem to be working; let’s forget Scrum and just do the work”.  When a team has been doing Scrum for a while and they take stock of where they are, they sometimes conclude that Scrum is more work than they want to expend.  They can see the ceremonies as too much time wasted or that the timebox simply doesn’t fit their needs.  When this happens, they typically chose to abandon the framework and simply ‘work’.  They could just leave Scrum behind and choose a different method to become more Agile, but usually that is not the case because they have come to believe that the road to Agile is the problem; not its implementation of the method or framework.  When the team abandons Scrum, they don’t just abandon the sessions, like sprint planning or retrospectives, they tend to abandon the mindset that being Agile instills.  As they move away from Scrum, they also are likely to shy away from concentrating on the customer and the value they can provide to the customer, which is the core of the ‘Agile way’.  They see the ‘failure of Scrum’ as ‘failure of Agile’ because somewhere along the way, they have equated the two: Scrum = Agile and Agile = Scrum.

As the team ‘does what they want’ and does not follow any Agile methodology, they can easily fall into the trap of ignoring the customer’s wants and needs to the point of missing the mark.  When this happens, we have to examine why the team chose to move toward Agile in the first place:  to deliver what is really needed/wanted and not just what is listed.  If they don’t feel Scrum is working, the team will have a tendency to focus on what they want to do and stuff they find easy. In the end, the product is not what the customer is looking for; there tends to be wasted effort and time.  This wasted effort then results in many other issues with the project/product like not meeting dates, going over budget, risking the cancellation of the project/product, etc.

With all this said, it is not every team that reverts to ‘just working the list’; some simply find other avenues to be Agile other than that of Scrum.  These are the teams that understand that Scrum is maybe not for them, but understand that their attempt to be Agile is not the problem.  These teams usually find a way to move to other methods more suitable, such as Feature Driven Development, Extreme Programming, or even Kanban.

It’s important to remember that the point is to take time and examine what it is that is working, or not working, overall.  Most teams do this at the retrospective, but that should be focused on the team and the sprint.  There should be a time when teams do a more encompassing retrospective that looks at the process as a whole, which would look at things like release planning and working with other teams in the organization.  It is crucial that they take stock of what is working and what is not so they feel empowered to make changes to be as Agile as they can be!