Agile: About Self-organizing team

As an agile trainer, thought to start a series of articles on Agile/Scrum.

Let me begin with the fundamental concept of agile, that is "team". Agile relies on its team, we love to call the team as "self organizing team".

Self Organizing Teams:

Self Organizing team is a group of individuals, practicing Agile/SCRUM, organize themselves around a problem/challenge given to them by organization, without management’s direct control. Individuals are right people, chosen by management or they are already conditioned and think agile way. They are matured to give and receive feedback in constructive and proactive manner. They work in an open work environment, being "honest" to each other. They understand the client's interest, hence the goal that says delivering the software frequently. As a result, they are groomed and start cultivating the qualities/competencies that help them to deliver frequently. If they are matured to exercise SCRUM, noise will be less in the team. If there is any noise, management should step in to remove impediments. Scrum master is responsible person to guard the scrum team from external and internal impediments.

We believe that agile/scrum starts from “team”, not from “process”. Self-organizing team is fundamental concept of agile software development.

A self organizing team ideally will have following features:

Collective ownership:

Multiple individuals within the Scrum team pull tasks to contribute to the completion of a user story. Everyone shares responsibility for the quality and completion of the code. No single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere. Another way of telling this as team works as “Whole Team”.

Why collective ownership is emphasized in SCRUM? This policy is believed to minimize delay from absent member of the team. The individuals in the team are expected to be cross-functional and owner of whole code. Since every iteration/sprint is time boxed, delay or lag is not entertained.

Cross-functional teams:

Every member of scrum team is expected to be multi-skilled. Does that mean a developer can test or a tester can code? Ideally, yes. However, with growing complexity of the system, this might not be 100% possible. Scrum master should strive to encourage the team to be armed with multi-skills and independent of fellow team member.  Scrum master can create an open environment and reward system that during time of need, right member of Scrum team can step up at right time.  And this is largely possible when the team is small team, isn’t it?

Small teams:

Team size is limited to 5-9 people to ensure everyone knows what the other members are working on. Members will pull unfinished stories and nobody will duplicate effort. The goal is to ensure reduction of waste. I have seen - the team can self-organize themselves, so that few members can work on main user stories of that ongoing sprint, and some can work on re-factoring of existing code to make the code more flexible to adapt change. Experienced scrum member can identify the perfect time of need to re-factor the code.

Parallel development and test:

Fail fast. What is that? Scrum preaches this policy. This means identify defects sooner rather than later. To ensure this, coding and functional test occur at the same time reducing down time for individuals supporting their user stories and catching defects at the earliest.  

I can think of two ways to achieve this:

1.   Pair programming: Two/multiple resources within a scrum team sit together to complete a task/user story. One is driver, who writes the code, and the other member is observer, who reviews each line of code. This way static testing of code can be achieved. The two members can discuss coding techniques, design pattern to follow, optimization of code, code coverage during pair programming. 

2.   TDD, Functional test and Automatic regression test: Test cases in TDD can be unit tests.

            When the code for a user story is committed in a repository, it should be unit test/functional test-passed and regression test passed. Since, scrum is incremental and iterative development methodology, regression test is mandatory.

Sustainable pace or sustainable velocity:

Scrum master should try to achieve this. This is something to do with building trust with Product Owner by being able to deliver a consistent amount of work over multiple sprints. The goal is to drive consistency in delivery. “Whole team”, “independent team members”, “cross functional team” are keys to achieve this competency.

Everything is hunky-dory? Please read on...

Per Mike Cohn, a misconception is that because of this reliance on self-organizing team, there is little or no role for leaders of agile teams. He says, self-organizing team does not free from management control. Control is exercised; but, it is subtle, indirect. Management chooses the product to build, or sometimes chooses the members to work in the project. Management control is exercised when needed, for example, if team needs direction after impediments created from evolution of behavior that comes from interactions of independent members of the team.

Another impediment could be wrong attitude coming from a team member who has agile-phobia. A person, who comes from a background that exercised thorough waterfall model for too long, shows resistance to accept agile. He tends not to accept the idea of “whole team” OR refuses to accept cross-functional work. Management control is exercised in giving him adequate agile-training.