Agile

Architect’s Role Revisited

I have touched this topic in at least two previous blog posts (Agile Architect and Agilists and Architects), but I seem to be getting into these kind of discussions on a pretty regular basis.

The main area of conflict or misunderstanding is usually around how to create a common architecture or framework (…ouch…) for the entire organization. Most managers and old school dinosaur architects seem to believe that this is best done in long meetings and by producing endless powerpoint presentations and documents containing every buzz word in the world.

I can not stress enough the importance of building an architecture from something that already has been proven to work. And to be able to do that, you as an architect have to get your hands dirty doing some actual coding. An architecture should always be communicated through code, not by slideware!

Øredev 2010 – final thoughts

Having attended all previous Øredev conferences I think I am pretty qualified when I say that this year’s conference was by far the best. Great topics, excellent speakers and flawless organization. Even the closing panel debate, which usually is just something you have to suffer through to be able to win prices in the raffle at the end, was interesting this year.

Since it is such a diverse conference, it is difficult to point out a single item that was the main trend at the conference. But if I should pick one thing, I guess it would be that most of the talks I attended more or less circled around the Get Real! theme of the conference. Hopefully this means that the industry is getting more mature. Don’t want to be a self-fulfilling pessimist, so it is just to be optimistic 🙂

See you there next year!

Are Unit Tests Necessary?

At work today I came across a project that had not written a single unit test for their new code and wondered what the hell they were doing. Nothing unusual except that apart from the usual excuses about time constraint etc., they had the guts to challenge the value of unit tests. I did not believe what I heard and for a moment wondered if I had gone through some kind of time capsule when I was visiting the pyramids in Cairo last week and come back in a time before unit testing was invented. But a quick glance at the date on my watch ensured me that it was still 2010.

The only comforting thing about this is that as long as there are projects like this, there will be plenty of work for software consultants to clean up the mess. Just a pity that the first couple of weeks will be spent writing unit tests to be able to start refactoring the code. Good thing that writing unit tests are pretty fun and addicting, or to quote one of Kent Beck’s tweet earlier today “… tests are like potato chips”.

Daily Scrum for Distributed Teams

Even if you are using Scrum or any other development model, agile or not, it is always good practice to have a short status meeting with your team every day. Usually the best time for such a meeting is in the beginning of the day as it gives the team the chance to resolve any issues the same day. Having the meeting in the afternoon implies that any issues probably have to wait until next morning, which is usually not a good thing.

So far, nothing new. The practice of a short stand-up synchronization meeting is pretty well established and non-disputed.

What if you have a team that is distributed not only in distance, but also over different time zones?

Which time zone should be used as basis for determining when to have the meeting? Usually the project it ends up being run by the project manager’s (*) watch. That means that the team in the other end probably will have the meeting in the afternoon. A pretty usual distributed team setup in Europe nowadays are something like this:

Europe: Project manager, architect, test manager
Offshore (China or India): Lead developer, developers, testers

That means that the largest part of the team, the team that actually are doing most of the work are having the daily scrum at a less optimal time of the day than the project management. I think that to really succeed with distributed agile development, you have to let the team decide how to work even if this implies awkwardly timed daily scrums for the project management. Of course, this applies to other aspects of the development process as well.

(*) …or Scrum Master if you prefer…

Øredev 2009 – Day 3

I was not present at the conference yesterday, so this is actually my second day here, and that also explains why there were no post from yesterday. Another explanation could have been that I was lazy, but that is not the case this time… 🙂

Well, over to what this post is all about: the conference. The keynote was held by Scott Hanselman. He gave an excellent talk about effectiveness and efficiency. Some really good stuff to bring back from that speech. Will try to list some of the techniques and tools he mentioned in a later blog post.

I will also summarize the rest of the sessions I attended today very soon here…

Great conference!

KanbanFX

I really like the simplicity in Kanban. It should be enough for most small projects, and especially AO teams. Even though all you really need as tool support is a white-board and a couple of post-it notes, larger organizations often require you to hook into existing tools for requirement management, issue tracking etc.

I have not been able to find any tool fulfilling this need, so I decided to create on myself. Thereby, KanbanFX was born!

KanbanFX is a JavaFX implementation of a Kanban board. Source code and a very limited demo version is available on Kenai:

http://kenai.com/projects/kanbanfx.

Please join the project if you want to contribute. I am pretty sure that I will need help with at least the graphical elements when we get to that…

Kanban

One of the new words buzzing around in the software industry these days is Kanban. Most people have heard of, or is using, some variant of Scrum or ScrumButt, but Kanban is still pretty new. Henrik Kniberg has written a great article where he compares Kanban and Scrum: Kanban vs Scrum – a practical guide.

In short, Kanban is the Less-is-more cousin of Scrum.
Kanban prescribes only three constraints:

  • Visualize the workflow
  • Limit WIP (Work In Progress)
  • Measure the lead time

The rest is up to you. Kanban does not exclude Scrum or vice versa. Read the article, inspect and adapt and find what is best for you and your organization.

JUnit Max did not survive

I wrote about JUnit Max in a previous post. In that post I commented that I was not sure if people were willing to pay $2/month for it. It turned out that I was right. Kent Beck just announced that he has deadpooled JUnit Max.

It is kind of sad that it seems impossible to sell such a great product, but I guess we have got used to that all tools are free. If I look at myself, I would rather have to pay one-time license fee for it than a $2/month subscription. Too much hassle filing expense reports every month for such a small amount.

That said, I actually never tried it since it was not available for NetBeans. Please remember us NetBeans folks next time! Maybe we are easier to get money from than the Eclipse guys… 😉

Kenai

Kenai is Sun’s connected developer destination. It is a integrated suite of developer services where you can host your open source projects. Currently the following features are supported:

  • Source Code Management (Subversion, Mercurial, and Git)
  • Issue Tracking (Jira and Bugzilla)
  • Wiki
  • Forums
  • Mailing Lists
  • Download facility for documents
  • Evolving integration with NetBeans

When you create an account at Kenai, you can host up to five projects for free. I imported two of my hobby projects to try it out, and I liked it. See wikipedia for a comparison of open source software hosting facilities.