Organisations tend to have problems transitioning from the waterfall methodology to agile. This blog will illustrate some of the common pitfalls which organisations seem to make when they are trying to adopt the agile approach.
Fear of Failure
Teams that adopt agile seem to have this fear of failure and no one wants to take responsibility of a failed iteration. Initially, when adopting agile the first few iterations will not be as expected as, the team are still trying to understand how agile works. It’s expected that there will be a few failed iterations but this will teach the team a lot of lessons mainly their velocity. Teams should learn from these lessons and there should be an improvement in future iteration. However, if the problem persists without justification then the problem needs to be addressed as a cause for concern. This could be detrimental to the success of the product.
Often teams that are new to agile seems to have this perception that they have to include all possible requirements for the product upfront. Again, leading to the aforementioned point of fear of failure. The downfall of this is that teams often spend most of the sprint planning rather than developing which recurrently leads to technical debt as they have had to compromise. The agile scrum methodology allows for feedback every iteration (sprint) via Sprint Reviews. Thus, teams should only include stories that are needed for that iteration rather than future iterations as requirements can change at any time due to the nature of agile and it’s constant interaction with the customer. There’s nothing worst than planning for features that the team thought was needed and the customer coming back after saying they’re changed their requirements. If Agile is done correctly teams will be able to be rapidly change to customer requirements thus inspect and adopt stories.
Daily stand-up Used Incorrectly
Daily stand-up meetings are used to update the team on work which has been completed the previous day, which work is being worked on and any issues that is causing a blockage which then can be addressed by the Scrum Master. However, these meetings can become a place were people use it to ask other team members how they can solve an issue. Often you’ll have team members explaining to others how they can resolve their issue which in turn isolates other that are not included. This also waste time that could be used on development. If a team member has a idea of what the solution to a problem could be this should be discuss outside the meeting with the relevant participants. Have a look at our daily stand up best practices blog.