New year resolutions

newyearSo it is 2012 now. A new year has started and people usually make new years resolutions for the new year. Most of the time they just drop these within a few days or weeks after the start of the new year.

I have other plans for my new year resolutions, I plan to fulfill all of them this year. Hopefully next year I will look back at this and will look at this list and can confirm that I achieved everything.

So for my new year resolutions:

  • Blog more often. I feel that my work experiences are worth sharing and that it helps me to gain insights to improve myself and just maybe it could also help other people who run into the same things as I do.
  • Delegate more. I am terrible at delegating work, even when I need to book a flight or hotel for one of my employees I do it myself. So for this year I plan to leave this to the people who got hired for it and who I should trust to do it.
  • Surround myself with people that share the same passion for work. I love my work and I am very passionate about it and I want to see that around me every day. I get goosebumps when one of my team members comes to me with something awesome they did or some great idea that they have and have that twinkle in their eyes when they explain it to me.
  • Give my first public Agile or SCRUM training this year. Last year I already gave a few extensive SCRUM trainings inside our own company to groups of 8 to 10 people. For this year my goal is to give at least one public training before the end of the year.
  • Start running again. I used to run. In the past I did about 20 – 30 kilometers a week. I at least want to start it again this year and see to which level I can get.
  • Read more. I have a big pile of work related books and magazines that I never got around to read because of the big workload at the office. This will change this year, I will make more time to clear my mind from the daily work and to gain new insights and gather more knowledge.
  • Have fun. Life and work should be about fun. I admit that working is a big part of my life, I cannot imagine myself not working. Even if I would win the lottery I would still keep working. But both in your work and outside of it fun should be an important factor.
I guess this should be enough for 2012 for now. Let’s see if I can accomplish this within a year.

It is not about the techies anymore

When the multiple disciplines in software development such as design, development and testing were working completely separated from each other the most important task of a manager was to get people that are exceptionally skilled in their specialism. As long as a person was skilled in his own area of work a lack of the so called soft skills (teamwork, communication, etc) could mostly be overcome. The project manager was responsible to provide the communication within a team and it was his or her role to make sure that information from one specialist was transferred to the other.

This resulted in a controlled environment for all people in the different disciplines. Developers only needed to communicate with other developers, designers only communicated with other designers and the management communicated the artifacts from one discipline to the other and to the customers.

Even though it was still no easy task, life of a recruiter must have been much easier back then.

The introduction of agile changed the entire playing ground. Technical skills are low on the priority list when recruiting for agile teams. Suddenly developers need to communicate to testers, documentation specialist and UX specialists and vice versa. And if that is not enough they actually need to communicate with the customer as well. Add to that the need for a team to be self organizing and multidisciplinary and we end up in a recruiters worst nightmare.

As a manager of several development teams I often need to make a decision about hiring a new team member for one of our SCRUM teams. For me the following criteria are most important in making the decision to add someone to an agile software development team, in order of importance:

My first introduction to agile

Today I was driving home after a two day Certified SCRUM Product Owner training. During this two day training I met a lot of new people, people who were unlike me, completely new to SCRUM. In the discussions and the questions that they had I recognized a lot of situations I encountered when starting with SCRUM. I heard a lot of comments like “Our organization just won’t work that way” or “It all sounds nice but won’t work in reality.”

While driving home I was thinking about how I got first introduced to SCRUM and what my first responses were.

In 2006 I was working for one of the top 3 internet development companies in The Netherlands. The company was working in a very traditional way. First concept & design would create the look and feel for the web project, then  information analysts would create the functional design. After the functional design was completed the software architect would create a technical design and after completing that, the developers would start working for several months to complete the functionality and then the test coordinator could let his team test everything. My role in this entire process was to be the information analyst who writes the functional design.

The CEO does not need training

Education is a very important part of a business that is continually changing like the magical world of software development always is.

Fortunately for all the IT professionals in  the business many companies acknowledge this and have training budgets available to make sure that we are all kept up to date with the latest technologies and procedures. In the more structured companies this is even part of the evaluation of personel.

One group of “employees” however is always overlooked when it comes to education, namely the upper management of the organization. In many cases it seems like most CEO’s, COO’s, CFO’s and other C level management seems to think “I am in charge, I know everything already”.

Even though the most important role of the management of an organization is to put the right people on the right places this does not mean that they don’t have to be up to date with the latest developments regarding their work area. Of course this does not mean that the CEO needs to attend a ruby on rails training but at least he or she should know the reasons why the company has chosen certain directions.

Besides the obvious need to know the reasons behind the core activities of a company it is also important to keep the management skills up to date. Just look at the way companies are managed nowadays compared to for example 15 to 20 years ago and you will see the need to constantly improve management skills and adapt to the changes in the business.

Unfortunately training the C level management of an organization is usually forgotten, which is a shame because you can have all the technical skills within your company that you can imagine, if nobody is able to manage it correctly it all goes to waste.

Tooling: retrospective

The development teams that I work with are either fully or party located in Lviv (Ukraine). This brings some challenges in managing these teams since all meetings require some form of video conference and information sharing. For the review, grooming, planning and daily standup meetings this was relatively easily solved with a simple form of screen sharing of our SCRUM tooling (VersionOne). However for the retrospecitve meetings we faced an interesting challenge.

I like to run retrospective meetings in an interactive way. When the team is completely located in a single location I let people put sticky notes with ideas and comments on a whiteboard and use dot voting to determine what the biggest problems are or what suggestion should be implemented first. When starting to work with a team that is partly in The Netherlands (4 team members) and partly in Lviv (5 team members) we needed some way to put this process in a software tool. VersionOne did not contain sufficient functionality for this so I had to start looking for another solutions and this proved to be a bigger challenge than I expected.

My search initially lead to no results and when the first retrospective meeting with a separated team aproached I had no clue on which tooling to use for it. Eventually I ended up on the website of twiddla (http://www.twiddla.com/). Twiddla is a web based shared whiteboard that also provides the possibility to add sticky notes to the whiteboard. In our retrospective meeting we used two computers, one in Lviv (Ukraine) and one in Wassenaar (The Netherlands) both were logged in to a shared whiteboard of twiddla.

People would add sticky notes with their comments to the whiteboard, after all notes were put on the whiteboard the team members would cluster their notes and then it was time to start voting to determine which items were most important. Unfortunately the only solution I was able to find for this is to draw marks on the sticky notes with the line tool of twiddla. All in all it worked and allowed us to perform the retrospective meeting, however I will be looking into other tools that hopefully suit our process better. Any suggestions are appreciated.

Blurred vision on Scrum

Last week I was visiting a software development company in L’viv (Ukraine) and had a business dinner with the CEO of the company. During the dinner we talked about software development processes and how they were implemented in his company. The subject turned to the way the company implemented SCRUM.

First a little background information. About 6 months ago a project manager of this company was suggesting to me that he would like to implement SCRUM in the teams that are working for my employer. Since I was already a fan of SCRUM and was thinking about implementing it in our development teams as well I agreed with the suggestion and so we decided to implement SCRUM with the project manager, who was a certified SCRUM master, as the SCRUM master. Not happy with the results after a few months I decided to evaluate and look for improvements. It turned out that SCRUM was not implemented at all. The only thing of SCRUM that was used was the daily standup. The concepts of a product backlog, planning poker, sprint review, retrospective and planning meetings were still unknown to the team members and even though we decided to work in sprints of two weeks, because of the incomplete SCRUM implementation the team members did not even know when the sprint was finished or started. I decided to step into the driver seat myself and became SCRUM master of the 3 development teams we have. After a few months we are finally seeing the advantages in the quality and completeness of the deliverables and can look back to a successful start with the SCRUM process.

Now back to the discussion I was having with the CEO of this company. I asked him why his company did not use SCRUM. He replied with the remark that they only used the parts of SCRUM that suited their company and that he did not like the fact that SCRUM as a result make the company lose control over the development process. Not understanding what he meant I asked him to explain it further. He explained that in his view there were the following flaws in SCRUM:

  • No documentation of specifications.
  • No overall planning of the entire project.
  • Functionality is prioritized by developers and not by business value.
  • No up front overview of all functionality that will be implemented because everything is cut up in 2 week periods.
  • Developers are in command of the project instead of the end customer.

I was surprised to hear this and asked him were he got this information. It turned out that his source of information regarding SCRUM were a group of developers. I gave him a short overview of the lifetime of a SCRUM project and all its concepts. We spoke about user story writing workshops, assigning business value to user stories, the concept of the product backlog, release backlog and sprint backlog and the role of the product owner in the SCRUM process.

At the end of the dinner he was intrigued about the possibilities of SCRUM and pleased to hear that it contains most, if not all aspects that, to his judgement, were needed to provide him with the control of software development projects that he is looking for. We ended the dinner with an appointment to discuss it into further detail and to see if and how it could be introduced in his company.

Now the clue to this post is that it is essential to retrieve your information from the right sources. I have no doubts that the developers that gave him the information about SCRUM had nothing but good intentions, but apparently their knowledge was limited to their own role in the process and that caused the company owner to get a one sighted blurred vision of SCRUM, not knowing what else it had to offer.