DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Release Is Both a Noun and a Verb

Release Is Both a Noun and a Verb

Enterprise technologists confuse the fact that the word release is both a noun and a verb.

Jonathan Harding user avatar by
Jonathan Harding
·
Apr. 30, 19 · Analysis
Like (3)
Save
Tweet
Share
4.64K Views

Join the DZone community and get the full member experience.

Join For Free

Recently, I attended a well run gathering of Banking and Finance technology professionals at Charlotte’s Packard Place incubator. PayCLT is a great organization which has a mission of bolstering the network and knowledge of Charlotte’s payments technology professional community and they’ve been doing it well for over five years.

The speaker for this session was Doug Hartsema, a founding partner of The Hartsema Group, a small consulting company that specializes in formulating customer advisory councils for large financial customers, such as commercial banks. These commercial customers have an ingrained business interest and are usually CFOs or payment executives from medium-size through large corporate customers. They rely on the banks for business to business payments, treasury services, and other wholesale banking processes that are critical to their daily operations.

In order to drive the discussion, Doug brought some interesting quotes and anecdotes from these sessions that will probably ring true to many banking and finance technology professionals:

“The implementation of the change seems more important than the change itself.”

“Easy gets done. Hard gets deferred.”

“Please don’t ever make me tell you your systems are down.”

My personal favorite, “Banks think implementation is complete when the service is set up. The implementation isn’t complete until I’ve received the value of the service.”

With the current book on my nightstand, “Project to Product” by Mik Kirsten, this quote also reminds me of something that roots back to the Banking industries over-reliance on the project management methodology and heavily siloed organizations, “Don’t confuse the fact that the word release is both a noun and a verb.”

Next to keeping production systems operating, managed IT change is ever present in corporate IT. In their daily activities, technology teams rally around and obsess over the activities, budgets, and risks related to planned technology change (and the hue of red, yellow, or green associated). These planned IT changes are managed like a project with start and end dates, people and technology resources, managed risks, an allocated budget, and perhaps most detrimentally, a stringent change control process. IT teams often wholly focus on the visible details that seem to indicate readiness for production traffic, while often completely losing sight of the business value contained within the features that make up the release itself. IT teams are obsessed with the verb-ness of a software release, and completely miss what matters to customers, the value within that collection of features and fixes making up the release. This is the noun-ness of the word release, and contains the important business value that should directly correlate to your teams reason for existence.

Overly siloed organizations, such as release management or infrastructure teams, often have no visibility or appreciation for the actual collection of features in the release. These features are designed to better serve internal employees or external customers, and it requires empathy to ensure this business value is understood. Focus on the business value of the product must be present in all work surrounding this change. There is a lack of awareness for the noun-ness of the release, the collection of valuable features meant to serve internal and external customers by solving a business problem, or improving a business process.

I’m reminded of the famous Winston Churchill quote, “Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.”

Here are 3 ways in which enterprise IT leaders can counter this pernicious phenomena:

Organize

Organized teams more tightly around the technology products they support, as is the core tenet of Dr. Kersten’s book, “Project to Product.” Use the tools of physical proximity, daily routines, and organizational hierarchy to enforce the product mindset.

Teams that sit together, work together, and play together share goals and team culture. Use the tool of physical proximity, which in some organizations can more quickly and easily be manipulated, to support your goals. If you have a critical team member that’s contributing a majority of their time each day to your product, insist they be seated near the product/feature teams. The closer the better, within space constraints. If it’s not at the same table, place them in a nearby room or floor. If not in the same building or city, at least get them in the same time zone!

Daily activities such as daily scrums, or other routines like staff meetings help form habits and build a positive culture. Individuals witnessing their teammates taking accountability to get work done on time and with quality build strong teams. If teams are not physically working together, if they rely on a virtual structure, or if they are not in the same organizational structure, you can use the tool of routines to help build a culture of accountability. Insist that team members critical to the end-to-end delivery of your technology product be present and engaged in these routines. As a leader, ensure you are regularly participating in these routines to enforce their importance and effectiveness.

For more virtualized teams, or those that may be reluctant to participating in routines, the reporting structure becomes critical. For team members contributing to your product, carefully consider who is setting day-to-day direction and defining team culture. The larger and more siloed the enterprise, the more challenging this may prove, but do not underestimate the value. Yes, release (verb) activities, risks, and budgets should be controlled with something that looks like a project, but it must be based on the foundation of the business value contained within your technology product.

Not every role type will benefit from this type of organization, but anyone who has the majority of their daily tasks supporting your products change activity deserve to be with (physically, virtually, or organizationally) team members rallied around the same business problem. Without this organization, overly siloed and specialized teams may benefit from a specialization of labor, but suffer from a lack of awareness of real business problems and mission.

Reward

Reward team members based on business results. Individual formal performance goals, regular coaching sessions, and incentive compensation must be tied to business results and need frequent reinforcement. For internal systems this may prove challenging, but seek a proxy metric that relates to revenue or cost. Ensure your team is rooted in this business value and maintains empathy for their users. As a leader, you must gear the foundation of your team to the value in your technology product and the changes and improvements contained within the software release(noun). When system change happens, it doesn’t end with the first customer transaction; as a leader, monitor the business results produced by your release (noun), and share them with your team constantly.

Rewarding and encouraging is a desirable leadership behavior, but it’s not terribly measurable beyond the binary fact of whether a manager exhibits these behaviors or not. For a much more scientific approach to measuring business value focus, see chapter 9 of “Project to Product.” This seminal work on transitioning enterprises to a product mindset clearly documents the different aspect of measuring the effectiveness of an organization’s focus on product-based value stream delivery.

Shout

Shout your business purpose from the rooftop, and radiate this mission to everyone touched by your team, even those not engaged on a daily basis. Promote internal usage of your software by your team and their friends and family if possible. Dog-fooding can be a great way to build empathy, and get quality feedback from those closest to the inner-workings of your product. Explain and share the business purpose of your technology product in multiple settings including staff meetings, town-halls, digital communication, or other opportunities to communicate widely with those supporting your team or even broadly within your enterprise. A network engineer who is physically and organizationally distant from your team deserves to appreciate the business problem they are helping to solve by enabling packets carrying your customer traffic.

I suspect you will find, as I have, that this focus on business value will lead to higher functioning teams. It will also make your team and your company a better and more desirable place to work as measured by employee net-promoter-score. Seeing teammates high-five not just when software goes out the door, but a few weeks later when the business results are made clear, may prove to be one of the most rewarding things you do. I know it was for me.

scrum Release (agency)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Writing a Modern HTTP(S) Tunnel in Rust
  • Why Open Source Is Much More Than Just a Free Tier
  • Why Does DevOps Recommend Shift-Left Testing Principles?
  • RabbitMQ vs. Memphis.dev

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: