Business and IT Working Together – Why An Executive’s Knowledge on Software Testing Matters: An Interview With Michael Hamilton and Ray Grieselhuber Pt. 1
Understanding the role of IT within an organization is no easy feat. Yet, here we are - maneuvering in a new marketplace that demands profit and growth in order to be successful. It’s no surprise then that for an organization to achieve this next level of prosperity, it’s critical for executives to understand IT and how it integrates with business functions. After all, it’s the executives who fully understand and leverage processes like software testing that have the ability to transform their organization and retain customers when the time calls for it.
To gain a better understanding of why this is important and how business and IT can better function together to benefit their organization overall, we sat down with Michael Hamilton- software testing consultant, founder of Hamilton Applications and author of “It Should Just Work: Customer Satisfaction & the Value of Software Testing” - and Ray Grieselhuber of Functionize for a two-part interview.
As the digital age continues to evolve, we face an ever-increasing need to respond more quickly to business demands. How can organizations ensure a reliable and consistent product?
That's an excellent question actually. Raising debate throughout many businesses today is maturity. I think maturity comes down to the people that you have, but also having the quality control processes. Now, when I say quality control, I'm not saying having a quality control roadblock at the end of the process that puts things into the production line.
Just having a challenging team and a challenging, mature environment, that is the most important thing. Having the right people around you, having the right mentors or advice is very important when you're in this area, especially from executive management all the way through down to the actual IT departments and the business around that. Each business or idea is different and must be assessed on its own merits also. From my personal point of view, you just need to make sure there's a quality control process in place at the end. That is something that I really feel strongly about.
A lot of people who want to move faster because of system products turn to the agile methodology, but the question I always ask is, is it the right fit for their business? Just because it's a fad people want to take it up, is it always going to achieve the result you want? I have been in situations where I've seen agile processes put in place, but they don't produce anything after a sprint and not put something into production to get that efficiency. All they have are processes around it to support production. That is something that I've noticed in the world today.
This is a really, really interesting question and something we could probably talk about for quite a long time. My experience, I've been building SaaS applications for most of my career. There are usually two origins of them: one is they come from startups, and the other is it comes from a larger company as internal projects and gets spun out. Both have different challenges.
Startups are usually generally better positioned to do them because they buy into this iterative mindset a lot more than larger companies do. The larger companies, they still fall into more of a traditional mindset, which is more like waterfall. The point is that in order to really be successful in building a product you have to ensure that you're building it for what the people who you're targeting actually really want. Suddenly projects that are a failure are failures because the people who were in charge of them failed to really understand what it would take to get to that product market set.
That is the general framework that I think is going to work with what you're looking at building successful products online in particular. The thing that's relevant to some of the topics we're talking about here is that the ability to move fast between those iterations is really critical. If you are relying on outdated processes or processes that are not efficient, you're not going to be able to iterate as fast as you need to, your customers want you to and the market wants you to.
Not just taking an iterative mindset, but being able to iterate very quickly, being able to move very quickly, and respond to customer feedback is very important. The whole reason for that is because you will be wrong when you launch your product the first time. You are going to make a lot of wrong assumptions about what your customers want, what they're willing to pay, what the market expects and how they see you versus competitors. The only way to get it right is to be able to respond very quickly to feedback, again in an iterative fashion.
Yeah, makes a lot of sense, especially moving fast. Obviously, when you do respond back to customer feedback, especially in the mobile device area, it's very important that you have automatic sits as a good example. Have the ability to regression test your software quickly when you do find problems and respond quickly with potential fixes it required.
Also, the ability to be online and check what problems are occurring. For example, checking the app store in Apple and checking the feedback on that, and responding back very quickly. Monitoring and having processes in place, and also understanding the limitations of your product and making sure the whole team understands it before it releases to market, is important. Also, communicating with the market about what are the limitations of your product and what the roadmap is to fix certain things. That is also a very good point that I find.
Why is it necessary for an organization’s business strategy to include software testers early in the software development process?
That is another great one. I write about this in my book quite in depth actually. The most important thing is to find issues before they're in the code. It is the old theoretical practices that are taught to a lot of software testers in the international standards. Basically, from doing that - talking to business, looking at requirements, looking at user stories, looking at the design of the software itself and how you're doing that in agile - when you find issues, it costs a lot less to fix them at that stage.
For instance, it's four times more to fix a defect at the design phase, about eight to nine times at the actual software testing phase, and then at production it could be extremely higher costs and impact to fix that. It is important to lower your cost and your risk profile by testing as early as possible. I actually encourage people to be involved in business use cases and business cases as well. I have been in organizations where I've been invited to review business cases because I can bring insight from other companies I've worked at into that discussion and see if the idea is realistic and if it can be achieved.
I would agree with that. I think that it comes back to a question of mindset.
Michael, why is this collaboration between IT and business key to a successful product?
The most important thing is, from my experience, when I've worked with telecommunication companies is that sometimes businesses don't know what they want, but IT have to deliver it anyway. I have been in that situation many times. It is the people side of things and the collaboration that's involved. It is important of IT that people do challenge the business and the business challenge IT. By having that challenge, you can fine tune things up front and, by what we said before around finding defects early in the test cycles, design phases or in business cases, will find issues in doing that.
Now, in traditional and old-school practices, IT comes later on after the business side has done all sorts of planning by themselves in isolation. For me, it's very important that we're involved in that phase even if they're doing some scoping in a room by themselves. It is important to have some form of sounding board of IT representation in there. That is what's good about agile - we have that up-front discussion.
Ray, have you ever been involved where the collaboration between the IT and business segment of an organization has really not been what it should be and has led to some sort of fallout?
Yeah, I've definitely seen that. The issue is that, and this depends on where in the industry you're coming from, if you're a vendor you're going to see one version of this. If you're an internal IT or business person, you're going to see different versions of this. It's all the same basic problem. IT typically likes to control all IT, of course, because they do that as their job. What happens especially with cloud-based technology is business people are able to own that technology without necessarily going through IT. A lot of times they're completely running around IT because that's a much more bureaucratic decision, creating ongoing contention.
Stay tuned for part two of our interview with Michael Hamilton and Ray Grieselhuber. We’ll discuss what C-level executives can do to help themselves better understand the importance of software testing, how IT can do a better job of keeping testing non-technical and relatable, and how to best approach this organizational change for optimal performance.