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.

Are coders better testers than regular testers?

Are coders better testers than regular testers?

My opinion is – yes, they are – when they test other’s code. They can be good in both types of testing – black box testing and definitely white box testing.

In case of black box testing:

Black-box testing is a method of software testing that examines the functionality or behavior of an application or system (e.g. what the software does) without the knowledge of its internal structures. Black-box testers normally use techniques like:

• Decision table testing
• State transition tables
• Equivalence partitioning
• Boundary value analysis

A coder-turned-tester should be able to guess which component/part of the software is defect-prone.

For example, inserting appropriate validations at the boundaries of all equivalent partitions are sensitive and critical part of satisfying user requirement. He knows there is a possibility of development team to succumb to a common error and there is a possibility that a validation is missed for a particular boundary. He might have experienced this when he coded for his own software. Naturally he will take extra care when he will write test cases using BVA.

In case of white box testing:

A coder-turned-tester has the inherent sense of internal structure of the code. Hence he is expected to be good in white box testing. Internal structure of the software code is how the code is written. By looking at the code, an experienced coder can understand the flow of execution, interface call, data flow, data dependency, design patterns used etc. He is expected to be good at:

• Control flow testing
• Data flow testing
• Branch testing
• Path testing
• Statement coverage
• Decision coverage

How about taking an example of statement coverage? If client acceptance criteria are to achieve 85% statement coverage before each deployment of code, don’t you think a coder-turned-tester will be at ease to achieve this than a regular tester?

Another example, Client acceptance criteria are to maintain cyclomatic complexity less than or equal to 7. For those, who are new to this metric - Cyclomatic complexity (or conditional complexity) is a measurement. It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It is based on the number of decisions in a software function. A coder-turned-tester, who has a working knowledge of control flows and re-factoring of code, he will re-factor the code (and yes, without changing the behavior of function) to achieve the metric threshold 7 in more time-efficient way, when compared to a regular tester.

My opinion is true for not only testing done in waterfall, but also testing done in agile. Especially, agile methodologies that follow TDD, a seasoned coder-turned-tester supposed to have better understanding of the structure of the code. Better technical understanding helps him to concentrate on writing effective unit tests, than a regular (non-technical) tester. Here, I am assuming the agile team is cross-functional and the team works on collective ownership.

But, yes, one argument against my opinion can be coders normally think technical implementation of the requirement. They think about more technical aspects to improve the quality of code. Testers think from user point of view. Sometimes they make use of error guessing, monkey testing or exploratory testing to find if the application is robust enough to pass the test cases.

Do you have opinion other than this? Please feel free to let me know.

My thought goes like ....

 My thought goes like ....

Agile! Agile is the solution for reducing the waste, we make in follow-up(s). Sometimes, we over-do follow-up to make sure we are getting the expected result on time. What a waste!
Agile relies on self-driven team. No boss-around from the bosses. The team is responsible for their work completion. This increases sense of ownership...team is well-organized, settled.

But then again, Lean or SCRUM?

Lean and SCRUM are mindset, thought process. This is not a short-term cost reduction program or short term idea of getting customer appreciation. It is the way company operates to create more value to the customer. Lean transformation is to how company changes their business operation from old way of thinking to lean thinking, reduce waste, come to zero waste.

SCRUM starts at the team, lean starts at the process. SCRUM talks about self organizing team. There are specific meetings in SCRUM (Stand-up meeting, retrospective), that automatically lead the team to take ownership of work. Team does the estimation for a work. So, if the work is not completed on time (I am thinking no major blocker), team is answerable. This creates value-system. Team will gradually hate follow-up.
Lean talks about set of engineering practices to reduce waste.