5 Good Habits of High-Quality Scrum Teams

Kent Beck said it best: “I’m not a great programmer, I’m a pretty good programmer with great habits.”  What are some of these habits which help product development go from good to great?  Beyond test-driven development and SOLID design principles, there are five good habits that will improve the overall quality of your software and build high-quality scrum teams.  These are not abstract concepts, but tactical process changes I’ve seen work wonders on teams I’ve been on!

1 – Technical Implementation Discussion on Every User Story

Most teams these days have access to a physical or virtual whiteboard.  Use it!  Get the entire team (don’t forget QA) together and sketch out the application areas that will need to be changed to implement the feature described in the User Story.  This gives everyone on the team an opportunity to ask questions and voice concerns until you reach a common understanding.  Heck, some team members may just learn something about the software architecture from these discussions!  Not to mention, it is a lot easier to erase a line or change a design on a whiteboard than it is rewriting code.

2 – Test Planning Discussion on Every User Story

Once the implementation is understood by all, have a discussion on how the feature will be tested.  Jot down a list of areas you intend to write unit tests around.  What tests can be covered by an automated integration test?  Talking about testing will get the brain juices flowing.  The team will naturally think of the impact these changes will have on other areas of the application, so this good habit can prevent “oops, I forgot to update that report when we added such and such!”  I have found the more everyone understands about the implementation, the better testers they become.

3 – Effective Tasking

For software development teams, capturing their work in tasks is not easy to do.  However, teams with tasks on their Scrum Boards which really describe the work, tend to implement features faster.  I think this is because there has to be some implementation/testing discussions in order to create the tasks.  The level of detail included in tasks varies from team to team, but eventually, the team will decide what is “just enough” detail needed to provide clarity and visibility.  People do better when they can focus on small chunks of work.  Clear tasks that are small enough or isolated to particular areas of the application, also encourage collaboration.  If you find you are creating the same tasks on every User Story (i.e “Implement the feature”), then this habit might be something to challenge yourself to do.

4 – Swarming on Stories

To me, it is a simple concept, but one that new Agile teams rarely make a habit.  That is, the team working together on stories in priority order until they complete all tasks.  This does not mean a team cannot work on more than one story at a time, rather, the team is aware of what needs to happen to finish a story.  Working to finish a story takes priority over starting work on a new story or one that is far from being finished.  Truly iterative development involves completing User Stories throughout the Sprint.  If you are waiting to test all of your story work on the last day of the Sprint, try swarming.  Focus on finishing, not starting.

5 – Product Owner Sign-off

The Sprint Review demo meeting should not be the first time the Product Owner sees the feature!  It is important to get PO feedback early and often as development proceeds through the Sprint.  This is why my last good habit is doing a PO Sign-off of every User Story.  We simply create a task on our Scrum Board to track it.  When we are ready to show the new feature to the Product Owner, we use an integrated environment which has been built using the Continuous Integration server (not the developer’s local environment).  Anyone on the development team can lead the sign-off demo and any other team member can listen in.  The objective is to get feedback from the PO on whether the Acceptance Criteria have been met.  The sign-off process typically includes these actions:

• Read through each Acceptance Criteria and demonstrate it
• Updates to the User Story/Acceptance Criteria if they seem unclear
• Discuss what was tested beyond making sure we met the Acc Criteria
• Discuss any automated test coverage
• Allow the PO to interact with the user interface

At first, you might find you will attempt to get PO Sign-off on the the last day of the Sprint and fail to get sign-off.  This causes the team to rush making last-minute changes.  I know I don’t like working under pressure like that.  With some good habits, your team will learn iterative development with PO Sign-off well before the end of the Sprint.

Does your team need help adapting and improving? Contact us today about our Agile Assessment services, where we can help you identify and implement the kind of improvements you want to make.