InRhythm

Your partners in accelerated digital transformation

Gunjan Doshi

The Future of DevOps: InRhythm’s Learning and Growth Newsletter

One of the driving forces behind our 10X growth methodology is DevOps. Its transformative ability to empower high-velocity delivery makes its principles highly sought after and top of mind for anyone in the software development space. But where is the future of DevOps? The open source movement has made several robust tools available to everyone; some of the latest—like Lighthouse from Google—paint a promising picture of the future, optimizing several crucial functions in the development process.

This week’s theme is all about the current (and future) state of DevOps. Whether you’re actively involved in the field or know someone who is, the rise of free tools and automated functionality is a thought-provoking topic that, like much of our industry, is being revolutionized and retooled by cloud functionality. William Bratches offers his take on Lighthouse, and our engineering team shares what we’re reading now. This is an exciting time to be in the industry as roles change and whole subject matter areas get retooled. I encourage you to be a part of the discussion on social media @GetInRhythm and on our InRhythmU blog.

Thanks and Keep Growing,

Gunjan Doshi
CEO, InRhythm


Lighthouse: The Coolest Tool You’re Not Using InRhythm.com
“Lighthouse is an open-source, automated tool for improving the performance and quality of your web apps. Lighthouse analyzes websites for performance, SEO, accessibility, progressiveness, and other best practices. In this article, InRhythm’s Will Bratches walks you through this exciting new tool.”

The Future of Ops Brave New Geek
“Should Dev/Ops capabilities be embedded within development teams? Must *every* engineer know their way around automated testing and container management? Some provocative thoughts on these issues that reward close reading.”

Cypress Cypress.io
“Some people enjoy using Selenium to conduct End-To-End testing. Others believe Selenium should be burned with fire and salted. If you’re in the second camp you might be interested in Cypress, a new and exciting E2E testing tool. Finally, testing has evolved.”

Mastering Chaos – A Netflix Guide to Microservices InfoQ
“Netflix is known as a thought leader when it comes to building scalable, resilient systems. Here, engineering leader Josh Evans goes deep on how Netflix manages distributed microservices. Chaos Monkey’s everywhere in one of the best tech talks of all time.”

Jenkins: Shifting Gears Jenkins
“Jenkins is a favorite workhorse of the SDET set. But its wrinkles are showing. The creator of Jenkins Kohsuke Kawaguchi presents the past, present, and future of his creation. He wants to ‘insert a jolt in Jenkins’ in the form of Kubernetes, cloud-native deployments, and more.”

Inside Look at Modern Web Broswer Google Developers
“In this series professional drawsplainer Mariko Kosaka breaks down for us almost everything you need to know about how browsers work, how the web works, and really, how you work. You can’t debug (or test) what you don’t understand. Maybe the best series you’ll ever read in a browser on the browser.”

Traits of True 10x Engineering Leaders

Last week, we hosted 20+ leaders of engineering teams for our first event in our new innovation center, 10x Engineering Manager Bootcamp. The need for this workshop came from witnessing how complex it can be to manage engineering teams in agile environments. It’s designed to enable leaders within an organization to lead their teams more efficiently by identifying common obstacles and equipping them with best practices to enable a stronger team. Some of the larger takeaways include thoughts on mindset, time management, people management styles, hiring, and learning and growth.

One of the most well-received takeaways was around the traits of a true 10x Engineering leader. In summary:

10x Engineering Leaders have a high-velocity, high-impact mindset

For 10x engineering leaders, the number one goal is to get results. Great talent with expertise in modern technologies is crucial, but it means nothing if a team does not execute efficiently. Agile teams are supposed to be ‘self-managed’, but the burning question is still “what is your team’s impact”? Enterprises run on results. On the backend, leaders must swiftly navigate many conflicting forces and learning to accept that you can’t please everyone. At the end of the day, teams are measured by ability to get results, attract and retain talent and staying relevant, and massive action with a high sense of urgency always wins.

10x Engineering leaders take complete ownership of priority 1s

Enterprise software development is constantly VUCA (Volatile, Uncertain, Complex, Ambiguous) and it can be easy to get lost in the day-to-day. 10x leaders remain aware of priority 1s and before the day is over, they make sure to spend time working on them. They create maniacal focus to maintain momentum.

10x Engineering leaders practice the art of communicating, delegating and negotiating

Most 10x engineering leaders are very good at communicating upwards, downwards and across. This is imperative, because delegating and negotiating are extremely challenging without strong communication skills. These three areas can be detrimental to a team if they are not done properly. Put mechanisms in place to ensure your team can operate independently and hold your team accountable.

10x Engineering leaders know people management should exceed project management by 4:1

People management is grooming and growing your people so that they can do their jobs better. 10x leaders become masters of growth, coaching and inspiring intrinsic motivation. They spend time leading their teams and enabling them to better support the organization and they remember to feed the winners. Being able to identify and invest in the stronger members of your team, versus the weaker, is an invaluable lesson. Giving a “winner” your time will result in 10X returns, as time is your most valuable currency. Giving that same time to a lower-performer may not return dividends.

10x Engineering leaders stay relevant and own technical debt

Technical debt is not something you can pass from technical teams to the product team, or any other part of an organization. 10x leaders spend time addressing the problems and focus on creating solutions to reduce this debt today and in the future.

10x Engineering leaders are cultural catalysts

Culture may start from the top, but 10x leaders are true engines of the company. Their focus ensures they do not get fall into the trap of the victim mindset or solely taking orders from above. These leaders understand the culture and have the unique power to solicit change from the organization.

Watch for more key learnings coming out of this powerful session soon!

Top 7 Problems Experienced Agile Teams Still Face

If you’ve been practicing agile for years now, you’ve probably hit a few roadblocks along the way. Here are a few red flags to recognize before you get slowed down:

 

Problem 1: Not understanding your customers and not knowing your impact.

Our software creates real impact for our customers. If you aren’t able to articulate who your customers are and what impact means to them, or you don’t have a way of measuring impact, that’s a huge red flag!

 

Problem 2: Having the struggle to launch at a faster pace.

The overall confidence in our team’s capability to deliver high-quality software faster increases every quarter. The absolute purpose of agile is to respond to market faster. If after years of practicing agile you are not able to release faster but just plan faster, you will run into a few problems.

 

Problem 3: Drowning in technical debt.

At the beginning of every quarter, the quality and integrity of the code has improved and technical debt has gone down. You may have inherited a legacy platform or you may have other valid reasons. However, if you are not able to pay back technical debt your ability to be really agile is going diminish fast and that is a problem!

 

Problem 4: Your Product, UX, and QA teams are reactive vs. proactive.

This is a frequent problem. For QA, it is the lack of automation and for Product & UX, it is the lack of time and preparation. Your Product, UX, and QA teams should be thinking and acting ahead of your engineering teams by at least two sprints  – if this isn’t happening you might want to take a closer look and address it!  

 

Problem 5: Not having time to focus on coding

Except for planning or demo days, programmers should be spending a minimum of 4-5 uninterrupted hours coding on what really matters. It may not seem like a lot to ask, but if you can create the time and space for this kind of focus for your programmers, then you’ll be a lot better off! On average I see programmers coding 2–3 hours max per day, which just simply isn’t enough. Collaboration can turn into annoyance if programmers aren’t able to focus on developing amazing code.

 

Problem 6: Not looking at sprints as a high impact priority.

Sprints are so much more than completing a backlog of tasks – they’re about execution and having a direct impact. Many of the teams we see get into a boring routine of just finishing tasks and stories – this is the definition of busy work. If you don’t keep the impact in mind, you’ll fall prey to this, too!

 

Problem 7: Not making sprint demos a priority in your agile teams.

Sprint demos sometimes don’t get the attention they deserve – they should be well-attended and feel like celebrations! I can’t stress this enough. If you are in for the long haul on whatever it is you’re developing, making a big deal of demos is key for boosting morale and energy. If leadership teams and stakeholders don’t make demos a priority, oftentimes teams don’t get the feedback they need, and they can begin to feel deflated and under-appreciated. Big problem!

 

At InRhythm, we focus on creating high performance agile teams  – effectively, efficiently, and strategically. It has become a key component in what we aim to provide, high velocity product development.