5 Best Practices That Boost Development Effectiveness, Part I

The Non-Technical Practices

What can my organization do to improve its development productivity? That question is on the mind of many a manager when faced with the aggressive timelines borne of a competitive market. Almost every software project will miss at least one milestone, and the factors that contribute to the variances are legion – some examples include unreasonable deadlines, uncertain goals, and underperforming teams. The costs to the business for these missed deadlines range from blown budgets to software that fails to meet market needs. 

So how does one improve a software organization’s performance? The most common approach is to add more headcount, but this approach often has the opposite result, as chronicled over 40 years ago in Fred Brooks’ book, The Mythical Man Month. There are certainly more effective approaches that are achievable at a lower cost. 

In this two-part article series, we discuss five practices that your teams can start today that pay dividends both in innovation and in reduced maintenance costs for existing features. In Part I of this article series, we’ll look at two non-technical best practices that require no prerequisites to getting started and return value in a very short timeframe. In Part II, we’ll look at three technical best practices that require a longer time for your teams to master but will form the foundation for an agile software practice and pave the way to sustainable success. Let’s get started with a look at team rooms and retrospectives.

Team Rooms

Have you considered the environment where your software is being built? The environment where your teams are working has a large impact on their situational awareness and the effectiveness of their communications. When you walk around the offices of highly effective software companies, you see some commonalities. Notably, the best tech companies have collaborative workspaces where all project members can work together toward their goals. These spaces utilize large, highly readable displays (both electronic and paper-based) to disseminate project information across all roles, helping to keep the team focused and aligned. This practice has the positive side effect of improving communication by physically collocating all the project roles, which in turn increases team alignment and situational awareness. 

Although we recommend teams be physically co-located, the canonical team room is actually a metaphor. Team rooms can and do exist in a non-physical form, and many modern tools enable a highly collaborative virtual team room. It is important that your team room, whether physical or virtual, can support all the roles required to complete the project. This includes product management, product marketing, quality assurance, development, and a reporting infrastructure that meets the needs of the business. 

A final point on the team room, whether physical or virtual, is that it’s essential to ensure your team room include some private spaces for times when quiet work is necessary. A phrase commonly used to describe early XP team rooms was “caves and commons.” While the majority of the team room should be a common area optimized for collaborative work, be sure to include some “caves” for those team members who need a quiet space to complete certain tasks. 

Retrospectives

“Those who cannot remember the past are doomed to repeat it” – George Santayana 

Retrospectives are a practice that anyone can and should use, regardless of the processes they are employing across the software development lifecycle. We consider the retrospectives practice an essential step in achieving improvement in process maturity and a prerequisite to realizing data-driven process change. Continuous feedback loops between work outcomes and observation-based experiments allow a team to learn and adapt from recent experiences. While they are easily started, teams will see a sizable benefit from utilizing a coach or facilitator in the beginning to help identify retrospective workshop formats that work best for their team’s scenarios and environments. Having a coach will shorten the time to achieve value with this practice, but this is not a prerequisite to start performing retrospectives. 

An excellent written resource for anyone looking to get started is Agile Retrospectives by Diana Larsen and Esther Derby. If your team is new to retrospectives, make sure your Scrum Master or Process Coach has a copy handy (and that it makes its way around your teams!). If the company’s goals include building a learning-driven organization, all of your teams should be performing retrospectives (or after-action reports, post-mortems, root cause analyses, etc.). Too often when we see retrospectives at work, they are confined to an island of one particular group or role in an organization (e.g., development, IT operations, or support). The entire organization is enhanced when all groups integrate a retrospective practice into their work culture. The costs of not learning from our experiences are simply too high for a successful business to bear in any competitive market. 

Conclusion

If you are looking for practices that can improve software delivery capabilities, team rooms and retrospectives are an excellent place to start. The initial investment can have a very small impact on costs, but the real investment will be from each team member, in their willingness to engage with the new practices and work to become fluent in their application. For those teams willing and able to make the investment in a team room, a great improvement in communication and project awareness can and usually will be achieved. Fluency in continuous inspection and adaptation of working methods using retrospectives builds an important cultural foundation that the team can leverage when adopting the technical practices we cover in Part II.