contains_even = False
for element in [1, 2, 3, 4, 5]:
    if element % 2 == 0:
        contains_even = True
        break
if contains_even:
    print "List contains an even element."
else:
    print "List does not contain an even element."

Compare that to the for…else equivalent code, allowing us to remove an additional flag variable:

for element in [1, 2, 3, 4, 5]:
    if element % 2 == 0:
        print "List contains an even element."
        break
else:
    print "List does not contain an even element."

The else suite will be executed unless the preceding loop has been terminated by a break statement. A continue statement will skip the rest of the suite and proceed with the next item, or with the else clause if there was no items remaining.

The team consists of one or more developers, designers, architects/tech leads etc., all with none or limited scrum experience. For the untrained eye, a good candidate for a SM is someone familiar with the company, its customers and its way of managing projects – preferably a senior staff member. Obviously, this is the natural choice for the management as well since they’re looking for someone to “take charge” of the project and bring it home, even though this new (Scrum) way of doing projects is new to them.

There are several things that should be noted with this first observation. Sure, it may be valid to put a senior staff member in the center of action for the purpose of showing a good project face towards the rest of the company. However, there are far more subtle dangers lurking behind a decision like this.

• Facilitate, not manage. A primary role for a SM is to facilitate communication between the team members, but never to manage. This difference may be noticed during the Daily Scrum when team members adress the SM instead of the team. A tech lead, or a project key figure in general will easier be seen as manager rather than facilitator in place of for instance one of the developers.
• Facilitate, not solve. Impediments in different shapes and forms often come up during daily scrum, or in between. One of the primary missions for the SM is to make sure that these impediments are removed, but not necessarily by the SM herself. It’s easy for a key figure as SM to get to deeply involved in the solution itself, rather than make sure it’s solved by someone in the team, by someone in the organisation, or someone else entirely.
• Prioritize the team, not herself. If an impediment surfaces, it’s important that the SM prioritizes to solve it, even if that means pausing her own current sprint activities. The team is priority #1 for a SM, so that everyone else can focus on making sprint progress.
• Work for the team, not for herself. The SM must always work to improve the progress and performance of the team, regardless of the impact this has on her own sprint performance.
• People, not technology or design. System and/or graphical design discussions are crucial ingredients to successfully complete any project, in Scrum even more so. When the SM is also for instance the tech lead, it’s easy for the team members to adress the SM for technical design discussions – instead of using other members, or the entire team as opinion. The SM should focus on the people in the team, and leave the technology to “the team”, i.e. collaboration.
• Single point of failure. The SM role in itself is a crucial role to keep the team focused and on track. If this individual is coupled with additional key roles, the team becomes vulnerable to absences, either to sickness or to other teams. It’s wise to spread the team load evenly among the team members.
• You should work with what you enjoy, and you’ll to a better job. Not all people are cut to working with technology, programming or any other role for that matter. This is also very much true for a SM, whose main purpose is to provide an excellent working environment for the team and its members. A key figure within a project is likely to have a thorough knowledge and passion for the area she’s working in. For the same reason not everyone enjoys technology, it’s likely that this individual doesn’t fire on all cylinders when it comes to dealing with people and group dynamics.

Citing Wikipedia for a definition of an Architect; “An architect is a person trained in the planning, design and oversight of the construction of buildings.” Although we’re into software rather than buildings, the traditional role of a Software Architect is generally thought of as being just that of a traditional Architect – that is, planning, designing and overseeing the construction of software.

Sticking to this method of designing software, including Big Design Up Front, may or may not lead to working software. However, keeping a single individual (or a team of individuals in the case of an over-sized project [resulting in even further issues, but that's a whole different post]) responsible for all design aspects of the intended software will likely render the project vulnerable to disturbances. Disturbances come in all shapes and sizes, ranging from real obstacles such as illness to changing or previously unknown requirements.

However, the key issue with this setup is the team environment it produces surrounding the software being built. Developers in general are curious folks (I’m aware that this may be a cultural thing, but this is true for all my current, previous and definitely future colleagues and programming friends) that thrives in finding good solutions to tricky coding and design problems. If all major design decisions were to go through a single entity (The Architect), where would then all the other great ideas spawning from the collaborative forces of the team be captured? Probably down the bin, or in a good scenario into the software, ignoring the Ever-So-Busy-Architect-That-Never-Tends-To-Pick-Up-An-Editor-And-Actually-Produce-Code.

I do recognize that this is an oversimplification, I’m however fully convinced that a collaborative effort triumphs that of a single individual, each and every time. The key is collective ownership of the software being built.

So, what are the alternatives, if any? Most projects will do just fine with a close team of Developers (disregarding the fact that the project most likely will need other qualities besides the technical ones) with a common goal and an agile approach to design and implementation. However, dealing with more complex systems as currently are being built all around the globe, I do agree that there are some projects that require someone with a different set of priorities, with a broader sense and understanding of both technical and business issues.

It comes down to the organisation itself whether there is an actual need for an additional business title for this individual. A common term surfacing around the web is Tech Lead (TL), or Lead Programmer. Depending on what you want to accomplish, this role may require one or several of the following qualities:

• Facilitate deployment of good practices. Preferably, it should be in the interest of the entire team to stay on top of current techniques and practices. The TL can however drive this process by making sure that a good idea is always pursued. TDD, XP, BDD, DDD, Continuous Integration, Camping, Memcached, Scala or Cassandra, the list is endless.
• Keep a technical overview of the major parts of the system. Since most developers in a team are highly focused on certain aspects of a system, it’s easy to loose track of the long term goals and make decisions that may be overly costly to change later on.
• Write a lot of code. This is probably the biggest difference in comparing a TL/LP with a Software Architect. A TL is never far from the nitty gritty, and thrives in solving difficult programming problems in the most elegant and/or high performing way. The TL is always a good partner to discuss programming issues with.
• Facilitate collaborative ownership. In order for a successful collaborative environment to flourish, it’s essential that the TL brings his A-game and encourages continuous improvements to the software by the entire team and all its individual members.

And most important of all, this individual should thrive in improving both herself and her teammates skill and delivered quality. This work is never done, it has merely begun.