In the past 10 month I experienced what it means – or at least can mean, as I am just one out of numerous people – to be a Scrum Master.
Agility
Before I start telling this story I should add, that I am personally very motivated to not just be a spinning wheel in a working machine, but to be part of a creative process together with other people.
This personal motivation fits very well with the agile idea, which is prominently reflected by the Manifesto for Agile Software Development. The Manifesto consists of regularities and not of rules. That is a very important differentiation to do, as rules stand for strict answers to be applied in a suited situation, while regularities need the human ratio to be applicable.
Agile Software Development thus promotes agility, as means to an end in IT projects. Agility is the adaptive potential of any living system to new environmental implications. Wiki says: “Agility is the ability to change the direction of the body in an efficient and effective manner” and thereby gives a biological example of how agility can be understood. Agility can be abstracted to a simply universal formula: See where you want to go (Transparency), evaluate the advantages of different options (Inspection), go one step in your desired direction (Adaptation), repeat.
This core concept of this triad can be found in the Japanese martial art Aikido, where a learning concept in three stages Shu, Ha and Ri is applied. To understand the philosophy of this triad helps tremendously by implementing principles (how humans decide) and practices (how humans act) of agility.
But Agilities way into software development was initially supported by some westerns who founded the first agile software development movement Extreme Programming (XP). What many people don’t know is that XP can be used as a framework, just as Scrum and Kanban. Agile practices in software development are suggested ways how humans can work as a team to create something great. It basically doesn’t matter what they are creating: the human nature is assumed (Theory Y sends its greetings) to be inspired by humanly possible challenges. Inspired to grow.
This does work with any kind of knowledge work; wherever the creational process is one of using the human ability of finding suitable solutions to given problems.
Introduction
I started in March by taking the place of a colleague who is also from my business consultancy. He moved to another project, which now had become a higher priority in our department. While his previous project lost some human resources and wasn’t deemed a priority by our company anymore, but seen as a good chance to upskill - me.
Also I was working on the IT RUN side before for 3/4 of a year and had made a good job in organizing process flows, meetings and moderating among different expectations of what is important. I found it very interesting in that job to be in contact with colleagues from India, China, Canada, the USA, Ireland and Israel. Business interests of each participant in collaboration were still bound to the specific roles people took over in the whole process of supporting our product, but each culture colored interaction and shed light on specific talents. Our colleagues from India where the most diligent and eager to do an excellent job (I often tried to take their opinion more into account, as it was obvious that these people had studied IT and worked hard every day.), from over-the-pond colleagues reflected the western understanding of professionally handling business processes, Israel seemed to me to have really smart people that quickly adapt new ways of solving problems for any given challenge, the Irish are of course the most sympathic in their way of speaking and collaborating, and also more then capable in putting up communication ways. I'm sorry but I didn't work so much with our colleagues from China to make a statement about them.
These were my previous experiences.
I didn’t know what was awaiting me, but I was packed with knowledge from my course of study around moderation and knowledge management, and with the lean and agile literature I did read as an IT consultant. Little I knew that what was understood by most people as “being agile” has little to do with agility itself. Therefor I unkowingly jumped into the consultation which had - taken all the peoples idea about "agile" into account - a very unconcrete job description. Whenever I asked what my job is, I got the same answer: “Be a Scrum Master.” And so I was.
First Milestone
Cucumber
We didn’t had automated tests in March, and I got the job as Scrum Master with the technical addition of me driving the project towards Continuous Integration (CI). So I had already learned about Ruby and UI testing.
For the UI tests we reached out for what deemed to us to be state-of-the-art testing for an agile software project. Cucumber Tests, which include a natural language format to capture business requirements. Cucumber can be very powerful as a testing framework if it is used as communicative tool for vertical information flow (from requirements to actually getting work done). It is still an as good tool for UI tests as any other, when just using the natural language as extended spec description.
After some time we had Cucumber set up.
I also had made a management presentation about Cucumber in the context of explaining the progress automated testing had made and how it slowly made manual testing obsolete. Ha. Manual testing is strong, as a lot of QA experts fear for their jobs. Thus, the power of UI testing, by using Gherkin to translate from business skies into developer basements, has yet to reach its full potential. If managers would understand how easily they can set up stories to extent their products, by simply describing the future UI and its capabilities, Cucumber would earn the credit. I personally think that the colleagues with a QA background are a perfect fit for learning about automated tests and even Scrum Mastering (as they are used to take over key roles in development processes), they simply need to adapt to these new challenges.
A well done test suite saves many developer resources. The devs are of course doing the test writing themselves in Scrum, but usually are not as empowered and mature as a team, that they could set up a holistic and easy maintenance testing framework by themselves. This is the chance for any QA person to set up personal claim to create the best testing frameworks a project has ever seen!
I am putting an emphasize on this topic as I think that excellent testing will still be the realm for QA people, they just gotta take the next step and start to act upon their responsibility by faciliating vertical communicating through installing TDD and BDD capable testing frameworks.
Continuous Integration
Our CI setup worked from there on as follows: 1) Code commit to Git 2) bamboo checking every 3 minutes for new commits 3) bamboo builds a new version of our software 4) after building the new version automated UI tests run 5) if they would fail, due to some new defect, the new version (our “latest build”) would paint the pipeline red.
We already had some ESlint (a style/code quality check) in place at that time that would be triggered, and be able to paint the pipeline red, even before the building process.
Before we put these UI tests in place we had a manual QA person in our team. She was hereby substituted and left the team to become a Scrum Master.
I did learn about (sorted from most lessons learned to fewest):
OO Ruby, Cucumber (based on the Selenium Webdriver), RedHat Linux, Bamboo, Ruby scripts
---
Thanks for reading, to be continued with the Second Milestone.
Any comments welcome. I am in general very interested in any exchange on implementation of methods and frameworks. Thus, emails etc. are very welcome.
Best Regards,
Paul
