Dependencies in Development Teams

Don't Get Tied Together. Break Free!

Philosophical conversations over lunch or coffee often lead to a lot of thinking about our current situations and clients. I sat down with a client over lunch and our conversation steered toward our team, and how it there are so many dependencies hamstringing the project currently. From technological and systems issues, to specific coding knowledge of certain individuals, and even dependencies on time zones. It got me thinking about how dependencies truly affect development and our basic assumptions about them.

Usually we assume a couple of things about dependencies (that are not always positive):

1. We assume that we must make the best use of all workers time, so we double and triple book them on multiple projects.

2. We assume that some of our needs stem from the fact that we don’t have subject matter experts or consultants to help us with our problems.

3. We assume that customers need all the features at one time so we don’t focus on the small functional slices of a project.

4. We assume that development, live production, and the architecture that holds it all together is as complicated and cannot be adjusted easily, or cheaply.

Having dependencies will reduce our ability to respond to change rapidly (New requirements, new product ideas, quick page fixes, etc).

Eliminating dependencies on teams needs to be a continual effort. We have to continually build an environment that allows our teams to not be hung up if road blocks do come.

What are some of the ways that you alleviate this issue?

[Image Source:]

2 Replies to “Dependencies in Development Teams”

  1. Pingback: Twitted by SolutionsIQ

Leave a Reply