From the monthly archives:

February 2008

If you claim to be agile, then be agile

by Eric D. Brown on February 29, 2008

As some of you may know, I’ve talked about agile methodologies in software development in previous blog posts (see links below). The topic of Agile methods still seems to be quite hot these days and many organizations want to ‘go agile’ and many vendors sell themselves as being ‘agile’.

This is great….but many of these same organizations and vendors don’t really understand what it means to be agile and to use agile methodologies in projects. It isn’t just about having a daily scrum or developing in iterations…it also includes working with your teams and clients in a more agile way and involving those people throughout the development process. This involvement of clients is a key piece of the agile world….but some organizations just don’t get it.

I’ll use an example from my past to illustrate:

I had a vendor working for me to develop a software product. The vendor was selected based on experience, recommendations and the fact that they were user iterative development methods. I spoke to them about their iterations and methodologies and was given the rundown of how they do daily scrum meetings every morning and are very agile in their approach. This was great news to me.

The project was scoped and approved and the vendor began the development process. As part of the expectations that I set at the outset, the vendor knew that I wanted to be very involved in the iterations and they agreed to do so. The day of kick-off came and went…and then another few days went by with very little communication from the vendor (and a few emails & phone calls to the vendor from me).

A week passed with no communication….I was a little disturbed but I thought that the 4 week iterations must have the vendor extremely busy and that I’d hear from them the next week. The folloing week came and went (2 weeks since kick off) and I had heard very little from the vendor and zero insight into their progress.

During the 3rd week I was finally able to get some time with the vendor’s project manager (note to vendors: don’t ever let 3 weeks go by without speaking to your client!) and he told me that they were still in ‘definition mode’. Huh? They had the requirements for the first three iterations….why were they in ‘definition mode’? What in the heck is ‘definition mode’ anyway?

I asked the project manager what he meant by this and he said that their first ‘iteration’ was always a project definition and requirements gathering mode and then they would move into development.

I asked him to look at the scope of work and explain to me where it says that the first four weeks would be spend gathering requirements. He couldn’t find anything like that but said that it was common practice for them.

If I had the decision making powers, I would have went to another vendor…but that wasn’t my call…the decision maker liked this vendor and so we stuck with them.

After 6 months of development and many discussions about what agile/iterative methods are and questions about when I could see some output from the iterations,, we were finally able to see the ‘finished product’….and it wasn’t anything like what we asked for or needed.

My boss finally allowed me to close the door on that vendor and bring in a few software developers to tweak the product. We were able to get what we needed out of it with another two months of work.

Funny story about that vendor…they finally stopped using ‘agile’ to sell and went back to their old waterfall methods and they are doing well. They have some good people on board but they were trying to be something that they weren’t.

The point of this story? If you claim to be agile, be agile. Don’t use agile and iterative development methods as a sales tool and then try to sneak waterfall methods into the project. Truly embrace the agile methods and in turn, embrace your clients and involve them in the development process. You’ll save yourself a lot of time, money and heartache.

Oh…and if you want to use waterfall methods….go right ahead. Take the same advice to heart though and embrace your clients during the development process and your projects will turn out much better than if you try to develop in a black box.

A few more of my posts on the subject:

[tags] Agile, Iterative Development, Client Management, Project Management [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 5 comments }

Going Live…

by Eric D. Brown on February 25, 2008

I’ve been a little quite lately due to being extremely busy with the Boy Scouts of America. We recently migrated the main site from a flat file HTML system to a content managed system using Sitecore CMS. The migration was a learning experience due to Sitecore’s completely customizable architecture…but…we got it done.

The new site (you can see it at http://www.scouting.org and compare it to the old site at http://old.scouting.org) went live on Tuesday Feb 19 and has been very stable. We’ve had a few minor hiccups (broken links, etc) but overall, it’s been good. The front page is 100% html and the rest of the site is 95% Sitecore driven…the front page will continue to morph as we change the design and add a few more Sitecore driven features.

Remind me to tell you about my thoughts on Sitecore one day. For now….i’d say sitecore is a good product but don’t look for an immediate ROI upon first implementation. Sitecore takes a lot of upfront customization but delivers long term benefits.

Now that this phase is over, we are on to phase 2 with some really interesting functionality and 35+ more sites migrated into the system.

I hope to be able to get back to more regular blogging schedule soon.

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 2 comments }

Tyner Blain - “Specializing Generalists’

by Eric D. Brown on February 16, 2008

I just read an interesting article at Tyner Blain titled “Specializing Generalists and the Politics of Agile“that is a good follow up to my “Better to be a Generalist or Expert?“article. An excerpt is:

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

Go read the article…very interesting.

[tags] Expert, Generalist, Specialist [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

Experience vs ability

by Eric D. Brown on February 14, 2008

Jeff Attwood over at Coding Horror wrote a great article titled “The Years of Experience Myth” that everyone should add to their ‘must read’ list.

The article discusses the use of phone screens to in the hiring process (and points to a couple of great articles on the topic) but the point of the article pertains to the trap of trying to be overly specific in your hiring.

Jeff writes about the myth of ‘years of experience’ and how many organizations fall into the trap of trying to hire the perfect person. You know the job descriptions that require “7 years experience in J2EE in a manufacaturing environment”. An excerpt from the article is:

This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match– exactly and to the letter– some highly specific laundry list of skills.

Somehow, they’ve forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

Emphasis mine.

Jeff’s article discusses software engineers specifically but this same issue can be found in any technical area and many other areas. I’ve talked with recruiters and organizations are filter out way too many excellent candidates. For example, the “7 years in J2EE in Manufacturing environment” sample I gave earlier is one that I saw while searching indeed.com (great site btw) for this post. What does someone with 7 years in experience know that someone with 6 years experience doesn’t? Does it really matter that the J2EE experience come from the manufacturing environment?

I’m of the mindset that you hire the best person you can regardless of the number of years of experience that they have. I’m not convinced that someone with 20 years experience is a better hire than someone with 2 years. I’d rather hire the person that will get the job done. As Jeff writes:

Employers should be looking for passionate, driven, flexible self-educators who have a proven ability

Absolutely.

Next time you go to hire someone…look at what they can do and what they have the potential to do; not what they may have done in the past.

[tags] Hiring, Experience vs ability, Coding Horror, Human Resources, Management [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 4 comments }

Buzzword Bingo Strikes again

by Eric D. Brown on February 8, 2008

I’m sure most of us have heard of “Buzzword Bingo” and some have probably played it a time or too. It’s a fun game that should get people thinking about their communication style…and it appears that Oracle’s PR people should have looked into it prior to releasing their latest press release. Here’s the first paragraph of the release:

Oracle today introduced Oracle(r) Communications IP Service and Network Management, a new market offering designed to simplify the lifecycle management of complex IP-based services. This offering enables communications service providers to manage growing IP service complexity, scale operations efficiently and facilitate ongoing network change by providing one integrated solution for IP service management and network change control. Included in the offering are updated versions of two key Oracle Service Fulfillment Suite applications, Oracle Communications Configuration Management and Oracle Communications IP Service Activator.

If you were playing the technical version of Buzzword Bingo, you probably would have won!

I think what Oracle is trying to say is “hey guys…we have a new product that manages your IP service offerings and helps you get a grasp of the complex nature of these services”. I think. :)
Ben Worthen at WSJ’s Business Technology blog pointed me to this press release. He agrees that there is way to much ‘Gobbledygook’ in this press release. Apparently, some of the snide comments directed at Ben disagree…a few people mention that since this product is targeted at technical people it’s OK to use technical mumbo-jumbo and buzzwords…but I disagree. If you can’t communicate the value of a product in a clear and concise language, then perhaps you don’t truly understand the value of that product (or there is no value in the product).Leave the technical language and other terminology for tech specs, manuals or white papers.

Did anyone get a bingo from Oracle’s press release? If so, let me know :)
[tags] communication, buzzword bingo, Business Technology [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }