Blog

Software that stands the test of time is only as good as the process to build and maintain it. From ideation to maintenance, the processes should be understood and documented across your team, so that everyone works in the same way. The challenge here is how to define the process and ensure that people stick to it, through a team’s life cycles and change.

The first part of this article series dealt with the fundamental question of what culture is, how culture can be understood, and what impact culture has on the way we work in an organization. After this stocktaking, the second part deals with the question of how culture can be actively developed.

Agility has long been a topic in organizations of all sizes. In an environment of increasing complexity, agility can become a key competitive advantage. It's no wonder, then, that companies want to use agile frameworks to organize knowledge work. However, introducing techniques is not enough. Becoming truly agile as an organization requires nothing less than a cultural shift. This understanding is equally important for management and team members, as development teams are often agile islands in a non-agile organization that limits their potential.

Kanban is an agile alternative that’s been receiving more and more attention in software development lately. Praised for its flexibility and simplicity, this method is known for the fact that instead of focusing on maximum utilization, it optimizes flow—the flow of work. We spoke with Agile coach Thomas Schissler about Kanban’s possibilities and its challenges.

Scrum has become a symbol of enterprise agility. Agility and scrum are often used synonymously. But anyone who does Scrum is not automatically agile, even though the framework can serve as a path to agility. Strict adherence to the Agile Manifesto’s values is much more decisive.

When talking about successfully implementing software projects, Scrum as a framework paired with agile development is the current state of the art. You almost feel transported back to your teenage years, listening to schoolyard conversations about “the first time”. The comparison with agile development using Scrum isn’t so far-fetched. Everyone wants to do it, everyone says they do it, everyone seems to do it better than you - and yet, probably only 10 percent do it. And those who really do it, do they do it “right”?

In the previous article "Scrum - an introduction for developers", we briefly addressed the topics of product backlog and user stories. We explained that an assessment of requirements with regard to scope and complexity is also necessary for agile product development. This article will go into this in more detail. We will provide an overview of how to move from time estimates and a content framework for a rough roadmap, or release planning to a concrete estimate of requirements for planning the iteration. It will become clear that developers help to get the estimates underway, especially during the process of estimating as a basis for planning.

In the first part of this series, we will examine the theory behind the Scrum Framework. We will discuss the roles of acting persons with a focus on the role of the Development Team.