This is a special guest post. Interested in having your work featured here? Email me at email@example.com
By: Kevin O’Shaughnessy
1. Mix up your retrospectives
First of all make sure that you are regularly doing the retrospectives. If you are skipping them, you are missing perhaps the most important part of the Agile process. Looking at your recent performance is key to determining what’s working well and what needs to change in order to improve.
But doing your retrospectives in exactly the same way every time can be boring and lead to that “groundhog day” feeling of doing the same sprint over and over again. Combat this by mixing up your retrospectives. There are many good ways to conduct them. Choose some different plans from this list.
Also don’t rely on the scrum master to always run the retrospective. Instead have a different member of the team run each one. You will be pleasantly surprised with some of the ideas that your colleagues come up with.
2. Allow time for continuous improvement work
Delivering user stories for the business is always important but so is doing work in order to improve your capability for the future. For example, having realistic test environments is critical to your success, but setting these up right takes time. Also having a full regression test suite is needed to prevent bugs going live, but they don’t get written by themselves.
Your customers will never be happy to wait for delivery until after all of this other work is done. Instead, reserve a small percentage of your time each sprint for doing continuous improvement work and have a meeting at the end of each sprint to agree on the most important work to do next.
Setting up a build screen takes some time initially, but is a big time saver long term.
3. Your interaction/sprint burn down chart should cover everything
As well as your user stories, your team may have IT Administration work to do or urgent incidents to fix. Maybe you have continuous improvement work to do. All of these should be included in that burn down chart. if you want to separate the user story work from everything else, it is okay to draw two lines on the chart, but use different colors to make it easy to see which is which.
The reason it is important to cover everything is because if you are running behind schedule, any work missing from the chart will get inadvertently deprioritised as you try to get the user story work back on track.
4. Use Lego avatars on your task boards.
Electronic agile boards are everywhere, but there will always be some advantages of sticking with physical boards. Physical boards are available for anyone to see at any time – any business user can come over to your team area and immediately see the latest progress on their story. No need for them to interrupt you to ask for a status report because it’s all there in front of them.
With electronic task boards, you have extra work to make sure it’s available to anyone who might be interested without being available to the whole world (you don’t want your competitors knowing all this info). If you use an electronic task board you may find that every time a new business user becomes involved you have to stop to give out the URL again.
It’s important that everyone can see what everyone is working on from their own desk. Initialling a task card is not a good way to do this because it’s very hard to read from more than about 10 feet away.
A better way is to use Lego characters on magnets. These are much more identifiable, and you’ll be surprised with how quickly everyone learns everybody else’s avatar. It also has the advantage is dissuading too much multitasking. It is a big myth that you need to multitask in order to be productive at work. Multitasking is actually one of the biggest productivity killers. Key to productivity is being able to focus on one task and do it well.
Lego avatars on a task board, with all characters working on in progress tasks.
5. Practice TDD, but not before you understand what it really is and the purposes of both schools
The Internet is awash with both fanatical hyperbole on TDD (Test driven development, also known as Test First Development).
The Internet is also full of posts from people who have briefly tried it, found it too difficult or confusing, and dismissed it as something that just doesn’t work.
I hope that this post avoids falling into either of these categories. TDD is a tricky topic to teach because there are so many myths about what it is and what it is for. So I will briefly address some of them but simply stating that TDD is NOT
- A silver bullet
- A way to avoid manual testing altogether
- Primarily a testing activity
- Writing all of the tests first
- Forming 100% of design specification with unit tests
- Guaranteed to lead to a good design
- Guaranteed to catch all bugs
- No good for bigger projects
Concepts such as the 30 second red-green-refactor cycle, coupled with toy examples such as the string calculator or the bowling game, can give the impression that TDD is something that can be done with minimal thought. Nothing could be further from the truth. It’s no coincidence that in Extreme Programming, along with Test Driven Development one of the required practices is Pair Programming. A coding partner can make the world of difference in the quality of your design, and the quality of your tests.
There are two schools of TDD. These go by a number of different names for the same thing.
The most common type of TDD is Classic TDD, also known as bottom up TDD, triangulation, state based TDD, Chicago school of TDD and Detroit school of TDD. This style is the easiest to learn and is particularly appropriate to testing code that is algorithmic in nature. If you want to get your feet wet with TDD in some but not all development work, classic TDD skills will do that for you.
The other type is outside in TDD, also known as the London school of TDD, behavior verification, mockist TDD and also behavior driven development (BDD). Outside In TDD is not actually quite the same thing as BDD but I’ll skip that conversation for now
This is generally more involved than classic TDD but has the advantage of being able to test not just the smallest units but how they interact with each other. This means the tests can be used not just for confirming low level behavior dreamt up by the developer, but acceptance tests required by the business user.
Done right, TDD will have a bigger impact on the quality of your code than anything else. Done right, it will also increase the rate at which you can work faster than anything else. But learning how to do it right is something that takes time, effort and patience.
Fortunately there are lots of books on TDD that can help you and your team learn and improve. Two books that I would recommend are:
- The art of unit testing by Roy Osherove
- Growing object oriented software guided by tests by Freeman and Pryce
There are also some good video courses, as well as a number of consultants who can give your team expert tuition.
If you are introducing unit testing and/or TDD to a large legacy application for the first time, (and I include applications written in modern languages as legacy applications) you are making large investment in the future. Do not be naïve and think that you won’t make mistakes along the way. You have a steep learning curve and a huge amount of work ahead of you. Most of the code there already will NOT be testable. Before you can unit test it, you will need to refactor it. When you refactor it, you will need to regression test it. All of this will take time, and in the meantime you will still have your regular development work to do. It won’t be easy.
Does this mean you shouldn’t bother? Well what are the alternatives? Keep your legacy codebase in a mess? Adopt a do not touch the legacy code policy? Plan a gigantic rewrite of the whole system? This last idea can be tempting, I mean think how much better all this ugly code could be with a rewrite! Well, I would definitely recommend that you read this first.
6. Improving your velocity is NOT the aim
The aim is to increase value for the customer and satisfaction for the customer. There is two parts to this: keeping your customers happy now, and keeping your customers happy a year or two down the line.
Key to keeping your customers happy now is being able to listen and respond quickly to their changing needs. This is one of the main reasons why in 2001 representatives from SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming settled on the name Agile when writing the Agile Software Development Manifesto. Welcoming changing requirements is a key part of the manifesto because changing requirements are inevitable and accepting them is essential to customer satisfaction.
The other part is keeping your customers happy a year or two later. This means not creating messes. It means having a mechanism to measure the technical debts in your applications and a strategy for reducing the overall debt. Keep a technical debt backlog and make sure it is regularly looked at and action is regularly taken to reduce your debt.
When starting Agile, it’s natural to think that improving your velocity sounds like a good performance objective. You may find that you can achieve big gains in velocity initially, for example if you are starting off with a very bureaucratic process, developers will typically increase velocity by throwing a lot of it away.
But you will find that this can only last for so long before the only way to gain a higher velocity is to work longer hours or take dubious shortcuts. Neither of these is a good idea.
Instead, once you have reached a good velocity, aim to maintain it. Focus on quality, not velocity. If you do this, you will find later stories can be done much more efficiently – for example instead of being a 8 point story it’s a 2 point story because that last story you did automated much of the work for you.
Now say your team has a velocity of 16. Instead of doing two user stories like this in a sprint, you can do 8 of them. But what’s happened to your velocity? It’s still 16. The senior management can’t see any improvement or give you credit for the extra work that you’re getting done.
This is why the velocity figures are often neither important nor relevant. They are just abstract numbers used to give a rough idea of how long something will take and how much it will cost. These numbers should never be compared between teams.
7. More haste, less speed
Once upon a time, in a land not too far way, a multinational company, Goldsoft, had a very large project it needed to outsource. So it put it out to tender.
Two companies, harebrained agile solutions and extreme tortoise engineering plc gave similar quotes and pitches, talking about how they would use Agile practices to deliver high quality software at great value.
To see which company most deserved the contract, both were employed to implement the same subset of features. This would be an end to end client server solution and the winner would be the first company to deliver a fully working solution.
The CEO of harebrained agile solutions, Mr H. Brain, gave the order “just get it done, and FAST!”. And the hares sped off to work. Within a couple of days they were estimated to be 90% complete.
Meanwhile the head tortoise insisted that all tortoises would use test driven development, behavior driven develoment and continuous integration. The junior tortoises said they didn’t know how to do these things very well, and they agreed to pair up with the senior tortoises. They split the project into 20 evenly sized user stories, agreed a priority order with the product owner but insisted that the top priority was to get tortoise continuous integration servers exactly the same as goldsoft’s servers.
After a couple of days, getting the environment right was the only thing they had done. They realized they were only about 5% complete.
A few days later, the junior tortoises were starting to get the hang of the extreme engineering and were gradually working more effectively. Meanwhile, the hares were almost done. They were about 90% complete.
The customer and product owner was working with both companies, and as soon as he realized he needed a change of requirement or two, he would tell both companies at the same time. Both the hares and the tortoises agreed to the changes, although the hares jumped around a bit first. The tortoises accommodated small changes into existing user stories and asked for bigger changes to be raised as new user stories.
The hares were upset because the changes meant they had to change their design, and weren’t sure what the changes would break. They now estimated they were 70-80% complete.
A couple of days later the hares had gotten everything working on their own machine running in localhost. All that was left was to upload everything to Goldsoft’s servers and prove everything works. They found that it didn’t run at all. The first server wasn’t talking to the second server.
A week later the hares had got the system running but after a couple more days going through all of the manual test scenarios, they were criticized by Goldsoft for the amount of bugs they found. The hares scribbled down a list of bugs to fix and started furiously changing code. The hares found out that the tortoises were now 80% done and worked even faster and harder.
The hares worked all day and night to fix all the bugs. They were exhausted when they demoed it to Goldsoft and even more exhausted when Goldsoft told them that all of their changes had just introduced a new set of bugs! The hares worked all day and night again to fix these, but Goldsoft found yet more bugs. The hares were now living in debugger driven development hell!
Meanwhile the tortoises successfully demoed their final user story to Goldsoft. And Goldsoft knew that the tortoises hadn’t introduced any regression bugs because they had a full suite of passing unit, integration and UI tests. The tortoises won the multimillion dollar contract and lived happily ever after.
Perhaps you are suspecting that I just made that story up? I couldn’t possibly comment! But what I do know is it never a good idea to rush your work no matter how much pressure you are under. Rushing risks expensive mistakes.
In the story, the hares followed what Martin Fowler termed “flaccid scrum.” This is following the scrum guide but not doing the engineering practices required in order to work safely.
This appears to be a time saver at first, but after a while regression bugs start slipping into the code, the code becomes more and more unmaintainable, the cost of manually testing everything becomes more and more unfeasible, and developers end up spending more time debugging messes than doing new developments.
The team with confidence in their well thought out practices is often slower at first, but over the longer term they deliver much better software, more quickly.
8. Story points estimation is effort not complexity
Many people get confused about the story points estimation. What do the units represent? Hours? Days? No, there is no unit. They are just an abstract concept used to roughly measure the size of one story against another. When giving an estimate, you will consider how complex it is, but you are not giving an estimate of how complex it is. You are giving an estimate of how much resource is required to deliver it. It’s effort not complexity.
9. Avoiding last minute Product Backlog Grooming
Grooming meetings are one of the less enjoyable parts of Scrum. Firstly the name itself is horrible. After several inappropriate jokes around the office, we came to the consensus of calling them product refinement meetings instead. Much better!
Another thing is there is never a great time to do them. The team is always in the middle of working on the current sprint stories and interrupted by them. Scheduling these meetings at the start or end of the day can be a good idea, but it is more important that all of the relevant business users are present so that they can answer any questions the team may have.
These meetings are vitally important because the alternative is to go into sprint planning with a story that the team doesn’t understand. This is virtually guaranteed to result either in wildly inaccurate estimates, or the story thrown out of the current sprint in order to do some spike work and the business users having to wait at least another sprint before delivery of an urgent story.
User stories presented to the team will typically be incomplete. The purpose of the meeting is to improve the story and any provisional acceptance criteria associated with it. Sometimes the user stories will be inappropriate altogether and the team may ask for it to be removed or merged into another story, or for a large story to be broken up into smaller stories. All of these are positive things.
A common problem is user stories coming in very late on and getting pushed as urgent. One of the principles of Agile is to welcome changing requirements, so the team should try to accommodate the needs of the customer in general, however it is important to be consistent with business users about what is expected of them and that they understand that the work needs to be sufficiently discussed in these meetings to give the team a reasonable understanding of the requirements before committing to the work.
The product owner must understand that he or she is expected to present enough work to last about 2 sprints beyond the current sprint. Preferably each user story will have an initial set of acceptance test criteria, but these should not specify the nature of the solution to the problem. The development team has the most knowledge of the system and is therefore best placed to decide and seek agreement with the business user on the best solution to the business needs once they are understood.
In these meetings, story point estimates are given. These are only a very rough indication and the team should not spend too long arguing if there is a small difference of opinion. For example if one person votes 2 points and 5 people vote 3 points, unless the individual has a very good reason he should agree to go with the consensus of opinion.
10. T.E.A.M: Together Everyone Achieves More
There are many differences between Agile processes and waterfall based methodologies. Some people say the most important difference is getting used to not writing as much documentation.
It’s not. You write documentation whenever there’s a strong need to do so. The biggest difference is the emphasis on the team. There are teams in just about every methodology, but mostly the individuals in the team participate in group work rather than real teamwork. In Agile, and especially in Scrum, everything is about teamwork.
You either succeed or fail as a team. If another member of you team has a problem, you have a problem.
Your performance objectives should be team based. Not everybody likes this idea because it can lead to weaker team members getting rewarded for the work of stronger members and stronger members getting penalized for the mistakes of weaker members.
This is actually rarely the case. In practice, members of the team who appear to be weaker are usually just inexperienced in certain areas and can improve dramatically with the right coaching. It is usually a good idea to include some element of personal performance or contribution to the team success as part of staff objectives, but the majority of the award should always be based on the performance of the team.
To facilitate strong teams, it’s important not to move teams around too much. Teams need time to gel and that can’t happen if team members are constantly moving in and out. Occasionally a change to the team is a good thing: it can bring new experience, new perspective and new ideas into the team. But if the team needs to change make sure that it is right at the end of a sprint. The team will have committed to delivering based on the team it has at the start of the sprint. Don’t jeopardize that by taking a team member away mid sprint.
A good team can be much stronger, and achieve much more, than the individuals working apart. If a team works really well together, all individuals will feel responsible for everything their team does and doesn’t do and feel guilty for letting down their teammates if they don’t perform well.
An example of this is Olympic Gold Medal swimmer Ian Thorpe, who regularly swam faster in the relays than in the individual events. The reason is in the relays he was swimming not just for himself but for his team.
There are many articles that explain the strength of a good team: