Category Archives: Non-technical

Articles that can be understood without coding experience.

Er IT-prosjektenes tid forbi?

Man kan lese fra moderne tanker på IT-utvikling at prosjekter er en avleggs arbeidsform. For de som har erfaring med utviklingsaktiviteter innen offentlig og privat sektor kan dette virke som en rar påstand. De aller fleste ser behovet for å unngå store prosjekter, men er prosjektet som arbeidsform virkelig avleggs?

Det spør naturligvis på hva man mener: I alle de årene jeg har jobbet med IT-utvikling er det en ting som er sikkert. Arbeidet endrer seg til det bedre når man går fra å bygge noe på laben og over til å lansere programvaren for brukere som benytter seg av den til daglig. Før dette tidspunktet er “kvalitet” en subjektiv og spekulativ egenskap, “fremdrift” er et begrep som må kvalifiseres med mange forbehold og formålet til hele initiativet er fortatt en hypotese der alle har sin egen tolkning.

I dag er den ingen gode grunner til å levere programvare gjennom et prosjekt som sitter flere kvartal eller år og bygger noe som så skal være klart til en stor lanseringsdag. I den betydningen er prosjekter en avleggs modell.

Men noen ting har ikke endret seg: Mange organisasjoner vil ha behov for et team som er større i en periode – et prosjektteam. Mange organisasjoner kunne ha verdi av leverandører som kan ta ansvar for at det arbeidet som gjøres er av god kvalitet og har en rimelig kostnad.

Men organisasjonen gjør smart i å koble dette prosjektteamet tett opp mot den mer permanente organisasjonen. Linjeorganisasjonen kjenner behovet og rammevilkårene bedre enn den midlertidige organisasjonen og vil ta over forvaltningen av produktet på sikt.

Og nye produkter vil ikke lanseres dager eller en gang uker etter at de har blitt påbegynt. Ved å levere så ofte som hver uke eller endog flere ganger om dagen kan organisasjoner heve kvaliteten og redusere arbeidet og bekymringen i forbindelsen med nye leveranser. Men det er ikke gjort på en dag. Dersom man skal etablere et nytt prosjekt kan man med fordel drifte dette (for eksempel i en skybasert løsning) allerede etter få dagers utviklingsjobb. Men det vil ta noen måneder før man har nok funksjonalitet til at man ønsker å invitere noen utenfor prosjektet til å bruke løsningen.

Er IT-prosjektenes tid forbi? Jeg håper vi ikke lenger vil se initiativene som bruker titalls eller hundretalls millioner kroner før man lanserer noe for brukere. Men organisasjoner vil fortsatt måtte benytte seg av økt bemanning i satsningsperioder. Og nye produkter bygges ikke på en dag før de kan lanseres.

Posted in Agile Release Patterns, Non-technical, Norsk, Software Development | Leave a comment

The key is empowering the people who do the work

I was humbled and encouraged to learn that I was nominated for Nordic Startup Awards category of Developer Hero for my contributions to the developer community. You can vote for me or one of the other great candidates here.

For the last ten years, I have felt that the main pain points of the software development world could be fixed by empowering and inspiring those who do the work. From my perspective, I have focused on the developers.

If you are a developer working on a project, both you and the people around you will benefit greatly if you learn new things and share what you know about the problem your project is trying to solve, about the technologies you use and about the way you’re working.

Ideas like pair programming to spread the knowledge, simple design to make it possible to understand the whole solution and collaborative product backlog planning to understand the problem can help you do this.

This was the inspiration behind me starting up Oslo Extreme Programming meetup in 2004. We have hosted about 100 meetups over the years.

But even beyond your project, if you can share and learn from others in you community, we will grow even further. I have long been a fan of the lightning talk format. Most of the smart experience is in the heads of those who don’t often give talks, who don’t have a lot of time to prepare a long talk and who perhaps only feel they have one or two things to share.

If you are a human being, you know something that can inspire someone else. All you need is to have the courage to try, the patience to structure your ideas and the discipline to practice your talk.

I am proud to have witnessed some of the first talks given by some of the speakers who inspire me today, such as Christin Gorman, Karianne Berg, Henning Spjelkavik and Filip Van Laernen.

This was the inspiration behind me and others starting the Smidig (Agile in Norwegian) conference in 2007. Since 2011, I have handed over the organizing baton to others and I am happy to see that the conference is still thriving and that our original vision is still a helpful idea behind the conference. Over the years, over 500 talks have been given at the Smidig conference, many by first time speakers.

As I saw the Smidig conference in competent hands, I looked around for other areas to contribute. Fellow Developer Hero nominee Simen Sommerfelt convinced me to join the board on the Norwegian Computing Association. The organization has a 60 year history and the people who are involved with the organization possess a well of knowledge. However, the competition from meetup and other communities threaten to siphon away the vitality of the organization.

If you care about a professional field, you can step up and help others in that field find their voice. If you know the people who are worth listening to inside a field, pulling together an event where they can share their knowledge is surprisingly simple. You can use meetup.com to organize a group or you can get help from an organization like the Norwegian Computing Association.

I have been helping events happen in Norwegian Computing Association and I hope to be doing this even more in the future. Together with a great team of organizers, I helped organize the Software conference the last few years. This year, we received recognition as the Event of the year in the Norwegian Computing Association, an achievement I’m very proud of.

As I have moved from event organizer to inspiring other event organizers, my own Oslo XP meetup has fallen off the list of things I’m able to attend to. If you are looking for a place where you can contribute to the community, I would love for someone to step up as organizer for a while.

I have been privileged to be able to watch what happens when developers care about their project, share their knowledge and take responsibility for their professional community. When I see the experience and the result of people caring, I also realize that this goes beyond just the sphere of software professional.

The Norwegian government is spending billions of kroner each year on software projects. Recently, there has been a lot of attention on many of these projects that have very little to show for their investment. I believe that this waste comes from projects being run without respecting the knowledge that the developer community possesses and the professional talent that is available.

Recently, Geir Amsjø has been able to gather together a loose group of like minded people who have been contributing in the public debate on public sector IT spending. We hope that this work can affect the very way money is being allocated to these huge and important projects.

By caring about your profession in your project, your community and the world at large, you can make a difference. Enormous resources are being consumed to build IT systems around the world. Only when the people building the system care about their craft and are being listened to can this investment truly pay off.

Posted in English, Extreme Programming, Non-technical, Software Development | Leave a comment

Getting excited about your project with a news headline from the future

I have an amazing time machine that lets me think better about projects. This is part 2 in a series of blog posts exploring the use of a time machine.

This is a trick that I learned from my User Experience (UX) friends.

In many projects, the project members have a great feeling about the possibilities of the product they are building, even if they quite know if they will get there or if the road ahead will be bumpy. A great way to focus your mind on the goal is to ask your future self to brag about what success the product was.

This exercise works great in groups: Form groups of 3-4 people (group of diverse people are better). Each group gets 15 minutes to draw the front page of a news paper (or online news paper) that picks up the story of the success of the product you all are building together.

Give each group a thick A3 paper and some colored markers. (Avoid pens – they don’t show up at a distance)

Some things to include:

  • The name (and logo) of the publication
  • A headline for the article
  • A sketch of an article image (including image description)
  • An ingress – a short summary of the news story

When the 15 minutes have expired, each group stands up and presents their article.

The posters make for great decoration of the team area (for a couple of weeks, anyway).

Remember: You will only build something remarkable if you can envision how it will be received.

Posted in English, Non-technical, Software Development | Leave a comment

Software 2015 i regi av DND

Jeg sitter i styret i Dataforeningen Østlandet hvor jeg er med å arrangerer Software 2015. Software er en kryssfaglig IT-konferanse hvor vi samler spesialister innenfor forskjellige fagfelt for å få dem til å snakke sammen på tvers av fagområdene.

På konferansen er det dagsaktuelle temaer og trender som står på programmet. Jeg er stolt av alle de spennende temaene faggruppene har tatt fram og samarbeidet vi har fått til på tvers av fagmiljøer.

Vi ser at både kravhåndtering, devops, prosjektledelse og arkitektur fokuserer mer og mer på å bevege seg mot kortere leveransesykluser. Da blir det viktig å forstå verktøyene og teknikkene som gjør dette mulig.

Et annet viktig tema er den stadig mer sentrale rollen IT spiller i samfunnet. Vi har samlet representanter fra store offentlige IT-miljøer som gjennomfører prosjekter som vil påvirke alle i Norge.

Software har også lykkes i å belyse den viktige debatten som skjer mellom sikkerhet, personvern, kriminalitetet og overvåkning i samfunnet.

Jeg synes også det var morsomt å snakke med Frode som er med å arrangere stormaskinsporet. Jeg har aldri satt meg nok inn i stormaskin, men har vært i flere organisasjoner der hjertet av virksomheten har ligget i stormaskinen. Det har som regel vært en målsetning å bli kvitt stormaskinen, men fordi man ikke har satt seg inn i hva den gjør blir dette veldig vanskelig. Frode sa: “De som vil bli kvitt stormaskinen setter seg ikke inn i hva den gjør – så de får det ikke til. Og de som setter seg inn i den vil ikke bli kvitt den”. Jeg er ikke 100% overbevist om at han har rett, men det er spennende tanker.

Meld deg på Software 2015 du også.

Jeg gleder meg, og håper å se deg også på Software 2015!

Posted in Non-technical, Norsk | Leave a comment

Pair programming with Sankalpa

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others.

When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa. In this session, we achieved something that we would be helpless to do alone.

The task Sankalpa and I was working on was to include information from a calendar in Confluence in a date picker in a web application. As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

Looking at the feed, I exclaimed “Oh, I know this – this is vcalendar”. A quick Google later and we had found a library for parsing vCalendar in JavaScript. We quickly finished the code to adapt it to our desired format and moved to the date picker.

I was at the keyboard and I had used a date picker library called jQuery datePicker before. We quickly integrated it and I proudly refreshed the page to show the calendar events in the view! But it turned out that all the functionality that depended on picking a date was now broken.

I started grumbling about how I was much more comfortable with jQuery than with AngularJs. Unfazed, Sankalpa mentioned that Manoj had gotten the date picker to work with AngularJs in an earlier project. “Hey, Manoj, where did we use this date picker?”

Having much more experience with AngularJs than me, Sankalpa integrated the code into our code base and everything was working.

All in all, I had expected this to take 2-3 times as much effort. If we had been alone, we would probably wouldn’t have the courage to start with the integration right away. If he had been alone, Sankalpa probably wouldn’t had known how to parse the vCal feed. If I had been alone, I probably would have searched the Internet for hours to find out how to make AngularJs play well with jQuery date picker.

Together, we did what neither of us could have done alone. (At least not anywhere close to this quick)

Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | 1 Comment

Using pair programming to combat project waste

  • Less Overproduction (of unused functions in interface between team members)
  • Less Waiting (for the only person who knows a particular area)
  • Less Motion (as everyone gets more skilled)
  • Fewer Defects (because two pair of eyes see better than one)
  • Less Over-processing (from duplicate responsibility)
  • Less Inventory (as team works on focused set of features and tasks)
  • Less Transportation (handoffs inside a story)
  • Less Underused talent (as everyone gets to share their skills)
Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | Leave a comment

Om å løse alt bortsett fra det egentlige problemet

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine.

Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser – gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss). Og det er bare starten. Hvor kommer denne impulsen fra?

Jeg har hørt to teorier om hvorfor Java-programmerere ender opp med en kompleks hverdag. Den ene skylder på sjefene, mens den andre skylder på programmererne. Jeg vil ta for meg begge og peke på en vei ut av jungelen.

Teori 1: Steak and strippers

Zed Shaw, mannen bak “The motherfucking manifesto for programming, motherfuckers” skylder på IT-sjefene. Han mener at selgerne fra teknologiske giganter tar med IT-sjefer ut på strippebuler og kjøper biffmiddager til dem. Og vips så kjøper IT-sjefen inn et ubrukelig verktøy som programmererne er tvunget til å bruke. (Zed påpeker at det vil være positivt med flere kvinnelige IT-sjefer, ettersom de i det minste ikke vil være like interessert i strippebulene)

Ref: Zed Shaw: Control and responsibility (http://zedshaw.com/essays/control_and_responsibility.html). Zed Shaw: Programming, motherfuckers (http://programming-motherfucker.com/). Zed Shaw: Video – Steak and Strippers (http://vimeo.com/2723800).

Argumentet er underholdende, men forklarer bare en del av problemet. Mange av verktøyene som står bak kompleksiteten i Java-prosjekter er åpen kildekode og selges typisk ikke av selgere med fete representasjonskontoer.

Teori 2: Blinkende lys

Jeg tror en viktigere teori er at programmerere er opptatt av fancy ting som blinker. Enkle ting som firmaet tjener penger på er kjedelige. Å sette seg ned og flytte data fra databasen og putte det i en webside er kjedelig for en programmerere. Å lære seg et nytt rammeverk som gjør den samme jobben på en fancy måte er spennende. Å fjerne teknologier og lage en enklere løsning er kjedelig. Å innføre et rammeverk som skal skru sammen teknologien er spennende.

Alle foretrekker å gjøre det de synes er spennende. Jeg vet det, for jeg har vært der selv.

Grunnleggende sett tror jeg at Java-programmere selv har skaffet seg de problemene de ofte klager over med komplekse teknologier.

Veien ut av villmarken

For meg var det viktigste skrittet ut av villmarken foredraget jeg hold på JavaZone for to år siden. I foredraget bygger jeg og Anders Karlsen en webapplikasjon i Java uten å bruke webrammeverk. (Innbild deg at du hører et ironisk gisp her)

Jeg har øvet meg på å løse de problemene jeg har i prosjekter med å bruke enklere teknologier. Slik vet jeg hva de komplekse løsningen gjør. Og så langt er det nesten ingen løsninger som ikke innfører mer problemer enn de fjerner. Det de gjør er at de flytter fokuset fra den oppgaven programmet egentlig skulle løse over til alle de teknologiske delene som man skal få til å fungere sammen.

Jeg tror ikke programmerere er bedre eller dårlige enn andre mennesker når det gjelder det. Men vi har alle en tendens til å bruke tiden vår til å finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte. Min far sa det egentlig best: Du bør ikke bruke en kalkulator før du kan løse de samme regnestykkene på papir.

Posted in Java, Non-technical, Norsk, Software Development | 27 Comments

If you’re an architect, knowledge is your enemy

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team.

The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages. When they realize that there’s not sufficient time set aside in the project schedule for the developers to read all this information, the architect may present the material to developers who sit and nod their heads. But what did they really understand?

Instead of the read-listen-and-nod approach, I prefer an approach that I sometimes call “dragging the information throught the heads of the team and looking at what comes out in the other end.” I provide as little processed information as possible, but instead give the team a structured workshop to uncover and structure the information by asking me or business stakeholders. The outcomes of the workshop should be some tanglible results presented by the team. This result is always different from what I had in mind. Sometimes the difference shows a critical misunderstanding, which allows me to go more in depth in this area. Sometimes the difference represents a trivial misunderstanding or difference in opinion and the architect has the difficult task of accepting a small disgreement without distracting the team. Sometimes, the team has discovered something much smarter than the original idea of the architect.

I find it most useful to do workshops in small groups of three people per group. Each group should produce something that they can show to the whole team afterwards. Here are some examples of workshops that I run:

  • Divide in groups of three with the users/business and the developers represented in each group. Each group should discuss and fill in a template for the vision of the product being created: “For some user who performs some business function the name of system is a type of system which gives a capability related to the task. Unlike most interesting alternative our solution has an important advantage“. The groups get 10 minutes before a debrief with the whole team.
  • Each group then brainstorms a list of users, consumers and others affected by the system and write these on sticky notes. This should be about 20-30 roles. The whole team decides on a few interesting users and the groups then write down for some these: What characterizes the user, what tasks do they perform and what do they value?
  • Based on the list of tasks that stakeholders perform, we create a sketch of a usage flow. I like to refine the documented usage flow with a small task group which takes a few hours to prepare a description of the flow of interaction between the system and external actors
  • Groups of three go through the usage flow to come up with Actors (users and systems), Domain concepts (classes) or Containers (deployment diagram) mentioned or implied in the usage flow and write these on sticky notes. After showing the Actors, Concepts or Containers to the whole group, each workgroup then organizes these on flipcharts to create a Context Model, a Domain Model and a Deployment Model.

Many of these workshops can also be run with distributed groups over video conference and screen sharing.

I like to collect all of these artifacts (vision, users, usage flow, context model, domain model and deployment model) in a PowerPoint presentation so it can be easily showed by the team to external stakeholders. Sometimes someone on the team feel that photographed flipcharts with sticky notes are too informal and decide to draw something in Visio or another fancy tool. This is just a plus.

By asking the team to produce something and present it, rather than explaining the architecture to the team, I ensure that the information is really in their heads and not just my fooling myself by my own understanding.

Posted in English, Extreme Programming, Non-technical, Software Development | 3 Comments

The Rainbow Sprint Plan

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you.

Here is an example of a Rainbow Sprint plan:

  1. A customer wants cheap vacations
  2. The customer signs up for daily or weekly notifications of special flight offers
  3. Periodically the System checks which customers should get notifications
  4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system
  5. The System notifies customer of any matching offers via SMS

    1. Variation: The System notifies customer of any matching offers via email
  6. The customer accepts the offer via SMS
  7. The System books the tickets on behalf of the customer
  8. The system confirms the booking by sending an SMS to the customer
  9. The customer can at any point see their active offers and accepted offers on the system website
  10. The customer enjoys a cheap vacation!

What you can see from this plan:

Use case overview: The plan gives a high-level picture of the next release. We can see how the work we are doing is fitting together and how it ends up satisfying a customer need. This is a requirement technique that is basically Use Cases as per Alistair Cockburn’s “Writing Effective Use Cases“. I’ve been writing use cases at this level for the last three years and found it to be a good way to understand requirements. The trick of good use cases is to stay at a the right level. In this example, each step is some interaction between the system and a user or the system and another system. How this communication is handled is something I find best to leave for an individual sprint.

Iterative completion: Each step has a color code:

  • Black: The team hasn’t started looking into this
  • Red: We have made something, but it’s a dummy version just to show something
  • Orange: We have made something, but we expect lots of work remaining
  • Yellow: We’re almost done, we’re ready to receive feedback
  • Green: Development is complete, we have done reasonable verification and documentation

So the plan accepts that we revisit a feature. As we get closer to the next release, things will move further and further into the rainbow. But we can choose whether we want to get everything to orange first, or whether we will leave some things at red (or even black) while bringing other steps all the way to green.

Demonstration script: When we get to the end of the sprint and demonstrate what we’ve created, this plan gives a pretty good idea of what the demo will look like: We will sign up the customer to a dummy signup page (red), we will register some flights in another dummy page (red), trigger the actual scheduling code (orange), then we will see that an SMS is received on an actual phone (yellow). Then we will simulate an SMS response (orange), see that they system made some communication to a dummy system (red), and send “ok” back as an SMS to the customer (orange). This will focus the team around a shared vision of what to do in this sprint.

I have been thinking in terms of a Rainbow Plan in my last projects, but I’ve never used the term before. I think the plan addresses three of the most common problems that I see in Scrum implementations:

  • The team doesn’t see where it’s going, because user stories are too fine grained to get the big picture. User story mapping and use cases address this, and rainbow plans put it into a sprint-context
  • The team dives into technical details during sprint planning. With rainbow plans, the sprint plan becomes the demo plan which coincides with the requirements.
  • The project has a purely incremental approach, where each feature should be completed in a single sprint. This means that it’s hard to keep the big picture and the product owner is forced to look for even small bugs in everything that’s done in a sprint. With rainbow plans, the team agrees on the completeness of each feature.

May you always become more goal oriented and productive in your sprints.

Posted in English, Extreme Programming, Non-technical, Software Development | Leave a comment

How I debrief workshops

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others.

  1. I give everyone sticky notes with three colors
  2. I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.
  3. Everyone puts their sticky notes on a flip chart. As people come up, I read through their notes and pick out some notes that I think were interesting to discuss
  4. When everyone has put up their answers, I read up 1-3 notes about what surprised the participants, 1-3 notes about what they learned and 1-3 notes about what they plan to use it for. I comment on these results.
  5. As I end the workshop, I tell everyone “now, pick up the note with your plan as you leave the room and put it in your pocket. When you find it in the future, ask yourself whether you have completed it, or whether you should put it back into your pocket

"What surprised you", "what have you learned", "what do you plan to do"

I feel this gives a nice closure to the workshop and a drive for people to apply what they’ve learned. Have you been to one of my workshops where I had this debriefing? I’d like to know whether you used the “what do you plan” note. :-)

Posted in English, Non-technical | 1 Comment