I would be speaking at Agile Australia on Distributed Agile

I would be speaking at Agile Australia 2009 on a panel discussion of Distributed Agile. Should be fun, I would write about it once I experience it.

Xebia would be exhibiting at the event. Catch you there.

Non Functional Requirements: The Usual Suspects

In Part-I of this series we looked at what non-functional requirements were and how different people react to non-functional requirements.

Ask any team what do we mean by NFRs and most probable answer would be the following and most probably in the order mentioned below

• Performance
• Scalability
• Availability
• Security
• Maintainability
• Reliability

If you come up with a different list on your first pass when asked about NFRs, let me know.

The NFRs which would generally give the biggest bang for your buck are Performance, Scalability, Reliability and Availability. Once you have taken care of these I would recommend looking at the others like Security, maintainability, re-usability, usability etc.

So lets us look at them one by one

Non-Functional Requirements : The Art of Capturing, Analyzing, Developing and Validating

WikiPedia defines the NFRs as

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints“, “quality attributes”, “quality goals” and “quality of service requirements”. Qualities, that is, non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.

Many people would turn their head in anguish on the mention of Non Functional Requirements primarily because of 2 reasons

What is the Optimal Agile Team Size?

This is one of the frequent questions asked in Agile adoption. I have worked on a project with 135 developers and as expected it was not going anywhere until someone thought that it was death march to proceed in that way. The team was downsized to 60. The process was changed to Scrum. 6 teams of 10 people each were individual scrum teams. But again within this team of 60 people dispersed across 4 geographic locations coordination and communication was still a challenge.

The “silverish bullet” came in the form of dividing the 6 scrum teams to collocated teams of smaller sizes. So the teams were distributed further with each team now having between 5-8 people. The crux was collocated on the same geography. Of course team communication cannot be ruled out hence one member from each team also met in a Scrum of Scrums fashion. Though the teams were drinking from the same backlog, however the sprint backlog for the teams was decided during the sprint planning meeting. The Sprint backlog were kept as much mutually exclusive as possible, but again SoS (Scrum of Scrums) helped for the rest.

So far it has been working for us. But still, what is the ideal team size? People would mention anything between 3-20! Some Agilists argue that the team size should be FIVE. This is the common denominator number based on various studies and falls on the intersection point of these studies. Want to read more about this magic # 5. Refer my post on InfoQ.

What have been the team sizes that have worked for you and how has that environment been any different from any other environment?

The Holy Grail of Iteration Length

One of the frequent questions in Agile adoption is related to the ideal iteration length. Teams usually gravitate between iteration lengths ranging from a week to two months. Choosing the right iteration length is an important decision and the success of Agile adoption depends a lot on the right iteration size.

Read more about the factors on which the iteration length should be decided. My post on InfoQ.

Mapping Traditional Roles to Scrum

Many organizations, which have embarked on the Agile adoption path, have to tackle the challenge of mapping traditional software development roles to the three roles that Scrum provides. Traditional roles like Product Manager, Project Manager, Business Analyst, Designer, DBA etc. do not cleanly map into roles defined by Scrum. In a series of views Mike Cottmeyer attempts to effectively map traditional roles to Scrum.

Read more about it on InfoQ.

Performance Engineering in Scrum

Performance Engineering is an often neglected aspect in software development. This is a bigger pain in Agile where a heavy amount of focus is spent on adding business value which mostly translates to adding more functionality thus sidelining the so called Non-Functional Requirements.

My post on InfoQ tries to address this situation. Read and comment.

Acceptance Test for Hiring Java Developers

While researching for my news post on InfoQ, I came across a very interesting acceptance test for Java developers in an extreme programming yahoo group.

The test goes like this

class SeniorDeveloperAcceptanceTest extends TestCase{
Developer candidate;
Collection team;
public void setUp() {
candidate = new Developer();
team = Leirios.getTeam();
}
public void testTechnicalSkills() {
assertTrue(candidate.isJavaExpert());
assertTrue(candidate.canDesignLargeApplication());
assertTrue(candidate.canReduceTechnicalDebt());
assertTrue(candidate.practiceTDD());
}

public void testTeachingSkills() {
assertTrue(candidate.canImproveTeamSkills());
assertTrue(candidate.canArgueAboutAgility());
}

public void testHumanBehavior() {
assertTrue(candidate.canPairProgram());
assertTrue(candidate.canIntegrateWith(team));
assertTrue(candidate.hasPositiveAttitude());
}

public void testMethodologySkills() {
assertTrue(candidate.knowExtremeProgramming());
assertTrue(candidate.canImproveTeamVelocity());
}
}

If Multi-Tasking is bad, Multi-Tasking with Multi-Reporting is Hell

There have been numerous studies to show that multi-tasking is not efficient and the human brain cannot multi-task efficiently. If we say that it is then we are deluding.

1. Multi-tasking is less efficient, due to the need to switch gears for each new task, and the switch back again. It involves a lot of context switching and thus less time to be effective.
2. Multi-tasking is more complicated, and thus more prone to stress and errors.
3. Multi-tasking can be crazy, and in this already chaotic world, we need to reign in the terror and find a little oasis of sanity and calm.

There are ways to be efficient and the rule # 1 is not to multi-task

So by now you would have agreed that multi-tasking is bad. Now let me introduce you to hell.

Software Releases and Sustainable Pace

Several times we all have been in situations where there is a lull period in the product life-cycle. This is when the team is not being pressurized by the product owner to spew out releases because in turn marketing is not ready to push out external releases to the customer. This usually saps out the energy out of the Agile team and is against the principle of Sustainable Pace.

The Agile team should work on a sustainable pace and keep churning out production worthy internal releases. Marketing and business then have the opportunity of picking up the one that they want to promote to the external world.

Assume that you have created internal releases (IR)  like this

• IR1 – Product + F1, F5, F6
• IR2 – Product IR1 + F4, F9, F15
• IR3 – Product IR2 + F6.1, F12, F10
• IR4…n