I often have the feeling that programming and software development is largely misunderstood. Many people seem to still have ancient believes about how software development works. Believes potentially scaring them away from pursuing a career in software development. Let’s fix this.
In this blog post I’ll show why the mental image of one person sitting in a cellar all by him-/herself is as wrong as it can be. I’ll explain why I believe that the most important ability of a software developer is his/her ability to communicate. And I’ll highlight why I enjoy software development so much. (hint: there are also slides about this)
The typical misunderstanding
Let me take you through a somewhat normal conversation for me with strangers at a party:
Bingo! You’ve just won yourself a speech of how that is basically the opposite of what I do. My work is filled with lots and lots of communication. Let me walk you through some of the most important and most frequent communication activities in Software Development.
Communication within the team
Most software isn’t built by a single developer. It’s developed by a team or even multiple teams. I mean does anyone really believe that a single nerd in a cellar builds Facebook and another one builds Windows?
This software is built by large collaborative teams. In a team you have to work together to achieve something.The parts developed by members of the team have to interact and play nice with each other. To Facilitate this the authors have to communicate. As software often solves complex problems, these systems also have to be carefully designed. This is best done in a group of people in front of a whiteboard – not in front of a monitor.
Modern software development actually focuses a lot on the team developing software and how they work together. Let’s take a look at the Manifesto for Agile Software Development, the foundation of most modern software development processes. It values:
Individuals and interactions over processes and tools
This is the very first point made highlighting that good software development is about people and how they work together. It’s not only communicating about the project, solving difficult problems together – of course the normal small talk and “grab a drink together after work” is included as well 😉 Motivation is very important.
It doesn’t stop here though. Often software projects are big enough that multiple teams have to collaborate to realize them. There is a lot of communication going on there as well. But there are still other people developers should communicate with like the system administrators and the customers. Wait, what – the customers?
Communication with the customers
Yep the customer. The ones ultimately using the applications. Or the client wanting the application.
Unfortunately that thought might seem alienating at first, but think about it. Those are the people who ultimately know what the application should do. They are the ones that will be using it, it should fit their purposes. The only way to know if the application reaches its highest goal, satisfying the customer, is through frequent communication and thereby feedback. That starts with asking them what the application should do and how it will be used. It doesn’t stop there though, it is enhanced through demos of a prototype of the application to verify understanding.
Some people take this even one step further. In one of the all time classic books about programming, The Pragmatic Programmer, it is recommended that you spend as much as one week working with the your users before writing an application. This way you should get to know what their work is like.
All of this generates invaluable insights and builds trust.
Look, there are two of them in front of just one monitor!
Yep that’s two developers in front of just one monitor. Actually it’s me and a good friend of mine. So what do we do? Well naturally we are working. We are doing Pair Programming. That is one of us is actually writing the code while the other one observers. We both design the code and talk about it. We work together.
Some people think that this is a waste of time. Hell those are 2 programmers, give them 2 PCs so they can write twice as much code!
It’s not as simple as that. In software development we constantly solve problems. Solving them together leads to a solution sooner, higher quality code and more knowledge spread across the team. The benefits of Pair Programming are worthy of a whole blog post of their own.
Despite the benefits Pair Programming is still a pretty debated topic. Some people despise it. Some people only apply it to difficult problems. Some people say that all production code must be written in Pair Programming.
For me I love Pair Programming: It makes programming a lot more enjoyable, at least to me. When you try to solve a complex problem sometimes you hit the wall. You just don’t know how to solve this problem. You’ve run out of options. It can be really frustrating. That never happens to me when I’m Pair Programming. We, as a team, never seem to run out of ideas on how to solve a given problem until we find one that works. On top of that I can communicate and collaborate with someone all the time. How much more awesome can it get?
And what’s my point with this? During a good normal work day, I actually communicate and collaborate with at least one person almost all the time. Sweet.
Communicating through code
Now I really gotta be kidding right? What does code have to do with communication?
“(…) when you program, you have to think about how someone will read your code, not just how a computer will interpret it.”
And that someone refers to the people in your team as well as yourself. As a team you work together meaning that you have to be able to understand and extend the work of your colleagues. And of course you must be able to understand what you wrote some months ago or even just some weeks ago. You might be surprised how difficult this can get with poorly written code.
Good code must communicate well. The best code, in my eyes, is the code that is the easiest to understand. Code that pretty much speaks to its readers. Writing such code can be very challenging. You can find me discussing with my Pair Programming partner about naming questions for like 2 minutes – it is important.
Does everyone work like that?
Not every company empowers their teams. Not everyone loves pair programming. Not every company cherishes communication. Not every company works Agile. There are people out there still following the Waterfall process, which has been a misunderstanding from the beginning, where at first rigorous documents are made and then the programmers are locked away to “just code it”. Why do people keep doing this? I have no idea. I just know that there are enough tech companies looking for developers out there so you don’t have to end up at an old-school command & control enterprise.
So with all this talk about communication one might ask: “What about the introverts? What about people who don’t like to talk as much?”
Well I’ve worked with some people who might qualify as introverts. Let me tell you this: I’d love to work with each and every one of them again.
See communication is not a one-way street. It’s not just about talking, it’s at least as much about listening. People who just talk but don’t listen are bad communicators. Maybe more introverted people don’t talk as much. However with the ones I know I found that if they say something it is of immense value. And they are very good listeners as well. Plus they enjoyed Pair Programming as much as I did. I would say they are good communicators and collaborators. To me bad communicators and collaborators are those that don’t work together with the team and spend most of their time simply criticizing others.
So what’s the lesson here? Well today’s Software Development is a lot different from what many people think it is. You work together as a team. You talk. You draw on white boards. You have those funny little post-its to coordinate work. Some people work together all day long. You have fun. You actually communicate with he people using your product.
As I hinted at first all this makes me believe that the ability of developer to communicate is more important than his/her technical ability. Developers are part of a team. If they excel technically but don’t know how to share their expertise with the team then they’re not helping much. Even worse, people who spend meetings just criticizing ideas can easily kill the motivation of a team and slow them down significantly. Luckily I haven’t met many of them.
Good communicators and collaborators on the other hand do everything for the team. They help and motivate each other. They happily share their knowledge and are always ready to learn new things.
So my point is this: Do you like solving problems? Do you like to work in a team? Would you like to work in a continuously evolving field with lots of new technologies and opportunities? Do you like to build something awesome helping many people?
Congratulations, software development might be just the thing for you!
just a quick note I updated my beloved Resource section with some quite nice new resources. I also restructured it so that Ruby and Rails got some distinct sections.
When I started this blog sharing resources for learning how to program was pretty important to me and it still is now. I love both teaching and learning. I hope that these resources can help you to learn how to program, teach someone how to program or improve your own skills. But it’s not only programming there, my favorite topic “agile software development” is also mentioned!
I’ve been at the XP 2012 conference and I had a great time and a lot of interesting conversations. One topic that particularly intrigued me is how we can teach agile software development at universities. There are, to my knowledge, quite some universities that don’t teach agile software development at all or do it very badly.
I attended a good talk by Mark Lainez. He, and some of his colleagues, use their spare time in order to give presentations and hold workshops about agile at Belgian universities. This is super awesome. They do this because they saw a lack of “Agile” education at universities in Belgium. However this is not only a problem in Belgium. It is much more widespread than that.
This post is mainly aimed at people like Mark and lecturers at universities, who want to introduce “Agile” to universities. I’m lucky to be at a, in my eyes, particularly good university. As I’m a student myself I’d like to share my thoughts on what worked for me, what didn’t work and what might work when learning about agile software development.
Theory is good – but people need practice
Let me tell you something about my studies at the Hasso Plattner Institute: We learn about design patterns in our third bachelor semester! Awesome right? The bad part: Few students care at first. You need a big project in order to understand the benefit of design patterns.
It’s the same thing with teaching agile, people need to work on something real in order to realize the benefits. People need to practice pair programming in order to see how much it improves their code, their skills and their productivity. I was very skeptical about pair programming at first. However I had a key moment with pair programming. I noticed that I hardly got stuck anymore on hard problems whilst pair programming. When I run out of ideas to solve a difficult problem my partner usually has a good idea to solve the problem. If that does not work then we can discuss and come up with a new approach. You have to experience this in order to really appreciate its value.
However it’s really hard for external speakers to arrange a course with the development of a whole project at a university. Therefore I recommend, inspired by what Mark did, little workshops where you introduce people to pair programming or other techniques.
Furthermore put an extra effort in a really good presentation. Students usually have higher expectations for external speakers than for “normal” lecturers. Try to get them engaged, for example with games. There are lots of little games you may play. These games usually don’t take too long, you get people engaged and most importantly you make your lecture memorable. You can find a list of suitable games at tastycupcakes.org.
At my university we had the Lego Scrum exercise. I liked the Lego Scrum exercise very much and I remember that my fellow students mostly felt the same. At the very least it is something that everyone remembers. Here is a little video of us doing the exercise (sorry for no subtitles!):
I highly encourage you to embed those games into teaching agile software development. I believe that they can truly make a difference. But once you got the students engaged and they know about the theory, then it’s time for practice! Time for a project! Or more?
Don’t conduct one agile project, conduct 2!
Let me tell you something more about my bachelor studies: We are supposed to develop our first project with agile software development methodologies in our fourth semester. And you know what? It was a disaster. But a disaster that was needed.
We were using eXtreme Programming (XP) for the first time. We had enormous problems with estimations, user story slicing, iterations, test driven development (TDD) and probably everything else you can imagine. We did a whole bunch of mistakes. It was not just my group. Nearly every group I remember faced similar problems. For instance nearly everybody wanted to do TDD but ended up with a code (line) coverage between 20% and 50%. When we didn’t get our user stories done during our first iteration we simply prolonged the iteration by one week. Yes we really did that.
Of course, there were bright spots. We used pair programming and loved it. Our planning went pretty smooth towards the end. However I honestly don’t know how I’d feel about agile software development if this would have been our last agile project.
Luckily we conducted a second project in another course, which has already been praised. There we were using Scrum in a team of 50 people (with sub teams of course). We developed a customer relationship management system in Ruby on Rails. Our planning and retrospective meetings were facilitated by students who took the course in previous years. It was interesting to see how much we all improved as we grasped the concepts better. Moreover it was a good experience in inter team dynamics.
It was good but we still had a long way to go. Unfortunately not everyone seemed to like the concepts as much as we did. We were one of few teams to choose an agile development process for our bachelor project, were we were (mostly) free to choose how we want to work.
Adaptive vs. Innovative
Clarke Ching opened my mind to another important aspect: Adaptive small changes when rolling out agile or the “all at once” package. I believe that some of the problems we had were related to this. If you try to implement so many new and different concepts all at once, you will most likely end up implementing every change just a little. There are just too many new things which you can’t possibly really implement the first time around.
Therefore I believe that it could be beneficial to run workshops specialized workshops or exercises prior to the project. These exercises could focus on estimation, pair programming, TDD or… you get the idea. This way students get the opportunity to familiarize themselves with a method prior to using it in a project. Or you could tell students to simply focus on a set of changes and not try to implement all of XP all of a sudden. I just had the feeling that it was a bit too much, so maybe these techniques could be used to mitigate the problem.
Theory is good and necessary, but practice shall never be underrated. If you give a lecture as an external speaker make sure to make it memorable. Engage them. Share your enthusiasm with them. You won’t convince them all. That’s alright. But if you give it all, you will successfully plant the idea of “Agile” in their heads. And I’m very thankful for everyone, who does this.
You probably know that there is the Waterfall process – by now feared by most as “the father of the plan driven approach”. Some may even know that Waterfall was supposedly “invented” by the paper “Managing the Development of Large Software Systems” by Dr. Winston W. Royce in 1970. But have you ever read it? Why should you? It’s probably just an endless explanation of how great Waterfall is… or is it?
What if I told you that it is the exact opposite? If I told you that it is a paper identifying this pattern (without naming it Waterfall) and describing its deficiencies and proposing enhancements? Don’t believe me? Well let’s see what Mister Royce writes right after introducing the pattern on page 2:
I believe in this concept, but the implementation described above is risky and invites failure.
Doesn’t sound so positive, does it? Oh and that’s not even the best part! The best part is that the paper actually includes some thoughts that I would classify as agile.
Yes back in 1970 the paper, that supposedly invented Waterfall was describing its deficiencies and actually contained some agile thoughts. I really recommend you to go ahead and read this paper. Or stay with me and let me explain it to you – or do both.
The reason why I’m bringing all of this up is that it seems that all of this is a little known fact. I mentioned it to two of my lecturers (both PhDs) during discussions about agile vs. plan driven. The fact that they didn’t know this kind of shocked me, so I decided that this probably needs some more exposure – and this is all the exposure I can give.
But all is not lost, I actually learned this fact from a lecturer, Dr. Joachim Schnitter, at my home institute – so thanks to him!
Royce doesn’t define the Waterfall model and recommend it, he identifies the pattern and shows one of the major problems of the Waterfall model as the testing phase occurs at the end of the development process:
The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.
He further on states that faults found there will most likely result in a major redesign of the software, he describes the devastating effects of this as:
The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
To me this analysis is pretty much right on target in describing Waterfalls biggest problem, highlighting that he doesn’t recommend this approach at all. He is suggesting improvements.
So how is this paper agile?
It is certainly not totally agile, but it contains thoughts that go in the right direction and really resemble some current agile practices. Winston Royce proposes 5 enhancements to the “Waterfall” model, they are as follows:
Program design comes first
Document the design
Do it twice
Plan, control and monitor testing
Involve the customer
Let’s focus on the latter 3 as the first 2 aren’t pretty agile to my mind (especially not number 2 as it highly emphasizes documentation):
Do it twice
Royce basically advocates that if your software product is original, the version delivered to your customer should actually be the second version of the product, at least for critical areas. He goes on to explain:
Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.
He explains that this is done to identify problems early on, so they can be tackled appropriately later on. All of this sounds like a “spike” to me. You go on to build a part of your system, which you have little knowledge about, in order to increase your knowledge about this part of the system . You do so in isolation and throw the code away afterwards. He says that you should do this, but for the whole system.
Plan, control and monitor testing
In this section he once again argues that it is bad, that the testing comes last. However he does not jump to the conclusion that testing should come first, but he greatly emphasizes the importance of testing for the success of a software project. He also says that code should be checked by a second party, as many errors are easy to spot. I know it’s a very far stretch but that reminds me a bit of one of the motivations for Pair Programming, although he doesn’t suggest anything like it.
Involve the customer – the involvement should be formal, in-depth, and continuing.
He also states what it is like when the customer is not involved and the development team is basically left alone:
To give the contractor free rein between requirement definition and operation is inviting trouble.
He suggests 3 points after the initial requirements generation, where “the insight, judgment, and commitment of the customer can bolster the development effort.” These are: Preliminary Software Review (after Prelimnary Software Design), Critical Software Review (after Program Design) and Final Software Acceptance Review (after Testing). Although this is not an on site customer yet, it is much better than “make a contract and then let the contractor work alone in the dark on the system according to the contract” – don’t you think?
So was Winston Royce agile?
Certainly not, but he had some really good ideas on how to improve software development, some of which may be classified as “agile”. But why have most of us never heard of this before?
So how did Waterfall become so popular if the deficiencies were so well-known?
What I write now is just a rumor, nothing more. I’ve no way of telling whether it is true or not and clearly no reference.
So from what I’ve heard sometime some guy of the Department of Defense was given the task to look for a software development process to develop a new system. He found the paper of Royce, read the first page (which is quite positive) and saw the figure at the top of page 2 depicting what we now know as the “Waterfall” model. As it was simple and seemed good he went on to propose the depicted process, without ever reading about the deficiencies and proposed enhancements. Maybe it’s just an urban legend, maybe it’s true – I don’t know. Either way I’m sad that Winston Royce has been so misunderstood.
It can be very beneficial to go back to the roots and read the original sources, even over 40 years after their initial publication. If some more people would have done this, maybe we would have (mostly) gotten rid of Waterfall as a Software Process by now. However it is still there and going strong. To each his own, but I prefer agile methodologies, practices and associated software development processes. To me they are way more productive, effective and fun. And it is always good to know that a CMMI level 5 company can highly benefit from a switch to Scrum – doubling the productivity and reducing defects by 38% (and many more benefits). I encourage you to go ahead and read about it in the Scrum Papers, the section (paper) is titled “Scrum and CMMI Level 5: A Magic Potion for Code Warriors”. Have fun reading it and I hope you enjoyed this read as well!
In my course Global Software Engineering, I wrote a paper about the topic whether a distributed project can be agile. It’s just a 3 pages essay (maximum allowed size, I’d have liked to write much more – about conways law and using teleboard- but well another time).
As the topic is really interesting I thought I might share it with you. In the end I have an idea to combine the agile inception deck with distributed development, ideas might as well be discussed 😉
Both agile software development and distributed software development are recent trends in software engineering. Both approaches essentially aim at a shorter time to market, more quality and less costs. The question, which remains to be answered, is whether these two approaches can be effectively combined to research an even greater benefit. In this paper ideas and facts of current research will be presented .
Agile and distributed development are two of the most recent developments in software engineering. Both are perceived to achieve great benefits, so the desire to combine both approaches in order to gain even greater benefits exists.
Agile and distributed projects are not just a theoretical concept but rather reality. In the annual ”The State of Agile survey“, conducted by VersionOne[*], the percentage of companies reporting that teams in their company are working distributed rose from around 57% in 2007 and 2008 [1,2] to 58% in 2009  and finally to 65% in 2010 .
At first this paper will briefly introduce agile development and distributed development. Afterwards the challenges of combining the two methodologies will be elaborated. Then the current approaches to distributed agile software development will be analysed. Then a new idea for starting an agile distributed project will be presented. The findings of this paper will then be concluded in the last section.
Agile Software Development
Agile Software Development is a development philosophy driven by the thought that requirements always change and that huge upfront specifications (as practised in the waterfall model[*]) are therefore wrong. Agile development processes aim at being lighter processes in order to respond to change much faster and better than traditional development processes. Agile comes in many flavours, the most well known ones are Scrum , Extreme Programming  and Lean. The core principles of these development methodologies were summarized and defined during a famous gathering in 2001 in a document known as ”The Agile Manifesto“[*], where the following values are emphasized:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The agile manifesto also highly emphasizes the value of face-to-face communication and co-location. So it is stated in the agile manifesto, that ”The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“ Moreover in order to realize the value of customer collaboration a customer should always be nearby, the so called on-site customer.
Agile stresses the value of fast feedback. The development principles of agile development processes also include developing software in iterations (usually one week to four weeks) and delivering incremental value. Therefore they are also often referred to as iterative and incremental development, however those principles are not as young as many think, they date back to at least 1968 .
Distributed Software Development
Distributed Software Development refers to the development of a software on more than one site. Usually there is on-shoring, where the all teams still work in the same country, and off-shoring, where teams work together across country boundaries. The latter is usually referred to as ”Global Software Development”, which will be analysed in more detail here.
Global Software Development (GSD) is an effect of globalization as a whole. Companies are looking to outsource (working with a subcontractor) or insource (working with/founding a subsidiary) software development activities to other countries for a multitude of reasons. Mostly the following perceived advantages of GSD are named :
Reduced Development Costs
Cross-site modularization of Development Work
Access to large skilled labor pool
Closer proximity to market and customer
Innovation and shared best practice
Leveraging Time-zone Effectiveness
Whereas the last two are assumed to be mythical benefits, the others are perceived as just being partially realized . A big reason for this are communication problems, mostly emerging from the distance between the teams. Distance in this context not only means the geographical distance but also the temporal distance (time zone difference) and the socio-cultural distance . Of course this also results in a greater effort for coordination, as delivering messages in this environment is much more difficult than in a face-to-face communication. This can especially be observed with modification requests, where research has found that modification requests, that are spread across more than one site, take more than 2.5 times the time to complete compared to a single site modification request .
Of course one of the main issues for distributed development lies in its very nature, as the team is not co-located. Co-location has been proven to be a major success factors for software development . The top issues in distributed development were identified as follows :
Communication Lack of effective communication mechanisms
Cultural Conflicting behaviours, processes, and technologies
Project and process management Difficulty synchronizing work between distributed sites.
Security Ensuring electronic transmissions confidentiality
Strategic Difficulty leveraging available resources
Technical Incompatible data formats and exchanges.
Challenges of Combining Agile and Global Software Development
Agile methodologies heavily rely on co-location, shown with practices like pair programming and the daily stand-up meeting (also called ”Daily Scrum“), which is one of the most widely adopted techniques. It is a short meeting where everyone in the team answers three simple questions :
What did I do yesterday?
What will I do today?
What impediments are in my way?
This practice is difficult in a distributed team setup, as not everybody can be physically present and also the time difference is a big problem.
Moreover the focus is turned towards working software and informal communication with co-workers rather than documentation. This lack of documentation can be a handicap when working in a distributed environment as information has to be made accessible to all team members [12,13,14].
At least when outsourcing there is another problem: Some practices require all the teams to use the same tools. For instance the practice of a shared code base requires all teams to use the same version control system and the practice of continuous integration requires all teams to use the same build tool . Furthermore these systems have to be set up in a way that they are accessible fast and easy for every developer, in order not to restrain their work flow. Additionally the temporal distance may impose the challenge of a twenty-four hour availability, complicating maintenance.
Current approaches for combining Agile and Global Software Development
However there are not just challenges when trying to combine the two approaches. Some agile practices can greatly help with problems in GSD. It has been found that the most commonly used practices in a distributed agile environment are Continuous Integration, daily stand up meetings and pair programming .
The practice of continuous integration for instance can help with the problem of the ”Big Bang“ at the end of the project. By continuously integrating the code of all sites it can be made sure that no major issues occur [15,14]. Furthermore the practice of Test Driven Development (TDD, also called Test First Development) can ensure a high test coverage of the code instantly notifying everybody of a problem in the form of a failing test . Both technologies give a fast feedback on changes, TDD for instance makes it apparent when expectations, that were set by the stakeholders or a developer, were broken by a recent change.
Furthermore it is suggested, that agile methodologies increase the quality of communication at least inside of a team [17,18]. A key aspect of agile methodologies is reflecting about the work. It is common to have such reflections at the end of a meeting and at the end of an iteration (often called ”retrospective“). These reflections help the team to identify problems in the way they work and allow them to adjust accordingly.
The short iterations of agile development processes make the progress apparent. This benefit makes it obvious when a project isn’t progressing as expected and measures can be taken . As such the daily stand up meetings have been proven effective, however this often comes at the price of shifting working times so all sites can attend .
It is recommended for loosely coupled teams to have one or more ambassadors from the remote team at the home site and from the home site at the remote site [15,19]. These ambassadors are there to facilitate communication and also to establish trust between the remote team and the home team. Ambassadors however should be exchanged every few months, so that one person does not have to stay away from his family for too long and does not loose the connection to his home team.
It is apparent that the level of documentation of an agile development process has to be increased in order to fully work in a distributed team set-up. The informal information exchange emphasized by agile processes normally just works for the people at one site, it is rarely shared with the other sites. As a result of this, practices that facilitate knowledge sharing are emphasized and official communication channels become more important . Therefore Fowler recommends a wiki as its unstructured nature allows the teams to apply a structure of their liking for sharing information .
As mentioned before, communication is crucial in a setup with distributed teams. Therefore communication channels should be plentiful, ranging from instant messaging, over a phone at every work place to good video conferencing tools [15,13]. There should not be a significant overhead in setting up a meeting across all locations . This of course is another additional cost distributed software development often introduces.
Travelling so that teams can meet and engage in face-to-face communication has been proven significant for the success of distributed projects, so it is suggested to travel often [12,15]. Especially important phases are the start of the project, in order to get to know each other, and the end of the project in order to smoothly finish it. However visits every few months are also encouraged.
The following two subsections will shortly present the findings of two case studies, that employed a successful distributed agile set up while employing approaches not found to be very common in the reviewed research papers.
Distributed Scrum Type C
Sutherland et al. describe a project which they describe as: ”For a globally dispersed team, it is one of the most productive projects ever documented at a run rate of five times industry average.“ . This was accomplished using a distributed Scrum Type C, which means that unlike most implementations of Scrum in a distributed environment the distributed teams weren’t loosely coupled teams but rather virtual teams.
Each team consisted of members from almost all remote sites. However the people mainly responsible for coordination were co-located or close. All Product Owners were based in Utah whereas all Scrum Masters were based in Utah, Colorado or Canada . This way they could conduct Scrum of Scrums  and other planning activities in a face-to-face manner. The teams had stand up meetings every day. However these were modified, the team members in the remote location had a local stand up meeting at the start of the day and a global meeting at the end of the day. For communication purposes however they found it to be necessary, to write their answers to the questions down before the meeting and distribute them.
The Distributed Agile Transition Model
A four-stage model towards adapting Agile in a distributed environment has been proposed :
Evaluation, different aspects of the project are analysed in order to determine whether to distribute the project and if so how.
Inception, infrastructure is set up and training on agile and the problem domain is provided. Many representatives from the remote teams are at the home location and the remote team has a low degree of self-organization.
Transition, some remote team members move back from the home location to the remote location. They are now familiar with the customer and the home location team, which facilitates communication. The degree of self-organization of the remote team increases.
Steady State, more team members move back to the remote location, which is now completely self-organizing.
At Wipro, this approach has shown to lead to less schedule derivation and more overall quality, whereas other metrics haven’t been impacted, compared to conventional plan-driven methods .
A new take: The agile inception deck
Looking at the current approaches I found that it seems to be a common practice to bring the team together at least for the start of the project. Remembering my favourite technique for beginning a project, the agile inception deck, I thought that it might be very well combined with GSD.
What is the agile inception deck?
The agile inception deck is ”a collection of ten tough questions and
exercises you’d be crazy not to do and ask before starting any project.“, as described by Jonathan Rasmusson in his book ”The agile Samurai“ [21, part II].
It is designed for anyone directly involved in the project (like the stakeholders and the development team) to get together and define the core characteristics of a project to ensure that everybody has the same idea of what the project is like, why the project is done and what to expect from the project. Creating an agile inception deck can take from a couple of days to two weeks . Some of the exercises conducted are the following:
Ask: Why are we here? Define clearly why the project is done and what the main drive that lead to a need for this system was.
Create a NOT list Be clear on what is in scope, and be even clearer on what is not in scope and therefore will not be developed.
Size it up Give a rough estimate of how long the project is going to need to be completed. This is not a commitment, just a guess so that everybody has an idea of how complex the project will be.
Ask what keeps us up at night The goal of this exercise is to identify major project risks early on and talk about it, getting to know your co-workers better.
Design a product box If the product you built could be bought in a store, what would it look like? This helps identifying the main features of the product.
How to combine the agile inception deck and global software development
I imagine that the agile inception deck could be conducted during the first weeks of the project when the teams are co-located. The exercises not only helps everybody to get the same understanding of the project but it can also be a great technique to get to know each other much better. Some of the exercises, like ”Design a product box“, are rather informal and allow the team to creatively work together, having fun in the meantime.
Once the inception deck is completed it represents a set of shared goals and information which should be available to everybody and updated when needed. Ideally it should also be part of a visible workspace [21, chapter 11], a workspace where everybody can see the most important information like shared values, story board, burn down chart and of course the inception deck.
In a review of empirical research papers it has been found that over 80% of the examined agile distributed projects have been a success, whereas under 5% have been a failure (the success of the other projects is listed as NA). This statistic certainly suggests that distributed development can be done agile. Also other sources document a successful incorporation of agile distributed development in a multitude of different companies like Microsoft [12,18], Thoughtworks  and many other companies [20,19,13].
In those studies it was said that an agile approach showed an improvement over traditional plan driven methods. However agile methods have to be adopted in order to be successful in a distributed environment, these adjustments work but are not always easy to achieve. For instance the recommended high amount of travelling (see V) comes with major costs, although it is said that these efforts are really worth their cost.
Personally I highly believe that agile methodologies can be effective in distributed environments and I think that distributed agile projects can still do better, as agility is all about adopting to change. I would like to see some new ideas and approaches being explored, like the incorporation of the agile inception deck or the highly loosely coupled ”2-Pizza“-teams at Amazon[*].
All in all I think that agile distributed projects may be conducted effectively in many environments. However more research in this sector is needed and there is still much room for improvements and new ideas.
VersionOne.2nd annual survey the state of agile development.2007.
VersionOne.3rd annual survey : The state of agile development.2008.
VersionOne.4th annual state of agile development survey final summary report.2009.
VersionOne.5th annual state of agile development survey final summary report.2010.
Jeff Sutherland and Ken Schwaber.The scrum papers.2007.
Kent Beck.Extreme Programming Explained: Embrace Change.Addison-Wesley Professional, us ed edition, October 1999.
Craig Larman and Victor R. Basili.Iterative and incremental development: A brief history.IEEE Computer, 36(6):47-56, June 2003.
Pär J. Ågerfalk Eoin ÓConchúir, Helena Holmström Olsson and
Global software development: where are the benefits?Commun. ACM, 52(8):127-131, 2009.
James D. Herbsleb, Audris Mockus, Thomas A. Finholt, and Rebecca E. Grinter.Distance, dependencies, and delay in a global collaboration.In CSCW, pages 319-328, 2000.
Stephanie D. Teasley, Lisa Covi, Mayuram S. Krishnan, and Judith S. Olson.How does radical collocation help a team succeed?In CSCW, pages 339-346, 2000.
Kenneth E. Nidiffer and Dana Dolan.Evolving distributed project management.IEEE Software, 22(5):63-72, 2005.
Ade Miller.Distributed agile development at microsoft patterns & practices.2008.
Balasubramaniam Ramesh, lan Cao, Kannan Mohan, and Peng Xu.Can distributed software development be agile?Communications of the ACM, 49(10):41-46, October 2006.
M Paasivaara and C Lassenius.
Could global software development benefit from agile methods?2006 IEEE International Conference on Global Software
Engineering ICGSE06, pages 109-113, 2006.
Samireh Jalali and Claes Wohlin.Agile Practices in Global Software Engineering – A Systematic
Map, pages 45-54.
Minna Pikkarainen, Jukka Haikara, Outi Salo, Pekka Abrahamsson, and Jari Still.The impact of agile practices on communication in software
development.Empirical Software Engineering, 13(3):303-337, 2008.
Andrew Begel and Nachiappan Nagappan.Usage and perceptions of agile software development in an industrial
context: An exploratory study.In ESEM, pages 255-264. IEEE Computer Society, 2007.
Kalpana Sureshchandra and Jagadish Shrinivasavadhani.Adopting agile in distributed development.2008 IEEE International Conference on Global Software
Engineering, pages 217-221, 2008.
Jeff Sutherland, Anton Viktorov, Jack Blount, and Nikolai Puntikov.Distributed scrum: Agile project management with outsourced
Jonathan Rasmusson.The Agile Samurai: How Agile Masters Deliver Great Software.
Pragmatic Programmers, 2010.