Aaron Worsham | Sazbean

Aaron Worsham / Mar 11, 2009

To pique their interest

flock Media Post ran an article last week touting the power of the ‘Mommy Bloggers’. The argument was that, according to uncited research, a large percentage of mothers in the U.S. use the web to give and seek advice on products and services for their children and families and that this group should be respected for their influence. Is anyone actually surprised that women today still hold purchasing influence in the home or that they consult each other for advice? Does the addition of the Internet really make this something we haven’t seen before? It seems more likely to me that creation of the ‘Mommy Blogger’ is more about collective advertising and less about collective bargaining.

It only makes sense that the media will want to classify on-line patterns into easily digestible generalizations because when they need to market themselves to advertisers they have only so much time to make their case. A website that covers teen celebrity is indistinctly after a different demographic than one that chronicles the latest senate changes in Medicaid reimbursements. The first might be self-labeled a ‘Tweener’ site while the other may pitch itself as a ‘AARPaphile’, and they will each use these terms to preen for the advertisers interested in capturing eyeballs in their respective markets. The unfortunate consequence for us comes when those same media sites take those generalizations that they have invented and bleed them on into their own content, dispensing adhoc marketing shorthand as actual class systems. The term ‘Mommy blogger’ has become a Bona Fide marketing demographic like ‘DINKs’ and ‘YUMPies’ a decade before. While the Gen Xers and the Gen Yers get to fight it out over who’s group is more disenfranchised, the new kids on the block are taking over the hearts and minds of the advertising intelligentsia. It may sometimes be nice to be advertised to in a targeted way, being a demographic is a far stretch from being an organized community with clear objectives and goals. The latter is a conscious choice, the former is not.

Two weeks ago I was a senior member of the highly coveted 18-34 year old male target audience, courted by razorblade manufactures and game developers and mens fashion designers. I was loved by all. Then last week I past beyond those golden shores on into the 35 – 49 year old middle-aged demo, a muddled mix of male enhancement pharmaceuticals and retirement consultations. Its like the island of misfit toys over here. My spending habits haven’t changed much in two weeks, but my statistical significance has taken a nose-dive. There is a danger in thinking that demographic has any real influence when a single day can separate the top of the world from the bottom of the barrel.

Photo attributed to russelljsmith

Aaron Worsham / Feb 27, 2009

Scrum, Agile, Extreme – when programmers get ahold of a thesaurus.

agile Computer people just love to name things. The server guy who names all his machines after Star Wars characters competes with the network guy who names all his routers and switches after Star Trek characters to see who has the more obscure references. Usually the Desktop guy wins with his collection of Windows PCs named after Transformer characters, but that’s beside the point. It sounds like it is all in fun, but there is a very important reason we all do it. Technology is hard for humans to relate to. It is cold and lacks personality. Names help give definition to the undefined. They help give things context.

Programmers, being computer people, really get into the naming of languages and processes. I’d like to take this post to identify and briefly explain some of the terms you may have heard your programmers using.

Agile development

If San Francisco could be considered not just a place but a lifestyle, Agile development would have a similar vibe in the programming world. Typically it refers to the 12 guidelines people in software teams follow when working together on software projects, though there are widely different ways to actually put those guidelines into practice. The ideal behind an Agile development team is that it is small, it meets all the time with each other and with the clients, and it writes code in small chunks that the customer sees working every couple weeks. Agile was a reaction to the inflexibility of older programming procedures that didn’t allow the customer any flexibility to change their mind late in the delivery cycle. Since customers are constantly rethinking their needs, Agile was developed to allow the code to change with the requirements. Below are the 12 principals of the Agile Manifesto.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum

HR, Sales and Accounting may have meetings, but only programmers can take the basic idea of getting together in the same room and rename it a ‘scrum’. Borrowed from the term used to describe a huddle in rugby, a scrum is a highly organized, short daily meeting of all people involved in an agile project. It has the singular goal of keeping people focused on the project, which is really important since a ‘sprint’, or stretch of time allotted to write working code, is usually only two weeks. Guidelines for scrums can sound harsh, only three questions are asked, everyone should remain standing, only people with a stake in the project should speak, but it was invented in direct contrast to pointless time-wasting mega-meetings that the Dilbert comic made an empire satirizing.

Extreme Programming & Test Driven Development

Who wouldn’t want to work on an something with the word ‘Extreme’ in it, huh? Extreme Programming (XP) is very similar to Agile, or it might be more accurate to say that it is a good case study of Agile programming before there was such a term. The real big take home from XP that sets it apart is its absolute devotion to the idea of testing. Now, as a lil programmer, I thought testing code was for suckers who worked government jobs. Then I was turned onto the wonders to full stack testing and how it changed my whole outlook on my craft. Testing is really the only way to write Enterprise ready code. Some guys saw that if you wrote your tests first, then wrote code that made the tests pass, your applications would have fewer bugs. They called it Test Driven Development (TDD). Turns out testing is becoming the rock star of the programming world thanks to web frameworks like Ruby on Rails and Symfony having it baked into the package.

This post just scratched the surface of the terms programmers (and computer people) love to throw around. If you know of a term that you want a little help with, add it down in the comments and I’ll try to reshape it into something that hopefully makes more sense. I’ve been known to use puppets with clients before, so anything’s possible

photo attributed to Foxtongue

Aaron Worsham / Feb 26, 2009

What were they expecting?

Succeed at managing your customers expectation and you can never fail. Fail to manage your customers expectations and you can never succeed. ~ me

This is one of my all time favorite universal lessons I have gleaned from business. There isn’t really any part of my life that involves other people which doesn’t benefit from the practiced art of managing the expectations of those I’m interacting with. When another human knows exactly what they can expect from you, on your terms, and when you consistently meet or beat that expectation on their terms, you have set the stage for a powerful ally in business; trust.

The reason this is so important is because people on a whole are very self-referential, which means they see their own perceptions and actions within the conversations and interactions they have with other people. Imagine two people talking business over lunch. The speaker could say ‘it will be a short project that we can deliver with limited resources and for a reasonable amount of money’. The listener will build context around the statements with their own assumptions, drawn from their own experiences of what is short, limited and reasonable, that will ultimately create very different picture than the speaker meant to convey. At that moment, an expectation was set in the mind of the client that may or may not be ironed out in the contract negotiations but will greatly influence the customers satisfaction when the project is completed.

I worked with a fantastic colleague on the team that had a very bad habit of responding to challenging technical requests with an automatic ‘Not sure yet, but that should be doable’. What he meant to deliver was ‘It SHOULD be doable, but of course I won’t know until I work on it” and what the customer heard was “That WILL be EASY and there is no reason it won’t be done on time”. So when said colleague moved heaven and earth to deliver on what turned out to be a very difficult task, the customer was unimpressed. They had already expected it to be done without effort and was maybe a little disappointed that the colleague didn’t work on some of the other, less important features. This is what I would call a ‘Technical win and an Expectation fail‘

Here are some tools and tricks I use when working with other people to help set the expectation

Pictures and mockups. When you are working in the web industry, their really isn’t an excuse to not mockup what you are seeing in your mind for the customer. A tool I like to use is Balsamiq, which is a Flash based web mockup framework that is quick and easy to use
Agile Development. The agile process focuses on rapid delivery of code, typically every two weeks, that gives the customer something to wrap their head around. I think Ill do a full post on agile tomorrow
Closing summaries. When I talk with customers, I have developed a technique of always closing out a conversation by saying ‘So, what I understand you want is…’ and just re-summing everything you’ve been talking about. Etiquette might frown on dragging on a conversation past what the listener wants to endure, but I almost always find mismatching expectations in the closing summaries.

What do you do to manage someone’s expectations?

photo attributed to polandeze

Technorati tags: software, software development, software management, agile, agile development, customer-centric, customer service

« Previous Page