Archive for the ‘cross-functional teams’ category

Cross-Functional Teams and Success with Agile

April 15th, 2011 by Bob DeMaria

I ask you- what do you think is the most important characteristic of an Agile team?  If you were to ask me, I would answer with cross-functional teams; I believe they are one of the most important contributors to success with Agile. A cross-functional team is ideally staffed with developers, testers, doc writers, and any other discipline necessary in order to complete user stories within the team.  At times, a team may add on a certain role, i.e. DBA, to assist with a particular iteration, but by and large a cross-functional team has what it needs to get the job done.

Cross-Functional and Self-Managing

One of the reasons for this is that the team strives to be self-managing, and to have that ability you need to be able to control your own destiny.  This is a bit of a chicken and egg thing… what came first cross-functional or self-managing?  These characteristics allow an Agile team to make their own decisions, collaborate amongst the team for the best ways to do things, allows team members to assist other team members when they have free cycles, and fosters a self motivated team that wants to succeed.  After all, the team sets its own priorities (to a certain extent) and then has the responsibility and accountability to produce.

Communication is Key to Cross-Functional Teams

For many of these functions to occur, and for them to be maintainable, you need to have a high level of communication between team members.  That’s just one of the reason why we do things like daily stand-ups, sort of a forced daily communication between all members of the team.  In addition to daily stand-ups we also have things like story boards, task boards, and burndown charts that are usually displayed and updated in a very open environment, again to facilitate openness and communication.  Better to know about something now then 3 weeks from now, whether its bad or good, right?

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.

Developers On Board with Agile, but Scaling Poses Obstacles

February 2nd, 2011 by AccuRev

There’s little question that most organizations are considering a move to Agile practices, but what’s holding back adoption?  Earlier this month, we released the results of research conducted over the past year as part of our “Agile Comes to You” seminar series. We surveyed approximately 1,000 developers, testers, product managers and other business professionals across the US and Europe, and findings shed new light new light on the obstacles software development organizations are facing as they move forward with Agile initiatives.

What obstacles hold back Agile Adoption?

The top obstacles identified by the survey included: capturing requirements (16%), lack of in-house experience (14%), and lack of automated tests (13%).  Other Agile pain points were challenges associated with teams spread across multiple projects (10%) and support for Agile with distributed teams (8%).  There are ALM tools available today designed specifically to help developers overcome these obstacles.  Development organizations can also implement a number of best practices processes to smooth the transition to Agile and accelerate adoption.  Following the survey results analysis, we’ll provide more details on the tools and approaches in a subsequent blog post.

The study also showed that pain points varied based on the extent of the organization’s Agile adoption: organizations in early and mature stages of Agile adoption both saw capturing requirements as a source of pain, while those organizations with some Agile processes implemented identified the lack of automated tests as their top issue.

In addition to spotlighting the obstacles to Agile adoption, AccuRev provided updated insights into interest in Agile.  Approximately 70% of those surveyed are currently implementing Agile practices – of this group, 23% are scaling, 37% are piloting, and 8% are already fully Agile enabled.

The full report of the Agile Adoption Pain Points Survey is available free for download at http://www.accurev.com/whitepaper/agile-pain-points-survey.

Here’s what others are saying about the survey:

Application Development Trends

Dr. Dobb’s Journal

We’ll have more insights to share based on what we’ve learned here, including next steps recommendations for organizations faced with these obstacles as well as the toolsets needed to implement and scale Agile.