Agile Software Development

In the absence of market facts, he who owns the compiler wins. © Steve Johnson

If you are on the customer side of a project (for example, being a Scrum Product Owner or a person above him) you might have experienced a situation, when you ask team for building features A, B and maybe C, and the build C, D and a bit of B, "because they thought D was more important for the user".

Theory

Scrum theory on the customer side is simple. Formulate your requirements in a list, team commits to what it can, implements the committed items during a sprint and in the end you accept or reject what they managed to come up with.

Ok, being a good product owner you don't separate yourself that much from the core team. You regularly groom the product backlog together with the team and during the iteration help the team understand what exactly you want, but the process still revolves around listing requirements and accepting/rejecting their implementation.

A Google search on the text "Ask and Thou Shall Receive" got me a few different references to Bible chapters, including Matthew 7:6-8, Luke 11:9-10 and John 16:24. It seems that the disciples were never shy of asking when they wanted something, and I cannot blame them.

Asking people for things you want really works!

Children Asking
There's a saying in my language (Dutch): "Wie vraagt wordt overgeslagen." It roughly translates to "Those who ask will be skipped". It is often used to get children te keep quiet when they're asking for sweets or presents. But my grandmother, a religious person herself, has fought against this idea. Several times she said to us: "Children that never ask, will not get what they want." She actually might have been referring to "Ask and Thou Shall Receive", either consciously or not.

I've been thinking a lot about the collocation of agile development teams (or any development team for that matter). Some people argue that collocated team members are essential to successful software development while others argue that it doesn't make any difference. The more I think about it, and the more we operate with geographically dispersed teams, the more I'm starting to believe that collocation matters.

Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL. While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications. The difference is that in the Ft. Collins office (and I'm sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members. You know, the kind of discussions that happen spontaneously. When these happen, a lot of project information gets passed between team members that doesn't get transmitted to other remote team members. There is no malicious intent to not communicate. It's just that the impromptu discussions don't usually inspire anyone to dial in to a teleconference number and all that...precisely because they are impromptu.

Let's face it, no matter where you work, fires flare up from time to time. Some are serious and need to be addressed, some are just smoldering and can be put off for a short time, and some are just people yelling fire when there is no fire. Some organizations are perpetually in fire drill mode and can't break the habit. So, if you're an agile organization and your agile teams are committed to completing their iteration tasks, how do you fight these fires without interrupting your agile teams Even if you allow a buffer of time within your iteration planning for handling unexpected requests, you still run the risk of distracting your development teams with potentially harmful context switching.

Its very interesting to see a new face to the interviewing process for a team member to enhance the trust and understanding. When adding new talent to the team, its become a practice to have the candidate to go through a day in team's life. Its very important to have the candidate f2f and nothing is like candidate spending a day in the life. Many organizations believe that both the candidate and the team can benefit from such an interview process.

There days many organizations practicing Agile processes are expecting team members to be multi-talented and be able to work in variety of situations. More frequently we hear the terms like "Self-Organizing" or "Self-Managing" teams in the Scrum world.

In the software development we have learned that the software is becoming more and more complex as the variables technology and requirements change (thus the upfront planning has become famous). In the traditional project management, the project manager used to take the responsibility of the Risks, Complexity, Deadlines, Release Plan, Testing, Documentation and etc... On the contrary the self-organized team is set of individuals with different skills and mostly complementing each other. This team is organized and re-organized depending on the project pressure, schedules and deadlines. This team wears different hats depending on the situation. This team works on a simple rule that "Tell me what to do; But not How to do" and sometimes even the baby steps.

Some companies are very picky at making sure that all their employees got a project to work on. Especially the top engineers. I've seen quite many environments, where senior guys are the ones who have to be "120% utilized" and who are actually doing the work, while juniors are expected to be floating around doing "something not critical" and being asked to help seniors, whenever those would need an extra hand.

Whole team practice recommends including on the team people with all skills and functionalities needed for creating the product: developers, testers, designers, technical writers and especially customers. It is a known fact that in software development a lot of information is lost or misinterpreted whenever the distant handover occurs. Even if everybody is doing his best and 90% of information is handed over correctly when the request goes over 4-5 handovers from customer to analyst to architect to developer to tester the information loss already reaches about 40%.

When agile software development is tried in a large corporate environment, it often happens that the agile pilot team or even teams have to cooperate with the old good waterfall team around the corner. It sounds reasonable that the new things (like the agile process) is tried first on the project of not too big importance, that are supposed to add value to the more important activities. For example, an agile team might be asked to develop a web-interface to the client-server system being developed by a waterfall team.

I don't have an experience with a really hard dependency, but I've been in a situation when our dependency on a waterfall team was rather weak. What happened is that the waterfall team tried

On Joel's Multitasking in the Workplace

Multitasking in the Workplace:
Joel Spolsky, a known writer on software development related topics is a long standing advocate of private offices for every developer, perfect working conditions and managers whose main role is to “move furniture out of the way, so people can concentrate on their work”. Lately he found the support in the published in the NY Times research report claiming that in the cubicle space people loose hell a lot of time on interruptions. I believe that there is a proven way to unite the advantages of the open-space communication and private office focus.