Introduction
Some weeks ago I attended a week long training session with the title “Certified scrum developer” (a.k.a LeSS in action), organized by the company Odd-e.
I regularly attend technical trainings in different fields, but I never wrote a blog post about them. Well, I wrote one with the title “How to do a proper technical training for developers”, but that post was the result of attending several trainings which I did not like.
This time the situation is different. I found this training really helpful and motivating. It had a clear effect on the way I'm thinking about agile software development, however there are still some points where I’m not absolutely convinced.
I’d like to summarize here what were the most important messages for me from this training.
And just to be honest: since the training I attended was not certified (even if its title was “Certified scrum developer”), I don’t have such a certificate, but it does not reduce the value of this training in my view.
The training
The training itself was very different from the trainings I attended before. The attendees have been split into four teams and each team had a workstation with huge monitors and computers (2-3 of such stations per team, each team had 5-6 members). Then during the week we simulated a sprint of working on a real product - an online game. We really worked day by day as teams in a large scaled scrum organization, and during these working days we had several sessions where we talked about dedicated topics. These sections were also reflecting on the situation in our sprint.
The first day was focusing on the refinement of the items. We did a nice refinement workshop, and we got a nice introduction into the methodology of specification by example and its connection to acceptance tests. We also did the sprint planning 1 where we decided on the items to be done by each team.
From the second day the teams really focused on the development. There was a CI system, which verified every new commit and notified all teams when something was broken. In this case one team take over the “fix the build” responsibility. We were doing mob-programming, so usually 3 people were sitting in front of the same computer. There was a navigator of the mob session (who had the keyboard) and others who gave the instructions. The lead of the session has been changed regularly. We started every morning with a daily stand up and we evaluated the results of the day at the end of the day.
In case of any questions we were free to ask the product owner or even the customer. We also had to sync regularly with the other teams, since we had to touch the same code and implement similar functionality.
It was really exhausting, because the training was every day between 9 and 6 and it was really intensive. After the first day I almost lost my voice from speaking too much.
Although I've been working in a LeSS team for about a year (you can find my post about my first experiences and my later experiences part 1 and part 2), but this level of team work with continuous mob-programming was still something new for me.
The main topics of the sessions were: how to work in team and in pairs, how to do proper TDD, how to write good quality code, refactoring and how to do it, how does an agile organization look like, software architecture and design in agile development etc.
None of these topics were absolutely new for me, but they showed me these topics from a totally different perspective with very good practical examples, so I learned a lot.
Finally we closed the week with sprint review and a retrospective, where surprisingly most of the planned features worked properly.
The most important messages for me
First of all I have to clarify that I’m not a religious scrum believer. I started my career in an organization where we followed the classical V-model very strictly. There I have seen some advantages and a bit more disadvantages of that way of software development. Later on I worked in multiple projects which were following some kind of scrum organization, and as I have already mentioned, I'm currently working in a LeSS organization. Here I also see several advantages of the development process, but also some disadvantages. However, I have already realized that some of the disadvantages I observed were because of the wrong adaptation of scrum. So I think learning something new about agile development methodology can only help me. And to be honest this training helped a lot. Here I would mention some important points I learnt.
Proper way of specification by example
I already heard before about the idea of specification by example, but it was nice to apply it in practice. The high level idea is to describe concrete scenarios for your software with exact input and output data and use them as specification. To cover multiple cases (even the corner cases) you can organize the input values (and the expected output) into tables.
This way you can describe your requirements in a way which is well-readable by everyone, even for non-developers.
Additionally you can easily write automated tests based on these scenarios by using some acceptance test framework.
Taking a first bite
It is always a problem to refine and estimate tasks for topics which are absolutely new and unknown for the team. If we have no idea about the topic, how can we estimate it or how can we ask the right questions regarding the task?
The idea of taking a first bite is a solution for that. It means to first take something really small and easy from the topic, work on that and solve it. In the meanwhile you are becoming more familiar with the code base, so as a next step you can take over (and refine) a bit more complicated tasks with the same code. And keep on following this strategy until you are feeling comfortable with the code and topic.
How to do very proper TDD
TDD is a very popular buzzword nowadays. Basically the idea is to implement the code and the unit tests in parallel. But just like in the case of other popular buzzwords (SCRUM etc.) it is also pretty often misunderstood or misinterpreted.
The proper way of TDD is to always implement one test case (better to say, one check for your unit test), let it fail and then make it working in the code with the possible smallest change. Once it’s done you can do some refactoring to make your code nicer.
What is pretty strange for me is that you shouldn’t write more code than really needed. You really have to behave like you are being stupid. For example if you are adding code where you know that you will have three different cases, you are not allowed to prepare your code for multiple cases as you are implementing the first one. It is absolutely against the way, how I usually work. I’m always thinking about what can be expected in the near future and implement my code to support these upcoming changes. It will still take some time to change this mindset.
The power of strong teamwork
I already realized before this training that teamwork is a really strong power. This training ensured me once again about this fact. I heard several times that pair programming is just a waste of resources, earlier I was not sure if it’s true or not, but now I’m sure that it’s not true. Simply the fact that we were doing mob programming all the time let us learn a lot and helped us to avoid making a lot of mistakes. And the flat communication channels also made it possible to detect issues in time.
However I have to mention that it is mentally really exhausting to work in such a way.
Software architecture in SCRUM/LeSS
There’s a really huge gap between the idea about software architecture in classical development models and agile models.
In case of classical development models software architecture is predefined, planned, well-documented and more or less static. Static in the sense that it should change as little as possible during the development.
In case of agile development there's usually a different practice. The architecture is not really planned, it just happens. It is just the actual state of the code and it is continuously changing. However there’s still a place to talk about the current architecture and to make architectural decisions.
The world is not always ideal
This was maybe the most important message for me.
The world is unfortunately not ideal. There are always issues which make it difficult to implement a proper scrum or to follow proper TDD. There can be thousands of reasons.
All these methods we learned about are working in an ideal world, but even if the situation is not optimal you should make the best of what is possible and try to optimize it.
Remaining open questions
There are some topics where I am still not totally convinced about scrum. Let's see those points.
How to apply scrum with less social developers
There are a lot of programmers who are not so good at communication and other social activities. For some of them that was the reason to become a programmer. But the world changed and soft skills became very important for developers. Especially in case of agile development models.
Of course these soft skills can be improved, but I think we can not expect wonder from developers who are not good at it at all.
I met a lot of developers who had very good technical knowledge, but they could not communicate with their team properly. What’s the future of these developers? How can they be integrated into Scrum teams?
Does it really make sense to avoid thinking about long term software architecture?
It is clear that software architecture is changing frequently together with the requirements. But there are several cases when upcoming functionalities can be seen in advance. Does it really make sense to use a simpler solution and implement a more complicated one some sprints later if it is already known that the complicated one will be needed soon? At this point I’m still not totally convinced.
How to make sure that our unit testing is really done properly?
The way of TDD is to write test cases and to implement related code and to keep doing it until we can not think about additional test cases. Well, but these test cases are really just up to us. How can we make sure that we really covered every corner case if our test cases are not connected to any kind of requirements? It is really easy to miss some points.
How to plan an agile project?
Well, agile projects are dynamic, flexible and open for changes.
However in case of projects the question is very often pretty simple from the customer: I need a software with this and this functionality: how long do you need to implement it and how much does it cost.
In case of classical project management both questions can be answered based on some estimations, however these estimations are not always proper.
But how to answer such questions in agiles modus?
Is pair programming always worth it?
I have already mentioned about the power of teamwork. One of the most common teamwork practices is pair programming. It really helps a lot, it makes the knowledge session much faster and it helps to improve the code quality. However there are tasks which are pretty easy, repetitive and even a bit boring and not challenging at all. I think there are such tasks in every big project. Is it really worth it to do pair programming for such tasks?
Final thoughts
I really liked the training. This was the most interactive training I have ever attended and I really appreciate it. From the content perspective it was nice to see a lot of things in practice, it helps much more than just reading about these topics.
It was really a pleasure to have hands-on experience with this way of working: strong teamwork, mob programming, TDD etc.
It was really active, so it is not possible to mention everything well-detailed in this post, but that was not my goal.
It clarified a lot of things for me, but I still did not become a religious scrum believer. I still see a lot of advantages of this working methodology, but it also has its own cons.
Latest comments (0)