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.

3rd
JAN

Results of an Agile Assessment

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

We recently set a team of consultants from my company to conduct a formal assessment of a medium sized financial firm’s an Agile capabilities. I’d like to share thew approach here. The team went on site to conduct interviews and observations in 5 areas –

• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture

Also, the investigation took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action.

Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. I’ll provide details in another post.

Tags: , , , ,

12th
DEC

Complexity and cost of change

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

There are many variables to estimating the difficulty of a code changes. We could talk about things like the complexity of the code (Cyclomatic Complexity), the experience of the programmers, their familiarity with the topic and/or the specific module, the quality of documentation, etc. It ends up being a fairly subjective estimate. In Scrum teams, story sizes are estimated in relative terms in terms of story points.

The primary benefit to using a technique involving Relative Estimates is that you are asking the team to give you an estimate of difficulty relative to other work that has already been completed. This means that a team can easily give judgments like “This will be twice as hard as that” and come up with functional estimations for predictions without spending a great deal of time coming up with them. Estimates are just subjective guesses anyway, understanding that can be a valuable way to put more time into building something and less time into trying to guess how much time it will be to build it. Planning Poker, also called Scrum poker, is one technique for building relative estimates and for coming to consensus on the effort or relative size of the stories.

Tags: , , , , ,

9th
NOV

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: , , , , , , , , , , , ,

25th
OCT

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.

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

4th
JUN

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: , , , ,

25th
AUG

What’s the Point of Velocity?

Posted by admin under Agile and Scrum, Scrum Basics

Scrum teams know that velocity is a rough estimate for the amount of work that a team can accomplish in a given sprint. It is calculated by simply adding up all the completed story points. Since the point values are merely estimates of the perceived difficulty and time necessary to complete the backlog item, a team’s velocity is not especially useful in and of itself. Instead, it becomes a valuable metric over time as teams complete multiple sprints and have the opportunity to establish a consistent velocity. Once this occurs, the Product Owner can look to the team’s established velocity to determine how much work it can tackle in the next sprint.

Amr Elssamadisy has just posted on the topic of velocity and concludes his post with the following questions: “Should velocity be used a metric for productivity?  Should it be used for iteration planning?  What about longer term release planning?  Should it be used at all, or is it a wasteful practice?”

As always, I’m curious to hear how you’d answer those questions, so please share your thoughts in the comments section.

As you might guess, I’m of the mind that tracking velocity is a valuable process. However, the limits of its value must be understood, since it is derived from estimates (i.e. abstracted valuations) and not an absolute indication of progress or productivity. Thus, it can be helpful for sprint and release planning, but should be regarded as an estimate all the same.Perhaps the most valuable aspect of tracking velocity is the ability to observe how a team develops over time. That is, if a team consistently increases its velocity, it can be inferred that the team is learning to work together better and incrementally improving its performance.

To see an example of a team computing velocity, pay attention about halfway through this example Sprint Review Meeting.

Tags: ,

9th
SEP

Scrum Product Owner

Posted by admin under Scrum Basics

There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.

In Scrum, the Product Owner is the one person ultimately responsible for the return on investment (ROI) of the product development effort. The Product Owner influences the development effort by conveying his vision to the team(s) and prioritizing the Product Backlog. The Product Owner must have the authority to make real business decisions, vision about what the product could be, and availability to the team(s). In bad implementations of Scrum, one of these elements is usually missing. For example, if I don’t have the authority to cancel product development entirely (an important ROI decision), it’s misleading to call me “Product Owner.”

This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Since Scrum is team self-organization, the Product Owner must respect the team’s ability to create its own plan of action. A Product Owner doesn’t demand additional work in the middle of the sprint. The Scrum Product Owner is discouraged from adding work to the sprint until the next Sprint Planning Meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.

It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions about what not to do.

In Large Scale Scrum, one Product Owner prioritizes a single Product Backlog for multiple teams. Multiple backlogs for one product — and multiple Product Owners — cause localized optimizations (detracting from a whole product focus), longer work-in-progress queues, thus are harmful to agility. Large Scale Scrum encourages teams to become truly cross functional and take greater responsibility for their own requirements clarifications. Cross functional doesn’t mean only dev + test, it also includes learning the requirements domain.

The responsibilities of the Product Owner are also described about halfway through this video module:
Introduction To Scrum video

Tags: , , ,

5th
SEP

The Scrum Backlog

Posted by admin under Scrum Basics

Scrum has two types of backlogs, the Product Backlog, and the Sprint Backlog.

The Product Backlog is a prioritized list of customer-centric features. It breaks the big-picture vision down into manageable increments of work called Product Backlog Items (PBIs). These are typically expressed in user story form. Product Backlog Items are not tasks, they represent the what rather than the how. If Product Backlog Items are estimated, they’re estimated in relative units such as story points. Items toward the top of the Product Backlog should be small enough that a team could accomplish several of them (including proper testing, integration, etc.) in one two-week Sprint.

The Product Owner and Team collaborate to refine the Product Backlog continuously (e.g. about an hour per week) in the Backlog Refinement Meeting.

In Large Scale Scrum, multiple teams pull their work from a single Product Backlog. Multiple teams collaborate with the Product Owner to refine the single Product Backlog.

The Sprint Backlog is created during the Sprint Planning Meeting. The team pulls the amount of work they want to do from the Product Backlog into the Sprint Backlog, and further decomposes the PBIs into Sprint Tasks. The team decides the how, and expresses this in the tasks. The best way to represent the Sprint Backlog is a physical taskboard, using PostIt Notes or index cards. During the Sprint, typically at the Daily Scrum Meeting, team members move the tasks around to reflect how they’re doing on them. One purpose of the Sprint Backlog is to limit work in progress (WIP). Humans become ineffective when they worry about too many things at the same time.

Tags: , , , ,

5th

Scrum Backlog Grooming

Posted by admin under Scrum Basics

While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.

Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.

Watch an example backlog grooming meeting.

Tags: , , ,

20th
AUG

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.

http://www.open.collab.net/nonav/community/swp/training/DailyScrumMeeting/DailyScrumMeeting.htm” target=”_blank”>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