ARE YOU A “GURU” OR A “NOVICE”? DO YOU DARE TO TEST YOUR MASTERY?
#3 Mistakes of Development Teams
As I write this post, I am thinking of the many great teams I’ve had. Some more eager than others to try new things, but for the most part they were all courageous and willing to learn. Out of my experience with them I like to share the 3 mistakes agile development teams make when starting out and here is what to do about it.
One of the most impactful mistakes I see consistently made by agile development teams is lack of designing just enough for a sprint. What do I mean by this? Let me explain.
Architectural path is supposed to emerge in agile. However, there are some teams that forget to leave enough time to create a high level idea of how they will be addressing the architecture of the increment of work. So they will start the sprint with out clear path. The danger in this is the amount of rework that can come out of this. Don’t get me wrong, incremental work already has an expectation of rework, but it could be minimized by just enough before a sprint.
The sprint goal should include a clear high level architectural direction. Sprint planning should answer not only what needs to be done, but how it will be done. I like to recommend to my teams to take time out of the refinement meeting right before the next sprint to go into a deep dive of how they will be executing. They have the “what” at this last refinement before the sprint starts, so it is perfect timing to meet and discuss the architectural direction.
The following is from Mary and Tom Poppendiecks’ book Lean Software Development: An Agile Toolkit. “Think big” implores teams to maintain an overall vision and direction for the architecture of the system. An architecture that is incremental yet emergent doesn’t mean that no one is anticipating and looking toward the future. Someone needs to be plotting out the strategic architectural direction of the product and anticipating the needs of the business. This is not a big up-front design, but just enough for the sprint. Brock Argue wrote a good article on this for the Scrum Alliance, however I don’t encourage that this should be done at Sprint Zero, as if you are really doing scrum, there is no Sprint Zero. Take the time after refinement or during Sprint Planning to come up with a high level design.
The second mistake agile development teams make is not testing. Unfortunately there are many developers who fail to even unit test their own work, thinking the tester will catch their mistakes.
Quality is owned by the development team as a whole, no such thing as a tester role. Yet many teams make the mistake of thinking testing must be done by a tester. Developers should not only unit test their work, but should lend a hand in testing the increment of work. They must apply the all hands on deck mentality for the quality of the product.
I encourage teams to include at Sprint Planning time to review their definition of done. This will keep the whole team aligned. This is also a good time to announce anyone who has bandwidth should jump to testing. Make sure you test as much end to end as possible.
The third mistake agile development teams make is taking on too much work in a sprint. This is one mistake consistently repeated by many new teams. The want of proving they can do it, or trying to please is strong in new teams.
The challenge new teams face is knowing what there velocity is to know how much to take on. There isn’t enough data for them to use. This is why I like to take teams through a capacity plan and tasking at sprint planning. The capacity plan will help them know how many hours as a team they will have to plan against. I know, there is a lot of noise out there that says this exercise is wasteful. However, if you have a team who is completely new, simply saying make the stories small enough for one days work isn’t going to cut it. Teams need to come to the realization they only have a certain number of hours to work in and they need to learn time management.
In order for a team’s pace to be sustainable, they can’t be working seven days a week and 24 hours a day. This exercise teaches them to manage their time. Once they have this, they can move to velocity planning.
Ok, now it is your turn. What mistakes have you seen agile development teams make?