What about quality? - Part II

“Quality means doing it right when no one is looking.” (Henry Ford)

Do you remember Petra and her team from my last article about quality? We identified some of the practices which led to poor quality of the delivered software, like no clear responsibilities, a neglected Definition of Done and no transparency about code quality. But did we cover all of them? I am sure you noticed that I missed some of the team’s “bad habits” in my last article ;-)
Let’s see what else the team could change to improve on quality.

Don’t work in isolation

Alex didn’t have the time to write unit tests for the last new user story because integrating the feature branch took too long. But why do we need feature branches? “I don’t want to interfere with the work of my teammates.” is the answer I hear quite frequently. When asking “Aren’t you working on the same user story?” I might get one of the following replies: “Yes, but he is the front-end guy and I am doing the back-end.” or “No, the story is too small to be working on it together.” or “No, because I was never involved in the offline implementation.”

These or similar answers tell you that the use of feature branches, apart from blocking the team because of merge conflicts, also exposes some other issues: the team is not truly cross-functional or it is not focusing on the story with the highest priority.

Using only the mainline without feature branches supports the developers in working together as a team and it prevents the creation of silos where only one person knows a particular corner of the source code. Frequent integration of changes means close collaboration and calls for communication. Don’t let some tool or process force you to create a separate branch for each feature, this will prevent the team from getting instant feedback when something is broken.

Use the team’s energy to share knowledge by doing pair programming or code reviews within the team - instead of wasting time merging a feature branch at the end of a sprint.

Own the code

“I am not going to touch that piece of code.” “We can’t take this story into this sprint because Ingrid will be on vacation and no one else knows how to change the database layer.” “I don’t care what Alex’s code looks like as long as he doesn’t mess with my well-structured classes.” Sounds familiar? Then your team has not yet embraced the principle of collective code ownership.

First thing to remedy these behaviors is to establish a basic set of coding guidelines which everybody in the team will use. Let the team establish these guidelines, since all team members should agree and consider the rules useful - which, of course, will provoke some debates on the “right” style. Going for the simplest set of rules as a start should help to keep the discussions short. (In cases where more than one team is working on a codebase you might want to find a common set of guidelines across all teams.) Adherence to these guidelines can (and should) be enforced on commits using various tools such as styleCop or Checkstyle.

Encouraging pair programming and joint code reviews will not only help to spread the knowledge, as mentioned above, but will also contribute to a sense of shared ownership for all parts of the code. The Scrum Master can support this process by facilitating the collective design of the architecture and user story implementation in the Sprint Planning II meeting. (You find some examples on how to do this in the Using taskboards correctly article.) If the whole team is involved in drafting new functions, concepts and classes, then everybody will be held accountable for the resulting piece of software.

And finally...

Care for your tests

Test code is often neglected and not really cared for. Because it’s only “test code”. That’s not fair. How often were you lucky to find a tricky bug after a little bit of refactoring - which otherwise would have crashed your customer’s database? Don’t you like that cozy feeling when all your tests are green after you checked in your latest changes? Would you be so relaxed discussing change requests with your customer without the confidence that your suite of tests will tell you that everything is still working after you added the modifications?

Day after day, night after night these little chunks of code do their work like brave soldiers, without complaining, and let you concentrate on the really important things.

So, give them the attention they need. Treat them like your production code and apply the same quality guidelines. Because they will grow and age with your code. As long as your production code is life your test code will be there, too. You will have to maintain, adapt and refactor it - just like your production code.

Poorly written unit tests might save time in the beginning, but in the long run they will cause higher maintenance efforts. If not written properly, keeping all the Clean Code guidelines in mind, they will be neglected as soon as the effort to adapt them to code changes or to keep them green exceeds the implementation effort for new stories.

And never, ever allow tests to be in a failing state for longer than a day. One red test will open the door to the next one and soon the number of failing tests will grow rapidly - without anybody caring.

Automated tests are like old friends: if treated well and with respect they will always be there for you.

Stay alert

Quality should become a habit - at the same time routine can be the greatest enemy. Because routine can turn into carelessness - when you stop thinking about why you are doing something. Therefore, we should always keep questioning whether our practices still achieve the intended purpose. We are living in a fast moving world, our environment keeps changing. Something which worked perfectly yesterday could yield completely different results tomorrow.

Inspect and adapt!

15 Mar

Me developer, you tester

By Susanne Albinger

According to the Scrum Guide all members of a Scrum Team are Developers. However, in reality, we come across teams which are split in two: developers and testers. But isn't Agile Software Development all about teamwork? One team transforming requirements into working software. But is this really how it works?

02 Feb

What about quality?

By Susanne Albinger

Everybody talks about quality in software development nowadays. The Scrum framework seems to solve this problem - but what does it take to deliver high quality software?

Latest Articles

  • Focus your improvements

    Sep 21 / Arjan de Jong

    Anyone who has worked in an Agile team, knows that at some point, almost every team will grind to a halt due to external reasons. Because agility focuses on short delivery cycles, any existing problems will show themselves fairly fast ...

  • Dysfunction of A Team - 5

    Aug 17 / Alessandro Grimaldi

    The ultimate dysfunction of a team is the tendency of members to care about something else than the collective goals of the group. Team members value their personal merit over the joint success of the team ...

  • The glue that holds it all together

    Apr 24 / Susanne Albinger

    Put six people in a room, provide them with post-its, a team board and a common goal and - voilá - here comes your Scrum team! High performing, creative and innovative, delivering a shippable product increment every two weeks. Sounds easy. But…

  • Team Objectbay skiing days

    Mar 17 / Camilla Franek

    Bright blue skies, snow-capped peaks and perfectly groomed slopes. The best conditions to start in our Team Objectbay skiing days.