Getting Started w/ Best Practices & Design Principles

3 Replies

Praveen had a seemingly innocent question here and there were lots of good answers…

If we are following Agile Methodology (Scrum) & We are in Java/J2ee Domain,

What are the Best Practises & Design Principles need to be followed
while designing the applications.

Big question is an understatement… here’s what I would advise:

  • Understand the business domain
    • because, if you get that wrong, it doesn’t much matter how well-crafted and well-tested your code is
    • Design using Separation of Concerns as the granddaddy of all patterns to sear into your brain.
    • Be sure you use a layered approach to your architecture — if I catch you putting SQL in your javascript, I’ll come over there and stab you in the toe
    • Design in the Large to avoid excessive dependencies
    • Design in the small to adhere to all those good practices like SOLID
    • Consider looking into the Domain Neutral Component — within which a shockingly huge number of domains tend to fit.
  • Architect and build the application in a highly consistent manner — much like Rails enforces.
    • If you have a dozen domain items that need the same sort of treatment from persistence to UI, please don’t get creative and do persistence 5 different ways.
    • Pick one and stick with it for the sake of consistency!
    • I’d rather a consistent implementation that is mediocre, than one with 5 different approaches (one stellar, one horrid, and the rest mediocre). Why you might ask? Because it is easier to refactor when things are consistent 🙂
  • And, of course, apply an agile process…
    • Involve a customer/proxy to ensure you understand the requirements from the business perspective, do not rely on documents — but if you must, then you need to exaggerate the agile process and make it more granular. That is, to compensate for the likelihood that the written word is ambiguous, you need to show small steps of progress on a feature and get rapid feedback to ensure you are not mis-interpreting the requirements doc.
    • Build a vertical slice of your design to prove it out and to serve as a model for how you will work on your app
    • If you have stringent performance needs, prove them out early
    • Show working code early and often
    • Get yourselves set up on an automated build
    • Try to build out the features using something like BDD or TDD
  • General
    • Be patient with your learning
    • Be impatient to see results, don’t let any team member or task go dark for more than a couple of days
    • Create the lightest-weight process possible
    • Don’t do anything to excess without frequent feedback
    • Always foster a team attitude to question everything with boldness — including my advice

Hope that helps

Ideas for a Distributed Team

5 Replies

In response to a posting on Agile Project Management…

I am starting up a ‘Distributed’ Agile Project and looking at tools to assist the distributed team communicate the status of work undertaken, stories, estimates and burn down/up charts as well as general collaboration (forums, document sharing etc).
There are tools such as Agile Wall, Mingle, Trac (with plugins etc).
I am ideally looking for an externally hosted solution (something that we will not be setting up in-house).
I have a core team of 15 people and with an additional 10 people that would want access. I am looking for any ideas or suggestions on online tools that you may have.
Thanks in Advance.
Regards
Neal

I’ve been doing this sort of thing since 2000, so it is very easy and very possible to be extremely effective as a distributed team.

Here is a very simple approach using Basecamp (and you can get an add-on for burndowns if you like that sort of thing). I’ve been doing this on a small project since March or so.

Then I set up other simple collaboration tools (looked like this on many projects, though you might have to march around that hodgepodge of a site to find more tool ideas):

  • Wiki: Project stuff that is not issues or code needs a home; a.k.a.,
    (you can use basecamp, though not as extensive as something like confluence)
  • Chat Room for being the virtual cubicle farm and water cooler. Skype or IRC works great. You can establish key words that call out for attention, like “@ALL I’m going to kick the TEST server.” You can even have textual scrums if voice is not always possible. For a while, we had a bot that recorded the chats and logged them to the wiki 🙂
  • Issues/Bugs: You need a place to store your lists of things to get done. Some call that an issue tracker; others, simply a To-Do list. I have used Jira for a l-o-n-g time for both features and bugs. I have also used Lighthouse — which is just fine too.

Atlassian Studio is worth a look. You can add in continuous integration and code reviews and what not.

My suggestion: start really small and humble with the tiniest process.

That really simple Basecamp process I blogged about? We actually got to PRODUCTION with much less ceremony. There were none of the “To be QAd” or “To Be Released” because we did it more in iteration chunks, so we knew the overall state of a given iteration (in dev, qa, or released).

The slightly greater ceremony of QA and Release buckets allowed me to answer the need from the stakeholders and other non-developers to know the state of the project at a glance. It’s easy to see what is in the backlog, or what is in progress, or waiting QA, etc. Now we’re doing Kanban. I crank issues and (rare 🙂 bugs through one at a time usually.

Anyway, have fun!

Response to “Three Things I Don’t Like in Agile Community”

3 Replies

Andy wrote some interesting observations in his “Three Things…” post:

1. Dogmatism
Agile is about adaptive, creative approach to complex work yet amazingly average agilists are the most dogmatic people I know.

Part of dogmatism is also treating agile […] as the all-encompassing solution to problems not only in software development, not only in IT, but everywhere. [This] is a far cry from healthy pragmatism that I think is at the core of all good management.

I see this is a common thread among those who have issues with Agile. Naturally, if someone is presenting a methodology at a conference, I can see where it might sound dogmatic. However, if an Agile Consultant is engaged with a team and preaches “Do it My Way or Else” in spite of vehement team opposition, well, that strikes me as non-agile.

For me, agile has always been more about the proper state of mind than dogma. We need to prefer to do those things that are best for the business/customer goals over doing things that are not as helpful at getting the project closer to “done.” Sure, there are practices associated with agile methods, but simply doing those practices don’t make someone agile per se.

No, what makes someone agile is a combination of what they are doing, how they are doing it, and all within the cultural and business context in which things are being done.

For example, you just can’t walk into an elderly long-term care facility and do yoga like you would with 20-30 year-olds. (Well, you could, but that would be stupid.) Similarly, you can’t simply ram your favorite XP tools and practices and Magic Scrumbans into a steeped-in-old-ways, very stodgy organization full of legacy software written in a 30 year-old, no-longer-supported language. Well, you could, but that would be stupid.

So, Andy, if you spot one of us “Agilistas” spouting off a dogma, smack us upside the head and say “Work with me, son!”

2. Sectarianism

Kanban, Scrum, XP – everyone follows their own method, and basically says others are useless or at least not as good. […] Again, this is in the face of core principles of agile.

Hmmmm. The only good method I ever practiced was the one I was doing at the time it was working right. While I can understand someone who is training in a strict methodology being sectarian, that is not the same as consulting. I attempt to be a generalizing specialist (as Scott Ambler likes to refer to it…) and use a blend of tools, practices, modalities, and therapies.

Andy, if you find yourself being preached to by a consultant (not a trainer) that is one-dimensional, take it for what it is worth. A single, focused, dimension — nothing more.

3. Domination by consultants Most if not all agilists that write, teach and coach do only this, and have not run a software project (or a business) hands on for quite a while.

Well, the lack of real-world experience should be obvious by perusing their background. While trainers can be good at getting across certain practices and methodologies, and while coaching dozens of teams provides valuable exposure, it does not substitute for actual production experience. I learned a great deal traipsing around dozens of companies to help train and consult to kick-start projects — lots of cross-pollination potential as well! Similarly, consultants with great experience at building real world systems and helping teams do that, may not be the best down-and-dirty, nitty-gritty trainer for a given technique.

It’s a trade-off. First off, don’t confuse training on a skill, with consulting to help achieve a business goal. I think you have to understand what the purpose of the consulting engagement is, and who was brought in for that task. If you just want to learn the mechanics and lingo of Scrum, it takes only two days — it’s that simple. But tell any Project Manager with real world software project experience, and they’ll tell you that you don’t know much after just a few days of training.

So, if you ran into an agilista trainer that has not been on a real world project to deliver production code in a long while — or ever, then you should not expect that sort of knowledge. It doesn’t mean they cannot provide you with valuable training.

However, I will also say that not much is new under the sun in software development in the past 30 years. I mean, seriously. The same core issues exist in trying to roll out a piece of software to production as did 30 years ago. Admittedly, I don’t recall having quite as much fun as I do now with delivering production code with Ruby, Rails, Cucumber, RSpec, github, Mongo, gems… The ecosystem makes it so much easier to “do the right thing” with BDD/TDD for example.

Andy, I can appreciate your observations about the “Agile Community” — like so many others I have read on the web. To that end, I suppose we need to re-double our efforts at re-stating that Agile is a State of Mind, not a set of dogmatic practices.

And, in the end, Andy, caveat emptor. The Agile mantra should be one of empowerment and individual freedom to please the customer in the best way possible. You are ultimately responsible for doing the right thing. Agile ideas, processes, tools, trainers and consultants are just that — and nothing more. We are not the answer, we just try to help. In the end, the team is the answer.

Responding to “What’s Next for Agile”

1 Reply

In this post, there are some scary assumptions. I wonder where they come from?

  • “But where does [the Manifesto] say that the customer gets what he wants?”
  • “Mary talked about the next inflection point in agile – getting back the customer focus.
  • “‘Agile’ until now was about the processes and tools that improve software development.”
  • “[We] now have to align with the business goals of the organization –  provide what the customers need.”

Everyone is entitled to their opinion. But this is sooooooooooooo far away from what Agile is all about, I find it shocking.

My primary response:

Well, if you aren’t building software for customers, then you can do what you want.

Even though the customer is mentioned explicitly in the very first principle, I submit it is obvious that you are to satisfy the customer to build valuable software. Always. We ain’t no stinkin’ charity for developers to play around with shiny new software trinkets. (At least not overtly <g>.)

Anyway, “satisfying the customer” is simply a “given” behind each one of us that met to author the Manifesto.

And, who ever suggested moving away from the customer (implied by the need to “get back”)? That is completely anti-agile.

Agile is also not “about the processes and tools” as the post suggests — if anything, Agile is about a state of mind to do the right thing in every circumstance.

How do these ideas get out there about Agile?

I’m confused.

Certification is a Good Thing

6 Replies

I read with pleasure “The Value of Certification” from Pawel Brodzinski, that emanated from a discussion about evaluating employees.

Pawel points out some obvious pros to certification, and one big con:

  • It’s objective measurement
  • It’s butt-simple (Pawel didn’t actually say this, that’s, ummm, me talkin’)
  • It’s, and I quote, “pretty much useless”

Then it dawned on me. College degrees are certificates, as are high school diplomas. So are participation trophies for the poor schlubs who didn’t win anything at tweeny league and are (defenselessly) surrounded by adults who mistakenly (IMHO) think such a trophy is meaningful to the kids (kind of like dogfood made to appeal to the purchaser). But that’s a digression…

In our software world, it is the Scrum Certification that bears the brunt of criticism — even though Pawel does not mention this particular style of paper valor. For those who pass an exam after two-days of grueling lectures, practical hands-on training (a.k.a., apprenticing) at the feet of master craftsmen, and in-depth co-op work experience at multiple cutting-edge development shops doing different projects… Oh, wait, that’s not quite fair as that really isn’t what’s going down in just two days. Crap. Scratch that tact.

Anyway, let’s just say many folks seem to be intent on hiring other folks based on Scrum certification (caveat emptor: I do not have said certification, so I am not speaking from direct experience — I’m too cheap to pay for it). I base this on my extensive analysis of randomingly seeing two hiring ads for Scrum Masters that were virtually identical in content — and buffoonery, I might add. For me, it was a big, bad smell for the organization. But, in large bureaucratic organizations (government or MyLargeCo), abdicating responsibility is honed to a fine art. Ergo, the HR departments did what they think was valid trawling for Scrumsters by evidently plagiarizing some sort of HR-i-pedia definition of the perfect Scrumster parameters. Good luck with that. These actions are a boon to your not-as-lazy-or-naive competition (oh, unless you are the Government, which has no competition, only an ever increasing appetite — I’ll not digress here, either).

So, maybe the Scrum Certificate is a bit like a Participation Trophy.

Yea, you were there. You participated. You didn’t actually compete/win or do anything meaningful in the real world to earn it, but there you have it. You should feel better about it. And it does mean that you at least did something (unlike me). Go forth and procreate little Scrumlins. (BTW: I’ve got nothing against Scrum, I think it is a great and simple approach to PM! It’s just hard to pass up the opportunity to poke fun at our own agile software world and make up little monikers as I go.)

So I can look at “certification” in at least two ways:

  1. Basing hiring or performance appraisal on a CSM certificate is pretty awesome for the individual on the receiving end. I bet they didn’t have to go into debt to get one (compared to a college degree)! (Although all of me wants to be judged on my real merits, not on some piece of paper — alas the chicken and the egg comes to mind for newbies.)
  2. If companies find a valuable correlation between a certificate (CSM or otherwise) and knowledge work, I would be surprised. In my experience, the last thing that I would qualify as a trait of software projects, is that they are “cookie-cutter” — that is, where one-size anything fits all (be it ideal Scrum process, database, language, etc.). However, sans external stupidity (like a bailout), companies will “learn” how to treat any software certificate — much as they have with college diplomas and belly buttons (i.e., everyone has one). The market will sort things out, eventually — in that I have faith.

So there you have it. Pawel says “Certification is Pretty Much Useless” — and I disagree. That very aspect of certification will serve a purpose to differentiate those that place undue trust in the paper from those that stick to good hiring practices and good employee relations. I predict the latter prevail.

ps: Pawel, I agree with you in spirit.

Agile Manifesto Simplified

2 Replies

JB Rainsberger took a stab at simplifying the Agile Manifesto.

Original (24 words):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I’ll see your 3 bullets (24 words), JB,

  • People working together over precise rules and pre-packaged solutions
  • Working software over promises
  • Doing what’s needed over doing what we said was needed

and raise (well, reduce) you:

  • People working together over dogma
  • Working software over promises
  • Doing what’s needed now

24 words to 13 words. Same context? You decide.

More to follow 🙂

Class- and Field-Level Custom Validations

Leave a reply

This is a simple example I put together for someone asking how this validation stuff works…
In this example, you can see field-level validation:

  • team must be chosen
  • name is required

And you can see a class/base-level validation:

  • at least one method of contact, a phone or an email:

Simple class example that employs some conditional validations and some regular validations:

class Registrant
  include MongoMapper::Document

  # Attributes ::::::::::::::::::::::::::::::::::::::::::::::::::::::
  key :name, String, :required => true
  key :email, String
  key :phone, String
  # Parent Info
  key :parent_name, String
  key :parent_email, String
  key :parent_phone, String
  key :street, String
  key :street2, String
  key :city, String
  key :state, String
  key :postal_code, String

  # Associations :::::::::::::::::::::::::::::::::::::::::::::::::::::
  key :team_id, ObjectId
  belongs_to :team
...
  # Validations :::::::::::::::::::::::::::::::::::::::::::::::::::::
  validate :validate_team_selection
  validate :validate_parent_contact_method
  validates_presence_of :parent_name, :street, :city, :state, :postal_code,
                                    :if => :parent_info_required?

...

  private

  def parent_info_required?
    season.parent_info_required?
  end

  def validate_parent_contact_method
    # one or the other must be provided
    if parent_phone.empty? and parent_email.empty?
      errors.add_to_base("At least one form of contact must be entered for the parent: phone or email" )
    end
  end

  def validate_contact_method
    # one or the other must be provided
    if phone.empty? and email.empty?
      errors.add_to_base("At least one form of contact must be entered: phone or email" )
    end
  end

  def validate_team_selection
    if registration_setup.require_team_at_signup
      if team_id.nil?
        errors.add(:team, "must be selected" )
      end
    end
  end
end

The above will result in always checking the name, the contacts, and the team assignment. It is actually pulled from a slightly more complex context in that a few conditionals exist to further complicate the validation logic. If you need checking only at certain points in the object life cycle, you can look to things like validate_on_create.

In the case of “Parent Info” being required, additional validations take place.

The “name” validation is a standard, out of the box field-level validation due to “:required => true” being added to the MongoMapper key.

Enjoy!

Refactoring Cucumber Features

Leave a reply

I was inspired by this post (You’re Cuking It Wrong) to re-look at some feature specs to see if I could improve them.

I went from here:

Feature: Season Management
...
Scenario: Create a Season
  Given an organization like "My YMCA"
  When I add a season like "Summer Basketball" for "My YMCA" from "1 May" to "31 August"
  Then I should see the "Summer Basketball" season for "My YMCA" in a list of the organization's seasons

Scenario: Add a Registration Setup
  Given the "Summer Basketball" season for "My YMCA"
  When I add a setup like "Summer Signup" open from "1 April" to "30 April"
  Then I should see "Summer Signup" under the "Summer Basketball" season

to here:

Scenario: Create a Season
  Given an organization like "My YMCA"
  When I add "My Season" season
  Then I should see the "My Season" season

Scenario: Add a Registration Setup
  Given the "My Season" season for "My YMCA"
  When I add a setup like "My Season Signup"
  Then I should be able to signup under "My Season"

This also led to improvements in the steps. For example, by getting rid of the unnecessary dates, I also removed some unintended “brittleness.” As an example, this:

When /^I add a season like "([^"]*)" for "([^"]*)" from "([^"]*)" to "([^"]*)"$/ do |season, org, from, to|
  visit organizations_path
  click_link org
  click_link "New Season"
  fill_in "Name" , :with => season
  fill_in "season_starts_at" , :with => from
  fill_in "season_ends_at" , :with => to
  click_button "Create"
end

to:

When /^I add "([^"]*)" season$/ do |season|
  visit organizations_path
  click_link @org.name # Created in a prior scenario, no need to pass in
  from = Time.now      # Create more appropriate from/to values
  to = from + 120*24.hours
  click_link "New Season"
  fill_in "Name" , :with => season
  fill_in "season_starts_at" , :with => from
  fill_in "season_ends_at" , :with => to
  click_button "Create"
end

Subtle, maybe, but certainly more clear and less likely to need attention if/when the solution changes.

Consultant’s Rules?

Leave a reply

Wow, it was a shock to read Gerald Weinberg’s “A Code of Work Rules for Consultants” blog.

While reading the lead-in to his list, I kept finding myself saying “really?” and “ugh!” I enjoy being blissfully ignorant and sheltered, I guess. Here is Gerry’s list:

  1. I will not work for an organization whose goals are not consonant with my beliefs.
  2. I will not work on projects whose goals I do not understand, or cannot agree with.
  3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.
  4. I will not work under measurement schemes that pit one person’s performance against another’s. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.
  5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.
  6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.
  7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

It’s almost a shame that Gerry had to post this list — in that it reflects a state of affairs that he and others have observed (I trust). I naively assume everyone innately follows Gerry’s rules — as I think I have done my entire 35 years of working (including starting out having a paper route in middle school and washing dishes at 15).

Knowing better, however, that your picture of reality is just that, I always advise that folks (employees and consultants, alike) need to be financially sound/independent. If you live paycheck-to-paycheck, it is harder to buck the system than if you have a 6-month or greater cushion of savings.

TIP: Just start out with small goals, putting savings aside until you have one month of living expenses. Before you know it, you will have two months, six months, a year or more! It is truly liberating to have that cushion! Naturally, incur as little debt as possible so you are not haunted by that “anchor.”

So, to Gerry’s initial list, I humbly suggest he add the following:

“8. Be financially sound so that you can stay true to your principles and not be chained to a paycheck.”

Be an Agile Survey Monkey

1 Reply

There’s seemingly quite a bit of a dust-up over assorted agile surveys:

  • Scott Ambler’s 2010 Scrum Certification Survey.
  • VersionOne’s “State of Agile” survey.

I did Scott’s simple survey last week. I did the VersionOne not-so-simple survey the other day.

After someone dissed Scott’s efforts and praised the VersionOne effort, I replied:

I could poke serious holes in the “State of Agile” survey. I mentioned a flaw or two back to VersionOne (i.e., I replied to the email with the link).

But I won’t. It isn’t worth my time.

Surveys are extremely hard to design. I submit that the VersionOne survey has a flawed model of development projects underlying the questions—not that it stopped me from supplying answers. And when you toss it out to self-selection, it gets even weirder to draw major conclusions. And to get subjective info on being more productive with agile, etc., is anything but accurate.

If people make decisions based solely on someone’s survey (or certification or education), it’s a free country.

Good luck with that.

I would never be so foolish.