Responses to Flat World Webcast Questions, Part 1
The online panel discussion, "Building Software in a Flat World," stimulated a tremendous number of questions from the audience. Some were answered as part of the panel discussion. Others that we could not cover will be answered right here, front and center, for all eyes to see. This first set of questions are answered by 6th Sense Analytics co-founder and CEO, Greg Burnell.
1. What is the current adoption level of adoption of software development metrics in North America? and what would make this adoption go up?
One of the reasons we started 6th Sense Analytics is because our research indicated a high level of effort being expended on attempts to introduce measurement and metrics into application development–on a global basis and with little success. One study we discuss from Gartner indicated that 76% of SD metrics were assembled and reported in Microsoft Excel. Needless to say, this indicates a free-form and very disjointed approach to consistent metrics. I would also say that our discussions with customers, prospects and industry veterans tended to reveal that most felt that–if it was not impossible–then highly improbable that meaningful data could be assembled consistently about the development process. Our excitement grows daily as we show the world that you can truly gather, report and make decisions on the data our solution provides.
Your second question may be answered by my first response. Once the development community understands that this is possible, and that a solution can be attained that does not require a wholesale overhaul of the development process, we strongly believe adoption will not only go up but explode throughout the industry at large.
2. Can you identify any key differences in either the SDLC or the project management of an offshore engagement?
Great question. I think the obvious answer (that people are simply in remote locations) is the most appropriate, but I could go on for days about the unique challenges associated with the phenomenon of globally distributed application development. There are some extraordinary research efforts that have been conducted by the various analyst organizations that drill down into the challenges. I will focus on the manageable ones: visibility, transparency and decision-making.
Let's be honest, the reason people outsource is cost—and not because somehow a good SDLC process allows it. The SDLC, depending on the process one "believes" they are following, is largely unchanged in this context. The challenges to any SDLC is the way in which effort and outcomes are managed. Regardless of how you conduct the SLDC, it is imperative to have a measurement solution that is not impacted by variations in process, technology, education, skill set, understanding or anything else. You need to measure "what is" not "what someone else thinks it is." Make sense? When push come to shove and a project slips for any of the 100 most popular reasons the SDLC becomes the GIDN (get it done NOW!). We all know testing is the first casualty of the time box. We also know that any effort being expended on non development activities such as project plan updates and cool spreadsheets to track effort go out the window even quicker . The trusty old time-sheet still gets filled out to insure payment, but the entries on that time-sheet become more about CYA then SDLC. I know. You know. Individuals, managers and executives are then thrust into a decision making mode based upon bad data. The solution we offer is not impacted by the things I just mentioned. It collects data and offers insight with no emotion or variation on a daily basis. Actually, our findings are quite insightful as we see the peaks and valleys that almost always reveal themselves in the conduct of a project. Push hard for a week or two and you better plan for a down week behind it. We're talking about the realities of a process that depends on the creative and focused energy of a talented mind. Wear them out and you get a worn out effort. Having the ability to see these normal cycles and plan activities and events in light of this understanding is as Mastercard would say … priceless! Now, magnify this across continents, timez ones, cultural norms, language and the other challenges of GDAD. Add in a vendor relationship if the team is not only offshore but outsourced and you have a recipe for the type of perception that is common in outsourcing … it fails to meet the expectations of the parties involved. Some challenges are mitigated by size, meaning that larger outsource relationships have a better opportunity for success simply due to resources available, but now companies of all sizes are utilizing the world talent pool to meet their development needs.
So, what is needed is clear: A way in which to maintain an appropriate level of visibility in the effort being applied to the project not the effort being reported as applied to a project. Transparency is a call to all participants in the development cycle to share a common view of what's actually going on within a project. In our opinions, data that does not serve all stakeholders serves no one. Finally, decisions made upon visible and transparent information are better received, more actionable and easier to implement. It sounds easy but it is not. But it IS possible.
3. Are there special metrics that are especially adequate or not for distributed software development?
ABSOLUTELY! Active time as a base measurement unit is, in our opinion, the fundamental building block for an effective metric. Active time is a reflection of effort expended. It is a measurement of time spent using a development tool or technology to build an application. Active time does not (and we do not think it necessary) measure events outside the use of desktop technology. Use your time-sheet for that if you have one and if not stop worrying about it. We don't. We do not devalue non active time effort such as meetings, planning sessions, whiteboard sessions or even the water-cooler or smoke time out back. Everybody has these activities to some degree. We just do not measure them. Active time then can serve as a proxy for overall effort expended on a project. You can drill down in the process, technology, tools, people, teams, locations, artifacts and many other views of the project.
What we do not say is what metrics work for YOU. We provide a framework that allows you to view the data in a multidimensional format that serves your needs. Comparative analytics are very important. Maybe comparing on-shore teams to offshore teams. You may find out that Tuesdays are productive days and Fridays are miserable. In time our community of users will offer their insights into the analyses that best suit certain decisions that need made or observations you wish to track. Norms, trends, velocity, capacity, peaks and valleys are all events worthy of consideration. Example, how important would it be for you to know that your team averages 100 active hours a week? Now, imagine that you ESTIMATE the effort on a task or project in active time. You now have the ability to measure progressions against not only a worthy estimation unit but you know that the progression is being measured by the same unit of effort. This brings a whole new meaning to 30% complete!! If a project or iteration is planned at 200 hours, then you should be comfortable in projecting a calendar completion of two weeks. We at 6th Sense Analytics manage in this manner and we have found it to be highly reliable and meaningful.
We see no limit to the insights that can be gleaned from analysis of the data collected. We're not smart enough to have thought about all of them and never will. We focus on those that have meaning to us and are happy to share that insight with you. And, we would welcome your input and advice on ones which are of value to you. That's what our community is all about.
Previous Post:
Don’t Ignore Your Career, continued