Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Playing Find and Seek on a New Project

DZone's Guide to

Playing Find and Seek on a New Project

Zone Leader, John Vester, talks about the impact on productivity when told by the SME to find and seek answers instead of offering quick assistance.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Have you ever found yourself in a position on a project where you struggle to obtain answers to your questions?  For me, I encountered this situation while being part of a team converting an application built in a proprietary language to a solution based on standardized languages and frameworks. On this project, the stories contained references to program code in the current version of the application - causing our team to play a game I have referred to as "find and seek" in order to derive the underlying business rules and functionality.

The Building Contractor Example

Reviewing a significant amount of proprietary code eventually leads to uncertainty with the results provided. While doing my best to analyze and understand program logic written in an application that I am far from an expert in, there are times when I would need to reach out to the subject matter expert (SME) on the project. Upon asking my task-related questions, most of the answers referred to re-visiting the current code to gain an answer. 

While I certainly understand that everyone, including the SME, is very busy with tasks related to the project, the following example came to mind:

Assume that my job is to frame houses for a living. I have a strong understanding of the framing process and have experience with the tasks assigned to me to yield a fully framed home. While on a project, I reached a point where I needed answers from the architect on the project. When I asked for a quick answer to my question, the architect instead provided me with the following answer:

"Get into your vehicle and drive about 20 miles to a house I completed prior to this project. Ask to enter into the home and find your way into the attic. Once in the attic, if you review the work I completed in the northwest side of the home, you will understand how I want this task completed."

In essence, the architect asked me to make a 40-mile round-trip drive to (hopefully) gain access into a home which had the same requirements when built. The hope is that I can actually gain entrance into the home to be able to navigate inside the attic to obtain an answer to a question that could have been provided by the architect within a much shorter period of time.

The Cost of Find and Seek

While the building contractor example may sound absurd, asking a team member to spend several times the amount of time to find the answer and seek an understanding is not much different.  When these types of situations continue to occur, it is easy to understand how a project can appear stalled or over budget as team members continue to derive requirements and functionality from the version of the application that is being replaced.

In addition to the loss in time, there is the aspect of the time required to regain productivity after an interruption in planned work. The following graphic appears in Arshad Hossain's blog entry "A study on unplanned interruptions in software development:"

Image title

With a goal of obtaining 70% productivity, the time period between data points I3 and I4 demonstrate the loss of productivity due to an interruption. Based on the graphic alone, it appears there is a 45-minute period of time where productivity bottoms out at 10%. In this example, the author references helping another individual during this time, but the segment could also reference the topic discussed in my example.

The productivity does not reach zero, as some level of productivity is gained from the find and seek effort. Eventually, productivity reaches 80% before a break is taken.

By comparison, the I1 data point could represent the impact on productivity if the SME was to take a few minutes to provide an answer. Here, there is a small drop during the conversation, but productivity increases rapidly as a result of the quick assistance provided.

Impact on the SME

Looking at the graphic from Arshad’s article could raise the question, "do the I3 and I4 data points represent the productivity loss by the SME by fielding questions about the application being converted?"

Considering the role of the SME, I don't believe this is a valid consideration. While the SME's productivity will be impacted from answering the question, it is part of the SME's job to provide expert information regarding the current application. In fact, Arshad Hossain concludes, "On average, about 40% of working time is lost because of interruption, not all of it should be counted as waste, some of it is unavoidable and some og it can actually increase other people’s productivity."

Conclusion

I truly understand the task load on team members during application conversion projects. During these types of projects, the product owner, development lead, and other key roles are often overloaded with tasks - focused on delivering a quality product at an accelerated pace. However, it is important to keep in mind the impact asking team members to play "find and seek" has on not only their productivity but also the cost of the project.

Have a really great day!

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile adoption ,developer productivity ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}