Posts Tagged ‘Agile’

Are You Part of a Scrum Team or Scrum Group?

March 14th, 2011 by LLowry

I remember the first time I heard the term scrum development.  A manager at a previous job told me “We’re doing Scrum now, read this.” Then he handed me bunch of photocopied book pages.

After a comprehensive review of the pages, all I figured out was that Scrum had something to do with fast meetings every morning. And that was my first introduction to Scrum.

At a later job, I found myself in a meeting, brainstorming the best way to make Scrum work internally, and arguing over what Scrum was supposed to look like. Both situations, a minimally explained stack of photocopies, and arguments over the physicality of Scrum, resulted in negativity- people around me decided that “Scrum doesn’t work.”

How Scrum Works

In my situations, trying to make Scrum work took precedence over the team, and whether or not it could really take advantage of Scrum practices. Taking advantage of Scrum practices is what makes a Scrum team succeed. After all, the development term “Scrum” was derived from rugby for a reason.

The name Scrum was chosen to represent specific software development practices because like Scrum team in rugby, one team needs to cover a variety of responsibilities. This team works towards a common goal, continuously, in parallel, and under circumstances that could, and do, change rapidly. In rugby, the Scrum team needs to cover ground together. The clock never stops, teams never switch sides, and the ball can only be thrown backwards or sideways, forcing the team to move together in a line across the field. Similarly to Scrum in development, all team members need to know their teammates status, so they become aware of new gaps in the field position that need to be covered. In this aspect, the team needs to be self-managing, while it pushes the ball forward in sprints. This can’t wait for outside direction.

If your team is new to scrum, or struggling with it, the tendency to blame Scrum practices instead of a team’s unity often highlights deeper problems. If a member of a rugby team isn’t keeping up and leaves a gap in the line, no one would say ‘rugby doesn’t work’. The word ‘team’ gets thrown around business a lot when ‘group’ would be a better description. A team communicates with each other, strategizes, and members know how to truly work together- not just in parallel.

Functioning as a Scrum Team

In the film Invictus, Nelson Mandella tells the captain of the South African national rugby team that he needs them to win the world cup to gain the support of the nation. Players complain that their schedules are already full, and extra work like running rugby clinics for children isn’t worth their time. But after working together on these clinics, the team became much more focused and productive when it came to new responsibilities. As the captain said “We’re more than a rugby team now, we need to get used to it”.

The expectation to function as a team is built into scrum. If a group has seen previous success without having to self manage, or without leaving their keyboards for things like planning meetings, there will naturally be complaints that scrum isn’t working. In some cases teams may need to tweak Scrum in order to fit a specific organization, but before making changes it’s worth looking to see if your team is functioning like a team, or like a group.

Join in the Agile Pain Points Conversation

March 3rd, 2011 by AccuRev

Throughout 2010, we surveyed over 1,000 developers, product managers and other software professionals during our Agile Comes to You seminar series, about the pain points they were experiencing on their way to adopting Agile. The results showed several interesting trends and obstacles when adopting Agile, and we provided multiple solutions in fixing such problems.

Just a couple weeks ago, we kicked off our 2011 Agile Comes to You seminars with events in Phoenix and Atlanta, where we re-launched our research efforts aimed at gathering more insights into Agile pain points.  Our next Agile seminars are in the Bay Area and Seattle, on March 16th and 17th.  In each of these sessions, we will address the top Agile pain points we discovered, and their necessary solutions. We encourage the Agile community to join in the dialogue by reading our pain points report or by attending one of our upcoming Agile Comes to You seminars!

Agile and SCM: Avoiding Agile Merge Disaster

February 22nd, 2011 by clucca

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate, and test those changes. Each team needs to be able to work on their own schedule, and if multiple teams want to work on different sized iterations, they can. In addition, they can deliver changes as necessary and on a regular basis, independent of other teams.

The problem? With a traditional SCM system, you have to merge these code changes daily for them to be of any use. You also need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, people use a single baseline or “trunk” methodology for this configuration, where changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you do not use this methodology:

  1. Delivering 2 weeks worth of changes only causes isolation among teams
  2. It’s too hard to pick out each user story as it completes from our codebase
  3. Figuring out the dependencies of those user stories is complex
  4. Being able to identify what changes came from each branch becomes impossible

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. An Agile SCM system supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.