Remote contract workers

A question posted this morning on one of the Yahoo groups ..

" We have a Scrum team in the Silicon Valley and two contractors who work with us remotely. Although they are proficient at what they do, it has been a challenge to get them (understandably so as contractors) to be apart of the team. We have two main issues:

1) They are contractors and don't see Scrum as more than just something to do to
keep a contract.
2) Daily meetings and full conversation required for communication saturation
are next to impossible over the phone (and really poor quality, unreliable Skype
video), and despite our efforts there is a disconnect and a lack of
effectiveness felt by everyone.

State of Agile

Introduction

Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

Stories - how small is too small

Today over on the Scrum Development forum a question was posted by a member. They have a situation where they have mixed some small stories with some larger ones. And the larger one is LATE - Really late. It's now been pushed into the 3rd Sprint and according to her it's still tight. So now they're faced with a situation where the smaller stories that are done can't be deployed as they never branched the code.

I find it alarming that folks can't break user stories down further. So many folks say you can't do it when over on the XP forums they're all working with really small stories so much so that they don't even bother with tasks any more.

The 7 Software Development Wastes - Lean series Part 7 - Defects

Introduction

When one looks at all the wastes, defects has to be the most obvious one. The cost and repercussions of finding defects varies depending on where in the cycle they're found. Defects found early on in the development life-cycle are way less costly to resolve than defects found later on in the cycle; the most expensive being when applications are already in-production.

Additionally, depending on when the defects are found, defects can and do trigger other wastes like task switching, relearning etc.

Defects can be very costly for an organization. So the trick with defects is that you need to 1) Prevent them from happening in the first place and 2) Find and fix them as early in the development life-cycle as possible.

So what can you do to prevent them from happening in the first place?

The 7 Software Development Wastes - Lean series Part 6 - Delays

Introduction

Interestingly, this weeks blog covers the 6th waste - Delays - as identified in Lean. How appropriate after the long delay since my last blog post on Task Switching. Herein lies an example of what Delays in software development can cause.  Delays introduce discontinuity and trigger additional wastes already covered like Relearning. It's important in any process, including software, to have continuity. This reduces cycle time and minimizes other wastes like Relearning, Task Switching etc.

The rest of this series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5.

Focus on the end-to-end process, not individuals

It's important to identify Delays early on and try to rectify them as soon as possible in order to maximize team productivity. It's interesting... I have been reading many interesting threads on the Agile forums lately about measuring developer productivity, team productivity etc. Managers/executives have us focus our efforts and attention on individuals instead of looking at the end-to-end process to find the real issues that address productivity and enhance team effectiveness.

There's two camps - Tracking Stories or Tracking Stories and Tasks

I have been debating with Ron Jefferies on the XP User Group about whether or not it's useful to do task breakdown and track tasks on a burndown. This friendly debate demonstrates that people work differently under the Agile methodology. Differing perspectives and experiences are worth investigating. Hopefully my comments here reflect Ron's and the XP users' opinions accurately. A lot of what they say makes sense but it seems like each approach has merit.

Camp 1 - Scrum camp

Most teams practicing Scrum track sprints at the Task level but also use Stories and Story Points for planning. Stories are estimated Story Points. During Sprint planning, based on previous velocity (calculated from the number of story points that get completed in a given sprint), Stories are selected up to the maximum capacity of the team. Stories are then broken down into Tasks (in the second half of the planning meeting), Tasks are estimated in hours and tracked on the burndown. Each day a brand new estimate is provided for each of the tasks (mostly just the ones in progress). Hopefully the hours go down and your burndown burns down.

Camp 2 - XP camp

The 7 Software Development Wastes - Lean series Part 5 - Motion

Introduction

Previous posts on software development wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features , Extra Processing and Transportation

I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There's quite a bit of re-acquainting and relearning so there's waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.

Motion - Task Switching

Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.

The 7 Software Development Wastes - Lean series Part 4 - Transportation

Introduction

Previous posts on the first 3 wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features and Extra Processing

#4 Transportation - Hand-offs

Transportation in manufacturing corresponds to hand-offs in software development. Anytime you hand a deliverable off to a different party, there is some loss in the transfer of knowledge.

There are many such examples of hand-offs in software development:

1. Developer hands off to another developer. In this scenario if the first developer never documented the code properly it's going to take significant addition effort to figure things out. Worse, the second developer may make assumptions and, as a result, introduce bugs in the system.

The 7 Software Development Wastes - Lean series Part 3 - Extra Processing

Introduction

Waste is a killer in any organization. But if you don't know what to look for then you're probably not going to be able to find waste and minimize it or eradicate it. This series primarily deals with explicitly defining the 7 wastes in software development so that you can start thinking about how this may affect your ability to remain as productive as you can be. This can make a significant difference to your company's bottom line.

As reference, the first two wastes can be found in my previous blog posts here: In-Process Inventory/Partially done work and Over Production/Extra Features.

#3 - Extra processing

Extra processing in Manufacturing is the 3rd waste and this can be equated to Relearning or Rework in Software development. The time we spend relearning things we once knew or having to rework the same feature due to poor code quality can be significant in many organizations, ergo, it's important to be mindful of this. It's probably useful to list examples that would cause extra processing in software development

The 7 Software Development Wastes - Lean Series Part 2 - Overproduction

Introduction

I wish I knew about Lean earlier in my career - I think it could have made the world of difference. Lean offers such practical advice on what to look for in order to make the process better. I think just knowing about these aspects of lean will help you day to day, help you make better decisions, make you a more effective player on a software development team.

Last week I covered the first manufacturing waste In-Process Inventory corresponding to partially done work in software development.

This week I will discuss the 2nd Waste:

Over - Production