Traditionally, the project manager or ScrumMaster is responsible for evaluating a team's performance. But peer feedback, when each member of a team picks another member, observes him or her, and then shares thoughts and suggestions about that other team member’s work, can also be very valuable to continuous improvement.
One of the primary goals of annual planning is to translate aspirational strategic plans into realistic execution plans. Sadly, rather than delivering plans we can all feel good about and believe in, too often it leaves us depressed about the work ahead of us. This article shares five practical principles to remove the emotions associated with annual planning.
As agile development has erupted over the software landscape, its core philosophy often has been neglected as organizations hurry to implement cherry-picked practices in the name of pragmatism. By avoiding these five common pitfalls, companies can better realize the true benefits of agile: high productivity, great software quality, and happy customers.
Contrary to popular belief, agile projects require as much planning as any other project type. It is the timing of this planning and how we attempt to minimize wasted effort that is different from other approaches. This article attempts to explain the different levels of agile planning and how we utilize them in an ongoing project.
Simply putting a handful of developers together and calling it a “team” doesn’t cut it. There’s a better, more analytical approach to team assembly that results in more cohesive teams, faster ramp-up times to peak velocity, and improved innovation, business outcomes, and value.
One of the most important features in agile software development is continuous improvement. However, after an initial burst of inspiration and productivity, teams may stop improving because they believe there are no issues left to address or the issues are too difficult to solve. People need to switch their mental models to keep addressing processes efficiently.
Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output.
A good product owner should be collaborative, responsible, authorized, committed, and knowledgeable. But what do you do if yours doesn’t exemplify these characteristics? This article aims to showcase mitigation plans that can be effective for overcoming Scrum violations due to the fact that you’re not working with a typical product owner.
Many engineering leaders and agile coaches believe that transitioning to agile is simply a matter of process training and expert advice. But frequently, it means that deeply ingrained habits need to be changed. This article identifies eight steps that address the wider organizational shifts implied by agile and will help create buy-in from your team.
A new approach to projects or a new tool is not a quick fix or a silver bullet. Too often, you have ingrained, systemic problems that require a cultural change. That doesn’t mean a new approach or a new tool won’t help. It can. But you also need to adjust the environment that caused the problems in the first place.