InRhythm

Your partners in accelerated digital transformation

Culture

3 Themes of Thanksgiving to Apply Everyday

The Simple, Rapid Test That Every Agile Team Should be Doing

A couple of weeks ago, I shared some thoughts around the concept of leading a team of agile craftsmen and how all of us were practitioners in a living lab. Agile product development, by definition, requires that we fail fast, learn from our mistakes and develop processes that maximize efficiency. Agile values also require that we put the emphasis on people ahead of the process.


That sounds incongruous. How do you do both in parallel? It seems like it would be impossible to put people first yet adhere to the rigor required by following a process. However, there is a way. It’s called the Agile Litmus Test. Although there is no standardized template for it, the basic concept is that each team member thinks about why s/he/they is doing what they’re doing towards the goal of assessing whether or not the individual, team or corporate effort meets the values and principles as defined by the Agile Manifesto.

Many of you may recall the litmus test from your chemistry classes. The Litmus Test is a simple, low-tech, low-cost way of determining the pH (acidity) of a given solution. It’s been around for centuries and it’s still in use today both as a physical test as well as a metaphor for describing a quick method for testing out a concept. The fact that it’s been around so long illustrates how effective it is which, in turn, underscores the value of the Agile Litmus Test. One thing that surprised me is how search results returned for this test seem to drop off after 2015 – have agile developers lost sight of its importance?

Within the context of agile product development, the Agile Litmus Test is a rapid means of straddling the duality of putting people ahead of the process  (Agile Value #1) yet still adhering to it. There are several versions of what it should be, but there are only a few basic rules regarding the application of the Agile Litmus Test. In short, keep asking yourself if you’re doing the right thing. Given that we’re all agile craftsmen, we should be encouraged to use a little latitude to make the “rules” work for each of us given our own scenarios. At InRhythm, we apply it to meet our needs.

Quite simply, the Agile Litmus Test is the act of asking practical, meaningful questions to assess our priorities. Which questions you ask and which order you ask them in are not critical. What is critical is that you ask some flavor of these questions regarding everything that you do. It’s less about the rigor of the questions asked and more about accepting the personal responsibility of asking them. Whatever you’re doing, which includes posting on social media, writing content, coding, documenting, how you conduct yourself at a meeting and what you say there, etc. should all be subjected to the Agile Litmus Test. 

Consider questions along the following lines:

  • Why am I doing X this way?
  • How is doing X going to help me meet my goal(s)?
  • Should I be doing X right now?
  • Is there something else that I should be doing instead of X?
  • How will my team or project be impacted if I do X?

The idea is to self-assign a mental speedbump, not a big hurdle. You want that little bump to be big enough to get noticed but small enough to accelerate through. Take the time to pause and think about what you’re doing and why you’re doing it. Each of our actions as agile software engineers who are part of high velocity teams has consequences for us as individuals, as a team, as a client and as a vendor. We need to consider the bigger picture for all that we do and not gloss over our own accountability for using our time in a way that advances our personal and professional goals. 

In my years of experience onsite at clients and working with 10x teams, I’ve seen people get caught up in their own agendas. Somehow, they lose track of the bigger picture or their leaders have not communicated it effectively to them. Regardless of how or why it happened, they are not invested in how their efforts tie into the collective efforts of the project. So, you’re thinking, well, if one individual has lost sight of the vision and the shared end-goal, that’s probably not going to have an effect on the overall outcome. Or, if you’re that individual, you may be thinking the same thing. 

Not so, because there is rarely just one individual on an agile project that loses sight of the priorities. Typically, it’s more than one which can have dire consequences on hitting the milestones and timeline that only some people are tracking to. If you were to apply the Agile Litmus Test right now, what is the question that you ask yourself?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

16 Quick Poll – a Litmus Test for Agile Product Development
Scrum Breakfast
“I want a litmus test, i.e. a short list of questions for challenging developers and their managers on their engineering practices.”

How to Test for Agility with the Agile Litmus Test
Dummies
“To be agile, you need to be able to ask, ‘Is this agile?’”

Taking the Agile Litmus Test
O’Reilly Safari
“When you understand these values and principles, you’ll be able to ask, “Is this agile?” and be confident in your answer.”

The Principles of Agile Manifesto
Educba
“Collectively, these principles are used to like a litmus test to identify if a project is being run on agile or not.”


The Importance of Placing Individuals Above Processes and Tools

Empathy should be regarded as a super-power. Not enough people have it and the workplace – indeed, the entire world – would be a better place if more people did have it. When you have project deadlines or you’re in the midst of an intense all-hands scrum, it’s easy to forget about the people factor. That is, there are people working with you and for you who are missing celebrations, concerts or the opportunity to just chill out at home because their effort is critical to your product development effort.

But you’re on a tight timeline. You have key deliverables. Your client has worked backwards from the launch and expects that you will deliver a bug-free software solution by the date circled on the calendar. As the Practice Lead, you may be luckier than most in your role if you have a dedicated team cranked up on caffeine and working late into the evening – every evening, in fact. This is great for deadlines but it can have far-reaching negative consequences if this pace is expected to  be sustained.

The Agile Value #1 requires that we value individuals and interactions over processes and tools. Yet you’re conflicted. Project deadlines and deliverables are what they are and you’ve explained them to your team. Missing a due date and delaying a launch is not going to happen on your watch. Processes for coding, testing, documenting must happen as prescribed, regardless of the yeoman’s effort required to get it done. Your team understands this, right? Surely you told each team member that they were doing great work when you met last year for their performance review?

Maybe they do. Or maybe they don’t. Agile product development places enormous demands on the people doing the work. Both the team members and their practice leads have to grapple with the relentless pressure and the temptation to skip part of the process to move things along faster. 

When you’re building high velocity teams, you need to make daily investments in your people, processes and infrastructure. Take any and every opportunity to express empathy, understanding and gratitude for the work that your team, and each individual on your team, is doing. Expressing appreciation once per year during a performance review will likely end up becoming a one-and-done experience because that employee likely won’t be around this time next year.

There are simple ways to bolster your team’s productivity and motivate them to stay on track with respect to processes. The easiest way is to say, “Thank you.” If you want a high velocity team who is loyal, dedicated to the needs of your customers and proud of the work they do, then say what you mean and mean what you say. Be sincere. 

To help ensure that your agile engineers remain “your” agile engineers, go one step further and acknowledge the efforts of individuals in front of others. People are human and their efforts, sacrifices and basic needs must be openly acknowledged. As software engineers in a hot market, we have the flexibility to go wherever we like towards the goal of being part of a community that values our membership. Agile leaders must reinforce appreciation of these “extra efforts” through grace, gratitude and occasionally, through special dispensation. Catering dinner (that’s not pizza) for the team every once in a while is a good expression of gratitude. This is how to build trust and long-term relationships, as well as high velocity, agile teams. 

Staying strong on execution and adhering to process is critical for success. Acknowledging the personal efforts that it took to enable that success must be acknowledged. Remember, as per agile Value #1 –  if you put people first, ahead of processes and tools, you will have created a space that fosters a high performing team’s success.

Simple Test for Every Agile Team

November 19th: The Simple, Rapid Test That Every Agile Team Should be Doing

A couple of weeks ago, I shared some thoughts around the concept of leading a team of agile craftsmen and how all of us were practitioners in a living lab. Agile product development, by definition, requires that we fail fast, learn from our mistakes and develop processes that maximize efficiency. Agile values also require that we put the emphasis on people ahead of process.


That sounds incongruous. How do you do both in parallel? It seems like it would be impossible to put people first yet adhere to the rigor required by following a process. However, there is a way. It’s called the Agile Litmus Test. Although there is no standardized template for it, the basic concept is that each team member thinks about why s/he/they is doing what they’re doing towards the goal of assessing whether or not the individual, team or corporate effort meets the values and principles as defined by the Agile Manifesto.

Many of you may recall the litmus test from your chemistry classes. The Litmus Test is a simple, low-tech, low-cost way of determining the pH (acidity) of a given solution. It’s been around for centuries and it’s still in use today both as a physical test as well as a metaphor for describing a quick method for testing out a concept. The fact that it’s been around so long illustrates how effective it is which, in turn, underscores the value of the Agile Litmus Test. One thing that surprised me is how search results returned for this test seem to drop off after 2015 – have agile developers lost sight of its importance?

Within the context of agile product development, the Agile Litmus Test is a rapid means of straddling the duality of putting people ahead of process  (Agile Value #1) yet still adhering to it. There are several versions of what it should be, but there are only a few basic rules regarding the application of the Agile Litmus Test. In short, keep asking yourself if you’re doing the right thing. Given that we’re all agile craftsmen, we should be encouraged to use a little latitude to make the “rules” work for each of us given our own scenarios. At InRhythm, we apply it to meet our needs.

Quite simply, the Agile Litmus Test is the act of asking practical, meaningful questions to assess our priorities. Which questions you ask and which order you ask them in are not critical. What is critical is that you ask some flavor of these questions regarding everything that you do. It’s less about the rigor of the questions asked and more about accepting the personal responsibility of asking them. Whatever you’re doing, which includes posting on social media, writing content, coding, documenting, how you conduct yourself at a meeting and what you say there, etc. should all be subjected to the Agile Litmus Test. 

Consider questions along the following lines:

  • Why am I doing X this way?
  • How is doing X going to help me meet my goal(s)?
  • Should I be doing X right now?
  • Is there something else that I should be doing instead of X?
  • How will my team or project be impacted if I do X?

The idea is to self-assign a mental speedbump, not a big hurdle. You want that little bump to be big enough to get noticed but small enough to accelerate through. Take the time to pause and think about what you’re doing and why you’re doing it. Each of our actions as agile software engineers who are part of high velocity teams has consequences for us as individuals, as a team, as a client and as a vendor. We need to consider the bigger picture for all that we do and not gloss over our own accountability for using our time in a way that advances our personal and professional goals. 

In my years of experience onsite at clients and working with 10x teams, I’ve seen people get caught up in their own agendas. Somehow, they lose track of the bigger picture or their leaders have not communicated it effectively to them. Regardless of how or why it happened, they are not invested in how their efforts tie into the collective efforts of the project. So, you’re thinking, well, if one individual has lost sight of the vision and the shared end-goal, that’s probably not going to have an effect on the overall outcome. Or, if you’re that individual, you may be thinking the same thing. 

Not so, because there is rarely just one individual on an agile project that loses sight of the priorities. Typically, it’s more than one which can have dire consequences on hitting the milestones and timeline that only some people are tracking to. If you were to apply the Agile Litmus Test right now, what is the question that you ask yourself?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

16 Quick Poll – a Litmus Test for Agile Product Development
Scrum Breakfast
“I want a litmus test, i.e. a short list of questions for challenging developers and their managers on their engineering practices.”

How to Test for Agility with the Agile Litmus Test
Dummies
“To be agile, you need to be able to ask, ‘Is this agile?’”

Taking the Agile Litmus Test
O’Reilly Safari
“When you understand these values and principles, you’ll be able to ask, “Is this agile?” and be confident in your answer.”

The Principles of Agile Manifesto
Educba
“Collectively, these principles are used to like a litmus test to identify if a project is being run on agile or not.”


Say Thank You Now: Don’t Wait for Employee Appreciation Day

November 13th: Say Thank You Now: Don’t Wait for Employee Appreciation Day

Having a dedicated holiday or annual occasion to formally celebrate someone sounds like a good idea on the surface, however, it doesn’t reflect the first value of agile product development. Why do we need to wait for a special day to tell someone that we appreciate them for who they are, for what they do and how they impact our lives? In fact, it seems a little disingenuous to share a message or token of appreciation on that given day because society obligates us to do so.

Let’s turn this around and refocus on the first value of agile methodology. We need to routinely take a moment to pause and communicate our appreciation. “Value 1 = individuals and interactions over processes and tools.” We could just as easily add “… over formalized events or occasions or annual performance reviews.” What this agile value is essentially saying is that expressing appreciation, gratitude or human decency and kindness to another human doesn’t have to be prescriptive. Instead, it’s quite the opposite. It should flow freely, be a natural expression and happen in the moment. 

When you’re building high velocity teams, you need to make daily investments in your people, processes and infrastructure. Waiting for a full 364 days or 90 days (or whatever your performance review cadence is) to tell someone that they are doing a good job and that you sincerely applaud and value all their late nights and extra effort is too long to wait. Telling them how valuable they are to your company and client as often as they deserve to be told (without being overly expressive as that has a similar negative outcome through the dilution of the message) is the best way to bolster your team. 

Do you want a high velocity team who is loyal, dedicated to the needs of your customers and proud of the work they do? I’m sure that you do. And, assuming that you do want your agile craftsmen to remain “your” agile craftsmen, then go one step further and acknowledge that person’s efforts in front of others.

The pace of software development is best described like that multi-movie franchise, “Fast and Furious.” It can be relentless. Many projects are inherently complex requiring sophisticated engineering. As if that wasn’t already challenging enough, layered on top of the work itself are the difficulties associated with logistics, managing international and remote teams, coordinating individual efforts, and keeping your teams motivated. These factors compound the burden carried by practice leads and executives. 

Just as the agile value mandates, we must put people ahead of processes and tools. The ones doing the work are human. They have human needs: they want to be with their families, spouses, and friends. Missing a night out or birthday or some other event can be tough, but manageable if it’s once in a while. However, repeatedly missing every social outing with friends and family month after month during an extended project sprint is not going to have a positive outcome. Nor will missing even one of the “big rocks” milestones like a graduation or wedding. These losses will have lasting repercussions on employee morale and taint corporate culture.

People are human. We need to belong and we long to be part of a community that values our membership. Agile leaders must reinforce appreciation of these “extra efforts” through grace, gratitude and occasionally, through special dispensation. This is how to build trusted and long-term relationships, as well as high velocity, agile teams. 

Leaders of agile craftsmen, particularly of those who are placed onsite at a client and disconnected from the “mothership HQ” must take time to pause and recognize the importance of showing appreciation. Yes, these sprints are fast and furious but they will never be successful if you don’t show your people that you care. Not to mention how one sprint flows into another, then another, and then the epic wraps up as another begins. As a leader, you must also impress upon your clients who are hosting your agile craftsmen that they also express appreciation for a job well done. Doing so fosters a sense of community and helps the onsite workers feel like they belong and are playing a valuable role alongside the client’s employees.

Staying strong on execution and adhering to process is critical for success. Yet there must be time deliberately factored in to pause, however briefly, to recognize the efforts of one individual at a time. In so doing, it won’t be long before everyone has been recognized for their contribution and be made to feel that they are indeed, an important part of a special community. Remember, as per agile Value #1 –  if you put people first, ahead of processes and tools, you will have a high velocity 10x team.

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

10 Creative Ways to Show Employees Appreciation
Business News Daily
“There’s no better time of year to brush up on your employee appreciation best practices than right now.”

The Importance of Saying “Thank You” in the Workplace
Forbes
“In fact, companies that spend a mere 1% of their payroll budget on thanking and recognizing their employees ‘are more likely to perceive greater impacts on retention and financial outcomes.’”

If Bosses Want Happier Employees, Start by Saying “Tank You”
CNBC
“In fact, 75% of U.S. employees surveyed agreed that motivation and company morale would improve if managers simply thanked workers in real-time for a job well done.”

16 Best Practices for Conducting Employee Reviews
PrimePay
“Be sure to highlight good performance and explain why it was good and how it helped the team and the company as a whole. Recognition is key in making your employees feel valued for the hard work they put in.”

The Employer’s Guide for Boosting Employee Retention with Recognition
Workest
“One study polled over 1,500 workers, finding more than half were considering a job move. When asked what would motivate them to stay with their employer, 69% said recognition and rewards.”


Practice What You Preach

As agile practitioners and thought leaders in software engineering, when we work onsite at our clients’ offices, it is important that we deliver our best. After all, as consultants, we are viewed as experts brought in with the expectation that we instrument and equip them with high velocity teams. In this regard, as we heard from our CEO, Gunjan Doshi, in last weeks Learning & Growth Newsletter, we are agile craftsmen. Our challenge is how we can balance learning on-the-fly while integrated onsite with our clients and managing their project expectations.

It is one thing to operate as a living lab when you are shielded inside the walls of your company’s office. With the right culture, mistakes will be expected and valued. When they result in a learning opportunity they ultimately drive a new insight into efficiency and judgement, however, when you are working onsite with a client, it can be an entirely different experience. Mistakes can result in injured productivity or be viewed as an inhibitor to progress and improving velocity.

Clients understand that software development is partly intuitive as much as it is scientific, and even masters of the craft will occasionally misjudge. Agile methodologies instill the mindset that we constantly iterate upon and improve our solution as well as our process. This not only holds true in what we craft, but also from within ourselves.  As agile craftsmen it is our responsibility to analyze our own efforts, understand and mitigate risks, decipher inefficiencies in complexity, and test and implement modern approaches, all on behalf of our clients. 

As each of us continues on our own path of learning, an opportunity to support each other within our living lab presents itself. We are a community traveling in the same direction. Such says the African proverb, “If you want to go fast, go alone. If you want to go far, go together”. We are bar-raisers and we travel together. In this sense, all of our clients can benefit from any of our thought leaders.

There will be times where we struggle. Perhaps, through a buggy release or during the release of a new product with unanticipated difficulty. We must take feedback with fortitude and cannot be afraid to pivot our strategies, evaluate new implementations, test and ultimately learn.

Learning by doing is often the best form of instruction. Agile craftsmen must recognize that failure is a part of the development process. As Robin Arzon would say, “Failure is the platform to which we build upon”. Often times success only provides validation and feedback is an essential aspect of agile development supporting the continuous loop through which we design, implement, test, and learn.

Earlier this summer, the much anticipated release of Apache Kafka 2.3, a vastly popular component in microservice architecture, enabling streaming and real-time processing of records, was met with its own challenges. One of the persistent bugs was related to the user unsubscribe functionality. This was obviously a critical part of their offering today given the growing requirements related to data privacy and simply an essential aspect of any offering to ensure customer satisfaction. I’m sure everyone will agree, in today’s modern service oriented technology landscape, that the customer is in control and products must incorporate their needs if they wish to remain in business.

It’s simply not easy to project our own living lab culture when onsite with a client. The pressure is already high to meet deadlines and each of our own efforts is codependent on others’ to execute and deliver. Another factor can be pride. Nobody wants to err and be labeled as the bottleneck.

So how will you manage to accomplish this? Observation and communication. Follow what the signs say in the subway stations and airports. “If you see something, say something.” This is actually universal advice and is highly applicable to agile development efforts. By remaining sharply aware of what you’re doing and how that work is impacting those around you, your sprint, project, and team, you will be in a better position to anticipate potential challenges and outcomes. You can then communicate these as you predict them or as they are happening so that you can work collaboratively with your client and your colleagues onsite to address them. Sometimes simply managing expectations can afford you the opportunity to make mistakes, and as we know, making them earlier saves future development efforts.

Failing is a part of the process and not having the visibility and foresight to identify and cross-communicate about potential issues creates risk and impedes high-velocity teams. Agile craftsmen are expected to be nimble minded, to think and learn fast. We are expected to err on occasion and it’s all about how we handle that situational awareness and how we are communicating to others so that we all learn and grow together.