How understanding the balance inherent in agiles guiding principles can help project managers make the transition from traditional project management methodologies to agile.

Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we're building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor...” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.

This article gives cases and anti-cases to help you decide when to adjust sprint length

an eye on our projects and look for small problems before they can become big problems. In his book Refactoring, Martin Fowler introduced the term smell to refer to something that may not be right. Just because something smells doesn’t mean there’s a problem; it does mean, though, that further investigation is warranted. This article is a first step toward collecting a catalog of Scrum smells; that is, signs that something may be amiss on a Scrum project.

From my own experience as a first-time ScrumMaster for a development team moving from a traditional software development process to Scrum, I have compiled a list of things you need to keep an eye on, almost all the time, during your sprints.

Like many people trying to implement a Scrum/Agile project for the first time in an organization, I encountered a number of obstacles that were almost project killers. As I write this article today, I keep thinking, “if I only knew that when I started.”

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

This article describes how a project was successfully downsized from 100 to 12 developers. To make such a dramatic adjustment the development process was switched to Scrum and user stories.

So, you have made it. You are the Product Owner of the company's flagship product. Now you will spend your days thinking about business value and customer satisfaction, and leave all that technical stuff to the development team - you never understood it anyway. Unfortunately, you're not off the hook so easily. In order to correctly prioritize the product backlog, you need to be aware of some of the technical items that will need to be included there. You need to understand the value of these items and recognize the terms the development team throws at you. Or worse, if the developers do not throw these terms at you, you will need to demand that they start using the technical practices you deem most valuable to your product. If you recognize yourself in these first two paragraphs, this article is for you.

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.