User story: It’s alive…. It’s alive!

In agile development methodologies user stories are a common way of capturing requirements that need to be implemented by the development teams.

In my opinion user stories are a very good way to describe functionality from a user perspective, there is however one big pitfall that people always fall into with open eyes (time after time).

The biggest mistake you can make with a user story is to see it as as static description of functionality, basically a small part of a design. This is definitely not how user stories were intended. A user story is an element on the product backlog that evolves over time. It’s alive… It’s alive…

User stories are often referred to as Card Conversation Confirmation (Jeffries 2001).

  • Card; The basics of a user story should be small enough to be written on a card or sticky note. Within one sentence you should be able to describe the functionality that is requested.
  • Conversation; The most important role of a user story is to trigger conversation. A user story is not complete, it represents a customers’ requirements but it does not document them. Team members, product owners and stakeholders should always keep that in mind. The story is there to get people talking, not to provide a “design” (damn I said the D word).
  • Confirmation; Even though conversation is the most important factor of a user story,  it does not mean that the results of the conversation should not be stored in any way. The outcome of discussions related to a user story should be added as acceptance criteria, development notes, attachments, etc to the user story.

Ok this is all very interesting but you are probably thinking “I can find this in any wikipedia article or agile related book, but how does this actually work”. And you are absolutely right about this so let’s look at an example of how a user story progresses through an agile development process.

When the wheels come down… When the wheels touch ground…

landinggearI spend a lot of time being in L’viv with our employees that are working from there. While I am there I spend quite some time in inspiring environments.

Even though their office space is not the best of all places it is still quite an inspiring place. Everywhere you see people working together, there is music playing in the kitchen, there is a fish tank, a wall of fame (or shame depending on how you look at it), there are people playing foosball together and you can see that people have spent attention to their working place since most of them have some personal things on their work place such as pictures, etc. Basically it is a lively place where you see good things happening regarding human interaction combined with work.

Next to the working environment and the people that are working there I also experience the hotel, in which I am usually staying while I am in L’viv, as a comfortable place which brings out the best in me. Usually the best ideas that I have surfaced while I was enjoying a relaxing evening in this hotel after a though working day.

And last but not least the face to face work related conversations with the employees and also the CEO of this company always motivate me to find even better ways to manage these teams and get even more out of them.

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.

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 ( 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.