The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


Strategic Vision and Scrum

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

When organizations adopt an agile approach to development like Scrum there is so much focus on the iterative nature of agile development that long range vision and strategic product design can get lost. Jimi Fosdick is doing a webinar on November 28 to discuss the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users.

Topics will include:
• Discussion of Product Vision and approaches to crafting a compelling overall vision for products
• Discussion of User-Centered/Value-Driven design and approaches to incorporating user experience (UX) and software architecture early in the development process
• Explanation of the pitfalls of a lack of vision and so-called “hybrid” models for incorporating UX and architecture into Scrum Projects

You can register for the webinar here

Tags: , , , , , , , , , , , ,


Estimating Earned Business Value on Agile Projects

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

A pattern I’ve noticed is that Scrum projects are typically managed informally, with the only measures used being various velocity metrics and burndown charts. This may be an issue. Many project managers and executives resist scrum because these only measure the speed of delivery, not the project’s cost or the business value it generates. One of the major differences between traditional and agile projects is that traditional projects focus on delivering software that satisfies requirements, while agile projects focus on maximizing ROI through continuous feedback and re-planning.

This is where Earned Business Value calculations come in. It fits well with Agile projects, since the focus of agile projects is on business value rather than conformance to requirements (outcomes over outputs). In many cases, EVM metrics are easier to calculate and understand in agile environments than in traditional ones. There are three key management measures – Cost Performance Index (CPI), Schedule Performance Index (SPI), and Earned Business Value (EBV) – that provide information to help manage an agile project from and ROI perspective.

There is a solid white paper on this topic at .

I’d also be very interested in your comments to this post.

, , , , , , , , , , , , , , , , ,


The Daily Scrum; It’s a Good Habit to Make

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Transitions

When you think of the word “habit” what do you think of? In the dictionary, there are several distinctly different meanings for “habit” such as:
1. A customary practice or use
2. An acquired behavior pattern regularly followed until it has become almost involuntary
3. An addiction, especially to narcotics
4. A dominant or regular disposition or tendency; prevailing character or quality

We tend to think of “good” habits or “bad” habits. When the behavior we are repeating results in positive circumstances, it is “good”. When it leads to negative results, addictions etc. it is “bad”.
The “daily scrum” is the heartbeat of scrum and is a “good habit”. Tamara Sulaiman, a Certified Scrum Trainer, in her blog post titled “Techniques for Improving Your Daily Scrum; when Your Daily Scrum isn’t Daily” says, “The daily scrum is one of the most valuable practices that any team can use.” The purpose of the daily scrum is to increase the team’s communication and focus by answering 3 questions, “What have I accomplished since the last meeting? What do I plan to do for the next meeting? What impediments are in my way? “ When teams don’t huddle daily, they risk losing the communication, focus and momentum of a team necessary to build the right product with the appropriate quality on time. Oftentimes, teams will have excuses for avoiding the daily scrum or stand up meetings. I’m sure you will be familiar with many of the excuses Tamara talks about. The daily scrum, however, makes teams more successful because it is the smallest, tightest feedback loop built into the Scrum framework. Think of it like brushing your teeth or exercising daily– it’s a good daily habit to make and will pay off in the long haul.

Tags: , , , ,


Standing Room Only

Posted by admin under Scrum Discussion

I just ran across this post ( called “How Many Chickens Are Too Many?” on InfoQ, in which Vikas Hazrati reports on a rather lively discussion that occurred recently on the Scrum Development group. The discussion in question was triggered when one user posted that as many as four to five “chickens” attend his team’s daily standup. Given that his team only consists of five or six individuals, the ratio of mangers to developers is nearly 1:1.

Now, most Scrum literature clearly advocates that if a manager—or “chicken” as Scrum practitioners are fond of referring to them as—wants to attend the daily standup, he or she may do so as a silent observer. The daily standup is a meeting designed for inter-team communication. That is, it’s an opportunity for the team to speak with one another frankly about how the sprint is going. When managers are present, teams may skew the reality of their progress to present a rosier picture of development for them. Or worse yet, the manager may simply usurp the daily standup, using it as a time to micromanage the team. When this happens, Scrum’s emphasis on self-organization—that is, the team’s ability to choose how it will accomplish its sprint goals—is effectively undermined and management reverts back to a traditional, command-and-control approach. In my mind, the issue is clear. A manager should probably not attend the team’s daily standup meetings, but, if it’s essential, he or she should do so as an observer only.

Interestingly, many of the Scrum users who weighed in on the conversation claimed that this is not exactly a black-and-white scenario. Several explained that it depends on the particular culture of the organization. That is, if management is supportive of its developers and empowers them to make decisions (even if they’re occasionally the wrong ones), then there’s no harm in them attending this meeting. Of course, few of us have had the good luck to write software in such an environment. It’s far more likely that your manager or Product Owner is not exactly hands-off.

What do you think? Obviously, Scrum is designed to be flexible so that it can adapt to the needs of specific organizations. But should something as fundamental as this really be up for interpretation? I’m curious to hear your thoughts on this one.

Tags: , , , ,


Scrum Meetings

Posted by admin under Scrum Basics

Sprint Planning Meeting

In Scrum, every iteration begins with a sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. This meeting is a time-boxed conversation between the Product Owner and the team. It’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments.

When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog.

At this point, the Product Owner may choose to leave while the team decomposes the forecasted backlog items into tasks. This meeting is sometimes called Sprint Planning Part 2.

In Large Scale Scrum, multiple teams pull items from one Product Backlog. Multiple backlogs for one product, and multiple Product Owners lead to localize suboptimizations, longer work-in-progress queues, thus are harmful to agility.

Watch an example Sprint Planning Meeting.

The Daily Standup

Every day, the Scrum team gathers in front of their taskboard to discuss the progress made yesterday, goals for today, and any impediments blocking their path.

  • What have I done since the last Scrum meeting (yesterday)?
  • What will I do before the next Scrum meeting (tomorrow)?
  • What prevents me from performing my work as well as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, we recommend they attend a sidebar meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.

Watch an example Daily Scrum Meeting.


Sprint Review Meeting

When the sprint ends, it’s time for the team(s) to demonstrate a potentially shippable product increment to the Product Owner and other stakeholders. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”

This public demonstration replaces status meetings and reports, as those things do not aid transparency. Scrum emphasizes empirical observations such as working products.

In Large Scale Scrum, multiple teams demonstrate a single integrated product increment.

Watch an example Sprint Review Meeting

Sprint Retrospective Meeting

After the sprint review meeting, the team and the Scrum Master get together in private for the retrospective meeting. During this meeting, the team inspects and adapts their process. When the Scrum Master and outer organization create an environment of psychological safety, team members can speak frankly about what occurred during the Sprint and how they felt about it. After all team members thoroughly understand each other, they work to identify what they’d like to do differently the next Sprint, typically focusing only on one or two specific areas of improvement each Sprint. The Scrum Master may also observe common impediments that impact the team and then work to resolve them.

Overall Retrospective Meeting (Large Scale Scrum only)

In Large Scale Scrum, the Sprint Retrospective is followed by an overall retrospective that focuses on inter-team interactions and the outer organization.

Watch an example Sprint Retrospective Meeting.


Tags: , , , , , , , ,

Scrum Training Courses