Most meetings, I loathe. Often they are drawn-out, not really useful except to maybe a few attendees and there are always those who seem to enjoy the platform to give their long-winded speeches. That said, meetings I actually enjoy and find very useful are Stand-up meetings.

Stand-up meetings are brief meetings held daily and typically at the same time and place where team members can report on their status on a given project. Typically, each member reports on three specific items. These are:

1. What did I accomplish yesterday?
2. What am I going to attempt to accomplish today?
3. What problems am I facing?

Stand-up meetings are deliberately kept short, usually from 5-15 minutes. When meetings go beyond 15 minutes, it is usually an indicator that there is too much discussion. It is important to remember that stand-up meetings are not the place to solve problems or to elaborate on project specifics. Rather, they are the time to report status and identify potential issues that might hinder a developer’s progress.

To get the most out of daily stand-up meetings, each team member must be prepared with his or her status report. In other words, they should come to the meeting with perhaps a written statement of their status. Having to write the statement is a good discipline to help one from dragging on, yet allows for a meaningful status report. I like the idea of a 3x5 rule. That is, if what one has to report cannot fit on a 3x5 card, they are saying too much. As an example, one might report the following:

“Yesterday I installed our repository, restructured the submission services and finished the submission logic. Today I am going to finish the retrieval logic and configure the CI server to run test scripts on the XYZ project. The problems I am facing is that I’m not sure what to use as test data and there is no documentation on the database”

Note, that the report was brief and did not include details as to how the tasks were accomplished or other unnecessary discussion. Finally, the developer stated a possible problem. At this point it is appropriate to identify people who can help mitigate the issues that developer is facing. Note, this is not the time to actually solve any issues, only to identify who can help solve them. Therefore, a likely response might be:

“I can help you with the db structure, see me after the meeting” or “See so and so after the meeting, he has already come up with test data.”

Keep in mind that it is often, it is necessary to schedule another meeting.

With such a limited scope for a meeting, one might wonder why have them at all. Why not just email the PM status? Here are a few reasons why stand-up meetings are important.

1. Stand-up meetings increase accountability by surfacing commitments and responsibilities to the entire team. Not only do developers report status but so does the PM. Since these meetings are held daily, everybody becomes aware of the overall project status by tracking with what others are doing.
2. Stand-up meetings help detect and reduce bottlenecks to the project quickly. Since these meetings are held frequently, problems are quickly identified and addressed. In my experience, weekly meetings are not frequent enough to accomplish this. By practicing this daily, risk mitigation becomes a priority.
3. Stand-up meetings help developer commit to realistic goals. It is much easier to commit to a days worth of work than to try to guess what one might accomplish in a week. This also helps the PM in knowing how much work the entire team can actually get done which results in better estimates given to management.
4. Stand-up meetings unify the team by getting team members on the same track with the project and encouraging communication and team effort in dealing with problems.

There are many more benefits to the stand-up meeting and you find numerous articles on the Internet and in most books on the Agile development process. Here are a few links on stand-up meetings:

It's Not Just Standing Up: Patterns of Daily Stand-up Meetings

Daily Stand Up Meeting

Stand-up Meeting Antipatterns

Tweet

Share

Development teams know that estimating is one of the more difficult tasks to get right. One of the frustrating things about estimating is that it often takes quite a bit of research to derive a fairly close estimate of a task’s required effort (usually given in time). Furthermore, estimating is not a quote. It is not intended to be accurate and we all know that…well, except the people asking for the estimate. Sometimes deriving an estimate takes just as much time as it would to simply implement the feature. Finally, estimates are always based on the best information had at the time which, most likely will change.

Story point estimating

Story point estimating (feature point estimating) helps to alleviate some of the frustrations of units of time estimating. Rather than trying to derive how long something will take, a developer can focus on the overall scope of the task and assign it a value relative to other tasks. In other words, it is an estimate of a feature’s size and complexity as perceived by the developer.

For instance a simple feature might carry the value of 1 whereas a feature twice the size might carry the value of 2, and so on. Over time, a team gets a sense of how many points they can complete in a 1-week or 2-week sprint. Here’s an illustration; consider the following questions:

How long will it take you (in hours) to mow your front lawn?
How long will it take you (in hours) to add another room to your house?

Which of your answers do you think is more accurate? Now consider the following questions:

On a scale of 1 to 10, how difficult is it to mow your front lawn?
On a scale of 1 to 10, how difficult is it to add another room to your house?

There is a good likelihood that both answers are reasonably correct based on your experience and know-how.

There are some real benefits to this type of estimating. Some of these are:

• A team can better predict how much work they will get done in a sprint because they are targeting points rather than specific features.
• It is a self-correcting model. As the team develops, they will only improve their estimating and eventually be able to confidently say how many points they can achieve for a sprint.
• It promotes breaking apart larger, complex features into smaller, less complex tasks to be estimated against. Overall, this reduces uncertainty and risk.
• Estimating happens more quickly because it is not intended to be precise.

Fibonacci points

There is a variation of estimating points that takes into account risk and uncertainty. Instead of using a uniform distribution of points to effort (1, 2, 3, 4, 5) a team can use points based on the Fibonacci sequence (1, 2, 3, 5, 8, 13 …). It was stated earlier that as the feature increases in size, so does its risk and uncertainty. In a sense, this model enforces that risk and uncertainty are taken into account in estimating (something developers are not prone to doing when estimating). For instance if a team considers a task to have a 6 on the proportional scale, it would need to be assigned a value of 8 according to this model. Hence, risk and uncertainty are taken into account

So just tell me how long will it take?

The key here is to ask the team the following question: How many points can you typically achieve in the given period of time? The answer is not when it will get gone, but how much will be done within a given time frame. This is a much better and more accurate way of determining what it is going to take to accomplish the overall goal.

Stay tuned for a future post on team-based estimating while playing Poker.

Tweet

Share

Here's a very interesting discussion on the Dynamic Language Runtime (DLR) by Anders Hejlsberg and Charlie Calvert from Charlies blog.

http://blogs.msdn.com/charlie/archive/2008/11/13/anders-hejlsberg-video-on-c-dynamic.aspx

I'm going to start looking very closely at C# 4.0, there are some very cool features coming.  Enjoy!

Tweet

Share

If you are a developer using C#, Visual Basic, Javascript and other and need to insert code into your blog posts, you'll need this extension which according to the web site enables you to:

"Insert Code for Windows Live Writer will format a snippet of text in a number of programming languages such as C#, HTML, MSH, JavaScript, Visual Basic and TSQL."

Go HERE to download.

Tweet

Share

Falafel Software showcased ActiveFocus on Telerik's web site. This is a great illustration of what ActiveFocus can do and it can do a lot!  I was the lead developer for the Windows version of ActiveFocus and I have to say, Falafel has really taken this project to levels I never imagined. It is extremely easy to use and richly functional.

You have to see this video - watch the filtering capability on how the graphs interact with the grid - wow!

One thing Lino (the president of Falafel) discussed was how the skins can be customized for different industries. Therefore, the terminology can be customized to a specific industry. I need to add, that for those engaged in Agile development, it would be easy to rename requirements to stories, events to iterations and so forth.  AF also maintains important information like estimated and actual costs and efforts - critical for teams trying to achieve repeatable processes and cost analysis.

You'll hear in Lino's video that the team plans for integration into Microsoft's Team Foundation Server - that's smart!

Falafel software will be showing ActiveFocus at TechEd 2008 in Orlando, Florida in June 2008 and at the PMI Global Congress 2008 in Denver, Colorado in October 2008.

If I sound partial to ActiveFocus, I am. Having conceived the idea, developed its first iteration and then seeing it turn into a state of the art web application by a rock solid team has been exciting to say the least. I am looking forward to using it with my clients and I will be showing how to use ActiveFocus in an Agile (Agile/hybrid) development setting. More to come later. For now, CHECK IT OUT!

Tweet

Share

If you're like me, and I am, then you appreciate the ease and debugging capabilities of browsers like Firefox.  However Visual Studio continues to use IE even if you've set Firefox as your default browser in your environment.  Gladly, this can be changed, here's how.

1. In the Solution Explorer, right-click over the .aspx page such as Default.aspx to bring up the context menu.  Select "Browse with..."  This will bring up a Browse With dialog (see figure). 

2. Likely, Firefox will not be in the list. Simply press the "Add..." button, browse to the program directory (c:\Program Files\Mozilla Firefox), and select the program (Firefox.exe).

3. Press the "Set as Default" button with your preferred browser selected in the list.

4. Note, you can even set the default size of the browser window.

This it! 

Tweet

Share

I've been wondering if there's any pattern to music I listen to while programming.  I'm considering if there's any connection between the musical genre and type of programming I'm doing. For instance, sometimes I'm developing something simple but tedious and just want to get it done fast. Other times I'm proofing designs, or implementing complex patterns. Then, there's designing/developing the user-interface which takes a sense of both creativity and structure.

Granted, I understand that musical taste is a major component here. Still, just as there are different types of programming, there are different types of music.  By the way, I should probably mention that in my development career, I have met numerous programmers who are also musicians ranging from amateur to professional. Any connection there?

Music I frequently code to:

Classic Rock: Most of it, particularly Led Zeppelin,  Uriah Heep, Pink Floyd, Jethro Tull, etc.  The key for me here is that I have to be familiar enough with the music so as not to be distracted by the lyrics. It seems I'm listening to classic rock when I'm coding something with which I'm familiar.

Various forms of New age: Enigma is a new age group that mixes in some old world elements like Gregorian chants.  This is great for coding and particularly when I'm coding a complex design. Check out the sustained electric guitar in "Hello and Welcome" off the A Posteriori album.

I'll listen to harsh fast paced dark electronica when I'm in the groove, so to speak. For some reason it seems to keep my coding pace up. Similarly, certain forms of dark hard-edged rock (maybe even gothic) like Flyleaf.  There are other groups, but if I mention them my friends will tell me I'm going to burn in hell. 

--- Edit---

Ok, I'll confess, The song "Maneater" by The Retrosic off their God of Hell Album. Simply awesome and guaranteed code performance improvement.  Check out the drums about 1/3 into the song.

--- End Edit ----

I'll often code to classical of course, Mozart's Requiem and Vivaldi's Four Seasons being my favorite.

I'll also listen to hymns and praise music. I particularly enjoy the reworking of hymn melodies by groups like Indelible Grace.

I can code to very specific forms of Jazz like Pat Metheny for instance.

Music I cannot code to (nor listen to for that matter):

I've heard programmers say that they like the upbeat rhythms of of dance electronica.   This doesn't seem to work for me - it's too repetitive. I end up with code like

while (true)

    do something;

Pop - I can't stand this junk with its overly simplistic melodies and cliche lyrics.  If anything, this drives me insane and makes me totally unproductive.

Most Contemporary Christian Music for the same reasons I can't listen to pop.

Rap, too repetitive and since many rap lyrics are angry, I'm thinking it would be a bad combination when I'm having a bad code day...or maybe not.

What music do you listen to when coding?

Tweet

Share

According to Steve McConnell, Gold-plating "comes from developers who want to explore a technically challenging new area..."  Jeff Atwood, in his blog, says that "In the purest sense, all refactoring is gold-plating. That is, it consumes extra project time and results in no material benefit for the users. But without periodic and aggressive refactoring, we can't produce sane, maintainable code."

While I agree with Jeff's conclusion, I would not go as far as he does in equating refactoring with gold-plating. Having maintainable code does have a direct benefit to the customer or client (the person paying for the development).  Ultimately, it's a cost/benefit matter. When the cost outweighs the benefit, then it's not worth refactoring.  Plus, at some point (I hesitate at saying this), the code just works and no further development/refactoring is needed regardless of the code being ugly. Furthermore, when it comes to gold-plating, there is an ill-motive even though it may be subtle. 

I should probably note that when I use the term "developer" I may be referring to a development consulting organization, an independent consultant or a developer (at any level) within a development team.  In all cases, this is a person who can influence the tools and technologies employed in a development effort.

That said, I find that an extensive amount of gold-plating occurs at a much earlier phase of development (such as the proposal phase) which is why I prefer the term "Technology gold-plating" over "Developer gold-plating".  This goes right in line with McConnell's definition.  

I divide Technology Gold-Plating into two categories.

1. New Technologies (Bleeding Edge)
2. Preferred Technologies

New Technology Gold-plating

New technology gold-plating is exactly what the name implies. The developer wants an opportunity to delve into the latest technology.  This is extremely dangerous for the client who may be investing his/her money to the effort.  In essence what is going on here is development research and education at the client's expense.  It works like this. The vendor comes out with a new bleeding edge technology. The vendor pushes it on its partners (who want to play with it). The partners push it on to their clients. Their clients get blood splattered all over them - not good and frankly, quite messy.

Preferred Technology Gold-plating

Preferred technology gold-plating is the use of technologies with which the developer is most familiar or favors for whatever reason. For instance, a developer may use a pre-designed architectural model from the latest popular book on software architecture. Or he may use some pre-fabricated framework.  I am by no means saying these are bad. They are excellent if they actually meet the client's technology and business needs.  Yet, it happens too frequently that a company ends up with an over-architected monolith of a system when all they needed was an html page and a few lines of java script.

So, how does one prevent this from happening to their project?  Stay tuned, I'll be covering this and more in future posts.

Tweet

Share

I have to say that I am very happy with dasBlog's technology. It has been relatively easy to deploy blogs sites.  My only gripe is a combination of the lacking dasBlog themes and my own artistic inability to create my own theme. Then, I discovered that numerous designers make their designs freely available. One is simply required to credit the artist accordingly.  It took me only an hour or so to theme my personal site at www.xavierpacheco.com.  To find free themes, simply Google "Free CSS Templates". 

Have fun!

Tweet

Share

I can say unhesitatingly that every project on which I have worked has been a collaborative nightmare.  The reason? Because Email has been the primary means of team collaboration.

I am pretty much sold on the Wiki approach to team collaboration. At this point, I have not personally implemented a Wiki, I am currently in the process of reading about the various options available. Needless to say, I am only interested in free / open source options.  At the moment, I'm considering ScrewTurn Wiki.  I am also anxious to see what Google does with their JotSpot acquisition.

In the meantime, to see why Wiki is good for collaboration, watch this video.

If you have any comments/suggestions on Wiki tools - do tell!

Tweet

Share