Category: Agile

Down memory lane, The Agile Manifesto

With the proliferation of agile term overloads and the software suites that claim to be “agile”, how do you differentiate the noise from the real thing?

Is chaos really agile?

No, certainly not. Collaboration and working software, developers at the center of enabling business change, that for me is Agile. Chaos and unmanaged change is not.

I signed the Agile Manifesto in June of 2005:
Lizet Pena de Sola is an agilite

Every time someone tells me about the next software suite that will track all my projects and solve all my problems because it will make the “process” really “agile”, I go back and read the manifesto.
If this new software suite contradicts or impedes any of the 4 cornerstones of the manifesto, that software suite, process, administrative paperwork, extra meeting, is out. Did I mention that extra excel file logging the exact same “issues” everyone knows about and the email chains?

Here are the four main points of the Agile Manifesto, focus on the ones on the left and feel free to apply these four points to any new “agile” tool that will solve all your problems overnight. The points are great to detect baloney.

UX advice I got from an expert…

1. Give users multiple ways to achieve their goals

2. Give users all the functions they need to achieve the task at hand.

3. Be consistent in navigation, screen layout, and interaction design.

4. Use ‘widgets’ correctly. Incorrect use of widgets make people confused.

5. Assume users have no memory. They shouldn’t need to remember things about function or navigation.

6. Users are like Bears. Never surprise a user.

7. Users should never need to figure out how something works – the function of an element should be obvious from its visual design.

8. Don’t crowd screens. Just because it fits doesn’t make it OK. White space=good

9. Alignment and formatting matter. Make sure elements are presented neatly and professionally. Group similar things on the screen.

10. Iterate your designs. The more you test-analyze-modify, the better your software will be.

Thanks to Rob Lokinger from CAI Canada.

The concept of test beds or velcros for software modules…

Last week I attended a conference by Mario Cardinal at MSN Canada. The conference was part of the Toronto Architecture User Group.

The presentation had quite a few valid points along with the concept of “velcro” or test bed for modules. Test beds are a very familiar concept in electronics. In order to test hard drives or dvd drives, the manufacturer create test beds as opposed to test the parts in a computer. The same line of reasoning applies to software.

Here’s a Tech Ed 2009 presentation by Mario Cardinal.
Download Video

I look forward to see the code from this presentation at CodePlex and see what Mario Cardinal will blog after the Alt.NET conference in Vancouver, whether the same approach can be achieved with mocking frameworks.

Today (June 15th) I found the code for the Velcro project at codeplex.com. Hope this helps you evaluating this concept: http://velcro.codeplex.com/

Happy coding!