I believe great programmers can create unique software in a way it has never been done before. This is a story about me joining a team and how we came a long way from a traditional development process to an agile one. We will contemplate on the events and decisions that led from chaos to order and from strict rules to a happy workplace. A place where a complete enterprise storage solution is made with almost no bugs found in production, thanks to a team ever open to change and continuous learning.
This is a brief article, highlighting the key points of the much more detailed agile experience report available on the Agile Alliance website as part of the Agile Experience Reports Program.
In the summer of 2010, I was searching for a new workplace. I happened to end up at Syneto. I was assigned to an older project, now retired. Up until this point, my programming experience has only consisted of individual coding. More precisely, I used to make small programs for the companies at which I was a network administrator.
Before joining Syneto, both in school and at my previous jobs, I had used process management techniques like Waterfall. Starting my activity at this company on a project planned in a similar manner could only make me happy that I was in a familiar environment. Little did I know at the time what was waiting for me.
After a few months, some problems regarding the project started to become obvious. Releases of new versions were always delayed and the project's budget was going to be exhausted before its term. It was obvious that a new vision and way of thinking and working was necessary.
Between the years 2000 and 2005 the company had a chaotic development process. Plain and simple, features were implemented when and how the clients demanded. This may seem agile, but it isn't. There was no vision for the product. There was no method of prioritizing tasks. The manager simply assigned tasks on some notes to the programmers. Nobody knew what had to be done and where we were heading.
By mid-2008, our development process had become more organized. We went from chaos to Waterfall. It was another false sense of progress. Not only did it not improve the quality of the product, but with the introduction of Waterfall, the number of bugs and delay times increased. Moreover, the budget for one and a half years allowed only three releases of new versions with six months periods carefully planned using Gantt diagrams and complex documents.
A change was absolutely necessary.
Any team can be defined by the work practices it uses everyday. Finding and continuous adoption of these new techniques in order to improve the development process is one of the major challenges in agile. We at Syneto, are firmly convinced that the best way to find the right practices for the current project is to adopt these potential methods, try them for six months and evaluate their utility at the end of the trial period. If we find an unnecessary practice, we abandon it. If we find a perfect one, we continue using it. In most cases we identify only isolated parts of these practices which are useful. In these cases, we adopt the pieces as part of our process as a whole.
I can still remember that sunny spring day, when our manager during that period, Flavius, came in an hour late to work. Very unusual for him, as he was usually the first person to arrive at work.
Shortly afterward he sent Bogdan, a colleague of ours, to buy something. We were too concentrated and busy with coding, so initially we did not pay much attention. After a few minutes, Bogdan came back with A3 papers, a bunch of sticky notes and a lot of markers. For the moment things seemed interesting ... but nah! ... coding was more interesting. We all 'hid' behind our monitors and continued our coding activity.
I can't recall exactly how much time passed until Flavius interrupted us. To everyone's surprise something similar to a planning board was built on the wall. We did not realize exactly what it was all about, but Flavius continued with rigorous explanations. Our first column "Release Backlog" would contain what had to be done in the future. After that, we would work in iterations and discuss what we'd do in every iteration. These tasks would be placed in the "Sprint Backlog" column. Each one of us would choose something to do and move the sticky note to the "Development" column. When it's done, the sticky note would be moved to the "Done" column. Simple, isn't it? Not quite...
I expected that this board would have a deeper impact, to bring some order in our chaos which slowly came back over the Waterfall plans. We were still doing too much planning and too little prioritizing of our tasks.
However, another peculiar effect emerged. The board offered us a surprising and efficient new way to visualize our activity. We began to realize what and how much we had to do. We could see what people were working at, and more important we could see what had been done.
Our board was fairly simple. A Release Backlog column contained what we had to do until our next release. Sprint Backlog contained what we would do in the current week. Development consisted of the tasks we were working on, and Done was made up of the finished tasks.
We made our first step in our agile transformation. We accepted the first change, that of following our entire development process using sticky notes.
As time passed, Flavius gradually introduced to us the other aspects of scrum. After a few weeks we had our first retrospective and after that we started planning sprints, with this opportunity we learned the term sprint. It culminated with mini-retrospectives of sprints and daily stand-ups.
But not only the scrum meetings were new to us, also the way we started communicating. We learned together terms like user story, story points, technical tasks, standup meeting, definition of done, etc. Not all of these things were new to us regarding our activity, but until then they had not been well defined behind the expressions.
After the first few releases of new versions we started to feel the positive effects of retrospectives and following the activity with burn-down charts. In the following years we experimented with a lot of retrospective types from which we remarked two: good-bad-actions and the sinking ship.
Sometime in mid 2011, we began to use the board in a more advanced way. These are some of the key aspects of the new board:
Scrum was good for discipline, but we identified some problems with it. The allocation of resources was one of them, so we started studying and applying lean techniques in our development process.
We tried to take into account all the lean principles, but two of them stood out: eliminating waste - by getting rid of dead times in dependency chain between programmers with the help of pair-programming, or by encouraging activities like minor bugfixing - amplifying learning - by going to conferences, courses and encouraging experimentation through code retreats and offering a library of exhaustive programming books.
Unavoidably, after changes in knowledge and practices, a change of the board was necessary, again.
Here are the essential aspects:
At one point, we identified a problem with our physical board: it became too difficult to organize and identify tasks on backlog. So we switched to a digital board, in form of an application. This allowed us to identify and organize our task faster, but introduced an unexpected and deep problem. People would not have something always visible in their faces, on the contrary they had to make a conscious action to open a web browser and surf to the application's page. And as we all know programmers are lazy, the digital board was initially a failure.
However, a smart tv on the wall resolved the visibility problem and after the programmers got used to always having an open tab with the app opened, even the tv became useless.
Probably the most important thing we learned was that the only constant in life is change. No matter if it's about personal life, professional one, or our favorite project, the way we act and organize should be in a continuous change.
Change is determined by a lot of factors, internal or external to us, like new requirements of the market or the monotony of the workplace.
After all, it's irrelevant what determines change. We need to be ready for it. It will surely come.
by Larisa Hogaș
by Kuki Edina
