Do lines of code matter…

March 17, 2018 / Isaac Hogue / 1 Comment

messy vs clean

Recently while having a discussion about how to keep code clean, the person with whom I was talking stated “if we were to manage our code that way our lines of code would be huge…” or something to that effect 🙂

I agree that lines of code can make an impact on the overall health and sustainability of the code; however, here a few things that I would offer up that matter more than the number of lines of code:

The code’s focus – how many problems is the code attempting to solve
The code’s simplicity – how cleaver is the code, does is it do exactly what you think it will do if you were to only read the names of it’s various parts,
The code’s testability – how easy is the code to verify when changes are necessary,
The code’s coupling – how many other areas of code will need to be tested if I were to change the code, and
The code’s resiliency – how impacted will this code be when other code changes

My suspicion is that the individual that I was talking with had encountered some crazy code that was hard to maintain, hard to triage, hard to test, brittle, and hard to understand over the course of their time working in code.

Generally, code like this is also huge; but, if an overall solution’s line count is huge and the individual pieces of code are focused, simple to read, highly testable, loosely coupled and resilient to change, the size of the overall solution will matter much less.

That’s my take, let me know what you think.

What’s the pulse of my enterprise transformation? – More on transformation scorecards

October 26, 2015October 28, 2015 / Isaac Hogue / 1 Comment

I think this is the last post in my series on using metrics to gauge the success of an enterprise transformation. As an enterprise transformation consultant, one of the key challenges I face is ensuring that steps I recommend throughout the transformation will help the organization achieve their goal, or the business drivers that inspired the transformation.

In part 1 of this series I framed up my hypothesis that in order to answer the question we need a business metric dashboard that is oriented around the transformation’s goal.

I continued the conversation in part 2 by exploring a set of challenges that are fairly typical to help answer the question of “why transform” and start thinking through a way to use a balanced scorecard as a business metric dashboard. The business challenge that I identified was:

“Our competitors are startups and they will try anything to eat our lunch. It takes us almost a year to release a new idea into the marketplace and by that time we are several months behind the next startup.”

In this post I’d like to frame that up just a little bit more to get to a set of clear business drivers. Let’s continue that discussion by imagining that our enterprise leader says the following as their primary goal or drivers for the transformation:

“We need to create an organization that is able to deliver early returns on our investments, quickly understanding how the market is changing, while continuing to provide predictability and high quality so that we can make and meet both internal commitments and marketplace commitments for our established customers.

In essence, our business drivers would be Early ROI, Quality & Predictability“

So what’s my take? How would I go from this statement to a business metric dashboard that would help us to answer the question “Are we succeeding?”

It’s important to take the time upfront to really consider the desired end state, working with the leadership and enablement groups to identify the key strategic objectives that will deliver the goal. These are sometimes referred to as the strategic pillars that will support and deliver the desired outcome. For the goal identified above the strategic objectives may look something similar to those in the picture below.

Strategic Objectives for typical business drivers

Strategic Objectives for the identified goal

While considering the strategic objectives, it’s important to look for relationships, or correlations, between each of them. These relationships help me to better understand how focusing on one objectives will impact the other objectives. These correlations are key to understanding the best approach for an incremental and iterative transformation. To help with this, I like to use a tool that Dennis Stevens first brought to my attention, the strategy map.

strategy map for this goal

Using the above map I am able to understand how each objective has the ability to influence or be influenced by the other objectives. I am also able to see themes or groupings between the objectives. In essence, Early ROI will be driven by ensuring the market fit is achieved quickly while keeping customer’s happy with the overall product quality and timelines. Each of these are driven by operational objectives that in turn are driven by organizational enablement objectives. These four groupings provide a balanced set of perspectives that can be incorporated into a context card that will focus our transformation phases for eventual success.

Balanced Perspectives – Strategy Map

Recall the original goal for this post was to establish a business metric dashboard that would help us to answer the question “Are we succeeding?”

I’m not quite there yet; but, this seems close! Next I’d like to identify specific measurements for each of the identified objectives. The following pictures show two different ways of visualizing the specific measures. The first (on the left) shows the strategic metric map, or the balanced scorecard perspective. The second (on the right) directly relates each metric to its key component of the identified business drivers.

Specific measurements for each strategic objective in support of the goal

Using the later perspective, I typically like to create a context card that will be used as the ongoing scorecard for the transformation. This context card also provides a clear line of sight into the near-term goals that have been identified by the enterprise or myself as we incrementally transform the organization. Combined, the context card provides both a near term perspective on the original question “Are we succeeding” and the long term business metrics that need to accomplished for the entire transformation to be deemed successful according to the original business drivers. An example of this type of business measurements dashboard is included here.

Maintaining perspective on the near and long term goals – answering the question “Are we succeeding”

I’d love to hear your feedback. Do you think this helps provide clarity around how to establish a set of business metrics that will enable an organization to answer the original question of “Are we succeeding with our enterprise transformation?”

Thanks for reading!!!

The next most important thing…

April 18, 2015 / Isaac Hogue / Leave a comment

Finding your next most important thing is critical and requires clarity. As teams begin thinking about how to address their meetings, the topic of a previous post, its critical that they first identify where the team needs to focus its energy over the next 1-3 months, or the “Next most important thing” the team needs to do in order to succeed.

So, how would a team go about identifying their “next most important thing”… It’s a fairly straightforward process.

For the sake of a tangible example, I’d like to use a set of three types of teams that I work with on a regular basis, teams that operate within a three tier enterprise product development structure. These teams and their purpose would be defined as follows:

Product development team: Produce the next most important working increment of product within a couple of weeks.
Program team: Establish and provide clarity for and to product development teams about the next most important increments of product that are needed within the next few months.
Enterprise portfolio team: Establish and provide clarity for and to program teams about their next most important thing for the portfolio to succeed. This usually requires creating or maintaining a multi-quarter capacity-aligned roadmap for the products and services that are owned by the portfolio

With these perspectives in mind here is the process that I would recommend for identifying the next most important thing within each team:

Review the team’s primary purpose,
Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
Review the team’s suggestions and filter the list down to the one thing that the team agrees is the most important goal for the next period.

its important to recall that the next most important thing for a portfolio team may look very different from the next most important thing for a product development team.

So, how would a portfolio team member identify the portfolio’s next most important thing? I’d recommend that they answer this question:

What is keeping our portfolio from delivering the next most important increments of product into the markets within the next 3-9 months?

Likewise for a program team member I would recommend the following question:

What is keeping our program from providing clarity to the product development teams about the next most important increment of product?

And finally for a product development team I would recommend the following question be answered:

What is keeping our team from delivering a working increment of product within a couple of weeks?

In each of these cases, the next most important thing would be directly tied back to the primary purpose for the team and would be expected to be resolved within a short period. Once we know what the next most important thing for the team is, we can start to identify which types of meetings we will need and how frequently we will need them to ensure that we are accomplishing our next most important thing.

What do you think, are there other examples that you would like to hear more about or perhaps where you have seen this fail?

And as always, thanks for reading and sharing your feedback!

Identifying a Transformation Scorecard

February 19, 2015October 26, 2015 / Isaac Hogue / 3 Comments

Shedding light on a transformation’s success

In a previous post, I asked the question of how can we tell if we are succeeding with an enterprise transformation. In the post, I closed with the notion of using a balanced scorecard for signaling progress towards the transformation’s core business drivers.

A couple of comments were shared after its publishing that cautioned on the dangers of creating a scorecard that would not drive the “right” behaviors or that was too broad and couldn’t be connected with the transformation’s success. This was great feedback.

In keeping with my desire to resolve this question, I’ll explore a bit more of the notion behind why many organizations are seeking a transformation. I think answering this question will help to frame up a sample balanced scorecard in another post. Thanks for continuing to share your thoughts and feedback along the way!

Why transform? I think its fair to say that the number of reasons why an organization would seek an enterprise transformation could be as varied as the people of the world. That said, I most often hear about the following handful of reasons for an enterprise to transform: (1) new competitive forces in the marketplace, (2) an inability to pivot or focus, and/or (3) quality issues. Frequently the statement goes something like this:

“Our competitors are startups and they will try anything to eat our lunch. It takes us almost a year to release a new idea into the marketplace and by that time we are several months behind the next startup.”

In this case I would probably orient around both (1) time to market and (2) innovation as key business drivers; but, it would be important to remember that innovation and time to market are usually not enough. We would need to keep our eye on the ball of business, cash or (3) return on investment. So, using traditional balanced scorecard perspectives, I would orient Financial around ROI, Customer around Quality, Ops and Processes around Time to Market, and Innovation around continuous improvement.

What are your thoughts, would you identify different themes for the scorecard or change the placement of the themes into different perspectives?

Thanks!

Meetings meetings and more meetings

February 16, 2015February 16, 2015 / Isaac Hogue / 2 Comments

Why on earth do I need to spend so much of my time in a meeting? This is an absolutely sane question that most of the team members wind up asking at some point in time while I am coaching an organization towards more adaptive management techniques.

Regardless of the role, there are other things beyond meetings that we have traditionally declared to be productive use of time. If you are a developer, then we declare productivity to be associated with time spent writing software. If you are a product manager, then we declare productivity to be associated with time spent defining the next version of a product or understanding the market’s demands. Whatever the role, its rare for an organization or a profession to associate meeting time with high productivity.

From this perspective, it makes a ton of sense when people beg the question,

“Why on earth do I need to spend so much of my time in a meeting?”.

Here’s my usual answer:

“What defines a productive minute, is it one that is spent focusing on your craft or is it a minute that is spent delivering value to the organization as quickly as possible?”

I tend to think that a productive minute is one that is spent delivering value to the organization as quickly as possible. So, while the time spent practicing a craft is absolutely a critical part of getting value to the organization it is a waste if the individual is not hyper focused on the actual needs of the organization. And this is where meetings come into the picture.

Effective meetings will have a specific theme and will enable a team to establish high clarity around the needs of the organization and teach accountability. For most of the teams that I coach this involves a few specific themes:

(1) Daily Standup – This is a quick touchpoint that is oriented around maintaining accountability within a team as each member takes a minute to update the other team members about the progress she has made over the past 24 hours, progress that she expects to make over the next 24 hours, and any issues or concerns that she needs help addressing.

(2) Tactical Meeting – This is an hour or more and has a very specific purpose, dealing with short term tactics such as creating clarity around near term market needs or ensuring that the team is successful in meeting its commitments.

(3) Strategic Meeting – This is usually a half day or more and is focused creating clarity about how to move the organization forward with a focus on the longer term vision and strategies.

What’s your take, are meetings useful in your organization? Do your meetings have specific themes or are they a mix-mash of agenda topics?

Scrum: Committing while discovering

December 22, 2014December 19, 2014 / Isaac Hogue / Leave a comment

committing while discovering

One of the more common themes that I come across while working with teams is the question of “how can we make a sprint commitment if we are still discovering how to solve for a story or set of stories”.

This is a great question. I may have lost some of you already due to my use of commitment and scrum in the same sentence 🙂

Hang with me if you will for a moment and then share your thoughts.

First a bit about my perspective on commitment and scrum: I feel that making a commitment in scrum helps to maintain transparency for both the delivery teams and also the stakeholders. I think that Scrum has a great tool in the use of both velocity and story points. Story points are an entirely nebulous unit of measurement that is usually derived from a combination of (1) complexity, (2) time, and (3) uncertainty or risk. Velocity is the average number of story points a team is able to complete during a normal sprint. So, the team’s velocity reflects how many of these points a team can usually complete within their next sprint, or their capacity.

I coach teams that they will usually need to look at a story roughly 3 times (or more) before it is committed to as part of a sprint. This usually takes place during regular backlog refinement sessions and then finally during the sprint planning session. During these sessions, if the team feels there is a lot of uncertainty around “how” the story will be fulfilled the points for the story should be relatively higher that it would be had the uncertainty been low. This could mean that a story that would have been rated as “5 points” if there were low uncertainty may now be ranked as an 8, 13, 20 or even 40 now depending on how large the uncertainty is.

So, given all of this, how do I answer the initial question of “how can we make a sprint commitment if we are still discovering how to solve for a story or set of stories”?

I generally advise teams not to take on stories that are larger than an 8 or 13 (depending on the relative sizes of their stories) into their sprint. If the uncertainty is high enough that they are not able to take the story in, then I will typically recommend that they try to split out the uncertainty from the story in the form of new risk stories. The original story will then be made dependent on the new risk stories. Each of these risk stories will then have a specific question or concern that needs to be clarified. The team can then decide if this clarification will take place as a part of a backlog refining session or if they are comfortable allocating a portion of the sprint’s capacity towards answer/resolving the risk. Once resolved, the original story is unblocked and allowed into the next sprint.

Thoughts?

Thanks!

activeHOGUE

staying active in life and thought

Agile