Yet another Dreadful Dependency!

I introduced Joe to you in Oct 2013 through our conversation on his question ‘Velocity Dip or Double Dip – What to do?’ Subsequently I wrote a post on how he affirmed ‘Readiness at the Starting Point Matters!’ to his product owner. Last month we met again to discuss about ‘Building on Legacy Code’.  I trust you read all these posts. I am writing this post to share another story. This story is about dependencies in software projects.

Last week I was in a 1-day workshop on emerging technologies. To my surprise, I met Jim and his technical architect, Alan in that workshop. We had some interesting conversation over lunch.

During the first five minutes of our conversation Alan was little skeptical on how iterative and incremental development works in large projects. That is how I perceived him because of his crisp answers and body language. He was not ready to open up and talk about issues on the ground. I wanted to understand his views. I had no other option but asking him pointed questions. And I started.

“Alan, tell me. How is it going in your projects? I know you have multiple projects – big and small. What is one single big issue that bothers you?”

Alan smiled and responded. “Well there are multiple issues. There are issues because of dependencies. How do we handle them? I am working with a large team – there are multiple teams. These teams are spread across three locations. Last week, we were about to complete a feature. That is when one of our team members alerted about a dependency. Our code depends on what other teams are developing. This is not the first time. In spite of multiple reminders, the other team did not act on time and complete their work. We are just a month away from our release! Believe me, it is yet another dreadful dependency! ”

“Let me add some more information.” Jim chimed in. “This is a large project. Initially we thought that our teams spread across these three locations could function smoothly. Because we put them on three separate modules. I can say, fairly independent modules. Now, we are deep inside the project. We understand that on implementation point-of-view – I mean, in terms of design and coding, there are several dependencies. Those are hurting us now!”

Looking at Alan, I probed, “That is, you are not able to finish something because something else is not finished by another team?”

He nodded and said, “Yes. Sort of. You can say that.”

I wanted to know more about what happened in their project. I continued. “Joe, I think we are good at managing ‘Finish to Start or FS’ dependencies. For example let us assume that we plan a trip from point A to point C with one hop in point B. Let us say want to go by air. The entire trip is covered in two flights - one from point A to B and the other from B to C, we know that there is a dependency there. I mean unless you reach point B on or before X hours, you cannot start from point B at Y hours. That’s is obvious. We plan for sufficient hours between the arrival of the first flight and departure of the second. We do this in our projects too. Simple. Isn’t it?”

Joe smiled with his short response. “Yes. We do. But I am not sure if we identify all dependencies and explore all possibilities. Could it be the drawback of iterative and incremental development? I don’t know.”

Alan, with his curious expression “I partly agree with Joe. I have a question. Finish to Start is interesting. What are the other types? Is there a Finish to Finish? How about a Start to Finish and a Start to Start? Do we have all these types? FS, FF, SF, SS?”

“Well, Yes. That is correct. I think the dependency issue you told me about in your project is a Finish to Finish dependency. That means that unless that other team finishes some work, you cannot finish your work.”

“Right! Absolutely!”

“So, what do we do about these?”

“Plan, execute, and monitor progress. These three are important for all types of dependencies. I mean plan, execute and monitor. Obviously! We know that. In spite of these if you come across issues, you will have to manage those issues! What do we do when our first flight from A to B is delayed? If we carry a refundable ticket and if there is ticket available in a flight on the same day, we reach after few hours of delay. If we carry a non-refundable ticket, and the flight operators are different then the solution is costlier - we get some refund but we need to find out way home by buying another ticket or doing something else to travel. That will be an expensive ticket! So, what is the take away here? We need to plan. We need to build some safety net or a backup plan in some cases. That is because dependency is a risk. If a dependency is perceived as a big risk, you plan to mitigate it. In our example, the mitigation plan is your refundable ticket with enough overlay. In spite of this mitigation plan if that dependency becomes an issue – for example, due to bad weather or flight delays you miss your second flight, you have to manage that issue. That will impact your journey. You may not reach on time!”

“Interesting example! So, do you say that we must plan for all dependencies?”

“Well, I think we must be aware of all dependencies and their impact. The next step is to plan. Without awareness we cannot plan. Without planning we cannot put in measures to reduce the impact of dependencies.”

“Of course! I agree. Is this all part of Scrum or XP or something else?”

“I don’t think so. And you know this better than me! These is a project management practice. You must be able to pick and choose practices like these and include them in your methodology. Then it becomes your hybrid methodology. Methodology is project specific. If that is what matters, that is going to work for you!”

“Well, I think it is clear now! Thanks a lot!” said Alan.

“Sure. We need to go now. Our next session will start in five minutes. I will share some more thoughts on project dependencies next time.”

With a smile, Alan acknowledged, “Thank you. And yes, we talked about these theoretical concepts. It is worth exploring some hands-on techniques as well. May be next time.”

“Of course. I will share those in my next blog post as I am on a long leave and may not be able to meet you until Jan 2014. Or we will discuss about those techniques and all that when we meet.”

With that parting note we started walking towards the conference room looking forward to an interesting post-lunch session.

Dear Readers, I am sure this post is a long but a fast read. How do you manage dependencies? Did this post trigger any thoughts in your mind? Feel free to share!