The logical conclusions

Monday, 12 March 2012 15:22 Written by Brian Wigfield 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:

My AdventureTech Experience: A Post From “The New Guy”

Tuesday, 31 January 2012 13:37 Written by AdventureTech 2 Comments

Post written by Joseph Davis, Web Application Developer at AdventureTech, AKA "The New Guy"

I first came in contact with AdventureTech in September of 2011. A good friend of mine, Donald Rossberg, had been attending a local business networking event where he met and became acquainted with Brett Gibson, one of the owners of AdventureTech, who was also attending the event. When Donald found out I was passively seeking a new opportunity he arranged a lunch meeting for the three of us so I could meet Brett.

Brett was a very talkative and friendly fellow. One thing that immediately stood out to me in his conversation was his deep interest and understanding of agile development principles. I could tell from the depth of examples he spoke of that, to him and to AdventureTech, “agile” wasn’t just some buzz word they adopted for a season. Instead, it was something they had successfully implemented, that they believed deeply in, and that they had enhanced through multiple experiences with clients.

Some time later I ended up in another lunch meeting, this time with several of AdventureTech’s developers, including Phil Ledgerwood, Troy Tuttle, Lee Brandt, and Brian Moon. I was prepared for a technical drilling as is common with many panel interviews I’ve been through in the past. Instead it seemed they were more interested in telling me about themselves as a company, what they were all working on and what tools they were using in their various projects.

They spoke of Inversion of control containers, object-relational mapping tools, test driven development, and other design and development patterns. Many of these were tools and practices that I had read about and of which I had a fair level of theoretical understanding but had not had the opportunity to put into practice in a professional work environment. The prospect of doing so was very appealing to me.

Until just recently, the team of developers at AdventureTech was composed entirely of very experienced senior level developers, many of whom are involved in the community and give talks at development conferences. Such was their culture and the nature of their team. Now they have begun bringing on some younger developers with the intent of molding the next generation of senior level industry leaders in Kansas City.

They aren’t looking for developers who already know it all, but instead they want people with an aptitude and thirst for learning along with good communication skills. One thing I heard a number of times during the interview process was: “How to write good code? That’s easy to teach. How to teach a person to have good communication skills… that’s something they should have learned in kindergarten."

I’ve been with the team for about a month now and am pleased to report that it is turning out to be everything I was hoping for. Many of the other guys on the team have titles on their business cards like “Software Practice Coach”, “Software Process Coach”, and “Developer Mentor”. I find myself in a place where learning is fostered and supported, and I’m picking up many new things each day. I feel empowered in this environment to be the best I can be and I’m very excited about the future of my career.

In addition to fostering learning and encouraging the use of new tools and technologies, AdventureTech also strives to create a compelling work environment and benefits package that will draw the best developers around. Apart from very competitive compensation and medical benefits, AdventureTech also provides an education and equipment budget so developers can stay sharp, and an extremely generous amount of Paid Time Off that I have only seen matched by some companies for their employees with decades of tenure.

Although I’m still fairly young in my career, I have been through several jobs looking for a place that had everything I was looking for. I’ve finally found that place and I’m proud to be a team member at AdventureTech.

Did you like this? Share it:

The Human Cost Of Deadlines

Monday, 12 December 2011 19:37 Written by AdventureTech 2 Comments

Post written by Brett Gibson, Owner and Vice President of Business Development at AdventureTech

Deadline: Originally a Civil War term for a line that marked the distance a prisoner could go before being shot on sight. (source: http://www.thefreedictionary.com/deadline)

When I see an employee who is asked to guess on a timeframe, be held accountable for such random number theory, and then forcibly held accountable to that speculation – I become concerned.

When I hear an IT department say, "We need to identify these timeframes so we know how much overtime we'll have to put in to make our deadline" - I positively cringe.

Many companies still have an unhealthy "adrenalin-junkie" addiction to deadlines because they confuse them with results. The truth is, and what many companies repeatedly fail to understand, is that they are actually incurring larger costs in the form of waste, technical debt, staff turnover, disengaged employees, and eroded company culture.

As this self-induced erosion occurs, these companies get a reputation in the community as a place to avoid, both from consumers and job seekers.

This tired practice of using wartime models for peacetime business practices is both misplaced and corrosive. Comparing workers to soldiers, projects to D-Day beach landings, and acceptable losses/collateral damage to the greater cause……all of this modern day nonsense eventually erodes the very business continuity and productivity gains they were trying to obtain in the first place!

If the goal is productivity – deadlines will guarantee the opposite. Forcing your staff to meet arbitrary timelines doesn’t build morale; instead it builds an unhealthy camaraderie of mutual hatred, resentment and distrust toward management.

Steady, predictable output, determined from actual metrics, gets you there – and more accurately. Agile principles, when applied correctly, have the ability to turn the tide of the deadline culture while simultaneously creating better work environments.

What company in their right mind WOULDN'T want that?

This year, why not change the way you've always done things? Let your employees enjoy the holidays without the threat of looming deadlines born out of someone’s need for their bonus or misplaced desire for a neatly packaged project completed at year end.

The deadline isn't what's most important.

Did you like this? Share it:

If IT Is Your Business Brain, Then You’ve Got Problems

Wednesday, 16 November 2011 13:58 Written by AdventureTech 1 Comment

Author: Brett Gibson, Vice President of Business Development at AdventureTech

I remember being asked once how shipping and handling was calculated in a client's system. I thought it was an odd question, but I was being asked by a Senior V.P of that company so I thought it best I cooperate. I’d been working there as a consultant for only about 2 months, but there was an expectation that I should know the answer “because it was in the code” and well, I was in the code too.

I think he could see the double-take on my face that said, “So how long have you worked here and been a Sr. VP? You don’t know how your own freight is calculated? Couldn’t you ask your CFO?”

But this sort of business-to-IT dialogue is common. After some research, I was able to look through the code and provide the somewhat convoluted calculation for him. He looked at the calculation and then…get this…he began to press ME as to WHY it was calculated the way it was.

“Who made that decision?”, he proceeded to ask me as if the IT consultant that had been at the company for only 2 months could go back in time and be a fly on the wall when that decision was made.

This scenario is an all-too-frequent and frustrating conversation between business and IT. But who else did he have to ask? Performing a witch hunt for an employee who no longer worked at the company was a worthless pursuit and, even worse, the inter-departmental politics were extremely ugly (Let's just say he didn’t want to ask Accounting.)

So why does this scenario keep happening between business and IT?

It’s inevitable that employees leave companies and that obviously includes IT staff as well. As new employees arrive, the software a company uses is often the only living record of all those historical decisions – both good and bad – and the business itself starts to look at those decisions (wrongly) as an IT responsibility.

But then something even more dysfunctional starts to happen. Not only is IT held responsible for past decisions that were made when they weren't at the table, they are then asked to offer new ones. This continues the cycle of mystery accountability for business decisions as time goes on. Many times consulting, clients are expecting IT to help them not with technology decisions…but with business decisions.

Soon, leadership begins to excuse themselves from the decision table. They start seeing business decisions as coding issues, and this is where a serious misalignment with IT and your business can occur.

In the absence of effective, engaged and decisive leadership, IT starts making business decisions. Which begs the question…..

Should IT be making your business decisions?

Would you call a communications professional and rely on them solely to “create” some pretty words for your website – relinquishing the responsibility of communicating the critical message of your company's culture, services and more?

Would you call a social media company for guidance and then sit back and hope that LinkedIn, Twitter and Facebook would require no effort or input while yielding magic results?

Would you send a sales rep into the field to just “go make me some sales…” without communicating the company message and positioning – hoping that along the way he or she is going to create a company brand for you?

These are all leadership responsibilities. And so too is IT.

Some "leaders" believe that giving money away to IT means that they have paid for a solution and therefore are absolved of all responsibility and accountability going forward. In fact, quite the opposite is true. The more money you spend on something, the more involved you should be to ensure you’re getting what you want.

Creating good software requires close collaboration if you want it to accurately reflect your business needs and daily operation. This should not be performed in an information-vacuum followed by a grand presentation of choices to be adjudicated by the business. If business doesn’t know what they want, or chooses to absolve their responsibility for the decision, you will have IT folks making "best guess" business decisions and your software (and business) will be negatively impacted for years to come.

The bottom line is this: Business leaders MUST come to the table. They MUST be engaged. They MUST be curious. They MUST evolve from their 20^th Century fear of technology.

The role of IT in that disovery process should be PARTNER – not DRIVER.

Leaders need to lead. Your business depends on it.

Did you like this? Share it:

Lean & Agile : A Panel Discussion

Thursday, 25 August 2011 13:02 Written by Brian Wigfield 2 Comments

Today we have short Q&A about agile practices with out esteemed guests Winston Churchill, Albert Einstein, Mark Twain, Martin Luther King, Jr, Gandhi, Bruce Lee, & Franklin D. Roosevelt.

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Churchill: The farther backward you can look, the farther forward you are likely to see.

Albert Einstein: A man should look for what is, and not for what he thinks should be.

Question: Is this because full discovery early on is hard to achieve?

Martin Luther King, Jr.: Everything that we see is a shadow cast by that which we do not see.

Albert Einstein: Occurrences in this domain are beyond the reach of exact prediction because of the variety of factors in operation, not because of any lack of order in nature.

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Gandhi: I do not want to foresee the future. I am concerned with taking care of the present. God has given me no control over the moment following.

Mark Twain: I was gratified to be able to answer promptly, and I did. I said I didn't know.

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Albert Einstein: No problem can be solved from the same level of consciousness that created it.

Mark Twain: Get your facts first, then you can distort them as you please.

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Bruce Lee: Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Albert Einstein: Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Bruce Lee: Learn the principle, abide by the principle, and dissolve the principle. In short, enter a mold without being caged in it. Obey the principle without being bound by it.

Franklin D. Roosevelt: One thing is sure. We have to do something. We have to do the best we know how at the moment… If it doesn't turn out right, we can modify it as we go along.

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Churchill: To improve is to change; to be perfect is to change often.

Bruce Lee: All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns.

Gandhi: Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position.

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Churchill: The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end; there it is.

Mark Twain: Let us make a special effort to stop communicating with each other, so we can have some conversation.

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Churchill: A lie gets halfway around the world before the truth has a chance to get its pants on.

Gandhi: An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it.

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Franklin D. Roosevelt: Are you laboring under the impression that I read these memoranda of yours? I can't even lift them.

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Martin Luther King, Jr.: You don't have to see the whole staircase, just take the first step.

Franklin D. Roosevelt: There are many ways of going forward, but only one way of standing still.

Bruce Lee: Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Franklin D. Roosevelt: The only thing we have to fear is fear itself.

Did you like this? Share it:

Category: Developers blogs

The logical conclusions

My AdventureTech Experience: A Post From “The New Guy”

The Human Cost Of Deadlines

If IT Is Your Business Brain, Then You’ve Got Problems

Lean & Agile : A Panel Discussion

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Question: Is this because full discovery early on is hard to achieve?

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets