The logical conclusions

Monday, 12 March 2012 15:22 Written by AdventureTech 0 Comments

Feeling a bit inspired by the recent DirectTV commericals I figured it's about time to apply the same rational thought patterns to the waterfall methodology.

When have a deadline approaching, you work all night.
When you work all night, you don't get enough sleep.
When you don't get enough sleep, you turn into a zombie.
When you turn into a zombie, you start eating your co-workers.
Don't eat your co-workers, get rid of waterfall.

When you try to generate an accurate project timeline you start guessing.
When you start guessing, you start grasping at straws.
When run out of straws to grasp at, you look for more.
When you look for more straws, you go looking through trash.
When you go looking through trash, you find yourself in a dumpster.
Don't go dumpster diving, get rid of waterfall.

When you plan too much, you can't make decisions later.
When you can't make decisions later, things will need to change.
When things need to change, you need to change directions.
When you can't switch directions, you drive off an oncoming cliff.
Don't drive off a cliff, get rid of waterfall.

When you estimate a feature wrong, your boss wants you to improve.
When your boss wants you to improve, you practice estimating.
When you practice estimating, you estimate how many tacos you can eat.
When you practice eating tacos all day, you spend all night in the bathroom.
Don't spend all night in a bathroom, get rid of waterfall.

When requirements can't change, the customer wants to change them.
When the customer can't change them, the customer gets mad.
When the customer gets mad at you, you get mad.
When you get mad, you go home mad.
When you go home mad, your mother in-law stops by.
When your mother in-law stops by, she tells you everything you are doing wrong.
When she tells you everything you are doing wrong, you punch her in the face.
Don't punch your mother in-law in the face, get rid of waterfall.

Did you like this? Share it:

7 Interpretations of Silence

Monday, 06 June 2011 17:15 Written by AdventureTech 0 Comments

Listen

Listening to clients is at the core of solid communication efforts. This is perhaps even more important to IT professionals than it is to average consumerism because we often deal with complex topics.

But listening is not simply affording someone the courtesy of audience, nor is it simply letting them speak because it’s their turn. The goal of listening is to understand the true nature of a client’s problem. It is an interactive, engaged discussion of discovery whose fruits are clear problem determination and resolution. In that order.

Demanding that any client, user, manager or executive fully explain themselves is not good listening either. It is a poor one-way model for collaboration; it builds fences NOT bridges. When communication goes south, you will probably be faced with silence out of nothing more than false politeness.

Understand that silence and head nodding agreement can mean one of several things:

1 – Mission accomplished

Yes, I’ve understood you!

This is typically the one we WANT to hear, so we presume it to be so most of the time.

The Risk? Potentially none, but ignorance is bliss.

2 – Partial absorption: Requires further baking

“I haven’t understood you completely, and I’m still attempting to process all of what you’ve told me. I might require more time to fully understand all this information, and may have questions later when some of it starts to sink in. I might ask you again, but then again, I might not…”

The Risk? Partial knowledge or interpretation means the client will fill in the missing pieces with what they *think* they heard. Those assumptions will come back to bite you – especially if they choose not to reengage the dialogue.

3 – Looking the fool

“I haven’t understood you, but I don’t want to look foolish in front of you because you act like your time is important – OR – I haven’t understood you and we are in a group setting. I don’t want to look foolish in front of my peers, boss or subordinates. They’re all nodding their heads and seem to get it, so I’m hoping someone will explain it to me later in language I understand.”

The Risk? No one likes to feel they haven’t understood something. Fear of asking important questions early leads to a paralysis of activity and co-operation later.

4 – Research required

“I haven’t understood you completely, and am hoping to research this all a little further to fill in the gaps myself. I have some lingering questions that I believe I need to ferret out myself.”

The Risk? IF a client takes it upon him/herself to get educated on your topic, understand that it is still potentially non-communicated. You won’t know if they actually performed any due diligence, so you cannot assume they did from silence.

5 – Wait and see

“I’m a practical/visual type. I’m hoping that later on, when I actually see this all in action that it will finally make sense. I’ll let you continue your speech and involve myself when this idea is made reality, and then provide feedback.”

The Risk? While you now believe that everyone has signed off and will start on your plan, this individual is withholding his/her vote of acceptance until it’s actually up and running. The potential waste of work here is high, and the 11^th hour death-marches start with this definition of silence.

6 – The personal touch

“What I’m hearing is that later, you will hold my hand in this process and personalize it to me. I’m expecting that you will follow up with me personally, and your speech today is just an introduction.”

The Risk? Personal touch types cannot work from pieces of paper, emails, phone calls or boardroom presentations. They require face-to-face communication and an emotional connection to a concept. Without that personal touch, this type of individual will fail to engage. Silence of this kind is in the form of non-communicated, assumed, personalized expectations.

7 – Assumption of ownership

“I’m assuming that you are just explaining this to me out of full disclosure, but that you will actually be the one doing it because you’re the one giving the speech.”

The Risk? What this individual has heard, is that you are in charge of this entire process. They expect to be managed rather than a willing and active team participant exercising initiative. They expect that you will be the one both watching to see if a ball is dropped and catching it.

And the list goes on…

If you are the type of individual who always believes that silence and/or head nodding means #1, your professional life will prove to be a frustrating one. Do not attempt to interpret the meaning of silence – you will fail miserably and it will only serve to dismantle trust and foster antagonism.

Do not place the burden of silence on the client. When you hear silence, flush out misunderstandings with empathetic, engaged, courteous dialogue. When you see a look of mild puzzlement on a clients face – ask questions and try another angle. It means that at least one thing you have presented did not click with them.

The responsibility is on you to facilitate a solid understanding with your audience not for them to simply participate as spectators of your speech.

Silence is a red flag. Know how to spot it and use it to create a positive client experience.

Did you like this? Share it:

Modern Day Software Development: “Making Change Difficult” – Part 1 of 2

Tuesday, 12 April 2011 10:24 Written by AdventureTech 0 Comments

No two software development efforts are the same. We live in a world where…

The cell phone, computer, iPad and TV purchased today are obsolete shortly after you walk out the door.
The marketing campaign that worked yesterday falls flat today.
The brick and mortar stores of yesterday are no match for the online storefronts that savvy entrepreneurs have up and running (Google Fiber as just one example).

Change is the rule in the 21^st century and software is certainly not exempt because every software development effort involves businesses, people, and technology.

-Businesses live in an ever-changing, ever-evolving landscape of both their market and the vendors that they partner with.

-People rarely work for organizations for 20+ years and instead change jobs and industries much more frequently than at any time in history.

-Technology is the largest culprit in this ecosystem of change we find ourselves immersed in today. It moves at a pace that even the most techologically savvy people have a hard time keeping up with.

None of these pieces to a custom software development effort are easy to nail down. Those of us in the Information Technology world have been attempting to minimize this problem for as long as we can remember.

So how is change traditionally dealth with? Below is how it currently works with most software development companies. In a future blog post, we will address AdventureTech's recommended solution…."Embracing Change."

Modern Day Traditional Approach (That Doesn't Work!) – "Making Change Difficult"

A logical conclusion to the fact that change occurs is to put processes around software development efforts that mitigate change (which is a nice way of saying “Let’s make change difficult.”)

While that may make sense on the surface, we would argue that many haven’t thought deeply enough about this issue to come up with a truly logical conclusion. It's the "it is what it is" approach vs. "why is it this way and is there a better way to do it?" approach.

A process-heavy approach involves gathering detailed requirements upfront followed by building, testing, and deploying the software. The honest truth about this approach is that it doesn't make much sense in today's software development world. You can muddy up a project by being TOO process-heavy or bureaucratic. The focus turns away from "what makes sense here" to "this is what the process is and we can't deviate from it".

Gather detailed requirements upfront

There are many goals in the requirements phase of the Software Development Lifecysle (SDLC). A simplified goal might be stated as making sure developers know what they are building and the business knows what it is going to get.

The unfortunate aspect of this phase is simply the overwhelming nature of the task. In methodologies like this, requirements gathering may easily take up to half of the overall scope and budget as it is where most of the work is done. For a company waiting for a piece of software to improve its business, that delayed delivery may be a heavy burden to bear.

Not only that, if we KNOW things change, writing specs for requirements that are going to change is a waste of both time and money which leaves only inefficient bureaucracies with huge budgets and little sense as the only logical customers left. This phase also involves the following:

Include everything the software will need to do now and in the future

This is probably the most challenging aspect of software development using this methodology. It challenges the business to know what the future may hold which if the truth is we live in a culture of change, may be a next to impossible task.

Carefully document and spec out those requirements

Many times this documentation is used to pass down to the IT staff so they have a clear understanding of how and what to build for the client. Now it may be a surprise to some of you but developers tend to have a somewhat limited ability to communicate outside of their own species. We know because we have worked around them our entire careers. With an approach favoring documentation over human interaction, misunderstandings are typically difficult to head off.

Get approval and sign-offs from all key stakeholders

The purpose of this is for the protection of both the client and the software provider. While its goal is to actually assist with the client-vendor relationship as everyone should be on the same page, it has been our experience that it tends to lead to an antagonistic relationship instead. It leads each partner in the relationship to point back to sign-offs and approvals as ammunition in a disagreement.

Begin build out of software

The least important aspect of this particular process – need I say more.

Not enough of a reason to vilify this process you say? Then let's think through their typical heavy change control process.

Change is found to be necessary to software
Documented summarization of reason for modification must be submitted
Analysis must be done and submitted by IT and stakeholders
Sign-off by appropriate stakeholders to approve or deny the change

The primary purpose for this complex change control process is to protect the software provider from the cost overruns that occur as a result of change. The secondary purpose is to provide visibility to the customer and to make sure they know what they are doing and how it will affect the overall cost and scope.

From our perspective, this continues to be just another thorn into the relationship that exists between both parties. (For example: A software provider is building a role based security module into an application. The customer assumed this module was going to be built utilizing their existing Active Directory infrastructure already in place. Since it wasn’t called out in the approved documentation that way, the software provider may insist on a change request which equates to more cost and a scope change thereby putting the customer and vendor at odds.)

Test software

Now we have no problem with testing and would only encourage it but this one is always confusing to us. In this methodology, we have reached the end of the project and perhaps the budget, but there is a bug. What do you do? While we are glad they found the bug, now another possibility for conflict exists between the software provider and customer. Perhaps the contract will elaborate more clearly on what the correct solution is for this type of issue. But if it doesn't….watch out.

Stay tuned…"Embracing Change"

Stay tuned for Part 2 of this series titled “Embracing Change”. If you just can’t wait, you can get a sneak preview in one of Troy’s latest blog entries.

Did you like this? Share it:

Sausage making

Tuesday, 29 March 2011 14:08 Written by AdventureTech 0 Comments

Taking the pulse of your community sporadically is helpful. Sometimes, it’s more helpful to detach and take the pulse of another community.

I'm a fan of Anthony Bourdain – he's never short of opinions and insights.

Here are 2 conversations from his No Reservations show I thought applicable to understanding both developers and our landscape.

Chef Brian Polcyn: “Practicing Charcuterie is like a lawyer practices law or a doctor practices medicine. You don’t stop, you don’t stop learning! That’s what’s so exciting about it. There are so many variable conditions that could cause success and failure. There is NO formula – what I’d have to teach you is the mentality about the respect of the ingredients and the food and have you understand that principle and that’s what I have you do here in the classroom.”

“You know that old German saying right, that there’s 2 things that you absolutely need but you don’t necessarily have to know –

How they’re done

Legislation of sausage making right?”

Bourdain: “Right – well they also say, everyone likes policy making and everybody likes sausage but few people like to see how either of them is made…”

The analogy to developing software and its relationship to our audience is sometimes sausage making… Often, people simply don't want to know and just want to get a finished product. There's a lot more room in that picture for education as a pathway to success.

This second observation I believe is true for our marktplace – just substitute developer for chef and see what you think.

Bourdain: “What this show is really about is customers are a hell of a lot smarter and sophisticated than we give them credit for. It’s a new world that we live in now – and I think it’s important to recognize that it’s happening – whatever it is that’s happening – maybe for the first time in history – in this country – chefs are actually being appreciated for their best efforts rather than punished for them and that’s been a wonderful shift.”

Did you like this? Share it:

Fighting atrophy

Friday, 18 March 2011 10:17 Written by AdventureTech 1 Comment

You have ideas and beliefs on how software should be developed and you spend hours a week researching the newest development practices, going to conferences/user groups to hear experts talk about a subject that challenges what you thought you knew. When you finally start to get “on board” the sources you were taking your inspiration from before now are telling you something else, in direct opposition to what you just learned.

The truth is that you were doing it wrong before, your doing it wrong now and you will be doing it wrong tomorrow. This an important realization that you need to grasp before you can continue to grow as a developer, the ability to accept that you don’t have the best answer but you are willing to fight towards it using what you know today. But just because you know you are not right should not stop you from acting like you are, developing software is an an exercise in learning and you learn more from being wrong that you do from being right.

To quote House when asked “How is it that you always assume you're right?” he responded "I don't, I just find it hard to operate on the opposite assumption. And why are you so afraid of making a mistake?”

The longer you are involved with software development the harder this is to swallow, you have a tendency to believe that once you reach a certain maturity in your career that you just have it figured out.

To me a graph of the continuous evolution of software would look similar to this. With every new wave comes good useable ideas & techniques that should be kept but without knowing when it has reached the apex you will continue to follow it down the rabbit hole until until it leads you to a place you don’t want to be. If you do this very many times you will convince yourself that the newest fad in software development is not worth following because you have been burned by trying to be on the “bleeding edge” before.

Depending on your situation, how much risk you are able to take on will vary. It is understandable that not every business can afford to follow the movements and instead decide to stick with the establishment, however you must not find yourself stuck below the orange line watching all the movements come and go without integrating lessons learned from the people who are taking the risks.

If you are in the movement don’t get discouraged that you must take one step back to take two steps forward.

If you are in the establishment, what you hold dear today came from a movement yesterday, so don’t forget to pay attention to what’s happening around you.

Did you like this? Share it:

Category: Business Development

The logical conclusions

7 Interpretations of Silence

Modern Day Software Development: “Making Change Difficult” – Part 1 of 2

Modern Day Traditional Approach (That Doesn't Work!) – "Making Change Difficult"

Gather detailed requirements upfront

Begin build out of software

Test software

Stay tuned…"Embracing Change"

Sausage making

Fighting atrophy

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets