blog.fossmo.net

I held a lightning talk a on a seminar a while back about electronic storyboards being pacifying. I like to share it with you. It’s in Norwegian.

Elektroniske storyboard er passifiserende from Pål Fossmo on Vimeo.

Tags: presentation

In the beginning of May I’m going to speak at a agile seminar in Trondheim. The topic for my talk is called “Electronic storyboards are pacifying!” and is based on a blog post I wrote some months ago. The seminar are arranged by Dataforeningen and XPmeetup. I’m looking forward to presenting my topic and the seminar.

Tags: presentation

Have you ever experienced how pacified you can feel when a co-worker takes control over your keyboard and mouse? It feels like he or she is intruding into your personal sphere. You might have asked for help, but not to be invaded. It's strange to think of how much "power" the person controlling the mouse and keyboard has. If the person holding the keyboard and mouse isn't aware of the "power" he or she got, and don't bother to include the other person, it's likely the person falls into a apathetic state just watching the screen, and not focusing on how to solve the problem.

When doing a sprint planning you should avoid using a electronic storyboard. My experience is that you end up with one person, probably the scrum master, running the whole show. The other team members will probably sit pacified looking at the screen. Doing nothing, or in best case trying to participate but not being able.

You should rather use a story board hanging on the wall in your office. Perhaps a whiteboard or maybe a board made of gray paper. And Post it’s, of course. This way everyone can participate in the process of adding tasks (and user stories). This promotes cooperation and builds team spirit. Everyone can have hands on experience with the process. It builds understanding for the problem being solved. It lets the team work more in parallel. While one team member is finishing writing one task (or user story), another member can start with the next task (or user story). I'm not saying that an electronic story board can't be used, but you should have very good arguments for using it. It's to pacifying!
If you disagree, remember one of the statements in the agile manifesto; "Individuals and interactions over processes and tools".
What is your experience with electronic story boards?

Tags: scrum

I have had vacation for a month this summer. I recommend it ;-) This has given me the opportunity to read some books. Not only fictional books, but also a couple of professional literature books. Both of them teaches best practices when developing. Head First Software development focuses on software development in the light of Scrum. A very nice book. I recommend people not familiar with Scrum to take a look at it. It explains things in a very brain friendly way. A great read. The other book I read this summer was Code Leader by Patrick Cauldwell.This book focuses more on best practices when developing software. When reading this book I found my self sitting nodding my head in recognition. Cauldwell has captured the essence of how I think software should be developed. Also a great read. I'm looking forward to the next book by this guy. If you do not have something to read right now, pick up one of these books. 
  
 

Tags: books

In many projects I have been working on, I often have seen that it can be problematic to get the product owner to create users stories with business value. The product owner understands what he or she wants, but forgets to focus on what is important to the business. If you run into this in a project, you should tell the  product owner that he or she never should create a user story that have no business value.

If the customer find it difficult to get the userstories down on paper, a pattern like the one below can helpe the product owner (or also the team) to get started: 

As a ROLE I want to ACTION so that BUSINESS VALUE (IS MEET)

Every user that interacts with the system should be put into a ROLE. Roles can be a user, a administrator, a report viewer and so on.

The ACTION is what the role is doing to the system.

The BUSINESS VALUE shoud be something that gives value to the business (or at least value to something using the system).

Here is a example of a user story that contains a business value:
As a user I want to log in with a password and a username so I can buy a Ipod.

And a example of a user story that probably doesn't contain any business value:
As a user I want to click a button so that the background color changes to green.

The last example does not give any business value to the customer and shoud never be added to the backlog in the first place. If the product owner later wants to add this story, it's ok, but it should be proritized last in the sprint.

Next time you are doing sprint plannig you should try to follow this simple rules, and I think you will end up with less features to be done in the sprint and you also will give the customer a application full of business value.

Tags: scrum

I have used Model View Presenter (MVP) a lot the last months. It's a great pattern, but a lot of the people I talk to have problem understanding how it works, and how to use it. I will try to explain it simple in this blog post.

Passive View and Supervising controller
The creator of MVP, Martin Fowler, spilt the pattern into to new patterns. This was due to apparent confusions between Model View Controller and MVP. The new patterns is called Passive View and Supervising Controller. The main difference between this to patterns, is that Passive View puts all the view update behavior in the controller/presenter and Supervising Controller encourage the view to do most of the updating itself, and only brings in the presenter/controller when there's more complex logic involved. In my example application later in this blog post, I show Passive View.

When to use it
MVP is a great pattern to ease up unit testing the graphical user interface (GUI), and to decouple the GUI from the underlying model. MVP makes switching GUI a breeze.

Explained graphically
MVP is a pursuance of an other pattern called Model View Controller. In MVP, the view and the model don't know of each other, but in MVC the view knows of the model, and gets its updates from it.
I will cover MVC in a later post.

The figure below visually illustrates the pattern.

More thoroughgoing, this is what happens:

1) The user executes a action. The action is forwarded to the presenter.
2) The presenter asks the database (model) for the data to view.
3) The model sends the data back to the presenter.
4) The presenter updates the view with the new data.

There are normally four main classes used in the MVP pattern. To be more specific,  three classes and a interface; the view, typical a WinForm, WebForm or XAML-file. The interface, witch describes the fields in the view. The presenter, witch executes the views actions and communicates with the model. And, of course,  the underlying model, e.g. a database.

Example application
I have created an application witch displays name, e-mail, state, etc. The application uses the MVP pattern. This is what the application does: You enter a name into the search text box and the program reads information from a textfile. Information about the user is displayed in the form. 

 
Shows the GUI in the application

Project
The solution consists of three projects. One view, one presenter and one model. If you wanted to have several forms, you would have to create more presenters and views. 

Shows the project structure

Interface
Let's look at the interface. It's found in the presenter project, and is named IPerson. It includes all the fields I want to display in the view.

The last field in the interface is Message. You will find it in the lower part of Form1, displaying: "Data fetched.". If any error occurs in the application, it's shown there. The class Form1 (Form1.cs), implements the interface.

   

Form1 implements all the properties in the interface. This is, as you know the startingpoint of the application. A instance of the presenter is created in the view. This way the presenter and view can communicate, and the presenter can update the GUI elements.

Shows some of the properties in Form1

When the search textbox is filled with a name, a event is triggered. It ends up in the method txtSearch_KeyUp in the class Form1:

The presenters constructor, inputs the view and the class fetching data from the model, as parameters. Hence, the presenter has access to the view and the model. This way of doing things is called Dependency Injection.

In the method UpdateData (called from the view), data is fetched from the datasource, and the view is filled with the returning data. If a exception occurs the field message, in the view, displays the error message. If nothing happens, the field displays "Data fetched.".

In the model (Data project), data is fetched from the file and put into a person object. Person object is returned to the presenter. If no data is found, an exception is thrown (witch is displayed in the message field in the GUI).

That is the course of events in the Model View Presenter pattern.
I recommend you to fire up Visual Studio and debug the sample application.

If you want to download the sourcecode for this example, you can find a link below.  

Tags: dependency-injection, model-view-presenter

Why, you ask?
It makes you and your team a lot more productive. A lot of the time you is programming, you is doing things that have been done by other programmers. Why not take advantage of what great programmers have done before you? I think it's a vast of your stakeholders money and time not to learn and use design patterns. Communication between team members will be much more easy. You don't have to draw complex drawings on whiteboards and spend hours explaining what you meant. If your team knows design patterns, you can just say Dependency Injection, and all the team members knows what needs to be done. It will take you about 2 seconds versus hours of explaining. A great book for learning the most basic patterns is "Head first design patterns".

Tags:

Last night I went to a meeting at a agile user group in Trondheim. It was the first meeting and it went really well. One of my co-workers presented hands-on experience with Scrum, taken from the project I'm currently working on. Many of the attendance had experienced the same problems we struggled with. The conclusion of the talk, was that the biggest problem is communication. Communication between stakeholders and developers, but also communication between developers. In future projects I'm going to focus even more on the communication between the project participants.

In one of the other talks, "paper" prototyping, was shown. I really liked the idea. This is how they did it: First they gathered the stakeholders and some of the developers. Then they used a white-board and drew all the screens in the application on it. A digital camera was used to take a photo of every screen they had drawn. They then imported the photos into PowerPoint and linked  the buttons and other interactive GUI elements together. This way they could click thru the application and "try" it out before the coding and graphical design started. Doing prototyping like this, makes it easy to change the screens and all the project participants easily sees how the application should work. This eliminates a lot of unnecessary discussions between team members. I will definitely try this out in the next project.

Tags:

In the current project I'm working on, we use Scrum. I'm a big fan of the process. I like the idea of letting the team have "full" control and decide how to get the software finish. A good checklist for Scrum is Scrum Checklists. It's free if you register.

Tags: