What Can Business People Learn from Developers That Work in Agile Teams?

Part 2: Quality of Teamwork

Porsche Digital
#NextLevelGermanEngineering

--

This article is the second in a series centered around agile methods and practices. In the first article, Porsche Digital’s Sarah Ouis, Product Owner E-Commerce, and Robert Wegele, Agile Coach, described what individuals stand to gain from agile methods and practices. Focusing on the team level, in this article, they outline how an agile approach can enhance the quality of teamwork within and between business and software engineering teams.

Transforming a collection of individuals into an agile, high-performing team with a shared purpose is no easy task. But with the right approach, methods, and practices, organizations and business units can embed agility into the heart of their operations. At Porsche Digital, we adapted a lot from Scrum and SAFe, like Dailies, Sprint Boards and Backlog, which have proven to enhance collaboration. Additionally, management best practices support team development. We will cover a few insights on synergies in this article.

Daily stand-up meetings

Daily stand-up meetings are essential for our collaboration, specifically for shared dependencies among team members or between teams. They keep teams connected and everyone well informed. However, we want to avoid unnecessary meeting marathons. In our development teams, three key questions are answered within our daily stand-up meetings: (i) what did I do yesterday? (ii) what am I doing today? (iii) and where am I blocked and where do I need support? In this way, we create transparency and synchronize each other as good as possible. Continuous exchange with your team on a day-to-day level prevents blockages and promotes problem-solving, which makes us faster in consequence. So where is a daily stand up beneficial? The goal is to minimize meeting time and to maximize productive time, meaning that we meet where the highest complexity is in place.

We tested this concept for our business meetings and initiated a daily standup for the alignment with our product management resulting in less project overhead and more trust, based on transparency.

Backlog & Sprint Board: Creating transparency

Instead of everyone managing their own issues according to their own methodology, the key is to have a single source of truth. Team project management software like Jira shows dependencies and facilitates communication. It helps us to create transparency across teams and several stakeholders and lets us know in which stage (doing, testing, done etc.) a ticket is and who is responsible for it.

The goal is not only to visualize the work, but we also want to know exactly when to support each other. Through the sprint board, we see immediately when a bottleneck opens up and anyone in the team can step in to clear it out. Meanwhile, our business partners also work with Jira and deliver content for feature development. Bringing tasks together on one platform creates a shared vision that can result in synergies. At the same time, we gain more productive time and create less overhead.

Create a common understanding of requirements and goals

Goals need to be specifically defined to achieve them. That is why our product development teams have committed to two very important definitions, building the “Yin” and “Yang” of agile requirements engineering: Definition of Ready and Definition of Done. The Definition of Ready determines when a user story is sufficiently formulated and can be scheduled into our iteration. Later in the process, the Definition of Done defines when a task is completed and can be closed. Both, Definition of Done and Definition of Ready, are specified individually and maintained regularly by each team.

When bringing business and development together, it helps speaking the same (agile) language. We see that some business tasks are very broadly defined, with differences in depth and a lack of complexity awareness. The “Yin”, our Definition of Ready, might support business teams in having a common understanding about the requirements and what needs to be done from all perspectives and disciplines. On the other hand, we have the “Yang”, speaking about the Definition of done, to double check if the requirements have been implemented as designed at the end of the day and close the feedback loop.

It is not only important for us to clearly formulate the requirements through acceptance criteria, but also to commit to working on them together, maybe even in pairs. After we defined a task, we make a so-called confidence vote with dependent team members, to figure out if everyone agrees with the scope and the plan. This creates transparency and thus provides security.

Clear role and team structure

There are clear structures, roles and responsibilities in our software engineering teams. In addition to that, we have learned that small teams with up to eight members are the most productive and communication is best ensured. As a rule of thumb, we use Amazon founder Jeff Bezos’ two-pizza rule: a team should only have as many members as can be satisfied by two pizzas.

The right team set-up — especially in terms of skills and strengths — is therefore particularly important: It is openly communicated who is being developed as an expert and who is working as a generalist in the team. We aim to foster cross-functionality in the team and to have the right amount of domain experts and generalists in each project. It is important that the know-how is distributed over several pillars so that work can continue even in the event of illness.

It should be mentioned that all these methods and principles are Scrum and SAFe 101. What distinguishes our work, is that we have a clear understanding of individual complexities and requirements between teams. This also means that teams can select the framework or only particular agile practices that work for them best.

“Hire for attitude, train for skills”

In addition to that, we work according to the Inspect & Adapt principle: in regular cadences, we openly challenge the status quo and adjust as needed. Porsche Digital shares a mindset of mutual learning and improvement, empowering teams to follow their passion. We hire new team members based on our guiding principles to make sure they fit culturally into our organization. This is also reflected in our motto “Hire for attitude, train for skills”.

In conclusion, we see that business and software engineering are two sides of one medal. Business requirements are often broad due to their conceptual nature. That’s why the outlined concepts are not easily transferrable, if at all. But understanding each other’s language as well as learning openly from best practices might foster collaboration and even enhance team productivity.

Sarah Ouis

Sarah Ouis works as a Product Owner E-Commerce at Porsche Digital

Robert Wegele works as an Agile Coach at Porsche Digital

Robert Wegele

About this publication: Where innovation meets tradition. There’s more to Porsche than sports cars — we are developing new digital products and services — always with our customers in focus. On our Medium blog, we tell these stories. It’s about our #nextvisions, emerging technologies, and the people that drive our digital journey. If you want to know more, follow us on Twitter, Instagram and LinkedIn.

--

--

Porsche Digital
#NextLevelGermanEngineering

Official Account of Porsche Digital | Follow us on LinkedIn for the latest news! | Our mission: To create value and spark excitement through digital engineering