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

The Daily Stand Up

Posted by Tue, 23 May 2006 03:57:00 GMT

12 comments Latest by Scott Berkun Tue, 22 Aug 2006 02:17:19 GMT

I’ll admit it. I’ve never read a book that outlines that SCRUM process in detail but do have a copy of The Art of Project Management by Scott Berkun. In chapter ten, Berkun points out the purpose of having meetings as well as the annoyances that surround them. Over the past six months, we have toyed around with a few different approaches to holding meetings. There was a short period of time where we really weren’t sure what the best way to get company-wide information to everyone without boring them to death once a month or week.

A few months ago we tried something totally crazy… daily meetings! It caught on rather well.

There is one rule though, nobody can sit down. :-)

We hold a meeting every day at the same time and do not make any exceptions. Well, I will admit that we’ve missed two or three in the past several months but overall, we’re very good at keeping to the schedule.

So, how does this process work?

Each morning, I spend about 15 minutes preparing for a 10 minute meeting… which also is how I build my list for the day. This list appears on an index card as I keep it with me throughout the whole day. I also keep the previous and next days card with me so that I can make sure that things that didn’t get done yesterday get done today or tomorrow. Some of these tasks end up on BaseCamp or just get checked off as I complete the task.

Each morning at 9:15 AM PST (now you know where we are when we aren’t working or on IRC), we meet in our conference room and stand in something that looks similar to a circle. I wait until everybody finds their way into the conference room and then say, “Good morning!” I then do go over the following things (and use my index cards to keep me on topic)...

  • What did I do yesterday (or Friday/weekend)?
  • What will I do today?

Then the person who decided to stand next to me follows and we do this around the room… I think the order this morning was:

  • Robby
  • Jeremy
  • Brian
  • Jason
  • David
  • Allison

This is a good time to also bring up any thing that might be useful for everyone to hear… such as, “we got a new development contract signed yesterday!” or “client x will be on-site at 1:30 PM.” Along with this, we’re able to ask questions about other peoples work and act as a sanity check. Why the stand up? Nobody likes to just stand around for too long… when you stand up you avoid getting too comfortable and people are more likely to stay on topic and focused.

The meetings typically last 10-15 minutes and if you’re not doing something like this with your team… how do you cope on a daily basis?

Project Borat, an introduction

Posted by Wed, 03 May 2006 20:46:00 GMT

7 comments Latest by Joe Grossberg Wed, 07 Jun 2006 19:56:03 GMT

This is going to be really exciting and a fun challenge for our team. Over the next few months we are going to take you, our audience, deep inside the heart of a real development project. We’re going to be writing about our whole process from the moment the contract was signed until we launch the first public version of the application. As a team, we will be blogging about our various roles in the project and as we keep do our best to blog the process, we’ll be interested in hearing your thoughts on our processes and be honest about the lessons we learn ourselves.

The Project

Peat Bakke, the Project Director at PLANET ARGON and I have been talking to a new client about their new project. We’ve come to an agreement with them, which gives us permission to blog about our experiences, but cannot give details about the business plan, logic, or other secret ingredients that they have up their sleeve that will make their product successful. What we can blog about it… is our experiences and processes. Throughout the course of the project, we will refer to this project as… PROJECT BORAT. don’t ask… (see Peat’s blog for details)

The Sales Process

Each client that we sign a contract with is unique. We have yet to have the same things happen twice when it comes to signing a custom development or consulting project. We met with The Client a few weeks ago after Jeremy and I returned from Canada on Rails. While in Vancouver, one of three individuals that make up the core team of The Client had gone to CoR to learn more about the Rails community and had approached me to discuss the PLANET ARGON development process. Little did I know that the next week, I would be signing an NDA with him and his colleagues in our office in downtown Portland, Oregon. After signing the NDA, The Client outlined their great product idea and Peat and I listened in and asked them some vital questions:

  • Why Ruby on Rails for the project? (how familiar are they, what attracted them to Rails?)
  • How will the project make you money? (always an important question… and they are usually happy to discuss)
  • What is your ideal deadline for delivery of the project? (aside from the common answer of ASAP that we often hear)
  • Do you have a set budget for the project? (qualifying question to avoid any surprises)
  • How soon are you looking to make a decision? (helps us prioritize our potentials)

We talked with The Client a while longer and off they went with our business cards. Peat and I then scheduled a time to go over our meeting notes and pair on an initial estimate for the first few iterations. The first two iterations would include a specification phase, which includes pairing with the client (something we can easily suggest when they are local) to gather project requirements, paper prototyping, Use Case defining, and estimates for the first few iterations of architecting, development, documentation, testing, and delivery.

We went back and forth over a few details, scheduling, and have since signed a contract to begin the first iterations of the project.

...and this is where I direct you to read the next installment of Project Borat... with your host, Peat Bakke.

UPDATE Read my next installment, Prototypes Are Your Friends.

Continuous Integration == Communication

Posted by Tue, 02 May 2006 14:24:00 GMT

1 comment Latest by Me Tue, 02 May 2006 22:19:16 GMT

Martin Fowler has updated his Continuous Integration article.

One of the points that I appreciated reading about in this article was that when you’re working in a team, the ability to keep consistent communication. This is vital to the success of the project, just like all forms of quality communication is important during the lifespan of a project.

“Continuous Integration is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.”

Another point reminded me of something I recently posted about1, which was that you should always keep your project releasable… at all times.

“To help make this work, anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.

Test. Before. You. Commit.

Fowler also mentions Ruby on Rails in regards to automating deployment practices yourself. :-)

In any event, read the article.

1 Agile development begins within…

Agile development begins within... continued

Posted by Wed, 26 Apr 2006 22:15:00 GMT

1 comment Latest by RyanA Thu, 27 Apr 2006 01:03:16 GMT

“It is not the strongest of the species that will survive, or most intelligent. It is the one most adaptable to change.”

- Charles Darwin

Last week I posted, Agile development begins within…, which referenced some bullets from the book, Practices of an Agile Developer. Since then, I have taken a little more time to read a bit further in the book. With books like this, I tend to jump forward and backward, so ten leaps further might put me on page two. In any event, I found a few more things that I wanted to point out… and by all means, you should go buy the book.

In Chapter 3, the authors, Venkat Subramaniam and Andy Hunt, discuss some ways to feed your Agile developer brain.

side note: while typing this… a huge bee just snuck in through my office window… where was I…

  • Learn iteratively and incrementally. Set aside some time every day for catching up. It doesn’t have to be long, but it should be regular. Keep track of concepts you want to learn more about—just jot down a note when you hear some unfamiliar term or phrase. Then use your regularly scheduled time to investigate it further.

This is a very important aspect of being a developer in any environment. Otherwise, you’ll end up like that disgruntled guy who has been programming in the same language for 25 years and refuse to use tabs in a web browser. Trust me on this one. There are people like that… and it could be you!

The point that I liked within this is that you shouldn’t just wander off and figure out what it is that you’re not sure about. I believe many people have a tendency to immediately look up at their google search box in their browser and…well… google it.

Don’t! Schedule time to do it… otherwise you’ll end up learning about the Canadian farming industry. GTD it! ;-)

  • _Attend local user groups. _

This is a no-brainer. Find a local Ruby user group… and start going each month. Perhaps your local Ruby user group meets more than once a month. :-)

Disclaimer: I’ve missed the last few meetings at PDX.rb. Bad Robby. :-/

I wanted to post more… but have since decided that it’s probably time for you to just go and purchase the book for yourself. :-)

Agile development begins within...

Posted by Fri, 21 Apr 2006 14:45:00 GMT

4 comments Latest by Aaron Schaap Sun, 23 Apr 2006 02:37:46 GMT

When I got back from Canada on Rails, I found myself looking at a review copy of Practices of an Agile Developer [1] sitting in our library. I haven’t had a chance to really dive into the book, but did take a few minutes to skim through a few sections that I found interesting.

Some bullets that I found useful.

  • Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

There have been times where I have found myself taking the quicker-well, it seemed quicker at the time-approach to solving an immediate problem.

  • Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

This is extremely important when there are several people working on one project. Developers have their own schedules and when we make a commitment to push new changes to a production environment, it’s important to be confident that all developers and designers involved in the project are following the same rule… test-before-you-commit. When this rule is followed, you aren’t concerned that if developer A needs to leave work early that the work that she checked in is tested. This allows us to push new changes to the production server at the end of each day if all tests are passing.

  • Develop in increments. Release your product with minimal, yet usable chunks of functionality. Within the development of each iteration, use an iterative cycle of one to four weeks or so.

This is something that PLANET ARGON has been practicing more and more. Our iteration cycle is limited to 2-3 weeks, no more (unless there is a good reason to). When we are able to look at a distinct set of deliverables, which take 2-3 weeks to plan, design, develop, test, demo, and deliver, we can build our cost estimates around the number of resources that we be necessary to achieve those well-defined deliverables. It might only take 2 developers and a designer part time for those 2-3 weeks and we can adjust our cost estimates accordingly.

  • Write code to be clear, not clever. Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.

When Jeremy and I began working with each other last Fall… within a day of working around each others code… we decided to build a style guide for all of our code. This style guide has evolved over time… but the core principals remain. Keep your code… readable.

_“Remember your code is for a human first and a computer second.” _

- Martin Fowler, Refactoring

As I continue to review the book… I’ll post more thoughts. :-)

1 Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt, The Pragmatic Programmers, 2006.

Keeping Prototypes is a Bad Idea

Posted by Sat, 11 Mar 2006 13:30:00 GMT

11 comments Latest by Perry Tue, 21 Mar 2006 00:30:46 GMT

In a recent article titled, Just Build It: HTML Prototyping and Agile Development on Digital Magazine, Garrett Dimon writes,

“You need to temporarily suspend any notions that prototyping is always throwaway work. If you approach it as throwaway work, it will be. However, if you approach it with the intention of keeping it, you can create modular code that can be reused.”

I disagree. :-)

I’m not a HTML web designer, but when building applications, a prototype should be looked at as a process in which you agree that what is built will and should be thrown away.


When you are in prototyping mode… you should be very aware of the fact that it is a prototype. This is your chance to take shortcuts, break the rules, get creative, and express your ideas on a piece of paper, in plain HTML, or perhaps you may even run ./script/generate scaffold to spit out some code that you know will not be used in a production application later on. The goal here is to figure out what direction you want to take the project and get the client to sign off on these ideas… not to build reusable and modular code. If you’re building a prototype with the goal of reusing it than it’s likely that you’re spending too much time doing it.

Just Toss It

While you might not physically toss your application into a nearby trash can, you should aknowledge and remove any attachments that you may have that suggest that the prototype was a waste of time because no reusable artifacts came out of it. It’s the ideas that are expressed here that make this time valuable. Perhaps you don’t need a prototype phase… this would mean that you know exactly what you are about to develop. If you go the route of prototyping and find it to return nothing useful… than imagine how you’d feel if you just started developing and determined that you really missed an important requirement a few weeks later.

“The physicist’s greatest tool is his wastebasket.”

- Albert Einstein

The shortcuts that you should have taken earlier have likely created too much technical debt in your code. A fresh start should be the next step. Prototyping is part of the development process but the moment you allow yourself to think that you should reuse some of the prototype in your application is when you begin to become too attached to the notion that your prototyping phase was a waste of time end energy. Go into the prototype phase knowing that reusable artifacts are not the goal of this phase. Throw it away. ;-)

“Every act of creation is first of all an act of destruction”

- Pablo Picasso

Keep The Lessons and Ideas

You don’t need to rm -rf the_prototype but you should be very honest with both yourself and your client that the prototype phase is a way to quickly express an idea or process in a both a technical (and often) visual manner.

Prototyping Generates Confidence

Clients have (many) ideas. I hate to be the one to break it to you, but it’s almost certain that they are not as confident in you as you would like to believe. Confidence evolves over time and should be nourished on a regular basis. Their ideas are important to them and they are paying you to be part of the execution of those ideas. If you even remotely sense that you are not confident in their ideas… tell them this. Prototype their ideas. It could save both you and your client a lot of time, money, and resources in the long run… especially if an idea proves to be too complicated to execute.

Ideally, this is when you both agree that this idea is a good idea and that you both understand how it will be executed. This is both a good and healthy process. :-)

Document your learnings, the changes presented by both your client and yourself, and then revisit your Use Cases.

What you are about to build is that much clearer now. This feeling of clarity is exactly why you created a prototype. Remind yourself of this.

Always Start Fresh

Now that the client and you have come to an agreement about what is to be developed… the next phase should begin.

rails the_real_app

...and remember… don’t be afraid to revisit prototyping again. If an idea is not clearly defined yet, whip up a new prototype and see what comes of it. Just keep it out of your code base…. and if it’s already happened… please Refactor. ;-)

Like I said… I am not a HTML person… reusing the colors, graphics, and html artificats that you worked on might be useful… but modular code shouldn’t fall out of a prototype.

However, prototyping is a good idea and I highly encourage it.

Prototyping can also be extremely fun!

Similar Post(s): Keeping the Code Organic, The bitter-sweet taste of agnostic database schemas

Older posts: 1 ... 8 9 10