What on Earth is a ScrumMaster?

This past week I completed the Certified ScrumMaster Course (CSM). Over drinks on Friday night, I mentioned this in passing to some friends. “What the heck is a ScrumMaster?” was the overwhelming reply. It’s a weird name, I’ll admit.

Well, before I took the ScrumMaster course, I figured that the ScrumMaster was an Agile Project Manager, who made sure the team followed Agile practices, facilitated the daily scrum and schedules sprints.

However, the course revealed another side to the ScrumMaster, that of a coach and shepherd. The ScrumMaster acts as a shepherd as they shield the team from external influences and over-commitment, and empower the team to make decisions, instead of making decisions for them. The ScrumMaster is the coach that cheers on the team, ensures they follow the rules (and enforces them through peer pressure), and teaches them how to self-organize and work with the Product Owner.

The ScrumMaster is really a facilitator, rather than a manager. In fact our ScrumMaster course instructor revealed that it would be best if the ScrumMaster were not a project manager or technical person; it was better if they were not, as they would rely more on the team to make decisions. It is best if the ScrumMaster is not a team member, as there would be a tension between oiling the machine and producing product. Any employee could be a ScrumMaster, if they have the right personality for the job; the kind of person that is approachable, trusted, people-oriented, and detail-oriented. I have read several articles implying that QA people make good ScrumMasters, as they have the right mindset (perhaps we are used to taking one for the team, being jammed at the end of the waterfall for so many years). ;)

Integrating Fit with Cruise Control

Why using FIT?
Test Driven development is an Integral part of Agile processes. As part of Test Driven Development FIT is a good choice to be used as an automated test framework for acceptance testing.

Why using CruiseControl?
Usually agile processes suggest that continuous build and testing must be part of the development process. CruiseControl,in a very flexible and configurable manner,accommodates automating and scheduling the build and testing of an under development code.

As the above suggests, CC and FIT are very likely to be used in an agile project and I thought sharing some information on how CC can run FIT tests and display FIT reports can be beneficial. If you know of any better solution please let me know.


Please Note that CC provides a plug-in for displaying FITNESS test results and not FIT test results. If you are working with FITNESS and need to configure CC to show the test results for Fitness tests then see Fitness Reporting posting on gmane.comp.java.cruise-control.user newsgroup for an example.

I assume the reader of this posting already knows how to configure a project on Cruise Control. In case you do not know how to do it you can find more info on the following sites:

-Getting Started with CC document: CruiseControl Getting Started

-11 easy steps to get CC going: CruiseControl - Getting Started in 11 easy steps

Let’s assume the target project is already using FIT. Below I show you how to create an ant target for running your fit tests and also configure CC to use it:

1. Create two properties that are available to your build.xml for FIT input and output folders:

For example:

fit.storytests.dir=src/test/com/sentinel/test/fit/storytests

fit.results.dir=${build.dir}/fitReports

2. Create an ant target in your build.xml for running FIT Tests in your project:

* Add fitlibrary classpath:

<path id="fitlibrary.classpath">
<fileset dir="${libs}" includes="fitlibraryRunner.jar"/>
</path>

* Add fit test classpath:

<path id="fit.test.classpath">
<pathelement location="${build.test.classes.dir}"/>
…
<pathelement location="${build.classes.dir}"/>
<path refid="fitlibrary.classpath"/>
</path>

* Add build targets:

<target name="fit.test.prepare" depends="compile.test,fit.test.clean"
description="Prepare to do fit test"/>
<target name="fit.test.clean">
<delete dir="${fit.results.dir}"/>
</target>
<target name="test.fit" depends="fit.test.prepare" description="runs fit tests">
<echo>Please see the Fit Test Report page for more details on following

results:</echo>
<java classname="fitlibrary.runner.FolderRunner" fork="yes" failonerror="yes">
<classpath refid="fit.test.classpath"/>
<arg value="${fit.storytests.dir}"/>
<arg value="${fit.results.dir}"/>
</java>
</target>

3. To test you changes and run the fit tests run: ant test.fit

4. Create an snapshot of your project under CC and create a Project element in CC config.xml.

5. Create a file called fitLink.jsp and place it under [Cruise Control Home]\webapps\cruisecontrol directory. fileLinks.jsp provides a link to your FitReport folder under artifacts directory. Leave the ouput folder point to fitReports folder under build directory inorder to have the FIT test reorts published under CC artifacts. This is the content of fileLink.jsp:

-------------------------------
<%@ taglib uri="/WEB-INF/cruisecontrol-jsp11.tld" prefix="cruisecontrol"%>
</p><p>
<table width="98%" border="0" cellspacing="0" cellpadding="2" align="center">
<tr>
<td colspan="4" class="unittests-sectionheader">
Fit Tests:
</td>
</tr>
<tr>
<td class="unittests-data" colspan="2">
<cruisecontrol:artifactsLink>
<table width="98%" border="0" cellspacing="0" cellpadding="2" align="center">
<tr><td class="unittests-data"><a href="<%= artifacts_url %>/fitReports/reportIndex.html" target="_blank">View Fit Results</a></td></tr>
</table>
</cruisecontrol:artifactsLink>
</td>
</tr>
<tr>
<td>
<table width="98%" border="0" cellspacing="0" cellpadding="2" align="center"></table>
</td>
</tr>
<tr></tr>
<tr>
<td colspan="2"> </td>
</tr>
</table>
-------------------------------

6. Modify the buildResults.jsp file in the above directory to include fileLink.jsp. To do so include the line below at the bottom of buildresults.jsp:

<jsp:include page="./fitLink.jsp"/>

7. Inlcude the test.fit target in the build.xml file used by this project on CC.

<project name="myProject" default="build" basedir=".">
<target name="build">
<!-- Call the target that does everything -->
<ant antfile="build.xml" target="clean"/>
<ant antfile="build.xml" target="deploy-all"/>
<ant antfile="build.xml" target="test"/>
<ant antfile="build.xml" target="test.fit"/>
</target>
</project>

8. Restart your CC and open CC home page in your browser.

9. Press the build button for your new poject.

10. After the build is completed you should see a summary report of FIT test results on your project build result page in Errors\Warning section. At the bottom of the page you should also see a FIT Test section that provides a link to FIT Reports page.

Risk Assessment or thoughts in an airport

Recently I was traveling from Vancouver to New York. I could not say it was a smooth trip. At first, my taxi was late. I was about to call a dispatcher, when the driver eventually arrived. When I came to the airport, I had an hour and twenty minutes until the flight and was glad to see that the check in line to Delta Connection was not that long.

Oh boy, it was probably the slowest line I ever saw. There was only one Delta guy at the counter and he was not in a hurry. Also, something was not working properly at his stand and for each passenger he was leaving his seat and going to another counter to print baggage tags.

Thirty minutes later, he started to deal with two old ladies who were definitely planning a trip around the world based on a number of boarding passes he printed for them.

I was the next in line, and was starting to feel nervous that I may be really late for my flight. When I expressed my concerns to check-in clerk, he smiled back and said: “Don’t worry, the flight has been delayed”.

Sure, this put me at ease! I had just forty three minutes to make a connection in Salt Lake City. Without skipping a bit, instead of worrying about missing the flight from Vancouver I switched to worrying about missing the flight from Salt Lake City.

We landed in Salt Lake City about 30 minutes late. Those of us, who had connection to New York, started to run to another terminal with a slight hope that our plane was delayed. When we arrived at the gate, there was no sign of the plane.

But the plane has not left without us; it was canceled, due to a snow storm in New York.

I did not make it to New York that day. Airline rescheduled my flight to arrive in NY in the next day evening. My meetings would have been over by that time, so I decided to go back to Vancouver.

When I was sitting in airport’s restaurant waiting for my flight back home, it occured to me that I spent the entire day worrying about the wrong thing. Whatever I was considering the biggest risk in completing my journey, was not worth worrying about.

At every step I was getting more information about my environment, which changed my assessment of what prevented me from finishing the trip. At the end, bad weather in New York happened to be a higher risk, than the late taxi, slow check-in line, or short connection time.

After getting to terms with the idea that I won’t get to New York this week, my thoughts switched by a strange analogy to the way we assess risks in software development.

While nobody really likes spending too much time on assessing risks, most people including myself agree that it is good idea to keep track of a project’s risks.

A much more interesting and controversial issue is when do you need to start addressing risks? If you follow a waterfall approach, the answer is clear – address them at the beginning of the project as all important deign decisions are made at that time.

Many of us were on projects where people worried about wrong things. And not just worry, but spent time and money addressing problems that won’t be problems at the end of the project, while failing to anticipate some real future headaches - all these complex solutions for weird use cases, high performance scalable frameworks for never implemented features, risks addressed in alpha release for release 5.0 features.

This is just one of the reasons, why Agile approach saves money. It views software development as a learning experience. In Agile, you delay making a decision and acting on it up to the last possible moment, because it is guaranteed that you are going to know more about the problem in the future and be smarter then, than you are now.

I booked another trip to New York - direct flight this time :-)

SCRUM illustrated

I like Is a Waterfall silent? post from Michael Vizdos blog illustrated by Tony Clark.
Both the content and the cartoon.

We're launching a blog!

Hi! Welcome to Think Agile – A corporate blog by Luxoft development’s employees.

Here you’ll find us at Luxoft sharing our everyday experiences with Agile software development practices and technologies, and reflections on working within a distributed Agile development team.