First Responsible Moment

You cannot escape the responsibility of tomorrow by evading it today. – Abraham Lincoln

Responsible is defined as “being the primary cause of something and so able to be blamed or credited for it.” While this sounds very straight-forward, I think sometimes in growing in our agility as a team, a leader or an individual we can forget the power of this word.

Responsibility is a cornerstone to agile thought in my opinion. We strive to teach our teams to be self-managing and instill the idea at the lowest possible level by having them select the work and manage its delivery. As agile leaders, we embrace responsibility coupled with our willingness to experiment, learn and grow and as a basis to keep at bay the fears of failure.

There are three core concepts that I try to instill and reinforce in teams; I ask that they apply a litmus test of reasonableness and responsibility to decisions they make (on an individual, team and organizational scale) and that they respect the power of the “first responsible moment”.

Being Reasonable and Responsible

What does this really mean? It sounds powerful, but also sounds very idealistic. For me, it is very pragmatic. I use these values for myself and my teams as a base “sanity check” for decision making.

Approaching decisions from a position of being reasonable and responsible breaks down this way for me personally allowing me to examine the decision to be made by asking questions:

  • Is what I am proposing an idea or solution that brings value not just to myself but to my team as a whole and the organization?
  • Is this a hotfix solution or does it hold long term value?
  • Am I proposing something from a position of fear or merely pain avoidance?
  • Is what is being considered the right thing for us to be doing?
  • Do I actually believe in this idea in that I could passionately communicate and adapt this position if necessary?

This seems like a lot of “stuff” to go through for a decision but it is really quite simple as when people have a shared understanding of “being reasonable” it really takes little time as muscle memory forms to evaluate quickly (reinforced by a solution oriented outlook).

But here is where the kicker comes in. Evaluation as to the reasonableness is half of the picture for an agile mindset. The final question is the linchpin of this approach.

“Are we willing to be personally and team responsible for the outcome of the decision we are making”?

This takes this application of values to a whole different level. This means should things go sideways, are we willing to accept the consequences of our decision and adapt to self-correct? Are we willing to accept that we failed? Are we willing to re-evaluate our position?

Coupling this with the personal willingness to accept the end result of the action is part of the core definition for this idea.

So why “first responsible moment”?

Again, in my humble opinion, this idea is a cornerstone of agile thinking and doing. It helps support our lack of fear to fail and reinforce our open communication. It empowers us to be transparent and promotes healthy working relationships that reinforce trust among people. It is something that I say often to teams when they encounter a problem.

The “first responsible moment” is how we approach obstacles, problems and impacts. We open the channels of communications to those invested into our work as soon as we see a problem that may impact our commitments.

Often times, there is a lot of fear that surrounds the need to have a conversation that delivery may be less than forecasted. But if we are truly building a healthy agile culture, we use this concept to allow fear to be diminished by encouraging folks to communicate an obstacle or impact as soon as it becomes visible and disruptive.

This does not always necessarily mean the inability to overcome and deliver but what it does do is to set the expectations of everyone involved in a reasonable manner. It always opens a communication for examination to see if there is partial value that may be salvaged and it strengthens the relationships through candid visibility into work. It allows us to take a problem at first encounter and approach it as a discussion for solution.

In an agile (or probably any other) world, no one likes to fail. My teams wring their hands and sometimes beat themselves up too much so I ask them to reflect in retros on “what happened” to create this situation. Sometimes by doing that, we can see patterns of actions that set us up to get there. If we can find these, then we can take actionable steps to reduce the likelihood of failure under those exact sets of conditions. But what is more important (as you noticed I inferred that you cannot just generalize failure to certain things) is that we learn more about ourselves, our team and reinforce our embrace of change. Sometimes things like sickness of a team member can cause items to become in jeopardy.

It can often be random events that create an obstacle. We cannot control the unknown, but we can control our response to it. One of the worst things we can do as a team is to remain silent, kill ourselves to meet commitments for which we know may be unachievable and damage our relationships by waiting until the last moment to make people aware. This stands potential to damage us as team and an organization. We may get the commitment out, but what did we lose as a result? I am not naive to realize that there are times when we are so committed to our work we go “above and beyond” to deliver. But this should be the exception and not the rule. A sustainable pace is always a better approach coupled with the “first responsible moment” when impacts arise.

If you, or your teams, are not presently practicing this concept, give it a try. I think you will be pleasantly surprised at how it can tighten the relationships and reinforce the core values of agility.

 

Advertisements

Working with Legacy Applications

“A people without knowledge of their past history, origin and culture are like a tree without roots” – Marcus Garvey

I work in a business where there is a substantial amount of technical debt left behind by legacy applications created in technology stacks that are typically not in line with our current technical approach. What this means that we are bound for the health and welfare of the business to continue to support and maintain them as some are business critical and invest in moving them forward so that their lifecycle can be reset.

Many of these applications were built without the consideration of what a lifecycle of software actually is and how to monitor its growth, ROI and decline. The intention behind them was that the skills and expertise needed, at the time of inception and creation, were viable technical approaches of the time and that they felt significant confidence to retain those skill sets for support. This is not uncommon in business at times and usually gives rise to those “dark matter developers” who become deep system experts and just keep the wheels running in the background. I point this out not as a complaint or contention of their motives, even though I might disagree, but to say that all software, no matter how amazing it is has a lifecycle. And by ignoring this fact we place ourselves in jeopardy of creating debt in the future.

Just like driving a new car off of the show room, once it begins receiving use, wear and tear occurs and only routine maintenance extends its lifespan. Software is no different. Where we have a transportation infrastructure that supports the base car design, with effective maintenance we can actually extend probably well beyond projected lifespans the life of a vehicle. However, this analogy becomes more closely coupled if we think about something like an ambulance. A vehicle that is required to perform a task that supports the end goal of ensuring people arrive at the hospital safely and sometimes within a critical need for reliability. These vehicles are on a life span. We do not even think about having a “dark matter mechanic” that is the only one that knows this ambulance model that can fix it if broken down in a critical situation. Routine maintenance and routine retirement of these vehicles to be able to effectively meet the business need is performed.

This is the same zone that I see software within. Attention, care and feeding and intention to transition should occur. It’s necessary to protect the business aspects of which it is supporting. Where it may be a longer lifespan than an ambulance, it is still a critical need.

What I have seen, even from myself, is often dislike of the aspects of supporting these legacy systems. While they are often far beyond their lifecycle, it’s our responsibility as service to a business being successful to keep them running but effectively plan for their retirement or transition. I have witnessed, and probably been guilty of in my past, of complaining about the past and the problems it presents as opposed to looking at it from a more objective viewpoint of business support and use a more strategic approach to thinking about how to determine its state in the lifecycle and how we can optimize support and maintenance while planning to remove the debt of sometimes bad or dated technology.

Ways of Dealing with Legacy Applications

I have read several articles about this subject and one gave some good suggestions and the consequences of each. As I cannot recall the exact article, forgive me for simple paraphrase. When approaching legacy application debt, there are a few immediate choices:

  1. Isolate it – Move the application in a more virtual space to enhance recoverability. This still requires, depending on the stack, keeping certain skills on hand for support and maintenance but does allow you to use virtuals of production environments to test impacts in isolation.
  2. Modularize it – Start examining the underlying architectural structure and see if you can begin abstracting and replacing the logic and data layer tiers. This still means for a period, you have to maintain support in potentially a older tech stack but you begin addressing large areas of the backend to try and move it into a larger more supportable space if possible. This allows the presentation layer to stay preserved but you are still modernizing the business logic and data structures. This can be significant and daunting work but hopefully is least disruptive to the business.
  3. Ignore it – This is a model that businesses often choose and the end result is often critical failure that results in lost reputation, business and effectiveness. Using this model means you retain skill sets for which the market is sometimes small or non existent or the complete opposite in which you pay astronomical prices for contractor or service support just to ensure the application stays viable. Some people choose this option as it is easier to complain and some consider that often our career lifecycles with a given company are shorter than the concern of critical failure. In other words, we leave it for the next people to deal with. This is a bad plan.

This is not an exhaustive strategic approach to addressing legacy technical debt. Just three brief strategies that I read and found interesting.

Supporting Legacy Application Debt

What my largest focus is on personally is the cultural approach that we convey when approaching legacy application support and maintenance. I have caught myself on many occasions lamenting the design, implementation and current state of an application only to realize that something has to be done to resolve and issue. The image I used for this post is something that I came across that gave me some perspective on how I should look at legacy support to have a healthy outlook on its support and maintenance (and not abandoning the idea of its lifecycle and care and feeding).

In support legacy applications for a business a healthy outlook is to consider 3 central ideas:

Humility – This code was not likely purposely written to be poorly designed, unsupportable or confusing. A team of people created this program to support a business need of the time based on the skills and abilities they possessed to meet that need. In support of these applications, we often dwell on the implementation of the past without realizing that in the future our code will be supported by someone else as well who may levy the same critical eye. How many times have I written a piece of code or script only to return to it much later and wonder “what was I thinking” as I went through the code.

Ownership – Like it or not as the arm of the software maintenance and support group, we now own this software. Embracing that ownership in an agile manner means as the owner we search for improve opportunities that allow us to make it stable, reliable and maintainable.

Commitment – Again, as the owners of this code base and being an agile organization, we take commitment seriously. We have made a commitment to ourselves and to our business to do the job we are hear to job to achieve the highest value for the business. Part of that is often getting into the deep and murky waters of an older code base upon which the business has dependence. Our commitment to deliver the highest value should be just as solid here as when we make a commitment to deliver that next sexy market grabbing innovative product. We approach challenges as opportunities to learn, grow, expand and bring value addressing the need.

Again, I am not saying that we should accept legacy technical debt and bury our heads in the sand. We absolutely should learn to effectively define and manage product lifecycles and optimize care and feeding while keeping a constant vigil as to where they are in their lifespan. But when we are faced with supporting legacy applications, how we approach that work, how we view the application in terms of the business and how we take base level ownership of the code can make a world of difference in the cultural perception of the support of these legacy items.

 

Unplanned Interactions

“Make your interactions with people transformational, not transactional” – Patti Smith

I have been preoccupied lately with organizations and their culture. I find it fascinating  how sometimes decisions with the best of intentions simply turn out wrong whereas sometimes a simple “nudge” in a direction with the freedom to shape an outcome that realizes a clear end goal or principle. Maybe I am so fascinated by this as it often seems elusive to me as a leader or maybe I just have not cleared my mind enough to be that intentional.

The reason I am taking a moment to write today is that I heard a phrase that seemed universal in building solid organizational cultures; unplanned interactions.

The phrase challenged that to really create unity inside a culture that creating space and opportunity for these unplanned interactions between people of any level in an organization create heightened unity.

The idea is that for the most part we, as humans and workers for a company, often see the same obstacles and opportunities but alone in our bubble many feel powerless to act upon them. But as a shared experience, creativity towards solution or change can have an opportunity to flow. How many times have you found yourself engaged with a stranger in a conversation and some subject that sparks you both arises to create a situation in which you build on an idea, experience healthy conflict from opposing opinions or just become more engaged as you are sharing and learning things you did not know?

This concept also supports the idea of cultivation of “informal leaders” or what I often refer to as “leading where you stand”. People begin to think of new and creative ways to better the world around them. For the most part, people want an engaging and positive workplace since we spend a great deal of our lives there. Most seek to make it better. Often people experience fear or lack of empowerment to do so through self-imposition, bad management or general organizational constraints that inhibit making change. Sometimes based on these constraints, we allow ourselves to become derailed to make any change as it doesn’t seem the optimal. I know this very well as I often question myself regarding change I make if a deviation from the ideal (although it rarely stops me).

So, back to this idea of “unplanned interactions” …  Does your organization create a way to support this? Typically we facilitate lots of planned interactions in organizations such as company picnics, Christmas parties, pot lucks, etc. But those can often create the stereotypical middle school dance situation in which people gather with people they know to enjoy the event as a shared experience. We do things like place cards at tables to mix people together but it often does not have the desired outcome. Why? Is it because it is an attempt at compliance to interact as opposed to facilitating the space to interact? I absolutely think that organizations should create planned interactions as a part of their culture as I think it familiarizes people with new faces. We just have to ensure that we take care not to make them something people feel mandated to take part in.

I really am curious about how to create space within my organization to facilitate connections. We have two distinct business groups (which have different cultures), but in speaking informally with people in both, there are shared passions and opportunities to engage in playful ways to connect people within the two. Perhaps we have to be brave enough to break from social convention and create and encourage playspace as an effort to create a more holistic view of our organization? It really has me thinking and wanting to learn more and try some experiments to see if we can foster these interactions. I think that by doing this we are looking at our organization with more of a systems view (from individual to team to department to division to whole) and stand the potential to tap into the creative minds that lay dormant inside our organization.

So I put out questions and a challenge to everyone who reads this. How are you facilitating unplanned organizations between individuals today? And if you are not presently doing so, why not? Or, how can you start? As always, I hope you change the world…

“When you want something you have never had, you have to do something you’ve never done” – Steve Roesler