Value

Do lines of code matter…

/ 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:

  1. The code’s focus – how many problems is the code attempting to solve
  2. 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,
  3. The code’s testability – how easy is the code to verify when changes are necessary,
  4. The code’s coupling – how many other areas of code will need to be tested if I were to change the code, and
  5. 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.

Advertisement

The next most important thing…

/ Isaac Hogue / Leave a comment

do this next

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:

  1. Review the team’s primary purpose,
  2. Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
  3. 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

/ 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!

Read more here! What’s the pulse of my enterprise transformation?

Meetings meetings and more meetings

/ Isaac Hogue / 2 Comments

BureauWhy 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

/ Isaac Hogue / Leave a comment
towingiceberg

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!