When planning releases, it’s important to understand where team effort is being spent. By using high and low watermarks, a project manager can determine a suitable approach to take when setting expectations and determining whether it is necessary to alter team behavior to focus more on getting those features into a release.
A couple of years ago, the Twitter hashtag #NoEstimates appeared. Its purpose was to start a discussion about alternatives to estimations, but the idea of a project without explicit estimates is odd to most people in software development. However, if you start exploring it, you may find better sources of information to rely on.
When it comes to transitioning to agile, if a team only goes off what it's heard from other teams and doesn't take a class or read any books about the process, misconceptions can abound. And that leads to problems. Read on to have three common agile myths debunked and to learn why agile is a cultural change, not just a project management framework.
Many teams think they're agile. They might work in iterations and have a ranked backlog, but they don’t see the value they could be seeing. Usually that means they have a number of false impressions about agile. Read on to have three common misconceptions debunked and to learn what you need to do to make your agile transition successful.
The fable of stone soup is often told as a lesson about cooperation in times of scarcity. Mike Edwards has used an approach based on this allegory to help teams make steps toward improving themselves and the way they work, especially when it comes to shifting to new methodologies such as agile and Scrum.
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.