Shu: I want to become a Scrum Master.
Ri: Why?
Shu: Because it’s easy, look at them, at their daily work: organize some meetings, make some reports and that’s it. Oh I forgot about motivation, pardon, pseudo-motivation.
Ri: Do you think that’s what a Scrum Master has to do ?
Shu: I’m not saying that this is what they should be doing, but what I have seen them doing, in the companies that I worked for.
Ri: No Shu, if you want to be a Scrum Master, you need to be a good one. Why would you want to be like that?
Shu: Because it’s easier, and because this is what most companies want, good reports. You have to have good Excel skills(or other similar tools), to present the stats of the project, and you will be the best Scrum Master for that company.
Ri: It’s not like that…
Shu: I saw Scrum Masters who encourage the team members to put working hours on tasks, which look good on reports, no matter if those hours tell the truth about the work to be done. It’s all about a nice burndown graphic.
Ri: Really?
Shu: Yes. I can give you an example, something that happened to me once: in a daily meeting the Scrum Master asked me how long it takes to finish that user story. I told him that I need 16 hours to finish. Can you imagine what the answer was?
Ri: No…
Shu: He puts 8 hours down and told me: there are 8 hours until the sprint is done, you have to manage with that.
Ri: That’s strange.
Shu: Yes, it is, but they want to send nice reports to management. But in some cases the management is surprised to see that the project fails, even if they received good reports all along. Unfortunately, this kind of situations, don’t raise a flag and, that in my opinion is sad.
Ri : I understand what you are saying, but if you see this and don’t like it, and don’t agree with it, why do you want to be like them?
Shu: Anger
Ri: Hey… You said that you don’t agree with the image that those Scrum Masters have, about their work, right?
Shu: Yes….
Ri: So….?
Shu: I know…I don’t have to act like them, and this applies no matter the position you have in the team: scrum master, developer, tester…
Ri: And…?
Shu: If I want to be a Scrum Master, I’ll have to act based on what I know a great Scrum Master should do. I don’t have to do things that I don’t agree with, only to have that position. But this would also mean that, maybe, for that company, I am not a good Scrum Master.
Ri:….<<a sigh>>…
Shu: hmm…, to be a good Scrum Master is hard as hell. So, actually, the fact that a Scrum Master is acting as they should, might be the reason why she/he might not be a good fit for the company.
Ri: When you want to solve problems, things get messy, really messy. It’s not about fluffy bunnies. I hope you’ll not be that kind of Scrum Master who in retrospectives, or in talks with their managers, does not have the gut to call things by their name, and instead be full of platitudes.
Shu: ….<<a sigh>>…
Author: Alexandra Vasile
Crystal (Clear) – Part 3
This is the third part of this series and is about the seven properties of Crystal(1)(2) applied in our context narrated by one of the team members, Alexandra Vasile, so:
“After working in the context of this project I realized that for sure the context on which I worked before, which claimed to be agile/scrum, was out of track. They reversed individuals and interactions with processes and tools.
Our work was to create a tool which helped all the other teams. We needed to move fast, to respond prompt to the unplanned things that appeared, take care not to disturb the others work.
Crystal has the following seven properties. I will come across them and discuss each related to this specific situation:
- Frequent Delivery – our work was delivered everyday in the test platform, and was tested by us and by the other teams which used that code. Every month, our code was included in the production delivery. This helped us to have a quick feedback regarding our work and in case of problems we could respond fast. At the begining of the month we did not have the whole picture of what was going to be delivered, at the detail level, we only had the direction of the changes. In a way, problems which occurred on production helped us a lot because it aid more to rafinate our decisions, priorities and daily work. Almost each time a bug appeared everything stopped and we tried to fix it. There are rare the occasions when we postpone one bug for more than a month.
- Reflective Improvement – This thought exercise did not happened because a protocol was in place. If it was a protocol, for sure, I did not felt it. Is like common sense prevailed also here. It just happened without too much hassle. We stayed and reflected on 2 occasions: when a bug appeared in production or when the monthly release was done to production. Everytime a problem occurs, we all discussed, sometimes very nervous, tried to find a solution/way to improve and not to make the same mistake again.
If I think better and try to make associations with past work, we had dailys when we took the coffee, but for sure were not those kind of dailys were reporting was done.
- Osmotic Communication – It seems this was a critical point in our physical setup. In other occasions/projects although we were collocated actually it did not matter because conversation happened almost exclusively on Skype, so strange. The fact that we stayed in the same office, with the business expert, closed to each other helped us. We communicated frequently between us, we knew what the others were doing. We didn’t need special meetings for that. We intervened when we heard a discussion between the other team members and shared our opinion/knowledge/piece of advice – we helped each other. This aids us a lot.
We had a Skype group shared with the client. We put on the Skype group, as a profile image, an italian police car and agents from DIA, for us it was a way to say “ok, no fooling around”.
- Personal Safety – We felt safe in the team. We didn’t had fear to make a mistake. Our team lead encouraged us a lot, he told us is ok if we also do make mistakes because we learn from that – who didn’t work, didn’t make mistakes. We helped each other, between us it wasn’t a competition. If someone made a mistake, nobody putted him/her on the wall, on contrary it was helped to find a solution. Another thing very important was that we trusted each other. That’s why it’s very important how the teams are build, because if you are in a team where you are not trusted this implies in a way that you don’t have trust in the other team members either. And when you don’t feel safe you will never do your best.
- Focus – The team was built specially for this project. It was a very important premise from the beginning that the persons involved will have to work full time on this subject, no part time work or partially involved. It was very important because the work needed to be done involved full concentration. We set from the beginning some premises and we all knew the final scope.
- Easy Access to Expert Users – The business expert, the one which envisioned the tool was with us. Also the members of the team knew the sub-parts of the product. When we had some unknowns we knew who were the persons to ask.
- Technical Environment with Automated Tests, Configuration Management, and Frequent Integration – Since almost most of our work involved repairing and fixing existing code we needed these changes on the test platform as soon as possible.Without knowing, the other teams by testing their product indirectly tested also our work.
Probably some will say the same things could have been done in other ways. What was nice is that we were able to see another unknown face of agile in this case was Crystal. Our scope was to move fast, to deliver quickly the work which was needed, because without this tool, which we made, they spend more than 90 days to have some things done, which now with the tool are ready in ~20 minutes.”
(1) Alistair Cockburn, “Crystal Clear Applied: The Seven Properties of Running an Agile Project”, http://www.informit.com/articles/article.aspx?p=345009
(2) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”, https://www.amazon.com/gp/aw/d/0201699478