Okay, picture this. You’re sitting in a coffee shop across the table from your prospect. You tell her “Hey I’m excited out of my mind about this new business I started. The products are fantastic and the opportunity is once-in-a-lifetime. I know you’re going to join me or at least become a customer.” After your […]
Suppose you have a software development project that will take you one year to complete. What if you broke the work up into two projects of six months each? Which approach would be better? Would it make a difference? What if you broke the work up into four three-month projects? What about six two-month projects? I could go on, but you get the point.
If you’re like me, you may be thinking “what difference does it make as long as the software gets developed?” If so, keep reading. You may just change your mind.
If you execute the software development effort as a single project, you have to wait twelve months before your product gets into the hands of the users. For twelve months, you will have developed software without the benefit of the one thing that only users can give you…feedback. Breaking the project up into smaller projects allows you to have the benefit of user feedback from previous “chunks” with each successive “chunk”. Feedback is essential to learning. Smaller projects means shorter feedback cycles which means faster learning. In other words, you get smarter! Longer projects…well, now the title of this post makes sense!
Lessons Behind the Wheel
Still not convinced? Imagine you’re learning to drive a car. Maybe you over-steer. Perhaps you drift out of your lane and hear the “bump, bump, bump” of your tires rolling over the road reflectors. Whatever you do, you’re probably getting immediate feedback – probably from the screaming person in the passenger seat! Now, imagine trying to learn how to drive if you had to preset all of your acceleration, steering, braking and turning moves ahead of time – say for twenty moves at a time. Few automobiles would survive long enough for anyone to learn how to drive.
Start Small for Big Results
I admit I am no expert on agile software development methodologies, but isn’t delivering working software on short schedules one of the core principles? If so, it would appear that agile software development supports faster learning. You may not be ready to jump in and adopt an agile methodology, and that’s okay. But why not look at the next software project you have to plan and look for a way to deliver it in two shorter parts instead of one long part? It’s a step in the right direction and if you learn from the experience, you can try to go for even shorter cycles.
What about you? Do you plan to apply agile techniques to your software development? Have you already adopted agile? Do you think going agile might make you and your organization smarter?
After experiencing some success implementing lean “Six Sigma” practices on their own, a manufacturer of audio cassette tapes called in some outside help to take their process improvements to the next level. The consulting engineer was no stranger to this process and diligently went to work. He observed the operation, consulted with key staff, and before long, mapped out his customer’s processes and completed his work with detailed documentation of the sources of waste and corrective action plans. As he reviewed his findings, the engineer couldn’t help noticing his customer’s excitement at the potential efficiencies he would gain and the money he would save! Finally, after reassuring his client the efficiency gains and money savings were real and attainable, he hesitantly asked…
When Inefficiency is Needed
Shift Focus to Avoid the Trap
- How does my organization provide value to its customers?
- How does the technology I provide or maintain directly benefit our customers?
- How can the technology I support or provide incresase the value provided to our customers?
- What technology would benefit our customers the most if only it existed?
image credit: CowGummy
The first step in mastering anything is to get a firm grasp of what the thing is. For this reason, I felt it would be fitting to begin this blog, which primarily deals with data, with a few definitions related to data.
What is this thing we call data? We deal with it every day, but how do we define it? Wikipedia defines data as follows:
The term data means groups of information that represent the qualitative or quantitative attributes of a variable or set of variables. Data (plural of “datum”, which is seldom used) are typically the results of measurements and can be the basis of graphs, images, or observations of a set of variables. Data are often viewed as the lowest level of abstraction from which information and knowledge are derived.
For me, this definition is a good start, but I crave something simpler for a working definition. Data are facts about things that can be observed or measured, recorded outside of the context where they naturally occur. In other words, data are facts without context. Examples of data would be 120 pounds, $33.57, blue, or the answer to the ultimate question of life, the universe, and everything when the ultimate question is unknown (if it is even knowable at all)!
One of the things I do like about the Wikipedia definition is that it states data are the basis from which information and knowledge are derived. This leads to another question. What is information?
If data are facts taken out of context, and information is derived from data, then a definition of information is: data placed into context. But wait, the facts were already in context before we messed with them in the first place! Aren’t we just going in circles? Not really. By taking the facts out of context and then putting them into context we can assemble the data in many different ways to reveal relationships and interactions that may not have been visible in the original context.
Now that we have working definitions of data and information, what is knowledge? How is knowledge different from information? I found this concept to be a bit trickier and required a little more thought to come up with something satisfying. Information puts facts into context…when where how what why and by whom. How does information become knowledge? Since knowlege is something you know, information has to get into someone’s head before it can become knowledge. So perhaps we need to understand what it means to know something and then we can figure out how to structure information so it helps people achieve this state of knowing.
A friend of mine once made this statement to me about knowledge. He said “If you really know something, you can draw a picture of it.” As I contemplated this statement, my mind went to the whiteboard in my office and the many others like them in my coworkers offices. Each one had scribblings and visual representations of various concepts. I saw a lot of truth in what my friend was saying, but I would still refine the definition a bit. I would replace “draw a picture” with “model”. A drawing is only one type of model. While knowledge can be visually modeled in a diagram, map, or chart, it can also be modeled by a document, recipe or actions as well. A model – any type of model – serves to communicate knowledge from person to person. So, if information is to be transformed into knowledge, it must be assembled into a communicable model of something knowable.
If you’re fortunate enough to derive knowledge from data, the knowledge you gain is only as good as what you do with it. To me, wisdom is simply knowing and doing the right thing at the right time.
Data are facts out of context.
Information is data placed into context.
Information cannot be assembled directly into knowledge, but it can be assembled into a model to communicate something knowable.
Wisdom is knowing and doing the right thing at the right time.
Now it’s your turn. Which definition will be most useful to you in your life and work? Which definitions can be improved and how? Where did I totally miss the boat?