Monday, September 25, 2017

My schedule at GOTO Copenhagen

GOTO Copenhagen 2017 is just around the corner, and I have taken a look at the talks that I definitely want to go to this year.

Unlike earlier years, GOTO Copenhagen starts on a Sunday this year, which makes some demands to the quality of the speakers, trying to lure people in early Sunday morning.

Luckily, the conference delivers - there are two keynotes on at 9:00, and while both looks interesting, I am going for Martin Thompson's talk. I have heard him speak a number of times, and every time the talk have been engaging and informative.

After the keynote, there are some interesting talks, but the next talk I really look forward to, is Dan North's Beyond Developer talk. Not only does the talk sound interesting and relevant, I also know that anything Dan North presents is going to be fun.

Skipping to the talks on Monday, I have spotted the following talks I'd be interested in:
The many security breaches in recent months, shows that security is still a hugely important topic, which is all too often ignored or neglected. These two talks addresses different, but equally important, aspects of security.

Tuesday, there is a track called Herding Cats: The Human Factor, where I plan to spend most of my time, for reasons I explained in my last blog post

Other than that track, I am looking forward to the end keynote by Linda Rising. Linda Rising is one of the most engaging and brilliant speakers I have ever heard, and it is a pleasure to go to one of her talks.

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.

Thursday, September 14, 2017

The importance of peoples tracks at IT conferences

Let's talk about the importance of peoples tracks at IT conferences.

Some IT conferences only focuses on technical issues, but some conferences, such as the QCon conferences and the GOTO conferences always include a peoples track.

I generally go to these tracks if I have the chance, since I think they are important.

Last month, James Damore published his now infamous open letter, where he wrote a screed against diversity in Google and the tech sector as a whole. The screed was not only incredibly scientific illiterate, but also clearly demonstrated the need for people tracks at conferences.


In the upcoming GOTO Copenhagen 2017 conference, there is a people track that illustrates why I think they are important.

The track contains five talks:
  • The Engineering-Manager Transition: How to take great engineers and make them great technical leaders
  • Stress and depression – a taboo in our time
  • Scaling Engineering Teams
  • The 2D Kitten Problem
  • Build the right thing: how to survive the accelerating rate of business change through experimentation
While these talks are all about people, they are quite diverse, allowing the listeners to learn from the experiences of others, and to see new perspectives.

In the above list of talks, it is especially the second and the fourth talk that I think makes the track worth my time.

The second talk,  Stress and depression – a taboo in our time by Gitte Klitgaard, raises a subject which is all too rarely discussed, and which most of us are affected by - either directly or indirectly.

The fourth talk, The 2D Kitten Problem by Laura Laugwitz, is described thus:
"Diversity" is one of those buzzwords that alternates between being supercharged and sadly hollow. While many tech companies like to boast about their diversity programs, the numbers regarding their employees don't change much. But that's no reason to give up on the concept of diversity just yet! However, we need to re-examine what actually constitutes this term in order to make it sustainable: Diversity is more than hiring a few "different" people, it's about empowering oneself and others to create positive change.

This talk will give back some meaning to the term diversity while illustrating why it's still important. There will be some interaction, some tangible examples and more than a few cats to help you through the more challenging parts of theories and self-reflection.
While it is highly unlike that James Damore would ever go to such a talk, it is talks like this that would have allowed Damore to understand the importance of diversity.

It is not possible to reach Damore and his irk, but there are other people out there who are not aware of the importance of diversity, who can be reached through such talks. This is why I think people talks are important, and why I hope conferences keep having them.

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.

Tearing down the walls



It is pretty widely accepted that one of the major challenges for IT projects is communications between the different parties involved.


The above figure demonstrates how a traditional IT project works, and why communication is such a big issue.

The business have some wishes, which they give to the requirement people, who turns them into requirements, which are handed over to the development team. The development team then develops the system, and hands it over to testing. When the system is tested, it is handed over to operations, which puts it into production.

Such a process is characterized by each group being walled off from each other, often in a real physical sense. It is also characterized by a lack of communications between the groups.
This means that it can take a long time to find misunderstandings, and that the requirements tend to become outdated before they reach production.

SCRUM and other Agile methods have tried to address this in different ways, but even so, communications problems still exists.

The above figure illustrates an IT project using SCRUM. Here the developers and testers form one team, and the requirements specification is handled by a PO who represents the business.

Due to the processes in SCRUM, the communication barrier between the PO and the SCRUM team is reduced, but there is still a barrier. Also, in most organizations, the barrier between the business and the PO is unfortunately as great as the barrier between business and requirements people in traditional projects.

There is also a communication barrier between the SCRUM team and operations.

The fairly recent concept of DevOps have tried to address the communication barrier between the SCRUM team and the operations people.










As the above figure illustrates, this is handled by embedding the operations people in the SCRUM team (this is obviously a simplified description).

Last November I was at a conference in Orlando, where one of the speakers were the PO for the SCRUM process, and he told us that there is a focus on adding DevOps to the SCRUM methodology.

Unfortunately, he also said that they are not going to do anything about adding requirements specification to the methodology.

This is, in my opinion, unfortunately, as it would help reduce the barrier between the business and the rest of the project, and between the PO and the SCRUM team.

So, what can be done instead, in order to remove the barrier between the business and the rest of the project?

Well, I think it will be hard to completely remove the barrier, but I think there are different ways of reducing the communication barrier.

These are, in random order:
  • Embedding a business person in the SCRUM team
  • Regular meetings
  • Techniques such as story mapping
These can obviously be combined.

Embedding a business person in the SCRUM team

This is an idea that was introduced with eXtreme Programming, though it probably existed before that as well.

It is simply getting someone from the business sitting together with the SCRUM team.

This is often hard to do, as it can be hard to get people released from their normal position in order to place them in an IT project, even if they continue to work on what they usually work with. This is partly due to the, probably reasonable, concern that the person will have much less time to do their job. But it is also often partly due to the fact that many bosses don't like not having people sitting apart from their usual team. On top of that, it might be hard for the business to see the value of embedding the business person in the SCRUM team.

If you manage to get a business person embedded with the SCRUM team, it is worth regularly evaluating whether the business person is the right person for the role, or whether there should be a rotation of the business people, in order to keep the focus fresh.

Regular meetings

A simple, but effective way of enabling communication between the business and the rest of the project, is to plan frequent meetings.

The sprint reviews in the SCRUM methodology is one type of frequent meetings, but there should be other meetings, such as requirements meetings between the PO and the business.

These meetings can be used for presenting user stories before they are taking into a sprint, in order to get the input from the business, and clarify any unclear requirements. It can also be used to prioritize the requirements, based on the current situation, and to adjust the scope of the project, based on any developments.

Techniques such as story mapping

Requirements in SCRUM projects are often written as user stories, and there are some techniques that can be used while writing these, allowing the business to get involved.

One of these methods is user story mapping.

No matter what technique is used, it is important that to ensure that the business are willing to get fully involved. If they are not committed, no technique will help reduce the communication barrier.








In conclusion, it is unlikely that it is completely possible to reduce the communication barriers completely in an IT project, but there are methodologies, concepts, and techniques that can greatly reduce them, allowing for a greater likelihood of the successful development of a system which fulfills the needs of the business.

One aspect I haven't touched on in this post, is the extra complications if the project isn't aimed at the internal business, but rather at customers outside the organization. External customers obviously adds an entirely extra complexity to communications, and is a subject for an entirely different blogpost.