Archive | Productivity RSS for this section
June 22, 2010 

3 risks with Agile decision making

Agile teams are generally cohesive and are empowered and expected to make day-to-day decisions. A large part of empowerment in Agile methods is that the team makes the decisions, not the project manager. However, there are some risks involved with this type of decision making. In this article I describe some possible risks.

Group think

The first risk in decision making is group think.

Group think has the following symptoms:

  • Little or no consideration of alternate plans
  • Risk is not assessed
  • No review is taken of rejected plans
  • Advice from outsiders is not sought
  • Facts that support the plan are acknowledged, facts that do not support the plan are ignored
  • Contingency plans are not created

Surprisingly, synergy and loyalty to each other and to the team leader are a team’s greatest qualities, however, they are the same factors that lead to group think.

Abilene Paradox symptom

The second risk in decision making is the Abilene Paradox symptom.

The Abilene Paradox symptom has the following symptoms:

  • Members, as individuals, privately agree on the correct decision to make. This is not shared with the group.
  • Members, as individuals, privately agree on how the problem or situation being addressed can be resolved. This is not shared with the group.
  • Instead of communicating their views, members keep their views and reservations to themselves, agreeing with views they are opposed to. As the individuals have not presented their views and reservations, a collective decision is made that is actually contrary to the views of all members.
  • Members feel frustration, even anger, at this and find someone, or some people, to blame.

The Abilene Paradox is real. How often have you agreed to a suboptimal solution? What if every other team member felt the same way about this solution?

Decision hijacking

The third risk in decision making is decision hijacking. This happens when for example a developer implements features that are not needed right now. The developer hijacks the decision to implement these features.

Example during daily stand-up:
Developer: The customer databases will be used by several applications, so I have implemented support for dealing with various technologies, including Oracle. It took a lot of time. Scrum master: Did we not agree on postponing this? Developer: We need this later and now it is done.”

Decision hijacking is a big problem because the decision making itself is removed from the team as a whole. This behavior has a big impact on trust within the team.

Solutions

Conflict in Agile software development projects can be beneficial to both process and product.

The literature proposes some solutions to the problems with decision making described above. These solutions are based on the existence or stimulation of intra-group conflict:

  • Separate groups should be formed, under different leaders, to propose solutions to the same problem (groupthink)
  • A devil’s advocate should be appointed (groupthink, Abilene paradox)

For the decision hijacking risk, make sure that developers are on the same page. Working together as a team means taking decisions together.

Sources:

  1. McAvoy, John, en Tom Butler. “The role of project management in ineffective decision making within Agile software development projects.” European Journal of Information Systems 18.4 (2009): 372-383. Web.
  2. Moe, Nils Brede, Torgeir Dingsøyr, en Tore Dybå. “A teamwork model for understanding an agile team: A case study of a Scrum project.” Information and Software Technology 52.5 (2010): 480-491. Web.
June 1, 2010 

It’s not about the features!

I believe that any software developing company that wants to have a competitive advantage needs to stop focusing on just building features, but instead focus on the users.

Many companies seem to focus on the checklist of features that are dreamed up by marketing. Most of these checklists result from doing ‘competitive analysis’, just look at what the competitors, and do that too. Development teams have to copy all the software features of the competition, just to keep up. That is mediocrity at its best.

Developing software is not a unique trait. It’s not that hard as it used to be, the lab coats are long since gone. Coding can be outsourced to China or India at a fraction of the cost, as can many other aspects of software development.

Shipping a huge amount of features became relatively cheap. The time of industrialization has come for software development. Lines of code are becoming cheaper every minute. A lot of open source software (‘free software’) now has the same (or more) features as commercial available software.

So, it is not about building a huge amount of features.

It is about building clever software that works really well, in its context. Companies have to build revolutionary, groundbreaking, surprisingly good software to be noticed and successful. It has to be different and fresh, revolutionary perhaps.

How do you do that? Invest in interaction design. Do research to find out who your users really are. Talk to them. The real users.

Learn about them. Find out what they need. Find out what they like, what they don’t like.
Learn where your software becomes part of their lives.

Learn how to improve. Improve your software, and learn more. Make your users happy. Never lose them out of sight.

November 1, 2009 

Automatically test your Wicket panel HTML markup

Are you testing your HTML markup automatically yet? If your markup does not match the Java code, your Wicket panel does not work. It’s easy to get early feedback when your panels are broken: just unit test them!

In this blog post I describe a way of automatically verifying that the HTML markup of Wicket panels match the Java code. Scroll down to download the demo project!

Unit test

Unit testing Wicket panels with EclipseI created a JUnit test that you can add to your project to automatically test as much Wicket Panels as possible. Automatic testing works by resolving all panels on the Java class path and feeding them to the WicketTester. When a panel has invalid markup, the WicketTester will give an error: early feedback!

How does it work?

The Wicket panels that can automatically be tested should have a ‘default’ Wicket constructor, like this:

public DemoPanel(String id)

Resolving all panels is done with Spring 2.5’s ClassPathScanningCandidateComponentProvider (don’t you love those names! How can they stay below 120 characters per line?)

The ClassPathScanningCandidateComponentProvider is a component provider that scans the classpath from a base package. It then applies exclude and include filters to the resulting classes to find candidates.

Testing panels

@Test
    public void testAllWicketPanels() throws Exception {
        WicketTester wicketTester = new WicketTester(new WicketApplication());
 
    	ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(true);
        provider.addIncludeFilter(new AssignableTypeFilter(Panel.class));
 
        Set components = provider.findCandidateComponents("nl/stuq/demo");
        for (BeanDefinition component : components) {
            Class clazz = Class.forName(component.getBeanClassName());
            if(hasDefaultConstructor(clazz)){
            	testWicketPanel(wicketTester, clazz);
            }
        }
    }
 
    private void testWicketPanel(WicketTester wicketTester, Class clazz) {
    	wicketTester.startPanel(clazz);
    	wicketTester.assertNoErrorMessage();
    	wicketTester.assertNoInfoMessage();
    }
 
    private boolean hasDefaultConstructor(Class clazz) {
        for(Constructor constructor : clazz.getConstructors()){
            if(constructor.getParameterTypes().length == 1 &&
               constructor.getParameterTypes()[0].getSimpleName().equals("String")){
                return true;
            }
        }
 
        return false;
    }

The test instantiates a new WicketTester. After that, the ClassPathScanningCandidateComponentProvider is created and configured to scan only for Panel classes in the nl.stuq.demo package and below.
After that, the found components are all checked. If they have a default constructor, the test is executed.

The boolean hasDefaultConstructor(clazz) method checks if the class has a constructor with only one String argument, the Wicket id.

Keep in mind

  • This is only for lazy people (good developers are lazy in some ways).
  • You need a dependency to Spring.
  • Only Panels with a certain constructor are tested.
  • Only instantiating the Panel is tested, so code coverage has no meaning for this test. Real testing is still needed.

Download demo project

The demo project is a Maven project based on the Wicket 1.4.3 quickstart that contains the test class and an example panel to be tested.
Download demo project.

Extract the zip file and run mvn test to run the tests. Then fire up your IDE and check how it’s done.

You can change or adapt the given JUnit test to also automatically test classes extending from Page or Component.

Join in with your opinions and code! I’m curious to see what clever way you have of testing code.

February 11, 2009 

Interaction Design and Extreme Programming

Discussions are fun!Today I visited TNO Information and Communication Technology to socialize and share some ideas, which was really inspiring. We covered almost everything, from Scrum to buying cars to the paradox of choice and much more. Agile minds wander along random paths, I guess…

Anyhow, Erik talked about the discussion of combining user centered design/interaction design and extreme programming. Here is a small analysis of both and some pointers for anyone taking interest in the discussion.

Basically, the discussion boils down to this: Alan Cooper says you should do interaction design before doing anything else. Kent Beck disagrees as he wants to integrate interaction design in the iterations of XP. What is your opinion?

What is Interaction Design?

Interaction Design deals with user related issues and tries to build products starting from the users point of view and not from the implementation or technological side. This “user-centered design“ approach is proposed by Alan Cooper, a very well known author in the usability community. He positions the task of interaction design as the first phase prior to the other phases of the waterfall model. It is important for him that no line is coded before interaction design is done in order not to influence or narrow interaction issues by pieces of the product that are already present. (source)

What is Extreme Programming?

The Extreme Programming software development methodology was conceived by Kent Beck. It presents an alternative to the waterfall model of software engineering by encouraging practices that invite early feedback and iteration based development.

Kent and Alan discussing

It seems the link to the original discussion is not working. Fortunately, archive.org has it.

Alan Cooper says at the end of the discussion:

The interaction designers would begin a field study of the businesspeople and what they’re trying to accomplish, and of the staff in the organization and what problems they’re trying to solve. Then I would do a lot of field work talking to users, trying to understand what their goals are and trying to get an understanding of how would you differentiate the user community. Then, we would apply our goal-directed method to this to develop a set of user personas that we use as our creation and testing tools. Then, we would begin our transformal process of sketching out a solution of how the product would behave and what problems it would solve.

Next, we go through a period of back-and-forth, communicating what we’re proposing and why, so that they can have buy-in. When they consent, we create a detailed set of blueprints for the behavior of that product.

As we get more and more detailed in the description of the behavior, we’re talking to the developers to make sure they understand it and can tell us their point of view.

At a certain point, the detailed blueprints would be complete and they would be known by both sides. Then there would be a semiformal passing of the baton to the development team where they would begin construction. At this point, all the tenets of XP would go into play, with a couple of exceptions. First, while requirements always shift, the interaction design gives you a high-level solution that’s of a much better quality than you would get by talking directly to customers. Second, the amount of shifting that goes on should be reduced by three or four orders of magnitude.

Kent tries to prevent the ‘phases’ in developing software with XP. He responds:

I’ll divide what Alan is talking about into two things: a set of techniques, and the larger process into which they fit. While I’m 100 percent with the techniques themselves, I’m 100 percent against the process that he described for using them. The techniques are optimized for being thoughtful in a cognitively difficult, complicated area where you’re breaking new ground, and the thinking that’s embedded in the practices is absolutely essential to doing effective software development.

[..]

To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that’s really far more effective than either of those two things in isolation.

It would be great if interaction design and extreme programming or other agile techniques can be combined. I have been in projects without the input of an interaction designer. After some time, you see where the user interface should be improved, but you have no time or knowledge to solve the issues. In my opinion, an interaction designer definitely has it’s place after starting a project.

But… I have no idea if it would work to start a project from the interaction design phase, as Alan proposes. I think a ‘proof of concept’ at the start of a project is very helpful, but when reading the discussion, Alan prohibits doing technical stuff when doing interaction design up-front…

Interesting discussion! What’s your opinion on this? Can interaction design and extreme programming be combined?

September 3, 2008 

User friendly form validation with Wicket

By default Wicket shows error messages together in a single place in the HTML form. This has some drawbacks to usability, especially if you have long forms with lots of fields. Read further for a tutorial exploring possibilities to improve the location of the error on the page, thereby improving usability.

The default FeedbackPanel shows all errors in one place. When you enter a wrong value in an input field below the fold, the input field is a mile away from the error above the form. This makes it unclear which error message corresponds to which field.

form-usability-scanning.png

The image on the left shows that a lot of page scanning is needed even with moderate sized forms.

With more than a few fields, the user is confused as which error corresponds to which field. It is a big problem when your e-commerce site scares away many potential clients who can’t complete your web forms!

The default form

Before I describe how to create a more user friendly form, first the ‘default’ form. The following is an example of a standard Wicket form. This kind of form is the one you get without doing any ‘special’ magic things. Place your mouse cursor over the image to see the default error messages above the form.

Default Wicket form with FeedbackPanel at the top

This form will be the starting point for our improvements.

The improved form

This is what we are going to make:

Better and improved Wicket form with FeedbackLabels throughout

As you can see, the error messages are directly next to the component that caused the error. This reduces the scanning of the page to link the error message to the right form component.

Step 1: Introducing the FeedbackLabel

The FeedbackLabel is a custom component I’ve written for this tutorial. With this custom label, you can show important feedback messages related to a FormComponent.

This has the advantage that you can place your Feedback messages in any place you want.

Add this to the Java part of the form:

// This shows feedback when the name input is not correct.
FeedbackLabel nameFeedbackLabel = new FeedbackLabel("name.feedback", name);
form.add(nameFeedbackLabel);
 
FeedbackLabel colorFeedbackLabel = new FeedbackLabel("color.feedback", color, customText);
form.add(colorFeedbackLabel);

Add another SPAN tag for every feedback label. You can place this near the relevant form component within the form.

Step 2: Removing the FeedbackPanel completely? No, filtering!

At first, it looks like you can remove the FeedbackPanel completely. But, then you will not be able to use the info() method to display text inside the FeedbackPanel! Therefore we need a way to filter the FeedbackMessages so error messages are not shown. I have written a FeedbackMessageFilter to accomplish that. It filters out the unwanted error messages.

// filteredErrorLevels will not be shown in the FeedbackPanel
int[] filteredErrorLevels = new int[]{FeedbackMessage.ERROR};
feedback.setFilter(new ErrorLevelsFeedbackMessageFilter(filteredErrorLevels));

I have included the ErrorLevelsFeedbackMessageFilter in the project files, so you can reuse this in your existing projects. Remember if you use the error() method, you cannot use this filter! Instead, create your own filter that filters based on components.

Step 3: Adding some style, the ComponentVisualErrorBehavior™

I always love extremely long class names, like the BookmarkablePageRequestTargetUrlCodingStrategy or the SharedResourceRequestTargetUrlCodingStrategy. It makes my day to introduce a class name consisting of four words, the ComponentVisualErrorBehavior™.

This behavior changes the CSS styles for components that are invalid according to the Wicket form validation. You see in the screenshot that the textfield has a red line around it. This is the result of the ComponentVisualErrorBehavior. You can easily change the styles that are applied.

form-usability-tutorial-namefield.png

To add the ComponentVisualErrorBehavior to your component, just add one line in your Java code:

name.add(new ComponentVisualErrorBehavior("onblur", nameFeedbackLabel));

“onblur” stands for the event that triggers this Behavior. The nameFeedbackLabel will also be updated when this is triggered, so that it will show the relevant error (or nothing if the input is valid).

Download

Download the complete example project and start experimenting! (run with mvn jetty:run and connect to http://localhost:8080/demo)

Let me know how and where you use it in the comments!

Older Entries »