image 

At the moment, there are several popular software development methodologies, each with its own recognized strengths and weaknesses. One of the most popular methodologies out there are the many different faces of Agile, which are all based on iterative and rapid development.

At Testomato, we use a mix of agile techniques to fit our company and our projects. In our minds, agile was definitely the way for us to go, but despite its popularity, it’s not for everyone.

Agile methodologies are well-suited for startup environments that must be able to adapt and evolve quickly according to user requirements and keep costs low.

Most of our core practices come from the Scrum method, which is a lightweight Agile process framework. As its definition suggests, Scrum is a collection of practices and concepts that help build a development process.

How we function and develop is a crucial part of who we are as a team and as a service. So, we wanted to share the Scrum practices we’ve chosen to use at Testomato with you.

Techniques that we currently use

1) We start our days with a morning stand-up

Every morning at 9:30am in the Testomato office, we gather together with a coffee in hand (or sometimes a tea) for our daily-standup meeting. These meetings are kept short (no longer than 15 minutes).

Stand-ups are a well-known practice used in agile methodologies, like Scrum, and play an extremely important role in moving forward projects.

The key objective is to make sure that every team member’s activities are moving the project forward to a project goal. In short, our stand-up helps us all validate that everyone’s time is being spent on important project activities.

In our working environment, especially where there are other projects going on at the same time, it’s very important time for our team to share our successes (and challenges) with each other.

Here is a basic guide to a daily stand-up:

  • Meet daily at the same time and place
  • All project members must attend
  • 15 minutes long
  • Team members present 3 things:
  1. What I’ve accomplished since the last meeting
  2. What I plan to get done today
  3. What obstacles are preventing me from making progress
  • A scrum master / facilitator teaches the team about the stand-up and enforces the process, but isn’t in charge of the meeting

Since the stand-up is limited to 15 minutes, it’s too short for unrelated discussion. It can sometimes be difficult to report quickly, but we’ve found with practice that this is an important interaction for our team to participate in every morning.

2) A scrum master helps us keep the wheels running

A scrum master helps teams to remove obstacles that get in the way of delivering a sprint goal. A sprint is a regular set period of time during which specific pieces of work are completed and prepared for team review (in our case, 1 week). It’s not his job to run our team, but to make sure our processes run smoothly.

In addition to Testomato, our scrum master is responsible for other projects as well. Since our teams don’t have leaders (we’re self-organized), his role is to help remove distractions or problems from our sprints, and make sure the Scrum practices we do use are being adopted correctly.

3) Retrospectives help us share feedback effectively 

Traditionally, retrospective meetings are supposed to be done at the end of a sprint. This meeting is meant to allow for discussion about the last sprint and what can be changed to improve the next sprint.

Some key elements of a retrospective include:

  • All team members participate, including the product owner and scrum master
  • Discuss what went well and what can be improved
  • Prioritize actions and identify lessons learned
  • Minimize any possible conflict and speed up problem-solving

Essentially, this is not about what the team has built, but how the team is building together. A sprint retrospective ensures that a team is always improving its collaborative processes.

Our team also participates in retrospectives, but we do not conduct them after every sprint. Instead, every month there is a company-wide retrospective. We apply the same elements as a sprint retrospective, but instead of discussing the specific sprint – we discuss the company as a whole.

This means that everyone in our office is given the opportunity to comment on new changes, suggest ways to improve our office workflow as a whole, and also bring up problems without the fragmentation of separate teams.

Techniques we are in the process of implementing

Recently, Team Testomato made the decision to try and add a couple more common Scrum practices to our development process. Both techniques were already loosely in place, but we would like to start using them in a more enforced manner. The goal is to tighten up our performance and make sure we are maximizing our resources to deliver what we promise.

4) Regular sprints will help us stick to our roadmap

As we previously mentioned, Scrum sprints are basic set units of development time. Generally, sprints last up to 30 days, but every team and project is different. Therefore, a scrum master will usually decide the lengths of sprints. Once the period is set, all future sprints will be the same length.

Before the sprint, the product owner and development team will decide what user stories should be delivered. Although the product owner is the one responsible for identifying what should be worked on, it is the development team who ultimately decides what can realistically be accomplished.

Although Testomato already functions more or less on this schedule. Our sprints have not always been set. We recently decided that we will now work with 1-week sprints.

In addition to these regular iterations, we will also be implementing in sprint planning, sprint reviews, and also release planning meetings to accelerate Testomato’s development process.

5) Sprint review demo days keep us accountable 

Sprint reviews are informal meetings meant to show what has been accomplished. It’s a great opportunity for developers to make good on what they agreed to deliver at the beginning of a sprint.

The basic requirements for a demo day:

  •  Limit demos to 1 hour
  • All team members must attend
  • Identify what was finished and what was not
  • Demo the work that was finished and review how the sprint went
  • Discuss what’s up next and the likely dates for completion

Demo days are a great way to resolve technical problems and share feedback about completed work. If done correctly, demo days should also provide input that will be important for the planning of your next sprint.

The last two techniques we mentioned are still new for us, but we can’t wait to share our experiences and results with you!

Want to learn more about our scrum techniques? 

Ask us in the comments below or on Facebook. You can always tweet us directly @testomatocom