Working Up

by Dwayne Phillips

Agile development is not an excuse for knowing what you did, why you did it, and how you did it.

You’re doing agile development. You hold a meeting to start a sprint (different methods use different names for this). You sprint! You meet again at the end of the sprint.

1. What did you do?
2. Why did you do it?
3. How did you do it?

Question 1: at the end of the sprint, you demonstrated what you did. You should record that in some tool you use for agile.

Question 2: you did what you did because someone asked for it. Again, you should record that.

Question 3: you wrote code, you changed code, you tested the result.

The answer to question 1 almost always happens. The answers to the other questions…well, not so much.

If you don’t know who wanted something, how can you demonstrate that something to them to see if they are satisfied? This requires recording information about who asked for what. I know, in agile, documentation is not as important as working code. But still, come on folks, we write software for a person. If we don’t record the person’s name, how will we satisfy the person?

Now the awful question 3. Can we repeat what we did? Do we have the information as to the data and methods we used to prove that our additions and changes satisfy what was requested? If we don’t, we are wasting time and money.

Note how I used the word “satisfy.” This is why we are working—to satisfy someone else.

The answers to 2 and 3 are met by the systems engineering function of tracing. Everything has a reason, a purpose, a place to fit. Tracing allows us to follow the reason through our work. Work without a reason is, well, unreasonable. Hmm.

Yes, working software is more important than documentation. Use of good tools allows agile teams to document work so it can be traced without doing more work. Let’s be aware of what we can do to satisfy others.

by Dwayne Phillips

We are here; we are gone. Sorry, others will forget us.

I’m sorry, but it will be forgotten, and I will be forgotten as well. Sure, computer technology can store my life, but someone has to pay attention, and that is where it falls apart.

In some library somewhere are copies of some of the books I have written. How long will these libraries stand? When will they dump my books into a bonfire as they convert from paper to something else at the local library?

It is just a matter of time. Again, sorry.

by Dwayne Phillips

Questions are just questions. No offense intended.

“No, I am not trying to be mean. I am asking questions to learn as there are some things I don’t know, but would like to know. Please help me understand.”

“I apologize if you think I am de-railing your presentation. I am seeking clarity.”

“If you don’t have an answer, please say, ‘I don’t have that answer now. I am happy to work with you tomorrow to find it.’ “

by Dwayne Phillips

Excellent maintenance sometimes indicates a faulty product or service. Sometimes, no maintenance indicates a superior product or service.

I first encountered this over 20 years ago. We had purchased similar products from two companies, let’s call them Smith Inc. and Jones Inc. for now.

The conversation went something like…

“What happens when a Smith Inc. widget breaks?”

“We call their 800 number, an expert answers, they talk us through the situation, and if necessary a team of technicians is on the road in 15 minutes and be at our location as soon as possible.”

“What happens when a Jones Inc. widget breaks?”

“Don’t know. Never had one break before.”

So, which product would you rather buy? Which company is better for customer service and product maintenance? Which product would you rather build?

by Dwayne Phillips

I recommend an organization for the future or work as we know it.

This is the new company. It is an agile team that has worked together on many software projects. The Team has learned much on all these past projects. The Team has become high performing (it “jelled” a long time ago). The Team can do what seems to be amazing stuff in a short time.

Hire The Team, not individuals.

How do you hire the team? Simple. Here is their “interface” or contract:

Give us an room (size specified) with Internet access via ethernet ports on the walls (access speed specified). We will bring the furniture, computers, white boards, etc. We setup the room the night before work begins. We’ve done this setup many times and have learned how to do it efficiently.

The Team arrives at dawn—seven persons. You supply someone who can describe the desired product. You pay $10,000 a day.

Life as we know it: Groups of persons work on agile projects. They learn how to work with one another. The group becomes more than the sum of its parts. The project ends; the group disbands, and the individuals go to other groups to work other projects. Start at zero again with the learning and growing.

Life as it could be: Let The Team stay together. Let them use what they have learned. One way to do it is for The Team to form it own company. Yes, this is like “two guys and a truck” and a movie production company and a band that has played together since high school.

Why can’t we do it in software development or in developing any other intellectual product for someone? I suppose there are reasons why the band can’t stay together. Perhaps we can learn from those heart-crushing breakups.

by Dwayne Phillips

We thank the person. We comment on the product. And we let everyone know that is what we do here.

Persons accomplish the work in endeavors. Persons use tools, sometimes they are really cool and expensive ones, but persons ultimately accomplish the work. The outcome of the work is a product (sometimes we call the product a “service”).

So, we have persons and products. How do we discuss them? What do we say to the persons?

I believe we can judge a product. I can hold a pencil in my hand. I can feel it, smell it, feel how it leaves marks on surfaces, see those marks, and sometimes taste the pencil. I can set the criteria for the pencil—how it feels in my hand is more or less important than anything else. I can comment on the product.

I believe we cannot judge the person who accomplishes the work. I don’t know what is in their mind. I don’t know much about the 3/4s of their life that they are not “at work.” I don’t know what and how they feel.

What can I say about the person? Almost nothing.

What can I say to the person? “Thank you.”

I believe this is how we should talk: We thank the person. We comment on the product. We let everyone know that this is how we talk.

Naive? Probably. Common practice? No. Still, I think these are worthy aspirations.

by Dwayne Phillips

Analysts seek to find the difference that makes a difference. What can be vexing is that often there is no final difference.

I believe that technical analysis and the analysis of technical systems comes to one question:

What is the difference that makes a difference?

Is it temperature that makes one system work and another fail? Is it humidity? Is it size, weight, power, color? What is it?

One of the great issues that makes analysis so difficult is that in many situations, there is no final difference. No system will move 1,000 people 1,000 miles in one hour on one gallon of gasoline. No system will move people to Mars in three hours.

Consider professional sports franchises. They draft people to be on their teams. What is the difference that makes Michael Jordon or Tom Brady the one player who will provide long-term dominance for their franchise? A major problem is that there is no one out there who will provide that. Maybe 10 or 20 years from now, some young person will be born with the ability and desire to dominate. Maybe not.

The analysts are searching for someone who doesn’t exist. They fail year after year and maybe generation after generation. The analysts and their methods are despised for their failures.

Continue to look, listen, smell, touch, and taste. Continue to observe. Continue to search for the difference that makes a difference. Understand, however, that there may be nothing to find.

by Dwayne Phillips

Take great care when everyone agrees about something.

Once the world was plagued with the longitude problem. Long-distance sea travel was dangerous and fraught with the great unknown, “where are we?!?!?!?”

Everyone agreed on the solution to the longitude problem. Everyone, that is, except the carpenter who solved the problem. For background, see the Wikipedia article on John Harrison—the carpenter who solved the problem, and the problem in general and the culture surrounding it in another Wikipedia article.

Of course the history is slanted because some people won with the solution and some people lost with the solution. That is the nature of science, engineering, and solving problems. I recommend the hours required for detailed reading. This was a real problem that tilted the world’s economy.

One lesson from this history: Take great care when everyone agrees on a problem. This is especially true when we can’t measure the problem and have to use a lot of approximations and extrapolations.

Consider climate change. The world’s economy rests on this issue. The temperature curves we have use a lot of approximations and extrapolations. The persons doing these approximations and extrapolations are well educated, smart, and caring people. All those people who knew the answer to the longitude problem were also educated, smart, and caring people. They held the great majority of opinion. They were wrong.

This happens with great unknowns. When we “solve” climate change, some people will win big $$$ and some people will lose big $$$. There will be great debate, controversy, and all sorts of grievous vexations.

by Dwayne Phillips

What is systems engineering? One answer is, “you can do it with only a pencil and piece of paper.”

I have been plagued with the question, “What is systems engineering?” for too long. As a job seeker, a common job opening is Systems Engineer. A quick reading of the job description shows that many so-called systems engineering jobs are really system administrator jobs.

Systems engineering job descriptions often have words like: CDR, PDR, CONOPS, requirements, design, eliciting information, DOORS, and RVTM.

System administrator job descriptions often have words like: server, Linux, Windows Server, install, setup, configure, VMWare, and Solaris.

One thing I have noticed about systems engineering:

you can do it with a pencil and piece of paper

I’m not saying that would be easy. Computers and applications make many jobs easier, and systems engineering is not an exception. DOORS and its related products from IBM make the systems engineer job easier, but the job can be done with pencil and paper.

The system administrator job cannot be done with pencil and paper. The system administrator quite simply administers computer systems. You can’t install a server without having the server. You can’t configure a server without a server and a computer terminal connected to the server. The pencil and paper can help, and I find them woefully under-used, but they are not sufficient.

So, when trying to decide if a job should be called a systems engineer or a system administrator, ask, “can I do this with a pencil and paper?”

For a few more details, see the International Council on Systems Engineering at incose.org.

by Dwayne Phillips

One function of systems engineering is to open the black boxes, look at the entire system, and apply some wisdom.

We often build systems by connecting existing systems and subsystems. These existing pieces are black boxes, i.e., we don’t know or don’t care to know what is inside them and how they work. These black boxes have defined interfaces and a history of functioning per these interfaces. These properties allow us to combine them into something that does what we want.

There comes a point, however, when building a system from black boxes doesn’t work or doesn’t work as well as we wish. At that time, the systems engineer opens the black boxes and peers inside. Hmm, we only this this part of this black box. We can discard the rest. That black box, well, we need all of it. That black box, we only need one little part of it. That black box, well, we don’t need any of it given that we are using only select parts of the other black boxes. And so on.

The systems engineer considers all the parts of all the black boxes and applies some wisdom. The result of wisdom is a new system that is more efficient, has fewer parts, is more maintainable, and lots of other better attributes.

The systems engineer’s job isn’t easy, and it isn’t easy to find a person with the required knowledge and experience. The hunt and application, however, are worth the effort.

For more on this and other aspects of systems engineering, see this short, free book on the subject.