I heard Scott Ambler talking about the "Generalizing Specialist" on DNR 460.  He was stressing that this is the best type of person to have on your project team as they are more effective in practice, and I agree with him.

So what is a GS?  It is a person that is deep in one or more specialties (such as programming skills, DB skills, management skills, ...), but also has knowledge of other specialties, and is willing to learn more about the areas of which they are not specialists.

The challenges with specialists are several fold:

1. Do their jobs no matter what needs to be done.  For example a data modeler may just do data modeling, even if you don't need it.
2. They have problems interacting with other specialists.
3. Specialists hand off work to other specialists when they are done their work, leading to critical path and sequential project tasks (instead of in parallel)
4. The project is only as good as the weakest point in the chain of experts
   
5. A lot of extra work gets done all of which may not be needed

On the flip side of this is the generalist.  In this case, no one has the skills to get anything done.

The gist of this is that you want to:

1. Provide your expertise where needed
2. Learn where not a specialist in case you are needed at a later time
3. Provide different perspectives to other specialists to open their thought process
4. Be able to communicate so as to be able to complete work in parallel, and with higher quality.
   

.NET Rocks episode 460 had Scott Ambler talking about his APMM.  Here's the link to his blog entry on APMM, and I also repost some of that content here.

The Agile Process Maturity Model (APMM)

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today. The APMM defines three levels, each of which build upon each other, for agile processes and practices. At IBM we’ve found that many customers find the agile message confusing, in part because of the multitude of voices within the agile community but moreso because the agile rhetoric often seems to ignore or gloss over many important issues which our customers face on a daily basis. Hence the need for something like APMM to provide badly needed context for agile methods and practices


APMM Level 1: Core Agile Development
Level 1 agile processes address a portion of the system life cycle (SDLC). Examples of Level 1 agile processes include:

• Scrum. The focus of Scrum is project leadership and requirements management. Scrum proponents claim that it is a process framework, but if so then it is a sparse and incomplete one at best and very clearly every other process in existence could also make this marketing claim. A more accurate description is that it is a high-level lifecycle for construction iterations (what Scrum calls “sprints”) and several practices such as daily stand-up “Scrum” meeting, product owner, product backlog, iteration/sprint planning, and potentially shippable software.
  
• Extreme Programming (XP). XP is a collection of practices for software construction, include refactoring, test-first design, pair programming, on-site-customer, continuous integration, whole team, and collective ownership. XP is very close to being a APMM Level 2 process but it is unfortunately missing (currently at least) explicit practices for project initiation and release the system into production.
  
• Agile Modeling (AM). AM is a collection of practices for light-weight modeling and documentation, including requirements envisioning, executable specifications, active stakeholder participation, prioritized requirements, and prove it with code.
  
• Agile Data (AD). AD is a collection of practices for database development, including agile data modeling, database testing, database refactoring, and continuous database integration.
  

APMM Level 2: Disciplined Agile Delivery
Level 2 agile processes extend Level 1 to address the full system delivery life cycle (SDLC). As the
criteria for disciplined agile development suggests they also tend to “dial up” certain aspects of agile development, such as testing, measurement, and process improvement. Furthermore, they include explicit mechanisms to support effective (ideally lean) governance. Examples of Level 2 agile processes include:

• Hybrid Processes. A common strategy is for organizations to cobble together a Level 2 process on their own, often around the Scrum "process framework" and XP with ideas either brought in or reinvented from AM and sometimes AD. This strategy is perfectly fine in theory, although in practice a lot of project teams seem to spend a lot of time in trial-and-error experimentation to figure it out for themselves. They invariably have some "learning experiences" which could have been avoided if they'd only started with a Level 2 process to begin with.
  
• Rational Unified Process (RUP). RUP is a comprehensive process framework for iterative software delivery which can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants. RUP practices include risk-value lifecycle, whole team, test-driven development (TDD), business process sketching, and continuous integration.
  
• Open Unified Process (OpenUP).
  OpenUP, the definition of which is available via open source, which combines and extends practices from Scrum, XP, AM and RUP for co-located agile teams which are building business applications. OpenUP practices include whole team, daily standup meeting, prioritized work items, risk-driven lifecycle, TDD, active stakeholder participation, and continuous integration.
  
• Harmony ESW. Harmony ESW is an agile software process for embedded software (ESW) systems.
  
• Dynamic System Development Method (DSDM). DSDM is an agile delivery process originally based on Rapid Application Development (RAD) which is often used to developer user interface intensive application. DSDM practices include prototyping, test throughout the lifecycle, reversible changes, and feasibility study.
  

APMM Level 3: Agility at Scale
In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities today’s software development organizations are facing. This is what Level 3 of the APMM is all about – explicitly addressing the complexities which disciplined agile delivery teams face in the real world.

The scaling factors which an agile team may face to a lesser or greater extent includes team size, physical distribution, organizational distribution, regulatory compliance, cultural or organizational entrenchment, system complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management). Each factor has a range of complexities, and each team will have a different combination and therefore will need a process, team structure, and tooling environment tailored to meet their unique situation.

Unfortunately, the term “maturity” is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integrated (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another, and in future blog postings I’ll discuss how CMMI and APMM fit together.

I was (am) listening to the Alt.Net podcasts today.  I just came across this podcast series last night.  I don't know why I didn't hear of this before, but perhaps it's because it's relatively new as it's only been publishing for a few months and is up to 8 episodes.

At the same time, I'm on a three hour train ride from Baltimore up to Connecticut to talk to a potential new client (to be specific, an interview).  The combination of brushing up on some things I don't do on a daily basis in case I'm asked about them, as well as some concepts discussed in this broadcast has brought me around to something that's on my mind relatively often but that I've never written down...

What are the key concepts in software engineering, as of today, in July 2008?  This is not meant to be an complete list, or that the items exhibit complete separation of concerns relative to each other.

Here my initial stab at what I think are the things you must exhibit to be an exceptional architect at this time:

• Domain Driven Design (DDD)
• Test Driven Design (TDD)
  
• Software Evolution / Continuous Improvement
• Patterns, Patterns, Patterns
• Dependency Injection and Inversion of Control
• Policy based programming
• Aspect Oriented Programming
  
• Doing things as much in a declarative nature as possible
  
• Domain Specific Languages
  
• Separation of concerns
• Design by contract / Interfaces
• Service Orientation
  
• Transparent translation of domain to persistent store
• Mocking
• Parallelism
• Caching
• Factories
• POCO 
• Event Driven Design
• Orchestration
• Rules
• Logging / Instrumentation
• RDBMS design
  
• Keep it simple stupid
  

I'm going to come back and expand this list as well as elaborate on each.

I found this "book" yesterday after Scott Hansleman twittered about it.  I just started reading it and just a few pages in I already felt inspired to start discussing it.  This is purely based upon some initial statements made about YAGNI (You Aren't Going to Need It) and being in the ALT.NET frame of mind instead of the MSDN frame of mind.

I really enjoyed the initial statements on MSDN versus ALT.NET.  I really do feel that there is a big difference between these ways of doing things.  In the book, Karl quotes Jeremy Miller (who I used to work with) as stating "that the MSDN way is a practice of having too much focus on learning the API and framework details and not enough emphasis on design and coding fundamentals."

I absolutely concur 1000% with this statement.  I used to think this way, because that was, for many years, what I was told was the way to think.  There used to be a days when I used to know the entire Win32 API, and I was really proud of it.

Then one day I realized that this wasn't doing me very much good; it wasn't necessarily doing me much harm, but it was limiting me in that through the process of this type of learning I was unknowingly preventing myself from really seeing how to solve real issues in software that were important.

I don't know where or when it happened (but I'll guess is was about 10 years ago if not 5 or so years before that), I started to think in larger abstractions about the problems I was dealing with.  I started to think that, well, in my adventures in enterprise software development, that:

1. I wasn't really solving any new problems
2. All of this detailed knowledge wasn't helping me solve those problems any better every time I had to do it again
3. That there must be better ways of doing this

I don't know, perhaps you might say that was when the lightbulb turned on and I started to thing like an architect instead of a programmer.  That may be it, but I think its too simple of a statement.  And I'm not sure what I think about the moniker "architect" either, as I think today it presupposes things, both good and bad, that may not really be important either.

I guess what I'm saying is that after years of trying to solve how to do things better, it feels that it is to me exactly what Karl states about the philosophy of ALT.NET, which is to focus on alternate solutions and approaches to the MSDN way of thinking, and I'll add specifically that this is a way of using best practices learned through experience of the community to solve problems through knowing the patterns of how to solve the problems, and then worrying about the details of solving the problem only if there isn't a solution already available.

To me this is a very fundamentally different way of thinking about going about the things that I do.  I often get asked many times what are the specific method or so and so class in interviews, and I'm often like, "I don't know off my head, but give me a second with Google, or better yet, why know them when I can solve the problem with a better tool providing a solution to the overall problem."

See, I think this kind of stuff is just cognitive overhead, knowing all these details.  Over the years, instead of knowing all the details in memory, I've built ways of knowing how to look up the details at a moments notice.  And by defering to other tools (like Google, or open source projects, or patterns and practices) for storage of the details, I really feel like I have allowed myself to become more creative and at the same time more productive.  I've effectively become more atune to being able to solve the problem effectively, instead of just focusing on mastering the tools.

The thing that I wonder is if this type of reasoning can be taught from inception instead of having to learn through street smarts over many years.  I think that sometimes this can be, but at other times I think we're just so entrenched in software with mastering tools instead of mastering solutions using the tools.

I mean it still amazes me that in many places that I consult, or with people that I talk with in my field, that they just stick with this means of doing things the way it always has been done.  Its really an anti-pattern, and it's a difficult one for many to break.

For example, I once told another developer on a project that I was consulting for, in front of his boss, that when he was done with some code he was writing to integrate data between several systems, that I would like to write a unit test for this code.  This would be something that would be mission critical, and run every day, and I wanted to make sure that if we had problems with it that I could be able to prove the failure using the test so as to fix it and make sure we don't have that problem again.

Well, I was aghast by the reponse I got, almost before I even got the entire sentence out.  Testing wasn't important, and that I need not (and I mean that I am flat out not to) build that test, as there were more important things for me to focus on.

Well, the really amazing thing about this was that this piece of mission criticality was just run for the first time, with some dummy data, and that was apparently good enough to push it into production the next week without any additional testing or plans on how to handle it if it failed.

Guess what?  It failed.  And it failed hard the next week.  And the users were pissed.  And I got to write that test then.  And it was another 8 weeks until the users allowed us to try this again, delaying us several months when I could have put together preventative measures in a few hours of work.

So, where am I going with this?  Perhaps nowhere really, but it's stuff kicked into my mind in the first few pages of this book that I though I had to get out.  I do really think that we're moving into a new paradigm in the next 10 years with software, and I think that some of this is embodied with this contrast of MSDN and ALT.NET.  I just hope we as a community can make this happen.

I had a few thoughts today on a direction that I think that software will be taking and that I think is important to document.  This idea ties into my post earlier today on generic programming and domain specific languages.  Take the followig three concepts as a set:

• Generic Programming
• Domain Specific Languages (DSLs)
• Intentional and Automatic Programming

Generic programming, as mentioned earlier, is programming that invokes a metaprogramming facility from within a hosting language (this is a part of the wikipedia writeup here, and I like it a lot).  It provides a means of extending a programming language to model higher level constructs, that which are much closer to the domain problem being addressed.

What generic programming provides is a means of being able to create extensions to languages that allow new syntaxes to be created that can be used by those working in the domain to be able to solve problems (instead of computer scientists) because they can utilize the computer to solve the problem, not write a program to solve the problem.

Now, if you are following the movement of the people touting DSLs, you might say that what I just described is the exact definition of domain specific languages.  And I agree.  And that is exactly why generic programming is important.

But whither to use generic programmingx or a DSL?

That is the question.  Here is my answer.  Generic programming remains in the domain of the computer programmer, ie the computer scientist worried about syntax and bit twiddling.  DSLs fit in with those who are trying to solve business problems.  I'm not going to go as far as to say that this is a business analyst, but it is potentially (and preferably) a person more atune to the problem domain then to the other problem domain of knowing how to program computers.

My point is, programmers will need to work to create DSLs out of existing languages (be they C++, C#, Ruby, ...), and Domain Specialists will use those DSLs to solve the higher level problems.

If you've read other posts of mine, you will find that I think that programming is too difficult.  It's not that its necessarily hard to do, but that it is tedious to do.  Hence my other ramblings on things like P#, a pattern based language that gets rid of a ton of boiler plate coding that I just hate to type everytime I code something.

Now, lets move up one level, or many levels.  I really believe that intentional and automatic programming (IP and AP respectively) are requirements for the future, and that DSLs are an important component in facilitating both of these into realization.

I personally see DSLs fitting into a role in IP/AP where the problem domain is modeled, and then an entity can automatically integrate and deploy software.  DSLs would in a way function as the implementation of well defined activities that solve business problems.  The DSL code could perhaps be generated out of a software factory where the domain specialist can check a few items off of a list and get an activity that solves the problem, and that is also checked against requirements to solve that problem.

Then, a similar process could be used that can integrate thse activities into higher level processes.  Note that each individual activity could be implemented via a different DSL (see my earlier posts about systems most likely being implemented in multiple DSLs), and the activities glued together via a software factory just as the individual activities generated.  And checked against requirements to work.  And automatically deployed and operated as the computer generated the code, and knows how to deploy and run it through the building of the DSL through generic programming.

Perhaps the eventual goal of fully automatic programming is not obtainable, after all at some point the computer must be told somethign about what to do, but surely this would be a great step forward into being able to quickly and reliably build software, and to business relying of IT to become agile.

I was sitting around and thinking about my experiences with distributed agile software development.  I've run a number of projects like this and have had a few challenges to deal with, and thought they were worthwhile writing down.

First, perhaps a definition for distributed agile development.  One of the principles of agile development is to have high bandwidth communications between members of the team.  This isn't necessarily bandwidth in the sense of Internet speed, but in having direct face to fact communications.  Once this direct communications is removed, you then have a distributed agile project.  This can be that some people are on another floor, another building, or state, or country; just that they are not instantly available for face to face interaction.  And this includes all participants in the process.

When distributing agile development, and therefore reducing the bandwidth of communications, you must then realize through communications theory (Shannon's law I believe) that the amount of processing to understand a message must increase.  In a sense, you must either start compressing the content of the communication, and / or increasing the effort to understand the communications.

The issue that then begs to be addressed is that how does the processing increases to handle the restriction in bandwidth?

To control this, you must get up front (as soon as possible):

• High trust / agreed SOW.
• Understanding of where the business value is.
• Agreement to collaborate frequently
• Set up means of collaboration
• Understanding that it is still an iterative process that assumes no specs but frequent changes
• Having the ability to access to subject matter experts

A lot of this can be solved by a kick off meeting that addresses these issues through:

• Discuss the scope
• business outcomes
• Get the team together
• Agree on how to break down communications barriers

This type of get together can range from a few days to a couple of months.  It's great to get everyone together as they will be able to begin to understand each other personally, and from that they can understand who they are dealing with when having communications challenges.

This can be very important in facilitating as remote communications will now feel more like they are face to face, making the communications seem much more personal.

It is also useful to rotate people through the sites.  This helps to facilitate keeping personal bonds tied, as well as in helping all members understand the culture of the other members (since this is often global in nature).

Another important thing is to be able to empower the team.  The team as a whole must be able to make their own decisions.  This will tie into having a vision for the work.  Often this can be set by a CEO explaining the vision (or other visionary).  I've found this to be very useful as it has allowed the team to understand where it is that needs to go.  By having the CEO of a remote partnership get buy in to the process, and selling that to his employees that are a remote part of your team, they will respond much better.

I've also found it useful to still hold daily stand up meetings to integrate the distributed members of the team.  I'd often have a daily stand up in the morning with my immediate team members, but also conference call in members of a remote team (say in Europe).  But, I'd also have a standup late in the day with the team, but with other members of the team in India (which late in the US day is their early morning).

The purpose of these meetings is just like that of every other standup: keep the teams tracking on the immediate goals of the project, and also work to identify any communications or technical issues while going around the horn.  And also make sure that you keep this meeting rolling.  Identify issues in the meeting, don't try to solve them.  Take the things identified offline into other meetings between the specific people needed to solve them.

Also, as a project manager (or Scrum Master, ...), use these times to also facilitate more interaction between the members of the distributed teams.  Basically, this comes down to being able to coach the team members to being up issues, and then to lead them into offline communications.  This is also particularly facilitate if you have co-located team members, as a member of the remote team being local can facilitate your understanding of what is being said from afar.

I've only scratched the surface so far.  I'll surely write some more on this inthe future.

This weeks Hanselminutes was a discussion with Tom and Mary Poppendieck on Lean Software Development and what is "software success".  Much of this discussion struck a chord with me and that I figured it would be good for me to drop a few thoughts onto my blog.

 

The initial part of the discussion started out with talk on what is the definition of “success” of a software project.  Scott apparently was chastised by Mary on a panel for mentioning that he thought it was to “be on time, in scope, and on budget.”  Mary stated that this is the definition of success according to “The Standish Group”’s chaos report, which measures software success on these criteria, and more specifically, failure of projects by not achieving these. 

 

She then said that she feels that this is not an adequate (or even correct) measure of success, and that for a software project to be a success it must be a business success, not a technical success.  This means that the software that is being implemented must create something that does what the business needs, such as achieving market share or being profitable, not simply accomplishing some type of task or goal.

 

I consider this to be a very important statement.  I’ve been on many projects that have been completed on time, on budget and in scope.  But they were never used.  Or used briefly, and then forgotten.  These, in essence, wasted all of the money put into the implementation.  These types of solutions have always been in my mind to not be successful software projects even though many call them successful.  Needless to say I don’t really like these types of projects, as in the long run I haven’t contributed to bettering the bottom line.

 

This leads to the idea that developers should not be measured by being done “by a certain date”, or on a certain “budget”.  Mary stated that when she was at 3M that the teams that she was on had to show P&L for the projects, marketing plans, …, to be responsible for all that, and in short showing that profit would be made from the project.  Or else, the project would not even be approved.  I agree with this whole heartedly, and more organizations should really learn to do more effective forecasting of the ROI / IRR on software projects before jumping in to that pool and building away.  Additionally, these measurements should also be used to guide the project alongs its path.

 

Mary then got onto a point that I think is very important, that her teams were held accountable to be responsible at a higher level than just time and budget, which are the typical things for which most software teams and project managers are held accountable.  These teams should be held accountable for creating things that address a tangible business need.  Their success must be measured on the actual problem solution, the successful capture of a financial opportunity by the organization.

 

One thing that comes to my mind, and that I feel she wants to say but never really gets around to it (probably due to time constraints), but I’ll say it (and I’ve said it to other before), is that it is my opinion that software is just a tool of implementation towards a completion of a solution / product.  Software development is a tool in building things that allow businesses to exploit opportunities, and the focus of software development must be to effectively address increasing profit in an organization, otherwise the criteria for success of the project is incorrect. 

 

Software development to me is not different than, say, using plastics in injection molding of car parts, or the assembly of those parts into a car, or any type of widget.  If the widget is not something that anyone will buy (that is, it will make money, and money above the cost of building it), then it doesn’t matter if it is plastic or metal machinery, or software development, that put it together – it just shouldn’t have been done in the first place.

 

Where this discussion in the podcast was going, but never got to, was into discussion of product development, and what I would refer to as software product line engineering (SPLE).  These higher level constructs for measurement that were mentioned by Mary, are in my opinion, components of proper product platform management, that uses software as the tool set for building the product, and where measuring success of products is in making profit (yes, I sound like a ferengi).

 

I'm going to follow up this post with another on my thoughts about SPLE as I think it is really important, but I need to address one more issue first.  During this discussion, Scott made a mention about the agile technologies, and that don’t these solve all of these problems?  Well, Mary had an interesting response which I totally agree with, and I’ll state it from my perspective:

 

Agile software technologies and tools as described today are an implementation detail of proper product management.  They are the means by which you create the parts of a singular product made of software, not how you define what should be in your product, or as the parts used to build a suite of products.  Measuring for success on using agile tools and methodologies alone is therefore an invalid measurement of the success of the products built with them.

 

I get a lot of flack from people I mention this to, especially at things like agile user groups.  I don’t care if you use XP, Scrum, TDD, MDA, Nunit, Mocks, FitNess, … all that stuff … if you are not building the right thing, then all these just help you build the wrong thing better.  Yes, they are important (and I do personally consider them to be very important), but they miss the overall target because the people working with them have myopic views of the overall organization since they are only in the trenches of software development.  It's not their fault, but it is a situation that does need to be fixed.

 

Also, and perhaps more importantly, even if you are building the correct thing, but you are not building it in a way that can lead to greater agility in the future, then what is the purpose?  This is something that touched on very briefly by Tom in the podcast, but could have used more elaboration as I think it is the real key to software success.  Software must be built in a manner where it is used to accelerate future product development, so that the organization can become faster to market with products down the line.  This is the holy grail of software reuse.  Not using software necessarily to build software faster, but to use product components built with software to build products faster than competitors.

 

This last note leads again back into software product line engineering.  I'll follow up with more on that topic in some future posts.

During this weeks Hanselminutes, Tom Poppendieck mentioned four types of value that a consultant can provide.  I thought they were good and were worth a note here:

1. Capacity, basically providing more labor.
2. Outsiders can bring in ideas that they have seen elsewhere.
3. Can see your situation in a different light and advise your on your problems
4. Acellerate acquisition of new skills to get better faster

Point of these are that you still need to know your companies core competency, and consultants often can't provide that.

You heard it here first.

Extreme Decomposition (XD) is a term that I believe that I coined a few years ago and I've still not seen it used anywhere, so I'm staking my claim to it officially here.

XD is a concept of designing software where functionality is broken down iteratively until it is completely decomposed into "atomic" items that serve a single unit of functionality in a system.  Each of these items must be able to be independently coded and tested to be a viable component of a software system.

Through this building of many atomic and properly functioning components to a system, they can then be reliably reused as subcomponents of higher level abstractions in the system, each of which must be individually tested themselves by building new tests that the test both the new functionality that integrates the child components.

Therefore by building a system of atomic components glued together then we can rapidly build new systems that meet the reliability and agility required in todays world.

For more information, please visit xDecomp.info.

I found the one of the recent .NET Rocks podcasts to be particularly interesting (show #322). In it Carl and Richard had Stephen Forte on to discuss managing distributed projects, and in particular using Scrum to manage those projects. The thing that I found most interesting was how Stephen had grown this skill almost organically, like myself (and I think anyone), and especially with how much in alignment he was with my opinions on the topic. Given that I felt that it would be good to itemize and summarize some of the main topics in the discussion between these three gentlemen.

1) Software development lends itself well to distribution of tasks.

The question then becomes why distribute your software development? There are a number of reasons, two of which are primary:

• High quality talent is not always local
• Isolation works - can not get "do not disturb" around the office, and this is a real important issue. There are references given that for example one phone call to a developer will make them take 10-15 mins to get back on track

2) How do I mitigate / manage risk in a distributed project?

There are a number of answers to this since there are actually a number of types of risk to mitigate:

• How do I communicate effectively communicate over large distances?
• How do I cope with giving up control (not micromanaging by having to have everyone right there)?
• How can I tell if someone is thrashing from a distance?

Basically, you can and will lose control of developers even if they are colocated. The trick is to be able to identify it, with local or remote staff. Thrashing is when a developer gets stuck and will not ask for help. This can happen even in a cube, and for weeks at a time, so this is not new even with remote staff. The issue is again how to identify it.

The solution to these comes down to using Scrum as your project management methodology, and this will assist in identifying these issues. Through this you gain control over your through empowerment and even if they are not right there.

Which also leads to the question of isn’t it important to have face to face interaction? Well, it is to an extent. As mentioned later it is important to make sure that most people know each other by face having had some type of in person interaction so that you can “see” the person that is remote, meaning that you can get a read on what that person is saying between the lines. Several techniques for how to do this are given later. Also, stress that communications by e-mail for important items is not the most effective means of getting things done. Stress using phone, skype, webcams, or getting in person if possible.

3) Distribute software development leads to greater agility.

This is true when combined with Scrum and short cycles / iterations. Doing this can lead to very quick releases when properly defined. This is actually a large topic to discuss that I will elaborate on independently in another post.

4) Use available tools to assist in managing the distributed agile process.

There are a number of tools available to minimize distance between team members:

• Scrum: Methodology for collaboration and identifying / assigning work.
• TFS / eScrum: Tools for running Scrum in a distribute manner.
• Skype: for communicating amongst the team with low cost.

And make sure that the Scrum Master ensures that everyone uses them and collaborates daily through the daily Scrum.

5) Identifying and addressing “Thrashing” with remote members.

• How can thrashing be identified over Skype? This basically comes down to being able to ask a simple question: “Why are you working for so long on this?” If you then you get a long answer, basically a laundry list of seemingly unrelated statements to the problem at hand, then they have probably tried lots of things except asking for help.
• Also, if you run one week sprints, you don't have to care too much about thrashing as long as the work is done at the end of the sprint. If it is not done at that time, then you are never more then one week behind and you can then identify those people who need help through the lack of a deliverable.
• It is also important to start with several small architectural sprints (and put these in the wiki - my input). These can be used to define a baseline for how the system should be implemented and reviewed against.

6) How to perform Scrums with remote people

• Keep iterations short, perhaps just one to two weeks. This will ensure that thrashing does not exceed more than one iteration.
• Use TFS with eScrum feature to manage the work items in the iteration and allow all remote team members to collaborate.
• Extensively utilize Skype as well as plug-ins for whiteboarding and sharing. Skypecast daily and make sure you go around the horn and use PTI (pardon the interruption - time is up).
• Prevent “hiders” in the Scrums by making sure that ScrumMasters make sure everyone participates.
• Be diligent to make sure that Scrums do not devolve into status meetings; remember that they are for solving issues and giving marching orders.
• What's the effective size of a scrum - 10 people, then do scrum of scrums

7) Team collaboration

What techniques are there to build collaboration amongst the remote workers?

• Kick off the project in person with everyone present no matter the cost as it will be saved later and it will allow distributed people to get to know each other
• Explain the business in the kick off, as developers will need to understand this to work independently, and may also likely take control of business features through the Scrum process
• Get developers to think as a user, having them always think in the frame of reference of a user operating the system.
• Empower the developer to make decisions as it will mitigate thrashing, and make them feel free to ask for input on the next sprint while working on the current one.

8) How to keep remote developers feeling as through they are part of the team?

The problem(s) here are:

• How to keep remote staff happy and motivated
• How to keep remote staff feeling that they are a part of the team

Solutions are:

• Operate with a staff augmentation model
• Engage with local recruiters to find what local talent you can
• Do a staff rotation model, were every person in a particular office should within a 2 year timeframe work in other offices for extended periods (2-4 weeks), and always have one person from every office in another office to build true relationships.
• These techniques will also let you get to know the people so you can understand them in the e-mail

9) How about dealing with the cultural differences?

• It’s Stephen’s opinion that the younger generation is much more liberal and technology has transcended the cultural borders therefore mitigating those issues.

10) In General:

• It seems as scrum master merges with product manager a lot. This is something that I was aware of from experience, but it was nice to hear Stephen express it too.
• Stephen had a great example of how to use current tools to manage a crisis. A remote worker said he had a power outage. Stephen used google earth and local search to find him an Internet cafe to go work at.
• Carl asked if it would be possible to use second life for remote interaction? I kind of like this idea and may look into it.
• Richard feels that he can handle only a maximum of 0.25 interruptions per hour (2 per 8hr work day).