First-time Scrum master in a cross-functional team

My name is Zlata and I have been in a scrum master position for 6 months which I do alongside my QA role. I was lucky enough to not be the first scrum master in the team, as the role is rotating. Because of this, I had learnt a lot from participating in scrum ceremonies established by my brilliant predecessors. I had been a scrum master with the development team for about 4 months and we recently restructured to have our developers and consultants merged into one single cross-functional team called ‘Operations’. Being the scrum master for the first time in an established team had provided many opportunities for learning, however, being the scrum master in the newly formed team has brought about many more interesting challenges.

This blog post contains my reflections on the challenges we are encountering in a small multi-skilled team and how we are addressing them. I hope some of the information here will be useful to a beginner scrum master or one working in a smaller organisation.

There is no handbook.

Ok, there are tons of books, papers, blog posts and memes but the truth is that processes and team dynamics never perfectly match the real life scenarios. There is no template you can exactly follow, furthermore, the one you tailor and adopt will always be changing. Oftentimes, when reading a book or an article, you realise that conceptually scrum may not tick all the boxes for your use case, however it still provides a great framework for getting things done.

There are many interpretations of scrum and agile out there and it is worth remembering that the definitions in the Scrum Guide may not perfectly fit the processes in your team and should be interpreted to match you organisation’s requirements. For example at thinkWhere we look at planned and committed work which the team estimates and limit it to two weeks, which seems reasonable iteration to deliver and review the processes. We also focus on having more face to face conversation and continuously self-improve in a constructive manner.

giphy-downsized (1)

This point is probably more relevant to the new scrum masters who are starting out, because with the amount of information out there you will see a lot of mixed discourses. I keep on reminding myself to use the proliferated theory as a guidance rather than the overall truth. It is important to stick to some of the main principles that focus on the team collaboration and being able to adapt to change rather than any particular details listed by an agile influencer. For me it was the hardest point to learn, this probably stems from the fact that you cannot actually formalise and enforce all the processes in agile, as those depend on the team and the circumstances.

Do not ask for permission, ask for forgiveness.

Sorry for the misleading heading. In my interpretation of the statement above, changing things and asking for constructive feedback is essential. The main lesson I have learnt is that challenging your own preconceived ideas and following people’s advice on the internet can be a great thing. Furthermore, getting people out of their comfort zone improves alertness and focus. Stress can be good in small doses.

Changes in everyday behaviour help keep us focused, and in scrum this can be easily implemented through changing ceremony setup, for example, the daily stand up locations can be moved, questions can be rephrased and many more. For the daily stand-up, one of the recent changes included removing the Jira board from the daily ceremony and limiting it to a weekly occurrence, as it seems to have been diverting team focus. For other ceremonies, for example, retrospectives, the format can be modified as there have been many engaging models developed and tested.

One of the first things we did as a new Operations team was to implement geographic changes. We have relocated everyone’s desk to ensure the team members are in closer proximity to each other. This may have created a deserted corner in our office but has ultimately brought people together.

For a scrum master, it is really easy to get into a certain routine of doing things, which may slow down the continuous improvement process. The potential solution for that could be temporarily delegating some of your responsibilities. You can learn a lot from how other people approach your tasks. For instance, I feel that I have been a bit lazy with the retrospective part of the meetings and it would be great to get other people to facilitate. The team may just learn about it from this blog post.

download (2).jpg

Skill distribution in Cross functional teams.

With the Operations team’s creation, there has been an increase in the range of skills, which has contributed positively towards the knowledge exchange. We have a lot to learn from each other and there are many ways to encourage internal cross-pollination of information.

Because the team is quite new, we balance various specialisation by doing capacity review during sprint planning to ensure effort and skill capacity is fully met for a story’s completion.

cross-funct

Fostering shared ownership of the issue is another approach to encourage knowledge exchange. Linking ‘3 Amigos’ to the sprint goal is one way to make sure there is more than one person who has a grasp of the project’s progress and encourage taking joint accountability. When capacity allows, we encourage paring up on tasks and capture required improvements in documentation or as technical debt tickets.

Focus.

In a small company it can be easy to lose it with the range of solutions offered and developed. Not to mention the unplanned support or high priority sales jobs that may come in. There are many approaches that can help improve focus and many of them are built within scrum.

Stick to scrum ceremonies. They are important as they provide the temporal indication on when the scrum begins and ends as well as the regulated framework for everyday communication. Ceremonies and meetings are the most effective way of formalising scrum.

testmeme

Document. Unplanned work is often unavoidable and it is important that the team capture it and make it visible on the board. If any other work is affected, then it should be flagged and, ultimately, reprioritised and removed from the sprint.

Agendas. Make sure ceremonies and meetings are time-boxed and well-coordinated. A detailed meeting agenda shared with the team keeps yourself on track as well as others. This improves flow and can be modified and perfected over time. Make sure the team is familiar with it as well. I attach meeting agendas to the confluence page for each sprint overview.

Fun.

Fun may seem distracting, however, well-coordinated fun outlined in the meeting plan helps the team to be engaged and more focused with the routine supplemented by some amusement.

queen.jpg

For example, I try to integrate two short sessions in a 2 hour meeting. The first is time-boxed to 5 minutes and is at the beginning of the sprint review meeting. The sessions vary and one can be a modified version of Candy Love, wherein I offer people skittles and ask random questions: What did you do over the weekend? What is your favourite office machine? The second short session is a modified version of 360 Degree Appreciation which follows the retrospective part of the meeting and I ask people to provide a constructive positive work feedback to the person sitting next to them.

These activities make people smile and also provide more natural transitions of the meeting’s agenda. They also provide positive reinforcement and contribute towards team building.

Retrospectives are the catalyst for actions.

Retrospective meetings are the perfect space to turn the potential rants into constructive actions that lead to resolving issues and break poor cycles. If you are a new scrum master, it is useful to review retrospective notes from previous sprints, as this will help you to acknowledge the improvements the team has been making and appreciate the ceremony more.

00e6dc1bb8767d093ec22a75237c83b4--tech-humor-jpg

It is important to use the retrospective meetings effectively: to derive executable action items and assign ownership to them. Mid sprint, when we review the scrum progress during the stand-up meeting, the team goals are also reminded and reviewed. In time, these action points can also provide an effective metric to demonstrate to the team the number of items completed within certain period of time.

Retrospectives don’t need to be boring. As mentioned earlier, it is relatively easy to alternate retrospectives’ styles, and the introduction of a new style improves focus. We do, however, tend to use online boards, so that people could write up their thoughts prior to the meeting, as this saves time and ensures that everyone is prepared. This approach may change with another team member facilitating this short session.

Oftentimes, retrospective meetings can bring up many negative points. During the meetings, it is of great value to allocate time to positive feedback, see my previous point. It is easier to focus on the negative events and to forget the achievements, therefore constructive compliments should be encouraged.

Conclusion

Being the first-time or the part-time scrum master in a multi-skilled team is both challenging and interesting. The challenges can often differ from your main specialisation, hence providing some exciting learning opportunities.

I hope that some of the points mentioned in this post will be useful to anyone working in scrum by sharing some of the challenges we are overcoming here at thinkWhere.

Automated Testing with BrowserStack & Selenium

Ensuring high quality software requires a lot of testing. Whether it’s code peer-review, unit testing, integration testing, system testing or exploratory user testing – it all has to be done! Therefore we look to automate our testing where possible. This blog post explores the automation of browser compatibility testing in BrowserStack using Selenium WebDriver.

BrowserStack is a cloud-based platform for testing applications in various Operating Systems and browsers. It is used for both Continuous Integration (CI) and cross-browser testing. Selenium WebDriver is a tool for driving browsers to replicate and automate user journeys and assert presence and functionality of page elements.

bstackWe aim to integrate automated testing into our Continuous Integration pipeline, however a number of our more established products are not yet part of this pipeline. One such product is Location Centre which is used by many local authorities where the end-user often has limited control over the choice of OS and browser. This often restricts the development to suit the majority of browsers used and their degree of modernity. Despite not being part of our CI pipeline testing our software to ensure high quality is just as important. Therefore I’ll now provide an example of how simple and straightforward it is to automate tests for Location Centre using BrowserStack.

BrowserStack offers a 100 minute trial so I recommend you also try it out! The site provides a range of multi-system environments for manual and automated testing as shown in the image below. bw_mobile_devices

BrowserStack runs the tests using Selenium WebDriver and these code examples serve as a great starting point. The tests can be scripted manually or by using Selenium IDE plugin for Firefox – the extension allows you to record the user steps with minimum coding, thus minimising hand-written code and saving you time. It provides hundreds of commands for element assertion, mouse position and many more. The tool decides by itself how to locate the element. The plugin is user-friendly and well-supported and the process of recording is quick and intuitive.

I have recorded the simple process of logging in to Location Centre, selecting the ‘Mapping’ tab and then zooming and panning the map.

selelnium_ide

Once created test cases can be exported in your language of choice – in our case it’s Python.

(File> Export Test As> Python 2  / unittest / WebDriver)

We can add the exported test case to our IDE. All we need to do now is modify the setup function to add the BrowserStack keypass and specify the browser and OS requirements.

We find it’s always worth starting the tests with the high risk browsers which is traditionally Internet Explorer which is used by the majority of Location Centre customers. Gov.UK recommends testing from IE8 and up, so we will run the test in IE8.

IE8 runs on Windows 7 and Windows XP, making it difficult to test locally. You could get IE8 from Microsoft virtual machine but BrowserStack makes it much easier. Using the BrowserStack tool we can get the capabilities and add them to the setUp function:

system_capabilities

System capabilities and the authorisation information can be input into the setup:

class WebDriver(unittest.TestCase):
    def setUp(self):
       <strong> self.verificationErrors = []
        url = 'http://USERNAME:PASSCODE@hub.browserstack.com:80/wd/hub'
        self.driver = webdriver.Remote(command_executor=url, desired_capabilities= {'browser': 'IE', 'browser_version': '8.0', 'os': 'Windows', 'os_version': '7', 'resolution': '1024x768'})</strong>

    def test_leics_l_c(self):
        driver = self.driver
        driver.get("https://lctrial.locationcentre.co.uk/")
        driver.find_element_by_id("ContentPlaceHolder1_loginControl_Password").clear()
        driver.find_element_by_id("ContentPlaceHolder1_loginControl_Password").send_keys("password")
        driver.find_element_by_id("ContentPlaceHolder1_loginControl_UserName").clear()
        driver.find_element_by_id("ContentPlaceHolder1_loginControl_UserName").send_keys("username")
        driver.find_element_by_id("ContentPlaceHolder1_loginControl_LoginButton").click()
        driver.find_element_by_id("Header1_lnkMap").click()
        driver.find_element_by_id("map-size-toggle").click()
        driver.find_element_by_id("map-size-toggle").click()
        driver.find_element_by_id("OpenLayers.Control.PanZoomBar_17_zoomin_innerImage").click()
        driver.find_element_by_id("OpenLayers.Control.PanZoomBar_17_zoomin_innerImage").click()
        driver.find_element_by_xpath("//div[@id='toolsPanel']/divg").click()

    def is_element_present(self, how, what):
        try:
            self.driver.find_element(by=how, value=what)
        except NoSuchElementException as e:
            return False
        return True

    def is_alert_present(self):
        try:
            self.driver.switch_to_alert()
        except NoAlertPresentException as e:
            return False
        return True

    def close_alert_and_get_its_text(self):
        try:
            alert = self.driver.switch_to_alert()
            alert_text = alert.text
            if self.accept_next_alert:
                alert.accept()
            else:
                alert.dismiss()
            return alert_text
        finally:
            self.accept_next_alert = True

    def tearDown(self):
        self.driver.quit()
        self.assertEqual([], self.verificationErrors)

    if __name__ == "__main__":
        unittest.main()

You can now run the automated test with BrowserStack as shown in the GIF below.

ice_video_20170105-102548

The test can be played back and each step can be reviewed in turn. BrowserStack will provide you with a screenshot for any failed step (I have broken the one below on purpose!).

bs_failed_test

This service offers many useful features including localhost testing, ability to upload files and many more. There is no or very little coding required – although you may want to change an elements location or add some custom assertions, cursor movements or text inputs etc. Furthermore, there are no (or not as many) compatibility issues between the Selenium methods and the webdrivers which one experiences when testing locally.

You can utilise the vast Selenium library for replicating user journeys in the required system at the desired speed. BrowserStack also has integrated Cucumber and Behave used in Behaviour Driven Development (BDD) and testing. However, at the time of the writing this post, there were issues running those on Windows platforms. Overall, it is a great framework for compatibility testing.

Alongside the automation, exploratory tests still need to be in place to avoid kaleidoscopic bugs like this one found in our product mapTrunk…good job we caught this before Go-Live!

openlayers_bug-1