Rich – Page 10 – In Search Of

Goal Strategy Policy

Posted on March 15, 2013Leave a comment

IT Strategy – what do those two words mean together? What do we mean when we say that we are working on IT Strategy?

In a prior post Vision Strategy Policy I talked about the relationships between Vision and Strategy. I also talked about how goals can relate to vision or strategy, and what I think that means.

So now I want to define IT Strategy – I would insert the word delivery, yielding IT Delivery Strategy, to make it clearer what we are talking about. We are talking about delivering Information Technology capabilities to some customer (internal or external), and how we will organize ourselves to deliver these capabilities.Continue Reading

Top 5 Reasons to use Sequence rather than Priority

Posted on February 6, 2013Leave a comment

I influence software delivery. Software delivery is abstract and complex. It is abstract because most people don’t really understand what happens behind the bit curtain. It is complex because it requires the translation across many layers of abstraction and back and sometimes the value is lost in translation.

I say that I influence it, because my job is to increase the probability of success. To make projects more effective. I do not manage the team. I do not decide the deliverables. I do not even run the process. I do not write the code, very often.

What I do, mostly, is give delivery teams ideas and concepts that can help them increase their probability of success. What I do, secondly, is to convince their customers that those ideas are important, and that their (the customer’s) role is as or more important in the success of the delivery than the technicians who are writing the code.

What is my number one idea? Sequence! Continue Reading

The Slide

Posted on January 31, 2013Leave a comment

Did ya ever work on a project that seemed like the schedule was too aggressive? Where the team had to constantly fight to stay on schedule, and to keep moving forward? Where things maybe got behind and we piled more resources on to catch up? Where things felt bad, but we kept on fighting until…

…it was too late. Like in baseball, when the only way get on base is to slide in? Like in football, when you just need that one more yard, and you then turn it over?

The thing is, software development isn’t a sport. We don’t have an opposing team. We don’t have a team owner or coach. Software development is a business activity. It is an activity of manufacturing, of logistics, of research and development and of analysis.

The enemy is risk. In order to defeat risk, we have to understand where risk comes from, and we have to understand how to retire it. Risk is tricky because it costs you little (or nothing) to carry it, but much to quantify, even more to retire it, and potentially even more when it is realized.Continue Reading

Yak Shaving Unleashed!

Posted on January 20, 20133 Comments

Yak shaving is the time honored tradition of needing to complete tasks that relate more to the path we have chosen than to the goal we seek.

My most recent incident involved upgrading my wife’s version of Adobe Lightroom on her iMac. My wife is a professional photographer, and she uses Adobe Lightroom to develop and organize her images. She had decided to prepare a “cheat sheet” for herself for the most common tasks, so she could make sure to be more consistent in the way she does things. She decided, though, since she was a version behind on Lightroom to upgrade to the latest and use that to make the cheat sheet, and that is where the trouble started.Continue Reading

Semantic Collision

Posted on December 27, 2012Leave a comment

Sometimes when you talk about application software, you find that the technicians and the customer are agreeing but don’t realize it. This happens when each party says something that is essentially the same semantically, but they don’t derive the same meaning from it. I have been in that situation many times, because of misunderstandings of the domain semantics or ambiguities in domain semantics.

Other times you have the opposite effect, where the technicians and the customer appear to be in agreement, but have different understandings of the problem or solution, so while all are smiling and nodding – there will be some time when, subsequently, they all realize that they missed something.

One of the reasons that these kinds of miscommunication happen is when the same term has meaning in multiple domains, and different people assume that they know which domain is in play without qualifying or clarifying it. These collisions, where a term has meaning in multiple distinct domains that are relevant in a conversation are sometimes very hard to detect. It feels like a wormhole opened in the conversation and we jumped from one domain to another without realizing it.Continue Reading

Semantic Overloading

Posted on December 21, 2012Leave a comment

I spend a lot of time with software developers. Most of the time I spend is clarifying semantics between business domain and technical domain. Semantics have to do with the meanings of words or terms. In the business domain, when semantics are ambiguous it is often context that allows us to clarify. I work hard to clarify terms that users posit to describe the entities and operations we are modeling in the software we use.

When words are “overloaded” it is hard to avoid being confused because we use the same word to describe multiple distinct entities or operations or operational states. Much of the overloading occurs because “qualifiers” are embedded in business context, so to the business staff, the qualifiers are unnecessary.

Sometimes, though business people actually use the same word differently in the same context and you end up with a buffalo.Continue Reading

Just Good Enough

Posted on December 6, 2012Leave a comment

Just Good Enough. That is what we need.

I need code just good enough to work, then you can make it beautiful, after its working.
I need requirements just good enough to start a conversation, then we can refine and revise.
I need architecture and design just good enough to ensure feasibility for a delivery cycle, then we can harden, and make it more robust.
I need plans just good enough to get started, then we can add detail and revise ad nauseum.

—
If you want to go fast, you need just good enough. Sure just good enough may not be good enough for ever. Just good enough to start may not be good enough to finish. That is the point.

In order to work using the Just Good Enough principle, I need people who are willing and able to deal with the emergence of information, who can adapt to new information without having a nervous breakdown. Continue Reading

What To Start

Posted on November 13, 2012Leave a comment

There are lots of people talking about “startups”. The talk is about starting a small tech company. Its interesting to techno-weenies, because of the potential payoff. I think that starting a small tech business is interesting to many because of the freedom, control and autonomy. But I am not only talking about a business. When I think of starting, I think much more broadly.

There are many other things that you can start. The universal requirements for starting are:

1) Motivation
2) Vision
3) Time

But this post is about what, so lets just throw out some ideas. Lets just get rolling and think about the consequences later….Continue Reading

A Fast Start

Posted on October 30, 2012Leave a comment

Sometimes, you have to get something started. At work, at home, where ever. You are starting something, because there is nothing. If there was something, you would just use it, do it, enjoy it, etc. Sometimes you can start by picking up where others have left off. Other times, you can start by putting together pieces that are unassembled. Once in a while, you have to start completely from scratch.

Starting from scratch is overwhelming. It can be overwhelming because you don’t know where to start. It can be overwhelming because you don’t know how to finish. It can be overwhelming because of all the things you don’t know yet. Starting is overwhelming because of the Unknown Unknowns. Continue Reading

Problem Solving Revisited

Posted on October 23, 2012Leave a comment

Why is it that you always find the cause of a problem in the last place you look? The correct answer, I think, is because when you find it, you stop looking. This post is a response to a conversation that I had with a manager I work with. We were talking about why people (software developers) take too long to correct software defects. My response was that often it is that they are lacking a problem solving framework that keeps them focused.

In my experience, there are two key behaviors that act to slow down problem solving:

1) Getting Stuck – not knowing what to do next or how to do it. This happens when I don’t know enough about the technical domain or the business domain of the product that I am working on.

2) Rabbit Holing – becoming focused on things that cannot lead to a solution of the problem at hand. This happens when I either don’t know that there are other possible causes for a problem, or I am unable to effectively evaluate the probability of a potential cause, or understand the cost of proving that something is the cause of the problem. Continue Reading