Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Managing your Life the Agile Way in 2009

Posted by Sun, 28 Dec 2008 20:20:00 GMT

We’re just a few days away from 2009 and it’s that time when we all start looking back at the last year and set goals for the coming new year. I felt like sharing some of my thoughts on how I’m aiming to approach the new year.

Historically, I’ve never been a huge fan of New Years Resolutions because my attempts were always too big to successfully measure. The goals themselves weren’t poorly thought-out, it’s just that it’s really easy to make a list of personal targets, without putting a lot of emphasis on how you’re going to achieve them. The biggest trouble that I’ve had with goals is allocating enough mental energy for implementation planning. (if only I had someone to and wireframe my life…)

Due to this, New Years Resolutions haven’t been a huge success for me. I’ve found it much too easy to pass the buck onto the usual suspects, which consist of: lack of time, energy, too much work, general life changes, health, etc.

So, for 2009… I’m going to try something different by focusing on a set of best practices that I can use on a daily-basis. I suppose that my main goal is to not place too much emphasis on any specific targets and instead place the responsibility on myself to follow these best-practices and see what good (or bad) comes of it.

By rephrasing my internal conversation from, “What did I achieve this last year?” to “Am I doing things the best that I can?” I am confident that the answer will usually be, “not likely.” I do believe that through this subtle change in context, I’ll be better apt to self-evaluate how (and why) I am doing the things that I do and refactor accordingly. If we’re not consistently Refactoring ourselves (as we do with our code), we’re going to retain a lot inefficiencies in our personal and work lives, which make it difficult for us to quickly respond to changes and opportunities.

Our life (personal and work) is just another project that we manage. Much of methodologies that we spend learning about and adopting can easily be translated to these other areas of our lives.

So as I brace myself for 2009, I find myself asking, How can I lead a more Agile life?

I’d love to hear how you’re adopting best-practices inspired by Agile methodologies in your life and I promise to share mine over the coming year.

Related Posts

RSpec: It Should Behave Like

Posted by Wed, 20 Aug 2008 01:47:00 GMT

I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.

To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with… login_required. Sound familiar? Have you found yourself stubbing login_required over and over throughout your specs?

describe Admin::DohickiesController, 'index' do

  before( :each ) do
    controller.stub!( :login_required )
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub login_required in several places. We can set this up in one shared group and reference it wherever necessary.

For example, here is what we’ll start off with.

describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  ...

However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option: :shared => true as you’ll see in the following example.

describe "an admin user is signed in", :shared => true do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

Great, now we can reference it by referring to it with: it_should_behave_like SharedGroupName. In our example above, this would look like:

describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

describe Admin::DohickiesController, 'new' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    @dohicky = mock_model( Dohicky )
    Dohicky.should_receive( :new ).and_return( @dohicky )
    get :new
  end

  ...

That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your spec_helper file)

You can learn more about it_should_behave_like and other helpful features on the RSpec documentation site.

If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)

Update

In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example: build_mock_user_and_login. then calling it in our before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)

Also, Ed Spencer has posted an article titled, DRYing up your CRUD controller RSpecs, which will introduce you mor to it_should_behave_like.

Thanks for feedback people!

Related Posts

Alan Cooper @ Agile2008 slides

Posted by Tue, 12 Aug 2008 22:19:00 GMT

Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.

If anybody knows if there is video of this talk, please let me know. :-)

Here are a few skitches from the slideshow.

The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience

Pair Programming and Micro Projects

Posted by Fri, 01 Aug 2008 01:55:00 GMT

It’s been quiet because I’ve been busy over the past few months. Projects, vacations, and pair programming with our new developer, Nigel. ;-)

Pair programming

In other news, Chris and I launched http://ohmyscience.org (on twitter) in an effort to get a small one-night micro-project out the door.

Oh My Science 2014 replacing god with reason... one tweet at a time

I have a growing list of a few micro-projects that I hope to be helping get developed and launched before the summer is over. Stay tuned!

Oh My Science 2014 replacing god with reason... one tweet at a time

I hope that you’re all enjoying your summer!

Basecamp...

Posted by Wed, 04 Jun 2008 16:13:00 GMT

Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.

I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.

Basecamp

Disclaimer: This is my get-rich-quick scheme for the day.

The Art of Delivery, part 2

Posted by Thu, 22 May 2008 17:42:00 GMT

Two years ago, I wrote an article titled, The Art of Delivery. I wanted to post a few updates based on how our process has evolved since then (and continues to).

Over the past few years, we’ve been fortunate enough to work on quite a diverse collection of projects. This has enabled us to work with many different clients and solicit feedback on our process. This has given us an opportunity to evolve a set of best practices that fulfills the long-term project goals/budgets of our client while making sure that we’re able to maintain a design and development process that is agile.

As I’ve mentioned in previous posts, our team typically bills work per-iteration on projects rather than per-hour or a flat-bid per-project. Since iterations are bite-sized pieces of the entire project and limited to 1-2 weeks, our teams estimates are much more accurate and we’re able to keep things rolling and on track.

stay on track

The basic structure of our project looks like this.

  • A Project has many releases
  • A Release has many iterations
  • An Iteration has many deliverables
  • A Deliverable has many tasks

Before we begin working on an iteration, we outline a set of goals that we want to create solutions for. This process comes out of discussions between our client and us until we agree on what is the highest value/most critical to the success of the project, based on our shared understanding of where we are today. These goals translate into Deliverables, which in a typical iteration might require Interaction Design, Interface Design, or Development. We tend to break our process up into stages so that Interaction Design on Module XYZ would be implemented in a following iteration. This is because it’s unrealistic to expect someone to provide an accurate estimate on how long it’ll take to implement something before you know how people will interact with it.

Within any given iteration, our team is spread across several sets of deliverables. As a team, we breakdown these deliverables into smaller sets of tasks. It’s our aim to keep tasks smaller than a full days worth of work as it’s much easier to measure progress across the iteration when we can track tasks at a granular level.

Essentially, tasks are the individual steps needed to achieve these goals. We don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. Each person providing estimates should avoid getting too granular and aim to find a good balance that compliments their workflow.

Like most things… mileage may vary.

Through this process, we can get calculate the estimated costs for each deliverable, which then provides us an cost for the entire iteration. In addition to deliverables, we also budget a set of hours/days so that we can be compensated for handling small requests, bug fixes, and project management. It’s important to factor these things into your process.

In future posts, I’ll discuss how we’re handling this process while working on multiple projects… as that’s where it can chaos can start if you’re not careful. ;-)

oops

How does your team work? As we’re always evolving our process in an effort so that we can be more efficient and speed up our delivery cycle, I’d love to learn from those in the community.

Older posts: 1 2 3 4 5 ... 10