I have a long list of topics for blog posts I want to write. However there never seems to be enough time. Also, I have realized that having halfway written posts and not finishing them because of my quality mind is stopping me.
I found a really nice blog where I somehow see the whole picture as the same, and I will get back to tester troubles later. One of the posts go right to the spot on what I believe in this case. Having a person with the skillset of a tester as Scrum Master, couldnt that be a good idea?
I want to be clear that I see the scrum master role as a full time job in most cases, so the person should not be appointed any “testing tasks” in the project.
Why tester as Scrum master?
Well, test driving your sprints would result in having quality in mind from the start when composing user stories together with PO or customer. This would create better testability and better overview understanding of the system.
I see both testers and Scrum Masters as information hubs in a way that no developer would think. They need to be able to communicate in all directions, project management, management, developers, customers etc. Through the diplomacy you need as a tester, usually there is a grown confidence speaking any cultures languages and adapt to the situation which is discussed.
I know that I have many other ideas around this subject, but hey, lets see if anyone has a comment on this so far.
Last week I attended Öredev for the second time. Somehow I was thinking that I was going to blog about everything that happened there, but I soon gave up on that. I am going to say some short things on all the things I attended during the conference in this post, and then probably dig deeper into some of those thoughts in later blog posts. This was my schedule at the conference, I should say that this is not the same as I planned/thought I would attend.
Monday and Tuesday I took the Certified Scrum Master course, with Jim Coplien and Jens Östergaard as teachers. I think I already know quite alot about scrum in theory and practice, but it was good to take the course to fill in some gaps. It was really good to have some scrum projects behind me, so I could get some answers to questions I have been thinking about. Another big thing about taking the course is that now I am actually able to discuss the course and how it should be used. Jim and Jens were really great to have as teachers.
Monday I went cold sea/hot sauna bathing with some of the participants/speakers. It was really nice relaxing with dinner accompanying it. I got the chance to meet with the lovely couple Marc and Lee Lesser, talking about awareness and many other interesting things. Marc held a really good keynote as a start of the whole conference, about Accomplishing more by doing less. I think everyone attending his talk appreciated what he had to say about noise and how it keeps people from doing what really gives value when accomplished.
During tuesday evening I was at Malmö city hall for speakers dinner. We had a real goose dinner, swedish (Skåne) way.
I am really into the testing as such, but somehow I always tend to keep myself to the more softer parts of it. May it be bad or not, but I really think that the most important thing is to get the right product through good communication. Not until then you are actually able to ask if it is right. That actually WAS a bias for me when putting together the test track. During the conference I got more and more confident in that it was the right speakers, with the right sessions speaking.
The diversity of test speakers was for me obvious in one way, but not in others as I spoke to some other people about it. I really think they connected to each other in a nice way. The softer skills like communication and thinking about software and then towards the more hands-on tools for communication and agile testing project solutions and further on to the bigger projects solutions for regression testing. I am going to write about some of the sessions later hopefully. What I really wanted to make clear, is that I really see all testing sessions connect to each other.
Now I think that I am going to read up on some of all the blog posts that have been written about the conference, and then write down some thoughts myself. Somehow I think I need to sum up the connection between all the sessions.
“I have heard a little on Kanban, which somewhat could be called an evolved agile or at least something in that direction. What i now am interesting in knowing is if these ideas, that are sprung from lean very much, affect or should affect the view of testing. What I do know, is how I would like to perform testing in the agile context. So what about kanban? Does it change the agile testing even more?”
The above quote is how I started this blog post some time ago. I didnt know how to continue in a somewhat professional manner. Part of that was because I had not gotten any picture in my head about how kanban works.
Yesterday, I attended the monthly Agile Skåne meeting, and one of the topics that was brought up was kanban. Since I was not the only one that didnt have so much of knowledge in it, we got a crash course in the form of a success story. While listening, I got some kind of vision of it.
Since I have been working alot with scrum, I had to ancor this kanban thing in scrum. I will now see kanban as scrum with the shortest sprints you can have, the size of a story. Then I will take into account another thing from kanban, the value stream context, which in my perspective means having only two places on the board that are allowed to have piles of cards, that is “Wishlist” and “Value for customer”. Having only these piles, while other categories like “implemented”, “tested”, “ready for test” or “ready for deployment” are not allowed to stack cards, you will get a flow of value towards the customer without leaving stories behind as untested.
While thinking of this, I realized that one issue with agile testing that has been bothering me for some time, and still does, will be easier in kanban. Why does testing in a scrum team many times end up in the discussion on “definition of done”? This is exactly one of the bigger issues I see when testing in the agile context. With this and the value stream context of kanban in mind, I realized that the fact that you extend the number columns on the board past the “sprint demo done” will visualize the testing in a more obvious way. This has the positive effect that the agile tester does not have to advocate testing as hard as sometimes is the case within developers. In the agile context, you can always add some columns when realizing where you want done to be, but in kanban this is default, meaning that the tester does not even have to argue for getting the “To test” column on the scrum board.
By only looking at this aspect of it, and imagining a little more about the kanban context, I would say that kanban is better suited for test than agile and scrum are. But I think Ill have to get back to this later on when having more knowledge of kanban.
Ok, first of all, I hope I wont scare everyone off just because my blog will start off talking about stuff I do at work. The thing is that it is almost like a hobby actually to learn more about those things, thats why I love my job.
I am not going to explain the basics about Scrum, if you are interested you can watch this.
In January, before I started to write my thesis, I had no clue what Scrum was. I barely knew anything about Agile either. I actually think its strange that we didn’t get to know much about it in school. Well, from the first day of thesis work, my interest in these things has been growing steadily and the fact that I am working in an Agile environment really gets me going. There is not a day that I dont talk about Scrum and Agile, and I try to pick up as much as I possibly can at seminars, workshops you name it. Next week my company is having a big conference, Öredev, where there will be so much knowledge running around just for me to catch it=)
As I work for Testway, my main area is actually testing (software). This is why I have gotten interested in the testing aspects of Scrum. But since I have attended different forums in the area, I have realised that all other disciplines within software engineering also have their aspects of it. Especially for example both testing and configuration management, which could in some cases be thought of as heavy in practice. This is where I state the final question:
How is it possible to get the absolutely best out of an Agile/Scrum project, when really considering the best practices within all the areas of requirements engineering (RE), testing, configuration management (CM), architecture (software of course), project management, portfolio management etc.?