7 Agile Software Development Tips to Build Exceptional Products

You do not need to follow every ‘rule’ of an Agile method like Scrum or XP to be an effective Agile team, particularly as the team evolves. Although Agile software development provides a set of patterns and best practices, they are only half of the equation. As a member of several highly productive, Web-focused development teams (at CBS Interactive, CNET, Vehix), I haven’t seen an environment in which a pure form of Agile is maintained over an extended period of time. Agile practices usually evolve into a unique development process that matches the cultural tenor of the organization.

In my current role as VP of engineering at romantic social network Zoosk, I participate in Agile team practices that help us fulfill multi-layered requirements and effectively complete complex development projects. Here are seven Agile development tips to help your team do the same.

Agile Software Practices are More Art than Science

The Agile Manifesto is intentionally broad, general and far reaching. At its core, it represents a set of values. Consistently guide your team with these core Agile values and then trust that your smart team members will adapt them to the unique needs of your culture and product domain.

Find a Sprint Length that Works for your Team

Agile development forces you to break large projects into discrete chunks that can be delivered in fixed-length sprints. The multi-layered requirements and typical complexity of Zoosk development projects mean that one-week sprints are generally too short to produce quality deliverables by a sprint’s end. It is particularly difficult to be fully tested and ready for release in one week. On the other end of the spectrum, a month or more is too much time between major releases for a Web-based offering (although this might work for more mission-critical software systems, like airplane components).

At Zoosk, we have settled on a two-week sprint, which gives the development teams enough time to explore options and build a quality deliverable, yet it also forces rapid decision making. Slow decision making is usually the main contributor to development lag. Two weeks also affords enough time to dig deeply into complex interactions and coordination with other teams across integration points. If your development team has fewer members and your production environment isn’t divided across multiple service layers, one-week sprints may work fine.

The level of automation for your functional regression testing should also be factored into the sprint length. Absorbing significant test and release overhead more often than necessary wouldn’t be ideal.

Daily Stand-ups Are the Heartbeat of Your Sprint

The daily stand-up meeting is a vital component of any Agile practice. It provides a set time each day, usually in the morning, where the Agile team meets and quickly reviews the sprint’s status. Each team member provides a short summary with three updates:

  1. What they did yesterday
  2. What they plan to do today
  3. Whether they are blocked by something external (such as another developer, a software license, hardware, and so on)

Physically standing up, which we do at Zoosk, tends to make the meeting move quickly. Also, each team member targets an update length of around 30 seconds and almost never more than a minute. If an attendee has no updates to give — often the case for a non-core team member — they just say “pass.” These meetings each day provide a natural pacing to the sprint.

When smaller development teams first consider using a daily stand-up, the initial reaction is often to the effect of, “we sit beside each other all day; why do we need a daily meeting to communicate?” Yet, I am continually amazed how little communication actually occurs organically between developers on a project (even between teams that sit 10 feet apart!) This reality is not the developer’s fault; the complicated nature of software development requires intense concentration. This creates a mode of thinking that isn’t conducive to updating another developer or product manager on progress. Also, each team member naturally assumes that they are working on the most important task at any time. This means that they are usually not considering opportunities to shift the order of development tasks to enable the entire team to finish more quickly. The daily stand-up meeting provides an efficient and open environment for accomplishing these coordination requirements of any software development project.

At Zoosk, we hold daily stand-up meetings for each of our individual development teams (Web, Mobile, API, Platform Services, Operations, and so on). The core team members all attend regularly. These are the developers, the product manager, UI designer (if applicable) and a QA team member. Other stakeholders are also encouraged to attend. This includes product leadership, marketing and executive team. Even our CEOs will drop into the stand-up for a particularly strategic project. We schedule them between 10am and 11am each day and purposely stagger the start times for each team’s meeting by 10 minutes to allow some individuals to attend multiple stand-ups. As the VP of Engineering, I try to attend them all.

These daily stand-ups also have the benefit of allowing the leadership team to efficiently gather updates on all projects across the organization, replacing many individual interruptions of team members for project status. For all of the above reasons, investing time in your daily standup will almost certainly yield significant dividends.

The Role of Testing in the Sprint Process

At the end of every sprint, there is a requirement to verify that the code written will not introduce bugs into the system. This assurance is usually addressed through various testing approaches. At Zoosk, we employ a number of mechanisms to test our code. This is particularly important because our business logic is very complicated. We have numerous business rules that control the user sign-up process, what content can be uploaded, interactions between users, how many messages they can send and receive, and so on. Rigorous testing of these interactions is the best way to guarantee consistency across sprints.

The first layer of testing that we employ is unit test coverage. Every developer is expected to build unit tests that exercise their code with each feature check-in. We don’t try to employ test-driven development, which would require the unit tests to be written first, but do expect a basic set to accompany the code that enables the feature. These unit tests are run against the code in our continuous integration environment, which is controlled by Jenkins. Automated builds with a unit test run are kicked off with each code commit. Jenkins sends an email to all committers for a failed test run.

The second layer of testing is manual testing of a feature. For new features developed in a sprint, the QA engineer assigned to that development team will begin an initial set of functional tests after the feature is generally working. This is followed by product manager demos and acceptance testing. The final layer of testing applies to existing features and business logic that weren’t directly touched during the sprint.

To test these functionalities, the QA engineer will run through a battery of manual regression tests at sprint’s end. As new features become a part of our permanent product offering over time, other QA engineers will create automated functional tests that run against the code in a controlled test environment. The output of these automated tests is compiled into a summary report that is distributed to and reviewed by the development teams daily.

How to Communicate Requirements Efficiently

The project requirements communication process is a place where many Agile organizations can get hamstrung. Teams should keep the desired outcome in mind: to get the product manager’s vision for a feature into working code on the production environment as efficiently as possible. Therefore, whatever tactics serve this end, adjusted for the nuances of each organization’s culture and structure, can become the standard practice.

If your development team is co-located, then in-person, high-bandwidth communication is often the most efficient. If a product manager can explain a feature to a single developer in 30 minutes, and then the developer can go and build that feature in the same day, then there is little need for detailed requirements documentation up front. However, as the feature becomes broader, with more developers and even multiple development teams involved, then some amount of written documentation is a more efficient means to communicate the requirements.

At Zoosk, we employ a fairly lightweight documentation process. The product team will generate visual mock-ups of the feature, usually anchored around the UI views. These mock-ups are then annotated with business logic or functional requirements. The documentation is stored in a page on our wiki. Each project’s work items are captured as a tree of tickets in our bug tracking system. The parent ticket will have a link to the wiki with the associated requirements documentation. Further clarification of requirements beyond this level of detail is usually accomplished through conversations. On the implementation side, the engineering teams will often create a design document for a large project. This is usually a wiki page as well, that includes data structures and basic class diagrams.

We invest more effort in specifying interfaces between systems, usually at the API layer. Detailing the data contract between the client application and the server-side API is very important and will save a lot of time, as it naturally forces the developers to discuss implementation details. We apply this general approach to requirements communication in varying intensity levels depending on the size or complexity of a particular project. At Zoosk, we generally err on the side of having a conversation versus requiring a written spec.

Keep Teams Lean

Since the Agile process values rapid, in-person communication, we try to keep our teams small. Our Agile teams range from 2-6 developers, plus a product manager and QA engineer. If a team gets larger than that, we start to see incrementally greater overhead in keeping the team informed and coordinated. Each team member is fairly self-directed and we entrust large swaths of feature implementation to individuals. For a larger project, we will appoint a project lead, who gathers status updates and coordinates activities across multiple developers (or even development teams). However, we still try to rely on the daily stand-ups and general Agile process to keep projects organized, versus falling back to a stricter command-and-control structure. Smart people, organized around a common goal with some basic shared practices usually find the most efficient way to collaborate and work through coordination problems.

Use Retrospectives to Tune Your Agile Process

If an Agile team’s process is continually evolving, it is the retrospective that provides the input for these process improvements. After every sprint, we conduct a retrospective with the full organization and capture input around two themes: what went well and what should be done differently. Originally, we gathered input on what didn’t go well, but changed that into “do differently” to make improvement more actionable. Many of our current Agile practices are “do differently” suggestions that came out of a past retrospective.

Also, after a particularly large project or a challenging production release, we will conduct an ad-hoc retrospective. The key outcome of these retrospectives is to reinforce how our process is working well and to identify new opportunities for improvement. Additionally, I have found that retrospectives have a positive side-effect on team morale, allowing team members to express their appreciation for the efforts of others and to air grievances in an open, non-threatening environment.

About the Author

Peter Offringa is vice president of engineering at Zoosk.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

More From DevX