Dealing with Distributed Teams

Almost every "Scrum" course I have attended suggests that in software development distributed teams are bad.  They discuss the problems that can arise by not having the product owner "always available" or the issues around not having a stand up meeting where everyone is actually standing up, looking at each other.

I agree with most of this.  There is definitely a benefit to being able to see someones face when they are providing their status updates.  I also agree that it is necessary for the product owner to be always available.  Where I am less inclined to agree is with the fact that all of these individuals need to be in the same physical location.  This was probably true a few years ago when the level of connectivity between individuals was much less than it is today.  There are several technologies available today that can help bring a team together at least to the point where they can effectively work together.

One solution that immediately comes to mind is the use of Skype or a similar technology.  The best scenario would be using something similar to their "Group calling" feature where all the team members can see each other when providing their status updates.  The Scrum Master would then be responsible for updating the board (whether this is an actual board or virtual).

The company I work for has a product used in education for helping with distance learning.  The product has audio, video, an interactive whiteboard and an application sharing feature.  All of these capabilities help my team to stay connected and help to bridge the distance between us.  There still needs to be the opportunity for the entire team to meet in person to firm up those relationships.  This helps take the team that extra step towards working well together.

The product owner needs to be always available and in my situation this is done using our own IM client.  I have found that most of the questions coming from the team can be addressed quickly using this mechanism.  If voice and/or video is needed, this can quickly be accommodated as well.  Where possible it is helpful if the product owner can be available, in person, during "sprint planning" to allow them the benefit of in-depth discussion with the team.  This is often a critical time when the team will engage the product owner repeatedly to gain clarity around the tasks being generated.  Once the sprint officially begins, the product owner still needs to be available however the frequency of request from the team will be reduced.

Distributed teams do pose a challenge for an agile scrum environment and this is amplified when those teams span multiple countries (especially when the time zone difference is extreme).  The closer the teams are, the easier things get.  I believe technology makes things easier however it doesn't solve all the problems a team may encounter.

--Ken

Breaking down the Epic Stories

I recently attended a course through CollabNet earning me the title "Certified Scrum Product Owner".  I found the course to be an excellent refresher on "Agile - Scrum" practices plus I learned a few new bits specific to the role of Product Owner.

An important piece that I took away from it was a series of strategies to use when attempting to break up "epic" stories.  For those less than familiar with this, an "epic" story is a story that has been sized by the team and has been deemed to be very large and/or very complex.  Epic stories typically have 2 main characteristics.  They have a large amount of uncertainty and risk plus they are usually lacking in detail.  When a team works to break down these epic stories, they often find that much more detail is put in to the resulting sub-stories and they end up being much smaller and much more manageable.

All this explanation is great, but how do you go about breaking these large stories up in to manageable bits?  Well, I invite you to read on...

Separate the UI from the "Plumbing"

Many stories produced by the Product Owner or the customer focus on a complete, tangible feature (or feature sub-part).  Often these stories contain both front end (user interface) and back end (plumbing) components.  Separating these out helps to reduce the scope of the story plus it results in something individual team members can do in isolation.

Separate by Operating System or by Browser

Stories can be separated to target a specific operating system or architecture initially and then be re-worked to include other architectures at a later time.  For web applications, targeting the most common browser first may be the way to go.  This provides the benefit of ensuring the feature is correct (as verified by the customer) before adding the complexities of ensuring the feature is cross platform compatible.  The other benefit is that the majority of the effort will be placed on the initial implementation leaving a much smoother path when adding support for the other architectures.

Separate based on "C.R.U.D." (create, read, update, delete)

This should be an easily identifiable split but when a team gets deep in to story creation, the strategy may not be so obvious.  Large stories encompassing all or part of these (create, read, update, delete) should be split out focussing on each one of these tasks.  This type of separation benefits the team in that the developers can address each one quickly allowing Quality Assurance the opportunity to test the code sooner.  Earlier is better since it keeps all team members busy and keeps the customer up to date sooner.

Separate based on Role

Some features in their original description may cover a variety of user roles.  These can present themselves in the form of a "first time user" or an "advanced user".  Breaking down stories to cover each of these in isolation will help to clarify a story plus it provides the benefit of focussing on the unique characteristics of a particular role.

There are many strategies that can be used to break down epic stories.  I have listed just a few that I find particularly useful in my daily grind.  I hope they become useful for you as well.

--Ken

From Development to Product Management

I have worked as a software developer for many years and have loved "almost" every minute of it.  Recently, I decided that product management was the new path I wanted my career to take but I had no idea how to go about making that transition.  I started by running searches on "how to be a product manager" or "how to transition from software developer to product manager" and I quickly discovered a common theme.  Product management isn't something you decide you want to do and then start looking for a job as one.  It is one of those fields where you need to gather experience first, then job search later.

How does one gain experience in the field without first getting a job as a product manager?  

Talk with other Product Managers in your company

I am taking the approach (since I'm still not a product manager yet) of talking with the existing product managers at my company.  This has the great benefit of allowing me to gather personal experience information from others helping me determine whether this is something I really want to do.  Aside from giving you some outside exposure to the field, this also gives you the advantage of being someone to keep in mind when that new product management position comes up.

Talk to the "Director of Product Management"

Once I gathered the information I was interested in, I decided it's time to speak with the Director of Product Management.  I approached this individual expressing my interest in the field.  This has the same benefit as above where your name is in their mind when they next look to fill a product management position.  This person will also often have the final say when you do decide to apply for that opening.  I was pleased to discover the Director of Product Management in my company was very approachable.  They made several suggestions of tasks I could take on and added me to a variety of important mailing lists.  This allowed me to silently observe the interactions between our existing product managers and our customers.  I would periodically question some of the responses or even take a stab (in a controlled environment) at a potential response myself.

Tell your manager

You may choose to approach this differently but I openly discussed my ambitions with my existing managers and they have been more than helpful in supporting my goals.  They have sent me on training courses and have also made some suggestions on areas I could gain further involvement.  I was nervous about this before but took the chance anyway.  I was pleased to see the value placed on the employee within my company and they show an honest desire to grow their employees.

Now it's in your hands

Only so much can be handed to you by others when trying to make this transition.  If suggestions are presented to you, it is up to you to take those on an execute them to the best of your abilities.  Showing incentive will go a long way and will make you noticed by those that have the power to influence your career.  I have been working toward this for just under a year and feel I am progressing well.  I realize that even though my business card doesn't say "Product Manger" yet, I am gaining valuable experience which will help me to "hit the ground running" once that opportunity does show itself.

I'm not trying to come across as an expert on how to break in to the field of Product Management.  I simply wish to relay my experiences in hopes that it might help others who are also attempting to make the transition.

--Ken

Bill St. Arnaud: The History of Usage Based Billing (UBB) and why it will almost always fail

Bill St. Arnaud: The History of Usage Based Billing (UBB) and why it will almost always fail: "mpetition or mandating simple and understanda"

Google voice in Gmail

Last night when checking my Gmail, I noticed a big "click Me" popup inviting me to try Google Voice through Gmail. Everything I had read previously indicated that Google Voice was not available in Canada however, I gave it a try and it worked. The official Google Voice site still indicates that the service is only available in the US but for now, it seems to be working (through Gmail anyway).

More here.

Don't throw away all that work

I recently read an "old" article related to common mistakes made by software developers and development managers. One of the biggest ones is to throw out the old code to allow for a fresh start on a product. As the author explains, you are not only tossing a code base that may be ugly and difficult to read. You are also tossing out hours (days, years) of bug fix efforts and field testing not to mention code that has proven to work in multiple unique environments for (possibly) years. As always, the one solution (or idea) fits all mentality never works. Keeping the culture of the company, the history of the project and the vision of the product for the future in mind will ultimately help to determine the best course of action for you.

Git: You have not concluded your merge (MERGE_HEAD exists).

Recently when attempting to do a 'git pull' on a remote repository, I encountered a CONFLICT which required resolution. After addressing this conflict, I added my changes via 'git add' and attempted to pull from the remote repository again. The following message was seen:

You have not concluded your merge (MERGE_HEAD exists).
Please, commit your changes before you can merge.

I found a solution here which simply stated to revert the merge 'git reset --merge ORIG_HEAD' and try again. The step I missed was the 'git commit' after the 'git add' before retrying the pull.

The commit should have been obvious except that I had just run through a series of conflict resolutions while doing a 'git rebase' against the master branch. During a rebase, it is expected for you to resolve the conflicts, 'git add', and then continue with 'git rebase --continue'. There is no commit step when resolving conflicts during a rebase.

A classic case of wrong frame of mind.