pmStudent

"Do you know of any material, studies or other which covers agile project management but with geographically disparate participants. I have a couple of projects where this is difficult - design team in Bay Area, coders in Malaysia, China, India and Pakistan, customers/user reps across dozens of countries and project team in Singapore... timezones are killing me!"

In terms of Agile, I don't know of any training specifically for remote teams. 

I do have some personal experience with it though. I currently manage 2 teams of which some members are remotely located. 

I think Kanban does a lot for this scenario, primarily because it enables some self-organization that I think doesn't necessarily happen easily with something like straight forward scrum. The best thing is that you can use the kanban board even while not doing strict Kanban..and use it with any methodology, such as scrum or even waterfall. 

It allows my team to conduct our daily stand-up and update the kanban board - even when I'm not able to be there. And yet I am able to see what updates were made later and still have a good view of what is going on with each project. 

My recommendation to you would be to first learn about kanban if you don't already know much about it, then look into the many hosted electronic kanban boards for use on your teams. I personally love leankitkanban - but agilezen and others are very good too. 

In this video, Josh encourages you to own your project management career. You are your best advocate, and your questions and answers are going to be individual based on your background, goals, and industry.

Like this? Share it!

Having taken over a project, I find myself in the awesome position of needing to revise requirements with my customers that are pretty obviously in need of some spring cleaning.

Here are some tips for your own situations where you must "scrub the stains" out of a set of requirements, as opposed to dealing with change management on one specific requirement.

Make it Easy

We use DOORS to manage our requirements.  For me, step 1 is to export from DOORS to an excel file.  Getting these requirements into a format people are comfortable with is very important.

Next, I trim away the fields that don't really matter for what I'm trying to do, and then copy/paste the requirements into a blank Word document.  The reason for this will be come clear in a moment.

Track Changes, with Comments

I turn on the "tracking changes" option in Microsoft Word, and go to it.  Whenever a change is made, a comment accompanies it.  I speak to my audience, the customer, so they will easily be able to understand why I am proposing some changes.  In this case, I want to add clarity and also specify some functionality that has become known as a user need over time, but wasn't captured in the original requirements.

Review With The Team

I always like to review any requirement changes with my teams before proposing them to the customer.  This way, I can be sure I'm on the same page as my team members and there aren't any communication gaps about the needed functionality.

Many times, the understanding I've gained about new wants and needs comes directly from my team members, who are interacting with the customer and future users of the system.  It would be very bad if I had a misunderstanding on a particular requirement and ended up making that part of the baseline, when it's really describing the wrong thing.

Meet with Customer

Next I meet with the customer to ensure the changes I'm proposing make sense to them.  The comments I did earlier come in really handy, and the better they were, the easier this process is.  In my environment, I prefer to do this before having it come up at a Change Control Board (CCB) meeting as a change request.  I want the customer to be knowledgeable about the proposed changes and see the value in them before having to make a decision.

Change Control Board

The final step is to "make it official".  If you don't have a change control board in your project environment, you should set one up.  It doesn't have to be complicated, but it does require that everyone on the project understand that changes don't get made to the project baseline unless they are approved by the CCB.  

The customer and sponsor should be voting members, and in my environment the customer is the chair of the CCB.  That means they have the final word on whether a proposal will be approved or not.  If you are in a different contract environment, it may be a CCB internal to your own company/contract you are interacting with.

Like this? Share it!

If you are a fan of Theory of Constraints (TOC) as I am, you may know of the Evaporating Cloud Diagram.

As I have been using Kanban for some time now, I have found myself going back to my TOC roots and unpacking some of the tools I am somewhat familiar with, but haven't used nearly enough in practice until recently.

The following figure is an example of this tool put to use.

Conflict Resolution Diagram

The Goal

This tool is useful when you have two competing interests that appear to be at odds.  Mapping it out like this helps walk through the assumptions being made.  Each of the arrows carries at least one assumption, perhaps many assumptions.  The 5 sentences below the diagram are the default assumptions being made here.

So in the main, this helps everyone understand the underlying assumptions so they can be analyzed with a skeptical eye.

Let's Walk it Through

The objective here is to have a cost-effective, quality system.  We want to maximize quality and minimize costs at the same time.  

I'm sure this is just a weird example, we've never run into this before, right?

One of these assumptions as I walk through them stands out to me.  Do we really have to sacrifice functionality and scaleability in order to minimize costs?  What about that statement seems like it may not be quite right?

In this example, I discovered that "minimize costs" was a requirement, but put this way, it was being assessed in the narrow and short-term way of project cost.  The life time cost (and from all sources) were not being properly factored into the ROI equation.

Quality was being assessed as a lifetime dimension of the system...but because of accounting practices and separate funding sources, costs were only being assessed in the scope of the project.

Looking at it this way (and using this as a tool to help senior management understand) is a great method to apply systems thinking to conflict resolution on your projects.  It's helped me personally to help sponsors "see the light" when it comes to justifying the expense of licensing software, procuring specific hardware, etc.  It has helped me in many instances.

Give it a shot!

Like this? Share it!

I've recently experienced an epiphany.

I should have seen it earlier.  I mean, duh!

I have been using kanban with my teams for some time now, and up until now we have been mostly focused on limiting work in progress (WIP) and evolving our value stream.  Only recently did we start trying to reduce the batch sizes of code being worked through the system.

The Changes Have Been Dramatic

Rather than trying to peer review a whole slew of code, the team is engaged in more frequent, shorter peer reviews that are highly focused on just a small bit of code, individual features in most cases.

As a direct result, I believe we are producing higher quality software.

Mind you, I can't prove it quite yet.  In our waterfall paradigm, it's going to be a little while before we get to a full release where we go through formal acceptance testing.  Because this is the way it's always been, defects in code are going to have to be measured against the previous benchmark established in previous releases.

It Makes Sense

I mean really, this is a no-brainer.

If someone has to spend 4 hours scouring through hundreds of lines of code, it's going to get glossed over and things will be missed.

If someone knows they will get through a peer review in 10 minutes, it's a lot different.  Easier to focus.  Higher scrunity on the code.  Better solutions are developed and collaborated on.  Awesomeness ensues.

Not to mention, there is a shorter turnaround time from when the developer codes to when they receive feedback, and when they can disposition comments and make it better.  Less knowledge lost, more value gained.

Now the nagging question is....why didn't we start doing this earlier?

Like this? Share it!