We all know that switching to Agile will solve all our problems. We can almost guarantee that adopting agile will be rewarded by a million per cent increase in productivity and ensure that we never miss a deadline ever again. It’s all so fresh and buzzwordy – how can there be a downside?
Unfortunately, as with everything, this is not quite the case. Agile when utilised properly can have a positive effect on productivity, it can go some way to helping make deadlines easier to hit. But when used badly, it can have completely the opposite effect.
There are a number of problems, or ‘smells’, we have identified in the Agile process that could be having a negative impact on all your good intentions. Here we outline some of the smells you may find in various elements of the agile process and give you some tips on how to spot and eradicate them.
The Agile Process
This document anticipates a certain knowledge and experience of Agile, and so will not go into any depth explaining the processes and ceremonies of Agile. If you are looking for more of an introduction to Agile excellent guides can be found here and here
Sprint Planning Smells
The Sprint planning session, or sessions depending on how you approach it, is the foundation upon which you build the entire sprint. Any problems at this point in the process could be setting you up for failure before you even get started. Here are a few problems we have seen that can arise during these meetings.
Hit By A Bus
“I know exactly how to do that, give it to me and it’s a 1 pointer”
There are always going to be developers who have more knowledge of certain areas of the application. The clichéd hit by a bus scenario, however, is a genuine risk; what if, once this 1 point story is added to the sprint, the “expert” developer is unavailable to do it? All of a sudden this story becomes a lot more complex due to having to find your way round code you don’t know so well.
Tip:
- Estimate every story as if you will be doing it
Swayed By Giants
“They said it’s a 1 point story, so I’m going to go with 1 point as well”
Every team is going to have a mixture of personalities and abilities, unfortunately this leads to a situation whereby some developers are reluctant to make their own estimates and instead allow their decision to be influenced by the stronger developers. The knock on effect is that the estimates are really only being done by one or two developers as the rest just agree. However the work is spread across the team, so these underestimated stories find themselves in the hands of developers who, while not estimating the story highly, believe it to be harder than their estimate.
Tips:
- As above, estimate every story as if you will be doing it
- If using planning poker cards, ensure everyone places the card face down first, ensuring that the initial estimate can not be influenced by others
Fuzzy Definition of Done
“That’s only 2 lines of code, it’s a 1 point story”
It may well be the case that the development of the story is trivial. But those 2 lines may be in such a core part of the architecture that the QA effort required to validate it will take days and days. With a formally defined Definition of Done, this can outline the steps required before a story can be marked complete. One of the key aspects of that should be, I am confident this code could go to production now.
Tips:
- Create a formal Definition of Done for the project
- When estimating estimate against this definition of done, not merely the development effort required
Anonymous Author’s task
“As a user I need better reporting”.
We have all seen stories that look a little like this. The problem is that this makes perfect sense to the author, but little sense to anyone else. If the author is unavailable during the planning poker session then you are left with two, fairly undesirable, options. You can either reject the story outright, citing a lack of detail. This is probably the better option here in order to protect the sprint, however it does go against the philosophy that we are all working together. The other option is to try to guess what you think the author wanted and estimate that. Which could threaten the sprint once it gets accepted if you have misinterpreted the story, particularly if underestimated
Tips:
- Ensure that stories go through a validation process before they reach the Planning Poker session. This can help avoid vague or incomplete stories reaching the session.
- If possible try to ensure that the author of the story is present in the session to answer any further questions about it
Premature Architecture
“We could implement a simple form here, but we’ll have to be wary of SQL Injection”
It really is no bad thing to be wary of SQL Injection, in fact it is to be positively encouraged. However this is not the forum to be having these kind of discussions. At this moment all we need to understand is how complex this story is, and thus how much relative effort will be required to complete it.
On occasion the manner in which the story will be tackled will need to be defined early, for example the problem could be solved by hardcoding a value in a page, or by creating an editable admin form. Clearly here the approach taken influences the estimate, but ideally this knowledge will be known before the planning poker session
Tips:
- Attempt to vet potentially contentious stories before they reach the planning poker session
- Consider the complexity of the solution, but not the finer details of it
Ramble on
“I think we should consider… then of course we need … but what about the case … then users in Tibet might find …”
Often in your planning poker session there will be a number of stories requiring estimation. Occasionally you will find the sort of scenario described above where the requirements are not quite specific enough and so the discussion goes back and forward with lots of questions and answers which either stretch this session out for longer than it needs to be, or meaning that some stories don’t get estimated as the time runs out
Tips:
- Ensure stories are clearly defined to avoid this kind of waffle
- Timebox each story, if an estimate can’t be reached in a reasonable amount of time then there are issues with the story
Standup Smells
The standup can be a somewhat misunderstood part of the sprint process. A common misconception is that each of the team members are reporting back on what they have been doing to their “superiors”. In fact it is quite the opposite, and should be viewed as such. The team is working towards a common goal, and the standup is the ideal opportunity to ensure that as a team you still are on course to reach that target. You are not reporting upwards, but rather sideways, ensuring that your team members are up to date with how the sprint is progressing from your point of view, while finding out how the sprint is progressing rom their point of view. Problems identified early, in this forum can be handled with a team effort ensuring any blockers get prioritised for the team’s common good. This leads us to our first standup smell.
Scrum Master Centred
“Yesterday I worked on X, today I will work on Y”
It’s not clear from the above quote (I couldn’t think of one that worked!), but the inference here is that the team member is ‘reporting’ on their day’s work to the Scrummaster, or Product Owner. The important thing to remember in the daily standup is that it is a forum for information sharing amongst the team. Not a mechanism for people keeping track on your progress.
Tip:
- Attempt to look at every single team member while you are giving your update
Turn Up, Tune In, Drop Out
“what, er, me? Oh ok. Er, yesterday I …”
Possibly as a consequence of the previous smell, namely Scrum Master Centered, because people treat the meeting as reporting to their ‘superior’, you quite often see the consequence is that people are essentially just waiting their turn to speak and not paying attention to the remainder of the team.
Tips:
- Mix up the order, perhaps using a ball, or other similar object, that the team pass to each other in a completely random order. This way anyone could be called upon to speak at any point.
- Remember this is much about you learning what your teammates are doing, as them finding out what you have been doing.
Ramble On
“So I started looking at … then I thought I might try … it didn’t do what I thought, but that was interesting … then it turned out that …”
This is not the forum to elaborate extensively on a particular thing you were working on, or a particular problem you faced. The standup is supposed to be a very short meeting, hence standing up for it. The 3 main questions each person should answer in a stand up are traditionally, “What I did yesterday”, “What I’ll do today” and “Is anything blocking me”. You should be able to get through those in under 30 seconds
Tips:
- Timebox each speaker
- Try to make your points concisely
- If necessary, have a further conversation with relevant members of the team outside of the standup environment
Hidden Impediment
“Today I’ll work on story Y, should take a few hours”
“Yesterday I worked on Story Y, I’ll keep doing that today”
“Yesterday I was still on story Y, today I’ll keep at it”
You’ll notice here that on the first day, the developer mentioned that he anticipated finishing the story within a few hours, yet 3 days later is still plugging away at it. This suggests that something unanticipated has come up and is getting in the way of the developer who, in this instance, instead of asking for assistance is doggedly working away at the task in hand. Clearly now this developer is behind schedule (having spent 2 unanticipated days working on this problem) and the knock on effect is that the sprint itself could be in danger.
Tip:
- Alter the language of the daily standup questions slightly, from what I will work on, to what I will achieve. This way, in the scenario above, the developer would have said on the first day that he would achieve story Y and when he hadn’t on the second day it would be more obvious that there may be a problem with this story.
Off Topic
“Did you see the football game / reality show result / interesting phenomenon last night?”
It may well be that the football game / reality show / phenomenon was the most fascinating thing to happen to the planet this millennium. But there will be all the time in the world after the standup to discuss it. The standup should be focused entirely on the sprint progress.
Tip:
- Stay on topic
Memory Problems
“I can’t remember what I was working on yesterday, but today I’ll pick up some task”
This is particularly common on the first standup after the weekend! These updates are of no use to anybody as they completely fail to address the overriding concern of the standup which is, “Are we still on track to deliver this sprint on time?”
Tip:
- Take 2 minutes before the stand up to reacquaint yourself with what you were working on, and what is likely to be your focus today
Problem Solving
“What was in the error logs with that problem you have? “
It may well be the case that you are struggling with a particular problem, and you mention that as part of the standup. The danger here is that the Standup gets taken over by an improptu problem solving exercise. This may not sound like a bad thing, after all we have the team together why not utilise that fact to try to get to the heart of this problem? The simple answer is that this is not the function of the standup, and it’s rarely the case that the entire team needs to be involved in this subsequent discussion. Identifying the problem, and identifying who can have input into the solution is the domain of the standup, but this actual discussion should then take place separately, allowing the standup to continue
Tip:
- Identify who can help solve the problem, then have a discussion after the standup
Talking Chicken *
“When will this feature be ready to test, it really is critical to our business”
Anybody related to the project should be welcomed, indeed encouraged, to attend the standup. However, as we have mentioned before, we need to remember the purpose of the standup and that is for the team to catch up with each other to get a sense of how the sprint is going. Just as this is not the team members reporting to a scrum master, it is also not the team reporting to an external stakeholder. An external stakeholder, such as a Product Owner, may be treated as a team member and provide an update of their own to the team, however they should not be given the licence to ask direct questions, such as “When will feature Z be ready”, or more dangerously, “What if it worked that way instead…”. The dangers of this range from the standup losing its purpose, through to scope creep, which we shall touch on later in the article.
* See the analogy of the chicken and the pig for the reasoning behind the title here
Sprint Smells
Now that we have got planning out of the way, and are happily working through the backlog as a team there are still a number of smells that can arise which threaten the delivery of the sprint. We analyse these in detail here.
Gold Plating
“I know how I can write this using [INSERT CODING TECHNIQUE DU JOUR]“
As developers we are always seeking a technical challenge, and ways to demonstrate our ability. However if left unchecked, these desires can lead to us unwittingly putting the sprint under threat by adding unnecessary flourishes to otherwise trivial pieces of work. As a deliberately ridiculous example, think of a story which has been raised to provide a couple of text changes to page on a website. Having been bogged down with stories such as this previously, you take it upon yourself to implement a CMS system letting the product owner make such changes in future. All in the best of intention aimed at helping save time ultimately. The only problem being that this initial story which was a trivial 1 pointer has now evolved into a completely new story, taking much more time and effort, and now meaning that the current sprint is under threat as the remainder of your tasks are unlikely to be completed in time.
Tips:
- Solve the current problem
- Don’t try to predict and solve every eventuality
Pulling the thread
“I don’t like the way this is written, I’ll just refactor it a little…”
Similarly to the above, it may be the case that you are working in a certain area of the codebase and you notice a piece of code that is far from optimal, and you can instantly see how to improve the code and perhaps improve the performance or security of this part of the application. It could even be the policy of the team that if you are working on a piece of code with insufficient code coverage or quality then it is your duty to raise that, even if it doesn’t directly correlate to your story. However the underlying danger here is that you start refactoring a piece of code and three days days later you are still trying to untangle code that is now so far removed from your initial story as to be unrecognisable.
Tips:
- Try to consider the current story complexity when considering refactoring. If the refactor effort will add a large overhead, then this is not the time for that
- Write a story detailing the refactoring required and try to ensure that it gets prioritised as appropriate
Scope Creep
“Well that is really good, but wouldn’t it be great if it did this…”.
One of the main advantages of Agile is being able to react to change, and to be open to this kind of request. However the sprint is a contract between the team and the product owner, and any change to this contract needs to go through a formal change process. This can seem overkill when the request is relatively trivial, but it is so often the case that when you do something once, it’s difficult to justify not doing it again. This is particularly an issue if the Acceptance Criteria are set, and this new change would go against these. Having a formal change review process would have the acceptance criteria altered as part of the process, meaning there is no cause for confusion between the developer and the quality assurance team. Allowing scope creep also may add complexity to the task, meaning there is a threat that the sprint will fail to be delivered due to this additional overhead.
Tips:
- Ensure that once the sprint has started that there is a formal process to go through should anything need changed
- Accept that these changes can happen, but ensure the project owner is aware that something already prioritised in this sprint may have to give to accommodate this additional change
Retrospective Smells
The retrospective is arguably the most important ceremony within the Agile process. It allows the team to dissect the previous sprint and analyse how they felt it went. Those aspects of the sprint that went well should be highlighted, allowing the team to self congratulate on a job well done, and actions should be made to attempt to continue doing the things that led to those successes. However, at least as important is the highlighting of those aspects of the sprint that did not go so well. Again, actions should be raised to attempt to eradicate any obvious problems that are contributing to these failures.
How to run a successful retrospective is beyond the scope of this document, however some good guides can be found here and here.
Utilised properly, the retrospective is a potent weapon in getting your team gelling and working well together. However falling prey to any of the smells listed below can result in the retrospective being little more than a waste of everybody’s time
Practising Insanity
“We’ll not bother with the retrospective this week”
We have all heard the phrase, widely attributed to Albert Einstein, that the definition of insanity is doing the same thing over and over and expecting different results.
Very rarely do you achieve the perfect sprint. There is always something waiting to trip you up. Unless you take the time to analyse how the problem came about, you will frequently find the same problem coming back to bite you again and again.
Quite often the retrospective is the first thing to get sacrificed when deadlines start looming. Unfortunately this removes the team’s ability to attempt to get to the root of any problems that may occur during the sprint. Without taking the time to acknowledge the problems, they will get ignored and there will always be the threat of these problems reoccurring in later sprints.
Tip:
- Stick to your guns. It’s going to be a difficult sell, but it is better to miss delivery of this sprint and ensure that the lessons learned get addressed, rather than sacrificing the retrospective for an extra few man hours of development only to get tripped up by exactly the same problems again
Lights..Camera..CUT
“Ok, good retrospective folks, shall we go to the pub?”
The second common problem with retrospectives is that they happen, they are productive, a lot of good content and self reflection happens within the context of the meeting, and then nothing happens. If you are going to the trouble of having a retrospective, then ensure that the outcomes of the retrospective get carried forward into not only the next sprint, but all future sprints. There are a number of techniques you can employ to ensure that you are making the most of retrospectives.
Tips:
- At the start of the retrospective, analyse the action points you came up with in the previous retrospective. Ensure that you have indeed been following up on these action points, to the point that they are becoming second nature. If you feel that you are still not naturally performing a particular action point ensure it gets carried across into this sprint’s action points
- Assign one or more action points to each member of the team, and make it their responsibility to ensure these action points are actioned over the course of the sprint
Conclusion
Agile itself is not a silver bullet that will instantly solve all your development woes overnight. It’s not necessarily even the best approach for your particular team. It is, however, a great methodology for fast reactive web design when utilised correctly.
As we have just seen, just blindly following the ceremonies and calling it Agile is not in itself going to guarantee any improvement in output, and could even have the opposite effect. With any luck you will not recognise too many of the items mentioned above in your own processes and you already have a high functioning team. Otherwise, hopefully this article will help you spot some problems in your process and assist you getting the most out of your team.
