Sunday, December 17, 2017

CapEx, OpEx and the Enterprise Agile Coach

Are you considering becoming or do you identify yourself as an Enterprise Agile Coach?

To me at least, this implies a certain degree of knowledge of enterprise financial reporting.

As incremental or agile approaches to the delivery of value grow in popularity, the ability to understand the difference between CapEx and OpEx becomes increasingly important.

A large organization may need time to prepare or learn more to properly support some of the changes in approach. 

If for no other reason, consider your ability to be taken seriously during discussion with financially oriented people. 

Imagine that the difference might be the building of a 100 Million dollar asset versus the building of a 10 Million dollar asset and 90 Million dollars worth of expense (an oversimplification only to inspire research. My apologies to my accounting contacts).

Of course, there is much more to the enterprise agile coaching than this one topic, but ignoring it is not good for anyone.  I really dislike lose-lose situations.

Consider ......

At a minimum, you should be able to explain the difference between CapEx and OpEx and the potential impact to Balance Sheet and Income Statement.

If you can't do this basic task with understanding, think about your circle of influence or the circle of influence of the person you are trying to help.

Some ideas for you to get started....

- take a basic accounting course 

- ask a finance or accounting person for insight (a great way to build a new relationship)

- Ask yourself.. "How would I feel as an Investor in the company with the different results ?" (public or private)

- Read some books or articles.

- Ask yourself... "How will I prepare my client for inevitable discussions with regulators, shareholders, or auditors?"

- Consider finding an experienced person with enterprise experience to help you navigate and learn about this.

- Bring someone into your local meetup that understands this topic well.

Many transitioning companies will need some time to learn and assimilate new ideas. In some cases, lawyers may need to get involved to help navigate the change. 

A sample trigger phrase to remind you that you are in an environment where this is fundamentally important: "In service date".  

Enjoy what you learn :->

Saturday, October 21, 2017

Consider a simple thank you.

I recently witnessed a situation where someone put a huge amount of effort into a post to clarify a topic that many people are confused about. 

In the complex domain being discussed, they were not advocating their explanation as the complete (or best) solution... They were simply helping others to understand based on the specific context of the questions involved.

That person knows that that only one answer cannot solve a complex situation and believes that small steps matter. They are willing to respond in a way to help others instead of trying to correct an entire system in one post.

Many people understand that there will always be something to add or improve in a complex system or understanding.

When a poster creates an article to help others (or simply move the needle a bit), this does not mean they lack knowledge of other approaches or parts of the complex domain.

Please consider that sometimes simply thanking them will help keep everyone engaged and comfortable sharing and learning..... 

One-upping someone is not always necessary (or helpful)... 

How about just saying ... 

"Thanks for the insight"...  

Just a thought.

Tuesday, October 17, 2017

Blockchain and Privacy

First, let me say I am not an expert on Blockchain. That being said, I have been following the advancements in this domain for some time.

One feature of a Blockchain is that a previously written block cannot be amended or adjusted in any way (Feel free to correct me if I am wrong).

This all makes for a very secure, distributed history of all things in the chain... 

Blockchain is becoming increasingly talked about in markets involving financial transactions...Trades and currency transactions seem to be a current hot-spot for the concept. 

Recently, I read an article (sorry I do not have the reference, but it stuck with me which is why I created this post).  

The article talked about storing contractor data and recruitment data in a Blockchain and using "smart contracts" to link contractors with potential jobs.  Someone posted it in a feed and proclaimed... "The Blockchain is going Meta".  

I have been wondering about security of sensitive private information and the ability for incorrect or bogus information to be removed.

If you consider that information in a Chain can never be deleted, how does one comply with laws such as the EUs "Right to be Forgotten" legislation  by example? 

My mind races with potential abuses to the concept of information being freely available to anyone with access to the chain.

Consider the example of skills being auto-matched to a requirement.. and the history that would forever exist about this.  I can see several pros and cons to this depending on which side of the situation you are in. 

I sincerely put this question out to experts in Blockchain... 

How DOES information get deleted, or can it (or should it)?  

It seems to me that just because you can put something in a Blockchain, maybe you shouldn't always?

I really don't know the answers.. I just have questions... 

I made this post hoping to find someone wondering.. 

What should go into a Blockchain and how we do we protect our privacy?   I think the time to talk about this is now. If you are in this field, are you having these conversations?

Based on my current understanding of Blockchain, if a country legislated a "Right to be forgotten" for any information in a Blockchain, it would be impossible without starting a brand new chain.  Do I have that right?

* references

Blockchain -

Right to be forgotten Legislation   -

Tuesday, August 29, 2017

Stop bashing corporate leaders

  • Pictures of Leaders with angry red faces
  • "Leadership doesn't get it" blog posts
  • "Greedy Board Member" blog posts
  • Posts about "foolish management"

... the list goes on ...

Do you publicly humiliate the management or leadership of an organization you work for (employee or contract) and then later complain you can't get time with leadership or wonder why you can't connect with them?

If so.... From a purely effectiveness level... If you publicly mock the leadership of an organization, you can't really expect to have a trusting, open relationship with the same people you just mocked. 

How would you feel if the leaders started publicly mocking you?

Something to think about next time you decide you want to post a "let's poke fun at the leaders" message.

Saturday, July 29, 2017

A misunderstanding about contracts in an agile context

The Agile Manifesto contains the following words...

Customer collaboration over contract negotiation

I recently experienced a person suggesting that as agilists, we can sign contracts and then just do what feel is right and that every decision after signing should still be a negotiation. 

There are ways to make flexible contracts. I have seen contracts designed to specifically require collaboration. I have seen contracts that get regularly re-negotiation based on changing needs. 

My preference is to work with a minimal contract (or with pure collaboration if that is possible).

There is always the option to not sign a contract you cannot live with.

Signing a contract with the intent of ignoring it is not collaboration. I would argue that it is very disrespectful to the other party involved. 

I have a different word for someone who signs a contract with the explicit intent of ignoring the terms... and it isn't Agilist. 

Reference: Agile Manifesto -

Wednesday, June 21, 2017

A story about a Hammer

When I was young, my father bought me a hammer.

While learning how to use it, I recall directly hitting my thumb one day. In fact, the pain was so excruciating that I doubt I will ever forget. My thumb turned a variety of colours and eventually the nail fell off.

I thanked my father last weekend.... Instead of telling me to try to learn a screwdriver as it might be easier, he convinced me to keep learning and practising and that likely I would hurt myself again. That's how we learn.

My confidence with a hammer increased considerably over time. 

Eventually, I started experimenting with other tools and their uses.  I have had the pleasure of using a variety of tools such as Screwdrivers, Drills, Mitre Saws, Table Saws, Sanders, Routers, and my favourite finishing tool.... A Bisquit Joiner.

I have built a house, build docks and decks, learned plumbing, done insulation, built furniture, and the list goes on. 

There is no challenge that scares me. I believe this is because of the lesson from my father...

When a hammer is the right tool for the job, don't let someone convince you to use another tool just because the hammer is hard to use. Stick with it if it's the right tool. Then, the confidence to use other tools will come on it's own.

Friday, May 5, 2017

A leadership question

Are you in a leadership position?

In your context, when you listen to someone talk about their leadership ability or history....

Do they talk more about leading things (projects, products) or leading people?

Would a balance be appropriate in your view?

Consider asking yourself... 

"How am I doing in this regard?"

Just a thought. 


Wednesday, April 19, 2017

A calm leader in extreme circumstances

One of the most amazing IT leaders I ever met simply sat back, relaxed, and asked simple, direct questions in a friendly way while 200+ people ran around in a panic during a system outage. 

It was fascinating to observe.

His thoughtful questions let others do their jobs to realize the problem on their own. 

He remained always calm and never laid blame. 

A great memory.


Have you considered your ability to remain calm and let others do their work?

Just a thought.

Wednesday, March 29, 2017

Human Senses - A Conversation Aid

Have you ever talked to a room full of blank faces?

These 4 base sets of human emotions are strong in other's communication patterns. 

Listen for them as a possible way to more effectively communicate with others.

The last slide has examples of the same question asked with emphasis on different human senses.  Enjoy.

Link: Human Senses Presentation on Slideshare

Tuesday, March 28, 2017

Thursday, February 16, 2017

Sprint Reviews and Stakeholders. Something worth discussing by Paul Heidema

I came across this post today from Paul J. Heidema.

It opens up an important discussion related to Stakeholders at Sprint Reviews.

Stakeholder have feelings and want to contribute as much as anyone else. We're all in it together.

Paul brings up some concepts related to getting stakeholders up-to-speed so they can best contribute at Sprint Reviews.

Give it read... 

It may get you thinking...  

What have we done to help our stakeholders feel like valuable contributors to our work?

Thank you Paul for the valuable post.

Here it is...

Tuesday, February 7, 2017

Tech Post: Unit Testing for Distributed Systems

I recently came across this very interesting presentation and article related to Unit Tests for distributed systems and felt it was worth sharing.



From the technical article...
almost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software.

and this one...

in 58% of the catastrophic failures, the underlying faults could easily have been detected through simple testing of error handling code.

This sentence really caught my attention...
In fact, in 35% of the catastrophic failures, the faults in the error handling code fall into three trivial patterns: (i) the error handler is simply empty or only contains a log printing statement, (ii) the error handler aborts the cluster on an overly-general exception, and (iii) the error handler contains expressions like “FIXME” or “TODO” in the comments.

If you are working on distributed systems and are wondering where to put effort in automated testing, it might be worth grabbing a coffee and spending some time on this.

At a minimum, it might have you think about just scanning your code for the word FIXME or TODO in catch blocks and put an end to that !

There's more that I could add, but it's probably best if you just read this article for yourself.