InRhythm

Your partners in accelerated digital transformation

Agile & Lean

When To Implement Pair Programming

Overview

No alt text provided for this image

A vast number of companies embrace pair programming as a way to increase programmer productivity (loosely defined as delivering “value” which can have many forms, but is generally interpreted as writing more code per day), but is it really that great? wondered why we should pair program and when is the right time to embrace it as a strategy.

Pair programming, as understand by the software community, came into popular culture as a facet of XP (extreme programming), a development framework that enforces practices that generally improve software quality and responsiveness. The idea is a new incarnation of the old adage: “two minds are better than one.”

Either way, the idea is right – two people have different histories, cultures, and experiences, so for those reasons they think about things in different ways. When two people work on a problem together they almost always come out with a better solution than a solo venture.

So how does this relate to programming?

The Positives

No alt text provided for this image

Pair Programming Does Reduce Bugs

The primary driver for pair programming is to increase quality and decrease bugs. When done well, it does that spectacularly. One study found that pairing reduced bugs in production by 15%!

Pairing Does Increase Code Quality

Many of the benefits of pair programming are not actually technical: they’re social. When working with a peer, it’s normal to feel encouraged to do one’s best, ensuring the coding is clean and avoiding any technical debt that they’ll “fix later.” 

When pairing, one tends to do things just a little bit cleaner, making algorithms easier to read and naming variables more sensibly. A Software Team will actually write unit tests to 100% coverage! With two sets of eyes, the quality is always higher.

The Variables To Keep In Mind

No alt text provided for this image

Pair Programming Does Not Entirely Eliminate Bugs

As much as one would love for pairing to just eliminate all bugs, it’s just not the reality. Bugs still happen. There are generally a lot fewer of them, but perfect code would require perfect programmers.

Pair Programming Does Not Fix Poor Product Direction

Good projects need very strong product direction. And to be clear, the responsibility for this direction is on everyone, not just “product people.” It begins with asking questions and making informed decisions about work to be done. Then the team needs to thoroughly discuss the work, breaking it down as much as possible to understand the full scope. If this isn’t done properly, deadlines are missed, everyone is stressed, work that should take minutes take days… Pair programming can’t fix that. Nothing is more important than good product direction.

Pair Programming Needs To Be Done Right To Mean Anything

Pair programming is a tool meant to help make a difficult problem more digestible.

Pair programming, when done correctly, generally means one person is writing code and the other is directing the work. Directing in this case means providing feedback about best practices and constructive criticism. It also means researching those best practices when one doesn’t know them off the top of their head and taking the time to think deeply about possible edge cases and hangups relevant to the work at hand.

Pairs should communicate thoroughly, share all relevant information about their work, and swap duties as often as possible. It’s taxing to think about problems in both a creative and technical way, so it’s better to distribute that work. That’s one big reason that pair programming is such an effective tool.

When To Implement Pair Programming

No alt text provided for this image

Pair Program When There Is A Very Difficult Problem At Hand

If you have a problem that cannot reasonably be broken down into smaller parts, it should be met by multiple programmers.

An 8-point story should generally never exist in an organization if doing normal web work. Features can almost always be broken down into “front-end” and “back-end” stories. Whole-page mockups can be broken down into component parts. Design and QA phases can also be separated out into their own stories. But a really tough problem is just a really tough problem.

Trying to add a new feature to a language is a really tough problem. Trying to figure out how to reduce the latency on database calls is a really tough problem. These are examples of problems that require both creative and technical thinking.

Pair Program When Two Programmers Are At Completely Different Skill Levels

Pair programming is a remarkably good way to teach junior programmers. Getting to participate live while a more senior programmer talks about how and why they’re doing something is ab invaluable experience. So is writing code while a more senior programmer coerces better practices on the fly.

Pair Program When Two Programmers Have Completely Different Skill Sets

Having two programmers with complementary skill sets can be very rewarding for both the programmers and the codebase. Pairing programmers who generally only work front-end or back-end can get an end-to-end feature out the door, or a Postgres expert pairing with a Scala expert to make a database call more efficient.

When two programmers work together live, they absorb a lot of knowledge about each other’s domain and ensure there’s no aspect of the project that’s neglected.

Pair Program When Both Programmers Are New To A Language/Framework

Sometimes a situation arises where nobody is an expert. This is an excellent learning and growth opportunity! 

A project will end up with two programmers working through a difficult problem and contributing their individual skills to build a better product, helping each other learn, and with a redundancy in the skill growth of programmers. This is important because the skills in within an organization should never be concentrated in one person. Having programmers pair on new languages and/or frameworks ensures that there are a minimum of two people who can work on this in the future.

Closing Thoughts

No alt text provided for this image

The best way to approach pairing is to partner two programmers and have them share a computer. Make them work together to architect, code, and then test their codes in a genuine sense of a partnership. While the ideal setup would include two programmers who are equally skilled (expert – expert or novice – novice), you can also use pair programming for training and educational purposes (expert – novice).

The pair should be able to decide how to split the work, and it is advisable that they should switch roles often.

What Does Your Innovation Timetable Look Like?

Overview

Innovation is at the heart of almost every business. Companies that can innovate quickly and frequently have significant competitive advantages, easily attract top talent, and provide excellent customer experiences.

However, this is easier said than done. Although most organizations agree that being able to innovate is the key factor that will help them stand apart from the crowd, there are substantial roadblocks to achieving simple advances. 

So… How do top companies innovate rapidly?

They understand a few core principles:

1. Time Is Money

Companies are often sidelined by a standard argument:

“We don’t have the budget right now.”

Innovative companies understand that every minute you wait to implement new ideas, even more dollars are left on the table. The balance of opportunity, cost, and wins is a relevant act, that requires a substantial amount of careful and calculated attention and execution.

2. Looks Are Everything

A heavy focus on UX Design and usability are key components to highly advanced companies.

Rapid iterations on design and function are a pertinent response to customer needs, setting advanced companies on a fast track to favorable brand image and reputation.

3. Right Resource Allocation Goes A Long Way

Introducing new products and features regularly can be taxing on an existing team, and the best people to get the job done may need to be added.

Companies that know how and when to implement talent can successfully curve innovation quickly. From experts in modern frameworks to responsive web, experience is key to get the job done.

4. There’s No Room For Reactive Planning

Upcoming initiatives often have a way of creeping up on companies.

There are typically foundational tasks that need to be taken care of prior to kick-off and resources need to be lined up, in place, and ready to roll when the green light is lit. To circumvent reactive planning, top companies partner with experts to help them tackle foundation tasks, line up the right tools and resources, and plan for big projects.

How and how often companies innovate is a defining metric to consumers – to both meet and exceed customer expectations.

Closing Thoughts

Allotting time for innovation allows organizations to get ahead.

If you concentrate all your energy on operating within the status quo, someone who has learned to set aside time for innovation is going to come along and define the space while you were busy maintaining your current process.

The number one thing you can do to propel your organization forward is to give innovation a leading piece.

Creating Robust Test Automation For Microservices

Overview

No alt text provided for this image

Any and all projects that a software engineer joins will come in one of two forms: greenfield or legacy codebases. In the majority of cases, projects will fall into the realm of legacy repositories. As a software engineer, it is their responsibility to be able to strategically navigate their way through either type of project by looking objectively at the opportunities to improve the code base, lower the cognitive load for software engineering, and make a determination to advise on better design strategies.

But, chances are, there is a problem. Before architecture or design refactors can be taken its best to take a pulse on the health of a platform End to End (E2E). The reason being, lurking in a new or existing platform is likely a common ailment of a modern microservices approach – the inability to test the platform E2E across microservices that are, by design, commonly engineered by different teams over time.

Revitalizing Legacy Systems

No alt text provided for this image

One primary challenge faced by a number of software engineers, is the adaptive work on a greenfield platform that has fallen several months behind from a quality assurance perspective. It becomes no longer possible for QA to catch up, nor was it possible for QA to engineer and execute E2E testing to complete common user journeys throughout the enterprise system.

To solve this conundrum, E2E data generation tools need to be created so that the QA team can keep upbuilding and testing every scenario and edge case.

There are three main requirements for an E2E account and data generation tool.

The tool should:

1) Create test accounts with mock data for each microservice

2) Link those accounts between up and downs stream microservices

3) Provide easy to access APIs that are self-documenting 

Using a tool like Swagger, QA can use the API description for REST API, i.e. OpenAPI Specification (formerly Swagger Specification) to view the available endpoints and operations to create accounts, generate test data, authenticate, authorize and “connect the microservices.”

No alt text provided for this image

Closing Thoughts

By creating tools for E2E testing, a QA team was able to eliminate the hassle of trying to figure out which upstream and downstream microservices needed to be called to ensure that the required accounts and data were available and set up properly to ensure a successful test of all scenarios i.e. based upon the variety of different data types, user permissions, user information, and covering the negative test cases. The QA team was able to catch up and write their entire suite of test scenarios generating the matching accounts and data to satisfy those requirements. The net result of having built an E2E test generation tool was automated tests could be produced exponentially quicker and the tests themselves are more resilient to failure. 

Even though the microservices pattern continues to gain traction, developing E2E testing tools that generate accounts and test data across an enterprise platform will likely still remain a pain point.

There’s no better way to maintain a healthy system than to ensure accounts and data in the lower environments actually work and unblock testing end-to-end. 

Letting Go of the Formality

It wasn’t that long ago that suits, ties, knee-length skirts, heels and pantyhose were required wardrobe staples. In fact, many enterprise Fortune 100s upheld a formal dress code as part of their HR Policy Handbooks. Goldman Sachs, the last bastion of formality on Wall Street, finally relaxed its dress code and offered a “flexible style” option. They only did so last year. Their updated policy permitted men to choose garments other than suits. Admittedly, this made things more complicated for women but that’s a topic for another blog.

Since we’re agile practitioners here at InRhythm, it made sense to look at our own approaches to talent and acquisition. Not to mention retention. Practices and policies drive corporate culture. Here, Agile Platinum Principle One: resist formality, must serve as one of the pillars of our talent strategy.

If your company doesn’t offer a culture that’s aligned with the needs and expectations of today’s job seekers, then, as Hiring Manager or Chief People Officer, you’re going to have a really hard time. At best, you’re going to struggle and slog through your days and recruiting campaigns. At worst, you’re not going to have any people to serve as Chief over!

The link between informality and tech

Ask anyone within the technology field, or external to it, to describe or draw a person in tech, be it a software developer or a startup founder. The universal response is a male, typically Caucasian, dressed in sloppy jeans and a hoodie. Where did this level of informality originate?

Many would cite Lou Gerstner’s (former CEO of IBM) decision to roll out “casual dress.” Even the New York Times balked with a headline that read, “Black Jeans Invade Big Blue.” Shortly thereafter, Hewlett Packard (HP) introduced “Blue Sky Days” which permitted employees to wear jeans to work on Fridays. From there, dress code devolved or evolved – it depends on your perspective – into what we see today.

However, the Platinum Principal of resisting formality is not restricted to dress code. It extends into everything that we do. Formality also has implications with unconscious bias, how we greet and interact with people, the forms that we require candidates to complete and so on. Tone and style go hand in hand.

How are we resisting formality?

We are constantly taking steps to increase our awareness and connection with our prospective employees, candidates, contractors, staff and employees. Efforts are made to understand what they need so that we can craft our talent, acquisition and retention strategies around their needs and expectations versus requiring that they conform to ours. Here, we have embraced an agile culture across the company, not just in our product development efforts.

As agile craftsmen, with respect to HR recruiting and retention strategies, we have adopted an approach that is more responsive than it is prescriptive. Our applications are deliberately designed with brevity in mind to expedite the hiring process. We measure how long it takes from the time that an application is submitted to an open job posting until someone is seated in the role. A conscientious effort, with monitoring, is made to ensure that we are constantly moving our candidates through the hiring process as swiftly as they seek to do so.

Another way that may come as a bit of a surprise is the effort we make to create a relaxed culture that allows for flexibility and downtime. We understand the enormous pressure and stress that our employees feel as they do all that they can to deliver on our clients’ needs. It’s okay to push through a couple of scrums or back-to-back sprints but it’s not sustainable. Over the holidays, we relaxed with an in-house office party and gave people some bonus time. This week is Valentine’s Day: celebrate it or not, you don’t need to make it about sending flowers and chocolates to your partner. Use it as a reminder to resist formality, take some time and reach out to whomever it is that you care about, be it a parent or sibling or a friend.

Resist formality! Make strides to emulate the people and culture around you. Forcing people into a process defined by its rigor and inflexibility is the antithesis of what a company should do. Particularly a company who’s purpose is to bring agile methodologies and success to our clients.

Stu Weiser,

Director of Talent Acquisition
Image created by katemangostar – www.freepik.com

Unleashing The Potential Of Your Offsite Team

Thriving vs Surviving

Are You Unleashing Your Team’s Potential? Or, are you an engineering Practice Lead or Manager who’s unconsciously capping your team’s potential? While there may be the odd diabolical leader who intents on deliberately holding his or her team back, I like to think that doing so is not the norm. Leaders of agile craftsmen want their teams to flourish and fly through each sprint. Doing so will require creating an environment and work culture that fosters improvement and unleashes a team’s potential.

With a new year and decade here upon us, the idea of making resolutions to catalyze changes isn’t new. It’s a centuries-old tradition that has begun to fall out of favor. Given that < 8%  of us make it through the year, performance and motivation coaches suggest that we set goals for the year instead of resolutions. By setting a goal, we know which direction we’re headed for and it allows us to “slip back” or go off-course occasionally yet still track towards the goal unlike resolutions, which do not offer the same latitude. 

Here at InRhythm, we’re looking forward to achieving continued success in 2020. With increased efforts to build and empower our 10x teams and to better enable our clients, we have set several key goals for the year ahead.

2020 Goals

  1. Continue to put our customers first and make every effort towards 100% customer satisfaction
  2. Foster a culture that truly embodies the Agile Manifesto
  3. Grow our footprint in new markets and industries 

As the Practice Lead , I’m conscious of how well my team is performing and how the toll of being onsite at clients’ workspaces affects them. I’m also aware that I need to give the team space to work together on a sprint and to figure things out on their own. When they hit an obstacle or begin struggling with forward progress, that’s the time to jump in. Until then, leaders must encourage their teams to experiment and err, support them, and back them when the choices they’ve made may not be the ones anticipated by their employer but they’re exactly the right ones needed for the client.

In addition to giving your team some latitude and space so that they can creatively solve problems without you helicoptering over them, you also need to think about giving them recognition. Of course, nobody wants to celebrate repeated failure, but, if a software developer made an informed decision to try to do something in a new way and everyone could extract lessons learned from that effort, then s/he/they should be celebrated for making a bold move and trying to do something different. It should go without saying that the successes also need to be celebrated. Recognition motivates teams to try harder.

Efforts in the opposite direction will have – no surprise – the opposite effect. For example, a lack of recognition for doing well or finger-pointing when there is an error will demotivate teams and start to put restraints on their ability (and desire) to flourish. Powering up 10x teams requires motivation and support so that members can dig deep and unlock their potential. Motivation should be a weekly or monthly focus and not reserved for the one day each year when companies formally recognize their employees, clients or management team. 

Here at InRhythm, we’re encouraging more dialogue between members and practice leaders and added the role of a liaison designed to facilitate open and honest discussion. We’re creating a culture where it’s safe to respectfully voice an opinion and to try new things that could make a difference for our clients. It’s also about accountability. If a team member come forward and voices a concern or a need that does not get addressed with an effort towards closed-loop communication, that member’s potential becomes thwarted. 

Have you made 2020 all about your team’s potential? Are you subconsciously thwarting it or actively boosting it? Be the practice leader that helps teams thrive – not just survive.