We all know the three questions of Scrum: What did you do yesterday? What will you do today? What blocking issues do you have? We all do our best to answer these questions. So how come so many of our initial demos turn up problems we didnt catch? Maybe its because, at least at the beginning, we need to add a fourth question to our daily standups.

Description of a project failure and investigation of the root cause.

Scrum promotes cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.

Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

True project success can be summed up in one acronym: RED (requirements gathering, estimation, and delivery). Each of these key activities is crucial to a successful project launch.

Teams adopting Scrum not only have to deal with the normal project complexities of prioritisation, estimation, and turning product backlog items into potentially deployable increments of functionality, they also often have to support a system in production or address bugs that come back to them during development. How do we track and prioritize these support activities? How do we handle emergencies? Who performs production support?

Many companies with existing legacy code bases bump into a huge impediment when they want to get agile: lack of test automation. Without test automation it is hard to make changes in the system because things break without anybody noticing. Defects aren't discovered until the new release goes live; worse, they are discovered by the real users, an embarrassment that results in expensive hotfixing, or even a chain of hotfixes, as each hotfix introduces new, unanticipated defects. These risks make the team terribly afraid to change legacy code, and therefore relucant to improve the design of that code, which leads to a downward spiral in the quality of code as the system grows.

Given that Scrum has a very pragmatic view of getting things done and a strong focus on teamwork, how do the psychological aspects of group dynamics affect the likelihood that Scrum will succeed? Two interesting theories on the subject, FIRO and RAT, have implications for Scrum, yet I have not seen them referred to in any Scrum or agile material. Understanding these theories and their implications can affect whether a Scrum team succeeds or struggles.

It is often said that to truly understand someone else, one must walk a mile in that persons shoes. Similarly, taking on more than one role on a Scrum team, on a temporary basis at least, can have unexpected advantages that may offset the disadvantages.

Every Scrum practitioner (certified or not) knows that while Scrum principles are easy to learn and to understand, they are often tricky to manage. The ScrumMaster finds himself at the nexus of the development effort. All around him revolves almost every single function in the organization (with the possible exception of the janitor). The ScrumMaster has to control and manage the fears and concerns of the customer, the Product Owner, the QA manager, his own boss, the VP of marketing & sales, and, last but not the least, his teams. In essence, he is the lamentation wall for a global village. This stress is always present—I know; I have experienced it over and over again. To succeed in this environment, the ScrumMaster needs powerful tools that can help him regain control and manage the constant stress