Archive for June, 2012

Mobile App vs. Mobile website

Comments Off on Mobile App vs. Mobile website

On the mobile developer conference Devmobile in Gothenburg I talked about “What suites our users best in term of the mobile channel!”. It was real crowded and over 110 people (too bad the conference room only had 70 chairs!) attend my break out session about what pros and cons for different solutions regarding. I have got rather many questions and contacts after this speak which is real fun. Here are my slides if you interested!

Cooking and team capacity

1 Comment »

Cooking is one activity that I have organized a couple of times with my development teams. It’s a good way to share common experiences and to get to know each other outside the office. When we were in a restaurant one evening, the chef in charge told us about yesterday’s session. They had a group from an organization that was very hierarchical. No one dared to show they were more knowledgeable than their boss and no one dared to be different from their boss. No one dared doing anything they haven’t done before, because they didn’t want to risk failure. When no one dares to risk anything or go outside their comfort zone, the food turned out to be very ordinary, and no one enjoyed the meal.

It’s the same with software development – if differences are accepted and group members take advantage of differences, the project tends to be better adapted to the needs of customers. If no one does something different or takes risks, the capacity of the team is minimal and is only based on what members know as accepted.

Why schedules are slipping!

Comments Off on Why schedules are slipping!

Milestones are like a progress bar indicators for internal stakeholders, they give everyone involved feedback on the progress. In different software I have come across at least three different progress bars, the first quite easily reach 90% then stalling and you’re wondering if stopped. The second one just shows that it’s working and never stall but you don’t know how much work that’s left. The third one gives you the feeling that it’s accurate and that it’s adopt in order to give you a realistic estimate. Even if the progress bar says it’s a long time left you prefer that because then you can do something else. Sincere (Swedish: uppriktigt) estimation is more valuable than working in the dark and hoping that the first 50% of the work will be evidence that the 50% of the remaining work. But this is not so easy as it sounds. Let’s look on some aspects of tracing progress.


Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship in time?”

“Hmm, something have come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one have thought of and the timetable slipped 3 month.” How big chance is that? Quite small I will say. Because timetable slips don’t happen at the end of the milestone or project. Slips just show up at the end. But they happen every day and every hour. As soon someone answers an unexpected e-mail, have to be home with sick kids or tracking down an intermittent but catastrophic bug, slips happens. These things are also important and needs to be done but the sooner you can identify how much that’s left and if there is a timetable slipping risks the better time estimation it will result in. Team members and stakeholders will be more able to trust the timetable.