Skip to content ↓ | Skip to navigation ↓

Over the summer, I celebrated six years of working at Tripwire and I retrospected on how the Engineering department has evolved since I joined the company.

I was originally hired as a Java developer at Tripwire and one of the things that originally attracted me to the company was the maturity of its engineering practices. The source code was well-tested, all code underwent peer review, and people felt personally accountable for the quality of the products they delivered.

After I had a couple of releases of Tripwire Enterprise under my belt, I was convinced that Tripwire R&D knew how to build software right. But I didn’t know whether or not we were building the right software for our customers.

What did our customers think of the new features that we released? Were we improving the lives of our users?

I wasn’t the only person in R&D who wanted to better understand our customers and the kinds of problems they face. Over the last couple of years, Tripwire R&D has applied a number of techniques from Agile Software Development to ensure that the software we deliver delights our customers.

The most impactful change has come from defining new roles within the R&D department. Tripwire R&D has always had top-notch developers and testers who are experts at modeling data, optimizing database queries, building cross-browser web interfaces, and finding ingenious ways to break our software before our users see it.

But we realized that we also needed experts at getting inside the minds of our customers and defining products that would meet their demands.

We identified Product Owners who are responsible for understanding our customers’ needs, prioritizing the features to be implemented, and making sure that Tripwire R&D delivers the functionality that is right for our users.

Gathering information about our customers and crafting features that will meet their needs is an art and discipline in and to itself. Led by our then-new Vice President of R&D, we established a User Experience Design (UX) discipline.

Our UX Designers work hand-in-hand with Product Owners from the inception of a project through its final delivery to learn about our customers, design how the user interacts with our products, and validate that the features that we build exceeds the expectations of our customers.

UX has fundamentally changed they way that Tripwire approaches software development. When we release a new feature or product, we don’t need to guess whether or not we’ve built the right “it”. We are confident that we’ve delivered something that will delight our customers because our UX Designers have gather feedback from our customers throughout the development cycle. Product Owners then take that feedback and integrates it back into the product plan.

At Tripwire, it takes a Team to build products that delight our customers. Product Owners, User Experience Designers, Developers, and Testers work together every day as part of a cross-functional Team. Team Members sit together and continuously collaborate to build the functionality our customers need.

The Team develops new functionality in increments that we review with members of our Professional Services and Support department every couple of weeks. Based on the feedback that the Team gets at these review sessions, the Team adjusts its plan and implementation to better align with the needs our customers. Many of our Teams apply tools and techniques from the popular Scrum methodology.

While the Team delivers the product, it’s the job of the Scrum Master (that’s what I do now!) to deliver the Team. The Scrum Master works with the Team to identify and resolve impediments to it being awesome. The Scrum Master facilitates brief, daily discussion of what the Team is working on and works with the Team at the end of every development iteration to identify areas in which the Team can improve.

I really enjoy the role because it allows me build an environment in which our Teams can be awesome every day so that they can deliver products that delight our customers.


Related Articles:


P.S. Have you met John Powers, supernatural CISO?


Title image courtesy of ShutterStock

10 Ways Tripwire Outperforms Other Cybersecurity Solutions
  • In contrast to traditional development methods, the Scrum demands changes not only in development, but also in other parts of the enterprise. The interfaces of the Scrum Team to the rest of the enterprise are embodied in the roles of “Product Owner” and “Scrum Master” which are new with Scrum. While the Scrum Master is supposed to shield off the Development Team from the outside world, the Product Owner is supposed to represent the outside world within the Scrum Team. Since the Product Owner is an individual, not a group or a committee, this is a daunting task. Practical experiences and reports in Scrum-related blogs show that these requirements of the Product Owner are quite often not fulfilled.

  • I completely agree with you David. Viewing the customers end point usage is always the best way to evaluate and gain a better insight into whether the product or service is selling its sole purpose. Whilst having a great technical team and a group of developers the end users view point will define the efficiency of service. The Scrum Master methodology is a great technique to reach common goals in a fundamental exciting way.

  • Noah

    A nice article afterall.

    It is however ‘always’ an important factor to keep end-users in mind while developing any software product.

  • Denari

    Agile software products are indeed a need of time and I only wish there was a software product for online fundraising management.

  • Jenny

    Agile software products are the best user friend interface software products.

  • Ion

    Agile Software products really delight customers.

  • Patrick

    The problem with software development is that it never stops and keeps on advancing. Not that it’s a bad thing, but people should stay ahead of the game and must always ensure to focus customer requirements while developing software.

  • marcelv91

    I agree with Patrick, software is an ongoing thing. I`m currently working as developer for invoicing software company in the Netherlands and it keeps going on ( The hardest part for me is to think like the customer. That`s why we are using Agile methodologies, more traditional methodologies don`t leave that much space for input while developing. I like to build a complete software system, brick by brick, thinking not too far ahead and certainly not designing the whole system in advance, without having tested smaller bits in practice..

  • Absolutely thinking as the end user would bring in great results in software development also right from the phase I of initialisation of requirements gathering developer thinks about the end user, product will be 80% out of reprocess.

<!-- -->