Both of us have left the project – we both received offers from other employers that were too good to pass up – and it is due time to have a retrospective of our time with the Team. (The project itself will continue, with the same Team members as before but with different Scrum Masters.)
It is a fairly long time period that we have been involved with the project – about 18 months – and we would like to summarize the accomplishments, highs and lows, of this time. This (a bit unconventional) retrospective will therefore be divided into three parts:
Part 1 is a look back on all the changes that have been made in the project during the last 18 months.
Part 2 is a reflection on our own effort in the project.
Part 3 is lessons learned, and which experiences we will draw on for future projects.
Part 1 – A look back
Looking back, there is a long list of positive changes that have been introduced during our time in the project:
- Test. Two testers are now active in the team. At first, there were questions from the developers why this was necessary (a Scrum team is supposed to be cross-functional, right?), but after proving their value and finding issues that nobody else discovered over and over again, it is doubtful if the team could go back to not having dedicated testers any more. The testers have brought two very important things to the team:
- A broader knowledge of the system and its rules and how they are perceived by the users (as opposed to the Product Owner or the Developers).
- A realisation that test on a higher level than the developers usually do is necessary to ensure a good experience for the end user. While testing on that level initially was the sole responsibility of the testers, the whole team now participates in short and efficient ”test races”, where new tests as well as regression tests are performed.
- Increased quality. In a year, the Team has actively been working with removing technical debt, removing bugs and stabilizing the system. Issues that previously needed manual attention daily have decreased from being almost equivalent to a full time job for a developer to only a few minutes of work every day.
- Build server with installation packages. Installation packages were initially built by hand for a long time, which was error prone and required a lot of manual work. We struggled for a long while with TFS and its build feature, but never got it working right. When we finally decided to switch to building our own installation software (which took some time to build, granted, but was a good investment in the long run), things got easier. Switching to TeamCity was also a good move, and with the build server up and running with auto-deploy turned on, the time spent for installation related issues are next to zero.
- Monitoring software. Issues requiring manual attention from developers usually starts with an error in the production environment (typically, these are database or integration errors, with services not responding or timing out). Since we already logged those, it made sense to build software that read the logs and signals the developers if an unusual amount of errors starts occurring. This way, we can immediately counter faults that occur in the system or in the environment, and avoiding manual work related to the issues.
- Keeping the backlog structured and tidy. The Team had a huge backlog with a lot of stuff that was never going to be built. Cleaning out the backlog, and switching to a more visual tool (KanbanFlow), helped both the Team and the Product Owner to visualise and prioritise what was important.
- Backlog refinement. When we first came to the Team, the sprint planning meetings could take an entire day. An important reason was that most of the team never looked at the backlog between sprint planning meetings. Introducing backlog refinement meetings, the Team more regularly looked over the backlog together with the Product Owner, and discussed the contents well in advance of sprint planning.
- From Scrum to Kanban. The Project started off as a standard waterfall project, but later the Team turned to Scrum. Since we joined the Team, we have moved towards Kanban and never looked back.
- Improved boards. Our task board has gone through several stages of complexity, but are now in a state where it is clear and simple for all Team members to understand priorities and states.
- The Calendar. The Calendar – a simple matrix with each cell big enough to hold a post-it-note – helped the Team visualize what is going to happen over the next few weeks. Events such as holidays, releases, sprint planning meeting, demo’s – everything goes on this board. Every day in the stand-up, we have a look at it and update it, discussing which events are upcoming.
- The Event List. The Event List is a simple list with each entry containing a date and a short description of what happened on that date. Every day in the stand-up we discuss if there is anything that should be noted on this list. This list helps the Team remember what happened during the sprint, and works as great material for the sprint retrospective.
- Breakfast. Introducing a short (30 minutes) weekly team activity, helped the Team function socially. This was important, since the Team was split into two groups with different tasks and locations in different parts of the office.
- Error List / Task Force meeting. Taking place right after the breakfast meeting, this meeting was for the entire Team to sit down and go through and discuss errors and faults that had occurred during last week. Initially, everyone was invited, but this developed eventually into only having a smaller part of the team, the Task Force, to participate.
The list of all the changes the Team has made during the time is a source of joy and inspiration! The Team is, in many ways, a more harmonic team that delivers better software today than 18 months ago.
The most important factor to having this improvement, is the Teams willingness to change; the Team has tried most of the suggestions that we and members of the Team have suggested.
Part 2 – our contribution
We had very different backgrounds when we joined the project. Christoffer was a system architect recently turned towards project management, while Jeff was an Agile Coach without coding experience. Both of us had dual roles: Christoffer was also project manager for the Project, while Jeff worked as a tester.
My biggest contribution to the Team during this time has been framework and structure. Much of my time has been spent on typical project managerial tasks, dealing with project plans, documentation and meetings. I have also tried to offload other non-developer tasks onto me – making sure equipment and software licenses are ordered, arranging team activities, synchronizing installations, etc. I have always wanted the Team to know that if they need something fixed, they can come to me.
As a Scrum Master, I have forced the Team to think and motivate their decisions, by asking ”why” and ”why not” and making sure that everyone in the Team understand. Again, focus has been on structure; every Team meeting have a purpose and a goal.
As a Scrum Master, I have tried to make sure that everybody in the group gets their say, and that everybody’s opinion is respected. When presented with new ideas, I have been open minded and asked the Team what they think.
I feel my biggest contribution to the team was in the form of the toolbox I brought with me. We had a great team who was eager to improve, which was the key factor in our success, but most of them being new to Agile they lacked some of the tools that can help accelerate that process. A few simple examples of this were how to set-up a backlog refinement process, how to use boards to visually manage your process in a useful and informative way, and how to run effective and productive retrospectives.
I also feel I contributed heavily in my way of thinking, being new to a team who has worked together a long time is helpful because they get someone who challenges the way they work and think, the best way change someone’s way of thinking is to be an example to those around you. I believe I helped the team to understand that they don’t need to accept things as ”just the way it is”, to challenge their beliefs. Also, I brought with me a mentality of experimentation, rather than trying to find perfect solutions, trying things out to see what works. I also focused very heavily on bringing a ”quality focus” to a team who, while writing good code, did not have a lot of focus on the end users quality perspective.
Finally, I brought motivation with me. I believe that people are more productive when they are happy, I am a happy guy, and I tend to make those around me happy. I did small things like try to perk people up when they were down, organised team outings, found small things to brighten peoples day’s, and walked around having off topic discussions with people. Or as one workmate called it ”Jeff’s story of the day”. While these things might seem small, I think they contributed a lot. Also, I was also able to encourage more communication and team work as I was constantly setting an example of this myself.
Part 3 – where do we go from here
Looking back, I am proud of what Jeff and I and the Team accomplished. I can regret that I did not have more time to do scrum master-related tasks, but found myself stuck with management stuff. But, I do think that Jeff and I had skill sets that are complementary: me with focus on structure and rules, Jeff with focus on letting the Team decide and looking for improvements.
I think Jeff and I had very different viewpoints on what ”agile” means before this project, but I think that we have merged our differences so that I, at least, have a much better understanding of the concept.
Perhaps that is the most important lesson here: there is more than one (my) way of doing things. Do not try to enforce things; ask the right questions and good things will emerge. Let the Team decide, do not make enforce your own decisions. Dare to try something new – it might be the best thing that has happened.
I could not be more proud of the journey we made, whenever we would look back it was always striking how far we had come.
My biggest takeaway from this is a lesson I learned from Christoffer, he always took the time to give me feedback and solicit feedback on himself, even when it was difficult or uncomfortable. While we may not have always agreed, I always appreciate it, and will work to integrate this into my leadership style in the future.
I also learned that people don’t complain when things work, several time I was told a specific tool or method was ”required” (TFS vs TeamCity for example), but if that tool did not suit our needs I encouraged the team to do what they thought was necessary, and never once did that come back to bite me. Because the solutions resulted in a happy customer and Team, and people don’t generally argue with that. So, stop covering you butt, and sort the problem out!
Finally, I learned to keep being myself and leading by example, as this is the best road to change in my opinion.