Planview Blog

Your path to business agility

Engineering Teams, Enterprise Agile Planning

What Fuels Your Engineering Process?

Published By Brandon White

team-1028829_640I’m a new Tasktopian but not new to the software trade, having spent 15 years as a software engineer at both small and large companies here in Vancouver. Last Friday marked my fourth week at Tasktop and I felt inspired to share my initial impressions.

Culture is all too often underappreciated but I consider it a key component of sustained organizational success. A healthy, transparent culture that empowers and trusts its employees is a core ingredient of good engineering processes because employees will take pride in their work and expect the same of others.

Tasktop understands how important (and intertwined) culture and sound software engineering processes are to sustaining their own success.

  • I felt welcome from the moment I arrived. During my first two weeks, I met virtually everyone in the Vancouver office and many remote employees through Skype or GoToMeeting. That included face time with each member of the leadership team where I was invited to ask them questions and learn about their roles within the organization. There have also been plenty of opportunities to get to know my new co-workers with a special nod to Happy Hour Fridays.
  • Information doesn’t live in silos. Sales, marketing, operations, product and engineering data is accessible to all employees with few exceptions. Want to know about the Fiscal Year 2016 strategic plan? It’s on the wiki. Want notifications on all high priority customer escalations? Join the associating Slack channel.
  • Remote team members are first-class citizens at Tasktop. When I started here, I was initially concerned about joining an implementation team in Vancouver with a Product Owner in the U.S. and a Team Lead in Europe but our tooling and processes have made coordination so seamless as to be a non-issue.
  • Tasktop channels the Kaizen principle of continuous improvement better than any other organization I’ve been involved with. There are numerous examples of this principle at work within the engineering teams and employees are rewarded for their efforts. At my first all-hands meeting, one of our senior engineers received an award from the CEO for his efforts to improve the efficiency and stability of our test automation. That level of recognition can’t help but inspire others to look for further improvements.

A strong culture forms the backbone of a productive and motivated team and this team has introduced and refined the most rigorous, quality-focused engineering processes that I’ve ever seen. It was immediately obvious, well before I pushed my first commit to Gerrit, that the engineering staff and management cared about not only what features were delivered but how those features were constructed:

  • The Integration Factory is an awe-inspiring concrete example of continuous improvement in action. It evolved over a number of years and continues to receive enhancements as the engineering teams seek new ways of optimizing the construction, maintenance, and testing of ALM, ITSM, RM, PPM, and other integrations.
  • At previous companies I’ve worked at, test automation mattered but it was generally considered a second-class citizen to feature development. If feature development fell behind, it was common to cut or scale back automated testing tasks. That is antithetical to Tasktop’s culture where automated testing – and in particular test-driven development – is a central pillar of their engineering process. On my third day here, I ran the TCK test suite against one of the connectors our team supports. My jaw dropped when over 18,000 tests started executing. The best part: all of them passed.
  • Every Gerrit review I’ve observed receives extensive feedback and generally requires multiple patchsets before a +2 vote is granted. Careful consideration is given to the logic, testability, style, and maintainability of the changes. In addition to a +2 vote from a code reviewer, any Gerrit commit must also obtain a +1 vote from a continuous integration build before the commit can be submitted. Creating a new Gerrit review or pushing a new patchset triggers a Jenkins job that builds the connector and executes its suite of unit, component and integration tests.
  • Engineering teams budget time during a sprint for continuous improvement tasks such as paying down technical debt or enhancing test automation. In fact, one of my initial tasks during the last sprint was to enable some performance and reliability tests for one of our ALM connectors. I know from past experience that it can be difficult to justify internal engineering tasks given the plethora of customer-facing requirements that tend to dominate a team’s backlog. The engineering teams, via good communication with the product owner and management, have been able to strike a balance that prevents perpetual postponement of internal improvement tasks.
  • Bugs inevitably slip into releases but the solutions and engineering teams coordinate very effectively to troubleshoot and resolve customer escalations. Beyond generating a Service Release build with the fix, engineering teams often try to create new automated test cases to prevent similar problems in the future. During retrospectives, defects resolved in the past sprint are analyzed to determine whether and how those bugs could have been avoided in the first place.

Tasktop’s transparent culture of continuous improvement is the indispensable fuel powering a high-performance engineering machine. Interested in working at Tasktop? View current openings on our careers page.

Related Posts

Written by Brandon White