Metrics
Derek Huether
Most Important Metric for an Enterprise

As an executive, you will be faced with the choice to do the pivot (if you can) or persevere (if you have no other choice). This will lead to a series of “bets”. You lead with a hypothesis that the things you change will allow you to operate at pre-event levels. But, how long will it actually take for you to validate your hypothesis and have a bet pay off with pre-event levels? If you run out of time to figure it out or run out of bets you can place, then you either lose your standing in the market or worse risk going out of business.

Derek Huether
How to identify dependencies with Tableau and ...

Regardless of the organization or institution, there will always be dependencies. The larger the organization, the greater chance of the existence of dependencies.
This template is available for download from Tableau Public

Video
Derek Huether
Value Stream Management

In the following interview (both video and audio), Dave Prior and I explore why Value Stream Management is so important, how it works, the connection to Value Stream Mapping, and how you can get started with it.

Derek Huether
Key Performance Indicators (KPIs)

Key performance indicators (KPIs) are metrics that are used to evaluate the performance of an organization or individual. They are used to measure progress towards achieving specific goals or objectives and to determine whether an organization or individual is meeting their targets.

Enterprise Insights, Jira Align, Metrics, Tableau
Derek Huether
How Atlassian Jira Align Supports Flow Metrics

I keep getting asked, does Jira Align support Flow Metrics, as defined in the Flow Framework and SAFe? The short answer is yes. If you believe these metrics will help unlock the potential of your teams, use this community post to see working examples of Tableau reports I have created using Jira Align and Enterprise Insights.

How Atlassian Jira Align Supports Flow Metrics

Challenge

Best April Fools Day Ever

On April 1, 1988, I graduated from Marine Corps boot camp.  To this day, the sights and sounds of MCRD San Diego are still vividly fresh in my head.  I joined the Marines on November 24, 1987.  One month into training, I broke my foot and was sequentially diagnosed with pneumonia (nobody said boot camp was easy).  I found myself with the decision of being discharged from the Marines or continue training after my injuries had healed.  It wasn't an easy decision. After being discharged from the hospital, I could go back to my old life (leave the Marines).  The other choice was to be sent to a medical rehabilitation platoon (MRP).  MRP is a kind of Purgatory for Marine Corps recruits.  In boot camp, your world revolves around a 12-week countdown calendar.  Every day you'd look to your fellow recruits and say "n days to a wake up".  That meant waking up from the living hell of boot camp.  If you go to MRP, you don't get any closer to day 0, until you're back in a training platoon.  I chose to go to MRP.  There I waited for almost 2 months.

I cycled back to a training platoon and my countdown restarted.  My new day 0 was set for April 1.  The day April 1 arrived, I actually thought graduating was going to be a big April Fools joke on me.  There were so many psychological games, anything was possible.   I thought for certain the Drill Instructors were going to swarm me, while in formation, and send me back to "the classroom" (a place of figurative mental and physical torture).  OK, maybe a little physical torture but that's the way the Marines were back then.  Well, they didn't swarm on me.  I graduated from Boot Camp.  I entered the Fleet as a "boot" private.

So, what's the moral of this story?  Sometime in your life, you may reach a fork in the road.  The easier path, though very attractive tactically, may not be your best decision strategically.  This critical event in my life made me the pain-in-the-ass person I am today.  Nothing, and I mean nothing, has come remotely close to the physical and psychological challenges of Marine Corps Boot Camp.  It doesn't matter if you're a project manager, an entrepreneur, or just trying to reach a personal goal.  Anything is possible if you're focused enough on the outcome.  Anything is possible if you have passion, commitment, and skill.

Graphic courtesy of Leatherneck

,

How To Effectively Manage An Offshore Team Of Developers

,

Offshore TeamsThere are probably two primary reasons you would go with an offshore team. (1) Your customers are also offshore, or (2) you're hoping to save money on development costs.

I'm going to assume your reason is number (2).  Though this post is brief for such a complicated topic, it should give you some things to think about.  Yes, you can certainly save a lot on development expenses. Then again, it can come back to bite you in rework expenses if there are communication issues.

How do you bridge the language barrier? (1) You need a go-to guy or gal who speaks the same language as your developers but will be working at your location. This is a must. Your probability for success is going to go way up by ensuring there is no breakdown in communications.

How do you receive the quality of code you need? (1) Use continuous integration (2) Use test scripts to understand requirements (3) Use short iterations (4) Have regular builds (5) Separate teams by functionality (not activity)

How do you communicate? (1) If you can afford to send/bring someone (an ambassador) over to work with the other team at the beginning of the project, do it. (2) It is critical that your "go-to" has a daily meeting with the team. Select a method that allows each side to see one another. (webcam/Skype) (3) Have everyone use Skype (VoIP) and/or a chat client for one-on-one communications. (4) Keep a Skype connection open between the offices. (5) Use wikis or other collaborative solutions for common project information. (6) Stay away from email, unless it is for formal communication. Information is going to get lost along the way and it will take longer to clarify.

Remember to use parallel communication methods, not serial.