BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Teamwork Content on InfoQ

  • Creating Impactful Software Teams That Continuously Improve

    Culture shapes how we feel, work, and succeed, says Natan Žabkar Nordberg. People thrive in different environments—some need autonomy, others structure. Trust must be given first, not earned. Leaders should guide, not control, fostering autonomy and safety.

  • Using DORA for Sustainable Engineering Performance Improvement

    DORA can help to drive sustainable change, depending on how it is used by teams and the way it is supported in a company. According to Carlo Beschi, getting good data for the DORA keys can be challenging. Teams can use DORA reports for continuous improvement by analysing the data and taking actions.

  • How to Improve Software Team Performance with Experimentation

    According to Terhi Aho, experimentation is a way of thinking that guides action. By experimenting we can develop ways of working without a major change process. It can help software teams to solve problems in small steps, relieve their workload, and foster self-management.

  • Fostering High-performing Work Environments for Software Development

    According to Eb Ikonne, leaders should provide a motivating challenge or mission so that the software engineering team understands what success looks like. They can provide an enabling structure for effective teamwork, address things that negatively impact team success, and reduce or remove friction. Coaching can help people discover how to work effectively together.

  • LLMs and Agents as Team Enablers

    Eric Naiburg and Birgitta Böckeler published articles on the benefits and challenges of using AI as a multiplier in dev teams. We report on their insights for scenarios such as simplifying the germane cognitive load of a domain, automating code migrations, and coaching scrum masters on team facilitation. We also cover Böckeler's experiments with using LLMs to onboard onto a complex project.

  • How Tech-Enabled Networks of Software Teams Work

    To maintain agility at scale, software teams can use technological and organizational solutions to reduce dependencies and work autonomously. According to Fabrice Bernhard, collaboration technology can be leveraged to create a distributed network of teams. To empower their teams, leaders can support them with a systematic problem-solving culture aimed at delivering good products to customers.

  • Increasing Productivity by Becoming a Dual-Purpose Stream Aligned and Platform Software Team

    To manage their increased workload effectively and maintain quality and efficiency, a software team decided to become dual-purpose: stream-aligned and platform. They rewrote their main application to be API-first and implemented micro releases with their customer-facing products, to provide value to their end users quickly and maintain a steady flow of accomplishments for the team.

  • How Team Health Checks Help Software Teams to Deliver

    In healthy software teams, people feel psychologically safe to solve problems and contribute, Brittany Woods said in her talk at QCon London. She presented how they do team health checks and the benefits that it has brought them.

  • Transforming Software Product Teams into Tech Investors

    The key responsibility of an organisation lies in balancing user value with profitability. In a product organisation, software product teams invest their own time. According to Fabrice des Mazery, software developers are much more than stakeholders; they are the main investors as they are part of the product teams.

  • Transitioning from a Software Engineering Role into a Management Role

    Software engineers who want to become good at leading engineers can use everyday opportunities to practice management. Peter Gillard-Moss gave a talk at QCon London where he shared his experience with becoming a manager, and provided tips and ideas for engineers aiming to become a manager.

  • Fostering Healthy Tech Teams in a DevOps World

    Building healthy DevOps tech teams that are responsible for a broad area can be challenging. To measure the success of your team, several frameworks provide metrics indicating team health. Psychological safety matters for healthy teams to ensure each software engineer brings their own lived experiences to build better products and that they feel safe to do so.

  • Adopting Agile by Increasing Psychological Safety in a Software Team

    To test the agile way of thinking, a software team worked on their psychological safety with kick-off exercises, sharing coffee breaks, celebrating wins, a stand-up question, and 1-on-1 talks. This helped them to increase psychological safety in their software team.

  • The Impact of Testing in Software Teams

    Communicating quality gaps, holding space for good testing, and writing automation are some of the ways that testers contribute to software teams. According to Maaret Pyhäjärvi, we need to think about testing, not testers. Collaboration and having conversations between team members can result in valuable impact that changes the product and the experiences of our users.

  • Why Stable Software Teams Aren't Always Best: Self-Selection Reteaming at Redgate

    There are advantages to having the same group of people stay together, especially in achieving a time-bound software development project. However, in a world where we increasingly see product or stream-aligned teams who own long-living software from creation through to delivery, operation, and ongoing improvements, then optimising for very stable teams is not the best idea, Chris Smith argues.

  • The Value of Repaying Good Technical Debt

    Bad technical debt is the stuff that has been lingering around; teams need to work around it or fix the fallout as a consequence of this bad technical debt. Good technical debt is intentional, enables benefits for the organisation, and is controlled. Teams can use a disciplined approach for managing and repaying technical debt, for instance by using the wall of technical debt.

BT