Cultural Patterns – Part 1

Recently I’ve been reflecting on cultural patterns I’ve seen in organizations throughout my career; how I experienced them, their impact, who thrived, who withered.

Over the next several posts, I’ll talk about a few of the patterns I think are key in determining the success or failure of change initiatives, including Agile transformations.

“Get It Done”
A GID culture is about finishing.  It’s an environment where success is achieved by reaching a finish line, and reaching it as soon as possible.  To be considered “good”, I need to multi-task, finish my work faster and better than the next person, and always be poised for action, ready and willing to take on the next thing to do.

Such an environment values:

• Activity over Inactivity
• “I did it” over “We did it”
• Meeting deadlines over Ensuring quality
• Accountability over Ownership
• Advocacy over Inquiry
• Results over Outcomes

If it’s true that “you get what you measure”, then in a GID culture, what do you get?

• Things that are done….but are they the right things?
• Things that are resolved….not necessarily solved
• Completed work….not improved work
• Competition….not collaboration
• Knowledge hoarding….not knowledge sharing
• Adrenaline….not passion
• Stress….not fulfillment
• Performance measures focused on….individual accomplishment and comparison to a standard
• And lots of meetings….to report status, trade information, plan, assign action items, etc.

In a GID culture, I don’t feel valued for what I bring to the table (my strengths), only for my ability to crank out work.  Weaknesses are viewed negatively, as things to be “fixed”, not opportunities to improve.  Good doers are promoted, but not supported with mentoring or coaching.  Work is reduced to a binary state, done or not done, success or failure.  There’s no middle ground, little opportunity or encouragement to grow, no pause to think or reflect, just finish and take on the next thing.

Don’t get me wrong, getting things done is important, and is a cornerstone of Agile delivery.  The difference in a GID culture is a lack of balance.  And organizations need balance to develop the resilience essential in creating or responding to change.

So that’s what I’ve seen and experienced*….what about you?

Does your organization have a lot on their plate?

Are resources spread too thin?

Have you heard the phrase “stop starting, and start finishing”, but aren’t sure how it applies to your organization?

If you answered yes to any of these questions, here is an analogy to help you describe why prioritizing and concentrating on fewer projects first is important. It’s okay to not start everything at once.

In Detroit entire blocks of houses sit empty.

Imagine we have formed a consortium to buy a cul-d-sac of houses. We have a fixed budget. The houses all require work before they can be rented or sold. Our vision is to do the work, and start receiving an ROI on our investment by selling, or renting the houses. Our budget includes money for the initial purchase, and repairs.

Option 1:

We divide and conquer. We look at each house and identify everything the houses will need to make them wonderful homes. Each of is assigned one or more houses to work on. We utilize our skills, and hire contractors to backfill our team to get the work done. We have more houses than project managers/leads, so we must spread ourselves out across many houses. It is a slow process, but all houses should be done in 12 – 13 months. Then our inspectors (QA’s & PO’s) will need to sign-off on all the houses, we will need to remediate any issues, and then finally we can start to do something with everything we finished.

While we are working on the houses, our specialist like plumbers and electricians are spread thinly across the project too. It is hard to schedule their time, and we have down time while waiting for them. Even worse than the down time, is the fact that while they are running from house to house trying to get things done, they aren’t as thorough as they should be. We find ourselves calling them back, cleaning up after them, or just don’t know that something was missed until the property is inspected. They suffer from task switching and trying to make everyone happy at the same time.

Everyone is stressed, progress is hard to see. Leadership pushes for more, and the teams become dissatisfied with their job.

Option 2:

We rank the houses by Return on Investment (ROI) or Weighted Shortest Job First (WSJF – considering job size, sunk costs, and cost of delay), and all of us begin work on the house(s) with the biggest ROI/WSJF. When the first house is finished we can immediately sell or rent it, moving on to each subsequent house completing them with dedicated resources until all houses are complete. Worst case, the last house is not complete for 12 or 13 months, however we have been receiving money from the first house for 10 months, and each subsequent house as completed. By the time we get to the last house, we may decide just to bulldoze it and build a park.

We welcome change. More importantly, we can choose to change. We haven’t wasted any work identifying what will be done ahead of time. We identify what we need for each house “Just-in-time”. If there is a new “green” lighting system available, we can choose to change the plans and use it. If we decide to add heated flooring in a particular area of the next house, we can. Furthermore, we can decide if it makes sense to include these items in other houses based on the impact to just one house.

Our rework on each house is minimal. Our teams get faster at doing their work the longer they work together as a team. Everyone sees constant progress towards a shared end goal.

We have our supporting infrastructure in place. We know who is responsible for the work, and can trust everyone to do their best. The team gains positive momentum, and direct feedback. Everyone sees progress. We follow Lean and Agile Principles to ensure our teams are happy and fulfilled with their job.

A frequent topic of discussion these days is what division should own equity lending: consumer lending or mortgage.  This question comes from our banking clients that offer a wide selection of lending products to their customers, and thus often face organizational design challenges triggered by changing business dynamics.

At one time, the high volume of piggyback loans made the move from consumer to mortgage lending for closed end seconds a common sense decision.  This allowed the loans to be originated and, more importantly, underwritten in tandem, saving time and money in the process.  Coordinated closings were simple, without the need for communication across divisions. But interest in seconds waned with the credit crisis and volume declined, and many organizations moved equities back to consumer lending.

Recently, increasing rates and renewed interest in piggyback lending for affordability has brought focus back to the equity side.  Many banks are re-thinking their production of equity products, and what makes sense about where they are originated.

There is no “right” answer for everyone, but decisions should be based on resources, technology, compliance and other factors, including what the strategic focus for the product is.

• A closed-end second has always been a stepchild in the consumer lending world, taking more time and requiring a more complex skill-set to complete the origination process.  With the parallels between closed-end seconds and first mortgages, the skill-set exists within the mortgage lending division, but a streamlined process may be needed to allow them to co-exist without slowing the origination of seconds.  HELOCs, on the other hand, are more consumer lending friendly and require more skills and knowledge to be added within the mortgage division if responsibility for these products were to shift.
• Most consumer and mortgage loan origination systems are delivered supporting the production of closed-end seconds.  Tasks such as setting up the appropriate products and pricing guidelines, defining new workflow and integrating of new documents will be needed, however.  Note that mortgage loan origination systems are not well suited for the HELOC product, although some vendors are moving in this direction.
• Compliance is a critical part of the equation these days.  The pending CFPB Integrated Disclosure regulations affect both mortgages and closed-end seconds.  Lenders must support new calculations and meet new guidelines to provide the borrower with disclosures and documentation in a timely manner. Lenders have a significant amount of work ahead of them, even if their system vendor is supporting their technology to meet the August 2015 deadline.   The level of effort should not be underestimated, and in many cases aligning first and second mortgages represent a timesaver for both the testing and ongoing compliance oversight activities.  Addressing these regulations is particularly important given the new, higher penalties that CFPB will impose should the regulations not be met.
• Equity products are often considered a bank branch product, and are promoted within the bank as part of the branch’s offerings.  The platform staff support the application and delivery of these products, increasing branch traffic as well as providing them with a revenue stream.  Mortgage lending, on the other hand, may be connected to a branch but is not as intrinsically linked.  A separate mortgage loan officer is involved and responsible for maintaining service levels to the customer.  Each organization must weight their pros and cons to any changes to the status quo, and ensure that all employees are appropriately incentivized for their efforts.
• Ideally, the bank should involve resources knowledgeable about both mortgage and equity products to help guide them towards the right product for their situation. Unfortunately, staff can only promote the products they know.  Mortgage loan officers should have deep knowledge of the mortgage products, pricing and process.  Bank branch personnel have knowledge and experience about consumer lending products, and their role in the process. If equity is under consumer lending, then the mortgage loan officers likely have no incentive, interest or even knowledge about equity products.  Likewise, the bank branch personnel are not well versed in mortgage, and given the current regulatory environment, are often prohibited from discussing too much with a customer for fear they will say the wrong thing or collect too much information.

The mortgage industry is entering a new phase, loan officers need all the tools and information they can get to offer the best solution to their customers.  This doesn’t always require that equity and mortgage be originated within a single division, rather that training is provided across the product spectrum to provide mortgage loan officers with a complete portfolio of knowledge, with opened communication lines between divisions (when needed), access to current pricing and product descriptions, and streamlined workflows established to take and process an application, regardless of whether the customer selected a mortgage or equity product.

Where are you on this issue?

One of the hardest things for companies transforming to Agile to accept is the idea that team members are to be dedicated to the teams to which they are members.  When it comes down to it, it is really about the cultural shift.

In order to better understand what the cultural shift is, you must first ask yourself: “do I know what a team really is?”  A team is defined as “a small number of people with complementary skills, who are committed to a common purpose, performance goals, and an approach for which they hold themselves accountable[1].”  Teams that are geared toward the same goals are much more productive and are said to be able to accomplish more together than individually— “T.E.A.M. = Together Everyone Achieves More!”[2]

Traditionally, when we discuss teams, we talk about them in the context of project teams.  However, there are a few things about ‘project teams’ that cause us to pause as we refer to the definition of what a team really means.

One of the things about ‘project teams’ that cause some dread is the fact that project team members are not fully dedicated to the efforts of the one project team.  In most cases, each member ends up being a member of multiple project teams.  As members become members of multiple teams, their focus is interrupted and therefore undermines their commitment to each of the ‘teams’ they are a member of.  It becomes hard to hold yourself accountable when you feel an obligation to commit to multiple teams, which usually will have different goals!

Another thing about ‘project teams’ that poses some stress is that they are only together for a short period of time then the members disperse and join other teams.  When this happens, they now have to build their commitment and goals, as a team, all over again.  If teams must continually come together then are broken apart, sooner or later the commitment to the team means nothing.  Each time the team dynamic changes, the productivity of the team goes down and very seldom has time to recover before there are more changes.

How does this change with Agile, you ask…

As organizations move toward a more Agile-driven one, how they ‘build’ teams becomes very important.  One of the main goals of Agile teams is that they are geared toward a specific backlog, which is centered around a particular product.  Once the team is set with the members, they have the ability to rally around the backlog and focus on that.

When building teams around a specific backlog, or product, it is easy to have them focus on the single team that they are members of.  Using this idea, the members that are on the Agile team are all dedicated to the same goals and outcome.  When this happens, the members have a higher level of commitment because they are dedicated to the one team and can focus on the goals of that team and none others.

Agile teams that are geared toward a specific backlog, or product, have no reason to be dispersed at the end, because there is no end.  Because a backlog, or product, is for all purposes, never-ending, the team keeps working on the backlog and the organization, in some way, keeps the backlog full with things that the product needs to have or do.

As the culture shifts from one geared toward the traditional definition of team to the Agile team concept, their focus and commitment shifts.  It is the organization’s job to support the change in the team structure and help to keep the team focused on the idea that “T.E.A.M. = Together Everyone Achieves More!”[3] holds true!

Tune in next time, when we talk about what it means to be a cross-functional, dedicated team…

A couple of years ago I started hearing more and more debate about whether the work to fix bugs that got past the customer’s acceptance testing should be counted towards a team’s velocity or not.  I like a good debate as much as the next person, so I joined in with the opinion that velocity is a measure work done, not value added, so it should be counted with some contextual wiggle room.  (I speak more about my reasoning in a moment.)  Since then, though, I’ve come to believe that putting too much energy into debating this question is just a way to avoid the more important, and honestly more difficult, question: What can we do to prevent the bugs being introduced in the first place?

Let’s start with the debate itself.  There’s a school of thought positing that velocity is a measure of value rather than “just” a measure of effort.  That seems to confuse value with cost, though.  The developers’ estimate for a story is a reasonable representation of the cost of the story, but those estimates specifically do not and should not take the potential value of the story into account.  A customer/product owner cannot prioritize their backlog on cost alone, they must have their own measure of the value of each story and use that in conjunction with the cost information to maximum the value of their project.  As such, there is a specific economic value to fixing a bug^[1] and a specific cost, both of which should be considered in prioritizing the fix.  In the context of contracting with an external firm to build software to order, I completely agree that I shouldn’t have to pay directly to fix a regression, but I cannot help but pay the opportunity cost for fixing it.  I should therefore get an estimate for fixing the bug and be able to prioritize it as I see fit.  I’d also expect to have the scope of my project expanded to include the estimates for fixing the bug.

The situation is worse when we switch to the context of internal development: Not only do I have to pay the opportunity cost, but I cannot avoid paying the full economic cost of fixing the bug and I also create a more hostile relationship with the team.  I could yell at the team and try to make them work overtime, but do I really expect to improve quality by doing so?  And don’t I court the danger of pushing the developers so far that they start to use their actual work hours less effectively than they could?  (See Tom DeMarco’s book Slack for more on this.)  Granted that I do want to track how much effort is being spent fixing bugs, but why shouldn’t I just track this directly instead of pretending I’m not paying for the bugs and creating a hostile relationship with my developers?

So, I do have a preference for counting bug fixes in a team’s velocity, but I’ve also come to the conclusion that you’ve probably got a more fundamental issue if you’re getting enough bugs that you want to fight over how to track them instead of trying to understand and eliminate the source of the bugs.  Unfortunately, the sources of bugs are legion:  Maybe the problem is that the system is too complex and the developers can’t figure out how changing one part of it will affect other parts.  (This was a severe problem for me recently while trying to enhance a legacy system.  Because of a lot of duplicated code and hidden coupling, fixing bugs became like playing Whack-a-Mole.)  Maybe the feedback from the acceptance tests is too slow or inconsistent, as often happens when people rely on manual acceptance testing instead of finding a way to automate their acceptance tests.  Maybe the acceptance tests are vague and the developers and testers interpret it differently than the customer.  Maybe all the testing effort is fine and deployment errors or environmental issues cause the system to behave in unexpected ways.

Alas, there isn’t a general purpose answer beyond just getting the team to really reflect on the problem and find the people that are sincerely interested in trying to make a great product.

CC Pace employees recently participated in Operation Gratitude, a program where Halloween Candy, Dental Hygiene items and cards and letters are collected and care packages are sent to the troops.

This year’s program was a great success!

We collected a whopping 37lbs of candy, many toothbrushes, various containers of toothpaste and dental floss and numerous letters and pictures for the troops!

We thank all who contributed and thank all of those that are currently serving and have served our country.  Learn more about Operation Gratitude at https://www.operationgratitude.com/.