Again On Multisite Collaborations - Various Setups

While writing the previous post, more ideas came to my mind about multisite collaborations. 

Just to have it under our eyes, here is the terminology I use in these articles:

• Multisite collaboration: several teams located in remote locations work together to complete a large scale project.

Multisite collaboration




• Lead site (the buyer): the initiator of the project, the place where the PM resides.

• Associate site (the seller): a site invited to work on the project.

Setup no. 1 - the associate site does not have a dedicated project manager.

No PM in the associate site

It may seem to work at first, especially for small teams in the associate. However, several developments become apparent quite quickly as the team grows:

• If management is done at a task level, most of the time the people in the associate will act in a manner very similar to being independent contractors, without much attachment to the product. There will be little communication or synergy between them. As we cannot speak of a real team, the value the associate will bring to the project will be directly proportional to the amount of time each employee spends on his tasks, focusing on getting the code to work instead of understanding the product as a whole. 

• Communication can become heavy and with plenty of misunderstandings, not only due to the language barrier but also because the engineers in the associate are most likely not hired for their communication skills but rather for their technical skills. Therefore there is a very high risk of rework and frustration on both sides.

• In this case, the associate site acts more like an HR firm providing temporary workforce, without any additional value that may emerge from team cohesion - like innovation and creativity. The setup is as if the associate employees are temps working for the lead site. 

Setup no. 2 - the associate adds a project manager, but the core of the process does not change.

PM in the associate site is excluded from the main communication flow

A PM is added when the lead site and the associate agree that there is something wrong in the collaboration - like low quality of the deliverables, misunderstandings, rework, delays. However, adding a PM without putting him or her in the main communication loop or not giving him or her decision power does not change the situation much. Satisfaction will not improve dramatically and the PM will mostly feel useless.

Setup no. 3 - PM on the lead side, PM on the associate site

Both the lead and the associate have dedicated PMs to follow the collaboration

While I strongly believe that engineers should not be impeded from communicating to each other directly, the main decision loop should go through the two PMs (one on the buyer's side, the other one on the seller's side). The associate now has a real chance of leveraging their potential and building a team. With its own backlog, own objectives and freedom of choosing their own internal processes, management is done based on clear KPIs and clear acceptance criteria. The associate has a champion on site, the project manager, who will lobby on getting on its plate higher value business cases and providing not only bare bones engineering services, but also securing the delivery, securing a certain quality standard, participating in the product design or offering additional creative services. The focus moves from tasks to features and added value. 

The last setup works particularly well when there are language barriers, process differences or different organizational maturity levels in the two sites. The PM from the associate acts as a facade, abstracting the development process that happens behind him or her and making sure the discussion does not deviate from the concrete, measurable objectives set for the collaboration. His aim is to protect the team, get acceptance on deliverables and spot opportunities for the associate to bring additional value to the project (entrepreneurial spirit).

To answer one of the questions from PM Days, what is the number one thing that can lead to a successful multisite collaboration, I would summarise everything by saying that my opinion is that PM proficiency (practice + formal) for the associate site project manager, coupled with a modest, outgoing, growth-oriented and curious personality should prevent a lot of problems.

On Multi-Site Collaborations

Now that the PM Days 2013 conference is over, I thought of assembling my notes and posting them here - more like a collage of thoughts, supported by slides from the presentation.

PM Days 2013

Why speak about multi-site collaborations? 

Well, for several reasons. One is that the topic is actual and that chances are that every professional project manager will, at one point throughout his or her career, have to organize a project that spans across several geographically distributed locations. If you are not convinced, just check the image below. :)

Globalization

Of course, the collaboration setup comes with its share of risks that we need to be aware of. It is my belief that anyone who had formal PM training, qualification and also practical experience should be well equipped to handle such a distributed project. PMBOK is a great reference and it was one of the aims of my presentation to look at multi-site collaborations through the PMI lenses: identify the patterns and build a collaboration model inline with what we already know.

As I am an engineer by trade and I like things clear, I need a model to rely on, a model that is discharged of emotional mess, that it is conceptually simple and from which I can easily draw my own conclusions as the project develops. Such a model should scale easily and it should be independent of the project specifics (like methodology, scope, stakeholders, initial risks and assumptions) .

Another reason is the personal opportunity. I honestly believe that collaborations open the gates of the world to the people involved in them. They are an amazing chance for learning, sharing, reaching out to other people and experiences and contributing to significant projects. By collaborating, we can build on each other's strengths while minimizing our weaknesses.

While the pessimist and the optimist fight over whether the glass is half full or half empty, the opportunist steps in and drinks it (thank you, Anca, for this joke)

The third reason is the business need  - the case of having to ramp-up quickly to a large number of people (hundreds), with very specific talents (composers, artists, specialized programming, etc...), which may not always want or can relocate. Without such collaborations, large scale projects may have not existed at all or smart professionals located in various corners of the world might have never had a chance to contribute to them.

S-curved ramp-up

To conclude, I will quote the presentation description from the conference website: "we live in a globalized, hyper-competitive world, where companies need to constantly reinvent themselves, their products and their processes in order to survive – all at an incredible speed. Talented people are key to organization success and thousands of papers and books have been written about how to acquire, retain, train, motivate and best use them. “Our employees are our most important assets” are not just buzz words; they are a realization that without the proper use of their human resources, then even the best strategy will fail.

Talented people are hard to find. What do we do when we need hundreds of them? Fortunately, globalization and the age of Internet have provided an answer: distributed teams and multi-site collaborations." 

What is a multi-site collaboration?

Multisite collaboration vs distributed team

To avoid confusion, just a few words about the terminology I will use from here on: 

• Multi-site collaboration: several teams, located in different geographical regions, working together on a project. The main characteristic is the asymmetric access to information. It is much easier for a team member to build a relationship with a colleague sitting next to him/her than to connect with someone remote. Due to our tendency to favor social comfort, team members will favor local relationships at the expense of distributed relationships, thus local tribes appear. This setup is characterized by a high communication bandwidth locally and a low communication bandwidth between sites.

• Distributed team (think of open source model): team members are distributed across the Internet. Access to information is symmetric, thus people will tend to build their social networks online. The tribes will form based on common interests and less based on proximity (because there is no such proximity).

The topic presented here is multi-site and not distributed teams (as per definition above). 

• Lead site - the site that initiates the project or where the project manager resides. 

• Associate site - a site that was invited to assist in the development of the project.

1. A buyer-seller relationship

Probably the most important conclusion we can draw by looking at the diagrams is that, even if the project happens under the umbrella of a single company, it still resembles very much to a buyer-seller relationship. And this is good news, as we have a model on how to approach it - the Procurement Knowledge Area from our beloved PMBOK. Thus, we already know that we need to perform several steps and end up with a contract between the sites. How should the contract look like? It depends on the scope of the collaboration but, somehow, it should be aligned along the lines of Fixed Price, Cost-Reimbursable or Time and Material. It can follow the Agile guidelines or more traditional ones. 

This leads to at least three main corollaries: 

• The lead site is the client for the associate - thus the associate should treat the lead site with a client-oriented mindset. Key words are "being of service" and "delivering value".

• The relationship should be a little bit more formalized than in a collocated setup.

• The associate should manage itself  (and have a good project manager on site) and that there should be a project manager on the buyer (lead) side as the main point of contact for the seller (the associate). 

I believe that the conclusions above are independent of the methodology employed or the scope of the collaboration. The exact details of the process should be clarified in the contract.

Project managers on both sides - buyer / seller relationship

2. The associate (seller) should take full responsibility for the collaboration 

LS - lead site, AS - associate site; the rest are various stakeholders

While one side should take full responsibility for the collaboration, I believe that the seller (the associate) should step in and guide the buyer (the lead) on how to deploy a successful process. Here is why:

• If there isn't a very strong motivation on the seller side to collaborate, the project is doomed to fail. The seller should have a very strong incentive to develop further, secure a constant stream of work for its people as well as a constant revenue flow. I believe it is healthy for the seller to aim at getting a bigger piece of the pie.

• The lead outsources part of its work because it doesn't have the resources to do it. By having the associate provide the full service to the lead, the lead offloads itself further while it shortens the communication chain, thus reducing the associated communication risks: misunderstandings, delays, things left out.

3. There are specific risks associated with multi-site collaborations

Let's look at the setup again:

The model

As said before, there are two main characteristics of the setup above:

• Asymmetric access to information due to the huge difference in communication bandwidth between the local and the remote, which leads to local "tribes". As a side note, I believe that it is healthy to acknowledge the existence of such tribes and celebrate their existence within the main project. This can be done by simple means, like customised T-Shirts with the geographical location imprinted next to the project name or cultural newsletters.

• The lead site has much more knowledge about the project then the associates.

These spawn several risks, some of them highlighted below:

Risks

• Unrealistic expectations from all sides:
• Top management - "collaboration should work"; this is especially true if the organization is new to such collaborations and does not have a uniform PM and risk methodology.
• Lead site - "we will not be challenged"
• Associate site - "we are welcomed with open arms and our ideas will be embraced from day one".

• Challenge to existing hierarchies and the associated resistance:
• For the lead site, the new guy on the block (the associate) expects to be part of the decision making process.
• For the associate, people that were once regarded as authorities in their field will now be subjected to test and will have to prove once again their value to the organization. Some of them will not be able to adapt as their position is challenged.

• The associate being out of the circle of trust:
• It is normal that there already exists an established decision making process in the lead site. It is not obvious why it should change, thus the associate needs to prove its value in order to get the necessary trust to be part of it. 

• Misunderstandings due to remote communication and language barrier. Assumptions

• The things "we don't know we don't know":
• I particularly like this one. These are the things that are so obvious for one site that it forgets to mention them to the other, like technical shortcuts, changes in technology or changes in the plans that were not propagated - the tacit knowledge in the project.  Because of these, the associate should never rely on the lead site to tell them when something happens. I believe that the associate should be on a constant lookout for changes and have a very proactive process to identify what they don't know they don't know. The excuse "I have not been told" is not acceptable.

4. To mitigate the risks, we need specific profiles as key players

In order to mitigate the risks above, I believe that the persons that take key roles in collaborations should have several personality traits that should not be treated easily:

• Modesty: 
• To listen to the other side and be willing to admit that he/she may be wrong or not have all the information.

• Outgoing: 
• "Everyone communicates, few connect" - J. Maxwell
• Because of the short time spans that teams spend together, key players should be skilled into quickly building relationships. There's no time to lose and there are so many things to find out.

• Questioning skills:
• As mentioned before, key players need to dig out the information themselves and not rely on what they are told. They need to be able to uncover project scope, identify stakeholders or find risks quickly and effectively. They need to be very good active listeners.

• Assertiveness:
• Sometimes things get out of hand and, at that moment, key players need to show self confidence and control the conflict. They need to be able to stand by their positions. 

In addition, they should not be afraid of putting things on paper because, in the absence of a healthy base of tacit knowledge and personal relations on which to rely on, security should be given by process:

Relying on process in the absence of another solid base

5. Successful collaborations need support from top management

Because collaborations are never easy, top management should be on the side of the collaboration:

• Time and money and the assignment of additional roles (like the collaboration manager) invested with enough authority to challenge the PM on collaboration topics.

Collaboration manager acting like a coach and supervising the collaboration

• If multisite collaboration is a strategic direction and not a one time initiative, there should be collaboration KPIs in place which, I dare to say, should not only sit side by side with the rest of the project KPIs but, in terms of priority, score even higher. The PMs should have strong incentives to make the collaboration work. These collaboration KPIs should be followed throughout the duration of the project and archived. No surprises at the end and no post-factum blame if the project is not successful. 

Project report which also includes follow-up on collaboration KPIs

• Clear escalation path which supports communication to the other side first, favoring problem resolution not complains.

Escalation path: talk first to the other side

6. Some tools (hacks) can help a long way

• Linked-in & sharing of professional CVs early in the collaboration: 
• It is one thing to be challenged by John Doe whom you don't know anything about and a totally other thing to know that your peer has 10 years of relevant experience. 
• Link to CV can be added to email signature or to internal messenger status to be easily accessible. 

• Video conference:
• Not much to say - it is one thing to discuss face to face and look into the other person's eyes and smile, and a totally different thing the cold, impersonal email communication. 

• Clear collaboration charter - the contract between sites:
• Not to underestimate! In a collaboration things need to be agreed upon and then put on paper. 

• OPPM report: a great tool!
• Not only that it is clear and easily readable (after all it is only one page), but it should also include regular follow-up on the collaboration KPIs, like the satisfaction of the other side.

• Recognize group identity
• Groups (local tribes) exists and it is in the power of the project manager to position them in the context of the project, thus leveraging their potential. 

• Recognition of the collaboration overhead
• The carrot.

Instead of the final conclusion:

I believe that collaboration comes natural to us, we just need to be open to it. We've managed to work together since ancestral times, thus ensuring the survival of our species. We should be able to adapt this innate ability of ours to the modern times, as long as we embrace it as an opportunity.

To collaborate is natural to our species

(Thank you Andrii Shafetov and Google for the artwork).

Agile Planning

Getting more agile:

In a word, agile methodologies are about acknowledging at the most inner level that change happens: http://agilemanifesto.org/ and http://www.AgileManifesto.org/principles.html

Agile methodologies still need planning. After all, I doubt that many commercial software projects are started without at least a partial visibility on the budget and the scope involved. They need a vision, a goal to reach for and the steps to get there in order to convince.

These methodologies welcome and favor change and their practitioners are not afraid to modify plans if needed. The tendency is to keep things simple and manageable, keep the team happy and focused for undetermined periods of time and minimize risk on quality through constant releases. Stakeholders are informed about what happens in the project by directly experiencing the results, rather than getting through tons of reports. Yet still reports and accompanying documentation may be needed for proper understanding, but the focus is on the product.

In a sense, the planning methodology described in a previous post has agile traits. Early planning is kept to a minimum, refinement is achieved throughout the course of the project, flexibility in terms of vision and features exist. It's just that we need to go beyond that and add new elements to get where we want: high quality within budget and a happy, proud team.

Improving processes and optimizing workspace:

First of all, let's start by ripping off the authoritative aura of the traditional manager, making him part of the team and adding him a new role: that of the facilitator. His/her goal when acting in this role is to find creative ways to improve team performance by removing obstacles and clearing the path ahead. Let's quote from the agile manifesto:

"At regular intervals, the team reflects on how 

to become more effective, then tunes and adjusts 

its behaviour accordingly"

Then, let's add some means to find out what the blockers are: the best I could find (yes, it was not my idea;) ) is to have a daily 10-15 minutes meeting to find out what the current problems are and have people discover if the problem is local to them or more common. The purpose of this meeting is to create an urgencies agenda for the day:

• Action plan for the manager
• Find out who has encountered the problem before, if any, and gather some quick suggestions
• Schedule more detailed meetings with people that manifest interest in the problem, after this meeting completes
• Celebrate success when the project advances
• Update the plan - where we are, where we are going

Software development and management are continuous, iterative processes of self improvement. While the goal for the agenda is noble and visibly useful (and fun), the actual meeting may not succeed from the first. It is important to keep the goals in mind, have patience and iterate. At first, it may become boring or too long but, as experience grows, it should get more and more successful and to the point. Just like anything else, the process is under continuous scrutiny by the team and suggestions for improvement should be made and always taken into consideration.

A second meeting should be considered; a longer meeting this time, one hour for instance, scheduled once a week or two, to discuss how we can improve and streamline our activity on a more macro level. While the daily meeting usually touches hot subjects, blockers that have just appeared, the longer meeting should take the form of a coaching or a brainstorming session, where more subtle issues can be discovered and action plans are laid to overcome them. Ideally, this meeting should be lead by a more experienced person or set up at first under less stressful periods so the people will be more eager to iterate.

Quality enforcement:

The second level of transition from the normal waterfall method to agile should be the quality enforcement. We need this because, in order to gain approval, we need success stories fast. We need a build that gets visibly better. People should feel first hand that something has changed such that, instead of focusing on putting features in as fast as possible, we now shift our attention to details, quality and, thus, self-esteem:

• Bugs have a higher priority than features.
• Quality is enforced early through smoke testing (daily builds) and code review. Additionally, the dev tester should be called in to verify the feature before check-in as, if the daily build fails, this is a dramatic event - part of the team may not work!

To have this, we need two prerequisites:
• A working pipeline and a daily build process that is checked continuously.
• Visibility, like play the version once a week, an hour, in an organized manner, with an emphasis on new developments.

The most important aspect of development is to keep the version clean and working smooth. This has higher priority than anything else and all the team should focus on this and find ways to improve and secure the daily build.

Planning in a more agile way:

Planning is a little bit more tricky because it has to deal with uncertainty. I think it should have three levels:

1. Macro level should contain top level components, with allocated times and budgets. Unlike imperative planning, where tasks are assigned and fixed, this level is maintained as a general baseline, a guideline for communication and for risk estimation.

2. Second level is created by adding user stories. User stories are the requirements. Their scope ranges from "the game should have a crew management system with an interface" (along with a rough estimation) to "when the player clicks on the crew icon, it should change colors". These user stories should have a time estimate (given by team) and value (given by the requirement owner) and they become more and more detailed over time, as implementation moves forward. They can be changed or deleted easily.

3. Refinement is done by the team, in a planning meeting, before the iteration begins. The team chooses what to do in the iteration based on the value and the dependencies of each user story. Then, each story is split into tasks.

Agile planning should be an on-going, forward looking process. User stories should be detailed ahead of the iteration so that, when iteration begins, the team knows exactly what they can commit to. Important: 1st step to develop a team: make everyone stick to their commitments fully, no matter how small they are. This increases self-awareness and self-pride.

Planning

Compromise sticks and spreads

Nobody wants to write poor code or dig through it, yet, somehow, it happens. It all begins with a requirement or a prototype that needs to be developed fast in order to obtain a validation. Management and designers like it, it hits the deadline. You are congratulated for your success.  Up until now, everything is as it should be. This is how prototypes should be developed.

Then a new requirement comes. "Wait! I've only created a quick hack!" But the prototype works and you've already been congratulated and the second deadline is coming fast. You promise yourself that you are going to fix it as soon as possible, but the very day that you check-in, you and other people start adding layers after layers over it and change never happens. It could be that the feature is perfectly engineered and polished at first but, as new code is added on top of it, the original is never truly reworked, so it slowly starts to rot.

The project becomes more and more difficult to maintain and grow. Morale gets down, quality gets down, and productivity gets down, self esteem gets down, will for self improvement gets down. Some people even leave their jobs. Even if some teams actually start by cleaning up their previous mess and bring again the code to a better state, it is a onetime process, that happens only once in a few months or years. Being a one time, massive scale endeavor, the result has high chances to only end up as a different mess.

When one makes a compromise, it sticks. And then, another compromise is needed to cover the previous one. Debts start to gather in and, in the end; the debt is so high that one realizes that he/she will never ever cover it. And the process keeps on going and accumulates more and more debts, until everything becomes so expensive in terms of money and people that we need to throw everything away and start again. 

Why?

I think it all has some simple root causes:

• People develop in isolation. They don't talk so they don't have the chance to unite for quality.
• No code reviews.
• No frequent informal verbal exchanges.
• Rigid planning, commitments to feature lists instead of quality.
• Bugs are not fixed immediately as they appear and, instead, are postponed to "debug periods", and often scheduled only at the end of the project.
• Interruptions of any kind.

Lack of communication and rigid planning make prototyping lose its core purpose, as it is perceived as feature complete when it is merely a quick proof of concept. Developing in isolation makes it difficult for people to say "STOP, we need to change this" and management never truly gets to the bottom of problems to fix them.

Do we really need to start from scratch?

A very good friend said to me yesterday that, in nature, something has to die in order for a species to evolve. But how does this translate to software development? Does this mean that we need to start from scratch in order to evolve? Always?

I don't think so or, at least, it should not happen unless a major technological breakthrough occurs that renders everything else obsolete. I believe that software needs only to be released in order to evolve. It needs clean, frequent releases and then it needs mutations. We, programmers, call them "refactorings". I will stress this again: in order to evolve, software needs to be cleaned up before the release - no debts to the next iteration. And we need a culture that embraces change and mutations. 

Beside internal clean-up, these releases should also reach their customers (editorial teams, designers, beta testers) in order to get their feedback and adjust the feature list for the next iteration. A release without customers is tough to justify (close to pointless) and it's a pity to put in so much effort and not take the opportunity to do some user testing. After all, evolution needs feedback in order not to generate monstrosities. 

To sum up, a healthy development process should accommodate short term iterations consisting of:

• Detailed planning based on a roughly detailed feature list
• Actual implementation; communication among developers, peer reviews
• Debugging and stabilization - no debts for the future, all bugs are fixed
• Sign-off by QA
• Release to customers for feedback
• Communicate status, negotiate features and deadlines, incorporate feedback, and discuss how we can improve the process so that the next iteration gets better.

Managers don't manage people

Another thing I realized, no matter how shocking it sounds, is that managers don't manage people. They manage processes. People buy in and start adding value or they don't. You can assign tasks but you can't really force anyone to complete them. Therefore, the notion of "motivating an employee" makes no sense, really.  He/she is either motivated or not. What you can do, however, is create an environment that appeals to the employees, so they get excited about their job and become productive. And this is the really tricky part. 

Quality from the user's perspective

Indeed, the only thing that matters to sales is how the product is perceived by its customer. Nothing else. Code doesn't matter, as it is invisible. Code only matters to the production people. If it is crappy, it ruins the life of the men and women involved in its production. It turns them away from the product, productivity drops, conflict sets in, and motivation goes away. Yet this does not impact sales directly; it impacts everything else. 

Getting back to process - Planning

I'll make a small detour from the quality issues to examine planning, as the core activity that drives project to completion. In the following paragraphs, I will present the normal planning method with its advantages and disadvantages and how it can be applied. After understanding planning, I will get back and show how to transition to methods that are more appropriate to ensuring quality in software.

Everything in a project revolves around plans and planning. Planning is a continuous process, plans change as requirements change, conditions change and understanding grows. Visibility and vision is based on plans. Communication with stakeholders is based on the same plans; resources are requested just the same. Commitments are based on plans. Monitoring and controlling is based on plans. Strategies are based on plans. Planning and plans - everywhere. Yet some managers either don't take planning seriously or they don't iterate on already made plans to adjust them. Why? 

The answer is quite simple and straight forward (order of bullets is irrelevant):

• In the early stages of the project making informed plans is really hard and it seems that we can do better off without them. After all, it is easy to get people to do something tangible now.
• Some engineers and designers are reluctant to planning as well (especially if they are not used with the process) and managers don't want to deal with this kind of issues up front.
• In the late stages of the project we are so busy putting up fires, escalating issues, requesting resources, fixing and dispatching bugs that we can't stop to plan. 
• Superficial planning is hard to spot therefore allow your plans to be challenged by the stakeholders and the team.
• Planning requires going back to the same document, ripping it off and doing it again many times. It's difficult to change everything when you worked so hard on it. Over and over again.
• Some feel that planning is a waste of time: things seem to work without plans at first.
• Some managers (former star employees) are so used to actively solve issues that have      visible impact on the project that, when they are required to stop and think about the future, they feel it is useless. Why? Because to them plans seem to be only coloured excel sheets, without a tangible impact on the outcome of their project.
• Planning is a costly activity and some organizations or teams may naively try to eliminate it as waste. Planning is costly because it involves not only the manager, but the whole team or, at least, the most senior part of the team.
• If not properly communicated, a plan means a commitment which seems hard to make and changed later.

How to plan? 

Here it is: http://www.projectsmart.co.uk/project-planning-step-by-step.html. Easy, isn't it? :)

For starters, I will assume that we already have some visibility on the sales volume, on the budget and on the release date. Let's assume the mandate sounds something like: "We need a project that will generate roughly X units sold and that will be released around the Y date. It should cost somewhere around Z monetary units." I will assume that there is historical information in the company about this kind of project and that the constraints are reasonable. Also, probably most important of all, we have some good visibility on the project deliverables and core features - that means that we are well advanced through Step 1 (Project Goals) and Step 2 (Project Deliverables) described in the link above.

Top-down approach - project schedule:

1) We know the release date and the budget, therefore we can establish quite easily the major milestones and the resource ramp-up (based on historical information, common sense and available technology).

2) Start drilling down and get a list of raw features and core activities for each milestone. 

For preproduction (research phase) we allow room for exploration, namely we select few core features (technical and design breakthroughs) that we are going to develop further.

For production, based on the already made list of features and the vision that we have at this point, we create a macro Gantt chart that displays all the major activities, with resources assigned and time frame. This estimation takes into consideration the following: rough duration, rough vision and feature value in the overall economy of the project.

Then, when the actual implementation is soon to be started, PM, design and engineers start refining the implementation so that it fits the allocated budget.

In order to ensure quality, buffers are embedded either inside the activities or/and special periods are allocated during the entire process for stabilization and debugging.

Ideally, the plan should fit on a single computer screen or whiteboard, so that the PM and all team members have clear visibility on where they are and what comes next, by a single look. Also, this coarse granularity allows flexibility for later issues. And let's don't forget that, after a certain level of detail, the amount or work required to reschedule and re-plan can be quite a challenge. 

Advantages of the method:

• Visibility - great communication tool. Very easy to understand even by an outsider.
• Not very hard to develop (it is all based on honest estimates, seen from the top) - yes,      the planning itself should be seen as a separate project conducted by the project manager and have all the team and stakeholders involved. Again, keep it simple.
• Accurate in terms of feature relevance - more important features are given more time      and more resources in the total economy of the project.
• The plan is small and easy to track and change.
• Mitigates some of the pitfalls of the pure waterfall method, as it allows room for changes down the stream - features are not detailed until close to their implementation.
• More important features are put in first.
• Dependencies are easy to spot and taken into consideration.
• Resources are easily leveled and their need understood.

Possible pitfalls:

• Distribution of effort in front of the deadlines (tendency):

Rough distribution of effort over time

(Effort increases substantially as the deadline approaches) 

• The plan is long term. Even if at one point the team commits honestly to respect the schedule, this commitment erodes in time, especially after problems arise. If the process for re-planning does not involve the team again, some people will feel the plan was sloppy from the first place, some will remain committed to the previous iteration while others will feel that the project is not firmly lead - after all, new requirements are added or tasks are exceeding their allocated time. Even if everything works fine, still the commitment erodes and some will try to break the boundaries. Commitment needs to be reaffirmed from time to time.
• People may feel that there is time. Initially the requirements are fuzzy and the tendency is to underestimate them.
• People may feel that there is room for sloppiness because of the buffers (especially if      the plan is not that detailed). Project is long, we have all the time in the world, and we can afford to be less disciplined. Milestones may be treated with discontent and some may even feel that they are added there only because it's good to have milestones. Again, because of the long time, people feel that there is no real pressure in the beginning. As initial task allocations are exceeded, a sense of poor quality spreads (broken windows).
• If iterations are added to plan, because we know how many iterations will be, the first ones may be treated superficially. 
• Some creative people will invoke the time allocated for tuning and debug at the end to over saturate the project with features. They will always claim there is time for debug, to favour putting features in - (http://blog.alexandrugris.ro/2010/08/software-quality-1.html). Beside the risk at which the project is exposed, this also creates tension in the team.
• It is harder to enforce quality bars. Outside debugging periods, bugs tend to creep in (after all, why are the debug periods scheduled unless to fix bugs?!) and, because it is hard to break the time commitments advertised to all stakeholders, project management may feel that the quality is good enough for the time being and that it can be fixed later. Just the same, it is hard to drop features if they were initially incorporated into the plan and some people grew attachment to them.
• Even though we try to retrofit the design and implementation on the initial estimate, many times it shows that the original estimate it just too short to be useful.
• Feature value changes during development. 
• Historical records show that, initially, most plans have much more features scheduled      then available in the release version. As project matures naturally, the number of features decreases dramatically and focus shifts to bringing core elements to perfection. Rigid plans are an obstacle in front of this natural selection process.
• New requirements will appear and we need to plan for them, even if they are uncertain in the beginning.

Some hints to apply (which worked for me):

• Clearly state that the plan is “tentative” and that it is subject to modifications.
• Allow room for iterations
• Commit only to what you know you can respect
• Estimate risks on each element
• Use it to derive a cut list when delays occur and estimate impact of delays
• Detail as you advance through the plan
• Release often to customers. Plan for intermediate releases to be used as benchmarks against the plan.

Quote - Bugs And The Agile Way

"1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream."

Full article:

http://agilesoftwaredevelopment.com/blog/jackmilunsky/accounting-bugs-agile-way-2

Being Agile

Being agile means focusing on features and the product as a whole. Being agile means to iterate and, after each iteration, have a working version of the product. Being agile means to deliver predictable value on the short term and act with the client's priorities in mind all the time.

When presenting Agile (Scrum) to programmers one of their main concerns that rise up is that their code will become spaghetti in no-time and that too much time will be used for changing what has been done. The general perception is that they need do hacks now to deliver an increment and then clean up the to deliver the next increment which means loosing a lot of precious effort. It seems so at first, but what is wrong with re-factoring? Yes, hacking is bad but hacking something quickly as proof-of-concept and have the designers test it quickly can eliminate a lot extra work needed to polish something that may be thrown away. And yes, once the proof-of-concept is validated, management expects the programmers to ask for time to clean up their prototypes and turn them into fully working, state-of-the art pieces of engineering that is then merged with the main development branch.

a) Agile starts from the premises that specs change over time and that the client is free to change his mind anytime after an iteration. This means that is very likely that the feature we try so hard to make room for will not be implemented after all, and that it's very likely that another feature will be requested that breaks the initial architecture. This also means that you need to make your code modular and flexible and be ready for constant refactoring. Good specifications means good enough to start working with and good architecture means something very simple that allows you to build modular code. And then clean it up!

b) Preserving the teams constant over time ensures that that the product is known and understood by everyone. The team takes full ownership of their code, cherishes it and keeps it tidy because, after all, they are the ones who suffer first if it becomes unmaintainable (then comes the whole product as it cannot be delivered on time, then come the customers that may receive poor quality as the result). Since the code ownership is shared across a small team, peer-reviews are constant and, if a culture of constant refactoring is in place, the code actually becomes better and better as new features are added - instead of constantly decaying.

c) Scrum is a tool that allows programmers to keep their code tidy and clean. It guarantees that during the sprint no one will interfere and that they are free to do their job as they see fit. Traditional models allow leads to randomly assign tasks, change specs all the time, in a word create chaos which is the prerequisite of hacks and unmaintainability.

d) Working in small teams leads to better understanding of the source code and knowledge sharing. Code becomes more uniform and has increased quality because more people work on the same areas, share ideas and help each other. Teamwork also minimizes the danger of having some programmers that are the only experts in some areas of code, just because they were the only ones assigned to those areas ever.

e) Traditional models have the risk of loosing track of what the project is all about and get lost in technical details. It is easy to loose a great amount of time developing some sort of cool technology that everyone is very proud of that, from the client's perspective, has very little or no value at all. Especially during the "technology development" phases clients, become very nervous and anxious because they have little visibility of what happens and they see no apparent progress. Therefore boxing technological changes in fixed term sprints increases client's confidence because he/she has at least some sort of deadline visibility and the illusion that that black hole that eats his/her money will, eventually, end soon.

More on this some other time :)

Debate Invitation: Design Documents Versus Mock-Ups*

I'd like to argue that user interface mock-ups, fake screen-shots plus annotations and verbal stories are, most of the time, a better design tool than spreadsheets, word documents or functional diagrams. While there are other valid arguments for / against them, I find the following rather strong and applicable to a wide range of possible scenarios:

• One of the main requirements of any software package is usability. The interface should be simple to use and intuitive and therefore, after a mental movie and a mental proof of concept are created and some ideas scratched down, developers should proceed with it right from the start. If the concept cannot be easily fit in a fake screen shot, then there might be something wrong with it. If the mock-up is not explicit enough by itself (and some side, contextual, annotations) then it might be too complex (and difficult to understand and use) and should be rethought.
• A UI mock-up provides an early feedback on whether the design is consistent. In the process of making the mock-up, one usually reviews its whole mental movie and his/her design notes and tries to blend them together in an accessible format. This way, elements that don't fit very well or don't provide enough value are discovered sooner.
• A mock-up is by far a cheaper validation tool than a full implementation, allowing you to spot a lot of the possible issues, very early in the process.
  
• A mock-up can be a great starting point for a debate or a brainstorming session.
  
• Unlike functional diagrams, mock-ups usually do not contain implementation hints. The construct is based only on what the user / player sees and, therefore, allows the programmer to choose the best architecture possible without any algorithmic suggestion. What I've seen is that programmers tend to take design specifications as architecture specifications, blocking opportunities for extensibility, clean code, better algorithms - UI Mock-ups are a step away from this danger.
• Mock-ups are simpler to grasp and provide better visibility to the design intentions.
• Product validation is easier to do when testing against a pre-made mock-up. It's there or it's not there - more difficult to forget features.
  
• Nobody likes to read lists or long documents. If ever read, long docs are read superficially and, again, some details can be lost and never get implemented. Such a missing feature is hard to discover during validation.
  
• Most of the time, lists and other types of documents have to the reader a different meaning than that intended by the designer (nobody understands exactly the same thing and everybody ends up with another mental image of what's required). If mock-ups are not on the paper, they are constructed differently in everyone's heads, leading later to arguments, difficult and costly implementation changes and frustration.
• The process of verbally explaining mock-ups triggers ad-hoc brainstorming sessions and clarifications. Communication and knowledge transfer is fostered as is friendship among team members.
  

What do you think?
------
Note:
* by UI - mock-up I mean a user interface design suggestion or a fake screen-shot of some relevant in-game (in-application) element or moment, polished to some degree

Blog To Follow On Agile Methodologies

Here is a blog to follow: http://agilesoftwaredevelopment.com/

Some highlights:

10 Principles of Agile Project Time Management:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/10-principles-agile-project-ti

The 12 Best Questions for Team Members:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/12-best-questions-team-members

Professionalism = Knowledge First, Experience Last:
http://agilesoftwaredevelopment.com/blog/jurgenappelo/professionalism-knowledge-first

Kano Customer Satisfaction Model:
http://www.12manage.com/methods_kano_customer_satisfaction_model.html

SCRUM:

http://agilesoftwaredevelopment.com/scrum/simple-product-backlog

http://agilesoftwaredevelopment.com/scrum/simple-sprint-backlog