InRhythm

Your partners in accelerated digital transformation

Learning and Development

Change? What Change? Everything Always Goes to Plan

As software engineers, we are conditioned to brace for change. The very nature of our work requires that we be ready for it. Yet, at our cores, we don’t want there to be any changes. We don’t surrender to the inevitable changes that are going to be required after we submit content for a code review. Instead, we steel ourselves against it, and gear up for battle with a mindset of resistance. We don’t want our QA teams to find any bugs because we’ll then have to make changes to the code we’ve already written. 

The experience, however, is like the Grinch who does everything that he can to stop Christmas from coming. Of course, the holiday arrives anyway. Similarly, despite our best efforts to plan and design an agile effort which builds change in, we’re still not entirely prepared to embrace those changes when they do come. And they will. They always do.

Agile Value #4: responding to change over following a plan” speaks to this behavioral response. It’s all about our attitude. Are we prepared for change and willing to accept that there will be change (as there is for every software engineering project)? Or are we preparing for a fight that we are inevitably going to lose? 

Agile craftsmanship requires that we be nimble in our designs and in our approach. The code we write must stand up to meet the quality demands of the project and not interfere with other parts of the project, but it has to be nimble, too. Anyone at any time in the future may need to rework that code or replace it altogether. If it’s rigid and inflexible, the effort to update it (or replace it) will be that much more intense. Working sprint after sprint is already intense enough – we don’t need to add more stress to our day. In contrast, we need to take measured steps to reduce it.

One of the best ways to manage this stress and to reduce our anxiety is to prepare for change. Embracing a mindset of flexibility prepares us for the change that is coming. If our response is calm and collected, the changes requested will be received just like any new project instead of what may feel like a personal attack on our abilities.

Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted colleague and partner to the clients we collaborate with.

Christopher Okhravi, an authority on agile software development, offers an insightful perspective on the application of Agile Value #4. He reminds us that, “We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.” Another factor that we need to remember is that rigid planning and process are the antithesis of the freedom derived from an agile approach. As each project unfolds, we learn more about the needs of that project and gain new insights on how to best deliver the code needed to execute the project. However, as we do so, we tend to drift further from the original plan which no longer reflects our reality and this creates tension for everyone involved. 

So, what is the best way forward? Embrace Agile Value #4. We must plan for the worst but hope for the best because change is inevitable. We must be nimble – and stay that way. Change is a necessary element of what we do. We can design our product roadmaps to be responsive and proactive or we can choose to be reactive and struggle to keep up. Getting ahead of industry needs and trends helps us prepare for the changes that will come. Being open to continuous feedback from our clients, our managers, our peers and our colleagues helps us evolve into a trusted co-worker and business partner. 

“Change always comes bearing gifts.”  ~Price Pritchett

Robert Morrell

Practice Lead, Java Cloud

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”


Change Is The Only Constant

A true Agile Craftsman Mindset understand that change is the only Constant

As product developers, we take pride in the “big picture” of the function of the software that we are designing and implementing. Delivering a solution for our clients, and their customers, takes diligence, long hours and impeccable planning. However, even the best-made plans can go awry. How we deal with those plans differentiates the inflexible resistors from the agile craftsmen.

“Agile Value #4: responding to change over following a plan” speaks to this behavioral response. Optimists hope for the best but plan for the worst. Pessimists expect the worst but plan for the best. And flexible realists exhibit behaviors that are the best of both understanding that being nimble and prepared for change is the right mindset. Framing everything that you do with the strong possibility that things will likely change and be different that you planned for cues up your brain to be prepared for change. Hence, you enable yourself to successfully adapt to whatever the new situation is.


Beyond one’s mindset, a critical aspect of practicing Agile Value #4 relates to planning and design. Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted partner. As agile craftsmen, our clients expect us to be inherently nimble, ready for change, willing to adapt and to plan for adjustments so that we can still track to a set schedule and deliver the quality product we are contracted to produce.


Understanding that change is a natural aspect of a project is one thing. Being prepared for it with a thoughtful plan and design that anticipates where and when those changes are most likely to happen is quite another thing altogether. Here, experience can make all the difference. The client relationship is another factor, one that we’ve discussed in a previous newsletter, ”Customers are Much, Much More Than Signed Contracts”. When a client and vendor embark on a path towards partnership, versus a client-vendor relationship, both sides enter the agreement and project understanding that it’s best to expect the unexpected and be prepared to flex. Sometimes, the client may need to be flexible. Other times, the contracted agile partner may need to adjust as the situation changes for the client.
If change is the only constant, and Agile Value #4 requires that we plan for and accept change versus resist it, we need to each ask ourselves if we are agile and flexible. Or, are we rigid and linear?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”


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.”