A Scrum Master’s Blog on All Things Agile

The talk by 2D Boy developer “Ron Carmel” creator of World of Goo was probably one of my most enjoyable presentations of the Agile conference, however it was probably the least focused on actual “Agile” and more on user experience testing.

The main focus on their discussion was really user experience testing. What that means is observing and reporting on the users interaction with the software, or in this case “World of Goo” video game, and how the user responds to the interaction. This is something that I think happens a lot of time after a product has already been shipped. We may beta test it, or get a few “UI specialists” to run through experience testing, but do we ever really pilot play test during the Software Development process?

The answer is usually no. We do not and probably should. The reasons I believe is that we would be able to find more than just “bugs” but "defects” in the users actual experience. The code may work fine but if the user experience is difficult, confusing, frustrating or anything other than positive we can witness these as they occur and apply those adjustments into the code during the development process and not after shipment.

Now unfortunately there is not always a way to have people off the street come and test your user experience during development, mostly for legal/security reasons. However there is probably many people in the company who could fill that role of an untrained user to help test the experience. Having someone go through and run your iterations worth of code when it is near complete(at the story level) to see if they understand or the deliverables are clear can be very valuable feedback tool.

I am very curious thou to successful user experience testing in Agile development shops that focus on web services and how they achieve great usability, any comments?

  Here is the link to the slides from Mike Longin and I’s 2009 Agile presentation on “Applying Modern Development Software techniques to UI Testing”

http://ulti-swat.wikispaces.com/file/view/Agile+2009+-+Applying+modern+software+development+techniques+to+automating+the+web+UI.pptx

I attended the Agile @ Yahoo: Experiences from the Trenches presentation this morning, and so far it has actually been one of my most enlightening and enjoyable experiences so far. The Yahoo experiences was to go through there pre-agile, agile adoption and agile maturity stages and to let people know some of the pain and success points they endured.

I am not going to focus much on the pre-agile pain points as I believe those are very similar to most waterfall environments, and have been heavily talked about it many agile sessions, books and trainings.

First I want to talk about some of the Risks that they experienced and needed to be overcome to improve the Agile transition and practice.

• External Teams outside of the Agile practice
• This can include other parts of the company in which one most rely/interact with that does not follow or believe in the agile implementations that your team my be following. This can cause delays, miscommunication and lack of productivity.
• UI Design teams need to be part of the Agile practice as UI design is critical to the iteration cycle of release.
• Team Inter-dependency.
• In large organizations many people rely on deliverables of other teams to move forward in their iterations. The communication and planning’s between these teams need to be aligned to make sure the goals are the same, or they need to be able to be built modular enough to be able to deliver independent of the other teams progress.
• Lack of Coaches
• Without coaches its hard to introduce teams to successful practices and help people learn the positive aspects of agile.
• Coaches can help communicate and begin dialogue with the non adopters to find where the fear lies in change.
• Fragmentation
• No centralized successful scrum practices. If people are not communicating what makes them successful how can anyone learn to succeed.
• Need to educate non adopters, and if not possible get rid of them. Having the team not believe in the process will always keep them from achieving true success in Agile.
• “Agile done wrong is worse then No Agile”
• Scrummerfall – bad or mix mashed agile practices are usually more damaging than the old ways
• Over reliance on Tools
• The tools used to implement agile are only as strong as the users understanding to use them.
• Don’t rely on a tool to solve your problems, rely on the people.

Now some of the things that we want to do to make Agile “Stick”

• Trust
• Trust within the organization that everyone is backing the change and the practices will allow for people to do what needs to be done without fear of failure.
• Roles
• Education on the roles in agile and how to properly work that role will contribute to the success of the people in them.
• Team “Field Trip”
• Team members need to move around to other team(preferably successful teams) and absorb different patterns and practices that are successful so they can implement them on their own.
• Internal Agile Community
• Sharing ideas is never negative. An internal community dedicated to the improvement of practices and education will give people rich experiences on how to manage Agile on a day to day basis.
• Agile Principles. Education.
• Many people don’t truly understand the principles and need to be educated and talked to about their benefits. This is a role of an Agile Coach. If you understand why we do it, you will be more inclined to do it right.

This was a highly interesting 45 minute session, and I will follow up some more once I read the white paper they submitted.

I am currently at the airport in Fort Lauderdale waiting to head to Chicago for the Agile 2009 conference in which Mike Longin and I will be giving a presentation on Applying Modern Software Development Techniques to UI Testing. You can see our outline and time here. I am very excited to be attending this conference that is specifically related to Agile practices and up and coming improvements to the practices being applied. Last year I went to the StarEast conference which focused more on testing, but as a Scrum Master I look forward to the techniques that will help me improve in team productivity, communication, distributed teams(remote employees) and apply more efficient agile testing practices.

I will be attending as many sessions as possible in many different areas. If you have any questions feel free to email me at chris@agile-tester.com.

We will be speaking this year about applying modern software development practices to UI automation. If your going to the conference be sure to check us out!

http://agile2009.agilealliance.org/node/91

As we work toward in enhancing our agile practices, we(the team) took it upon ourselves to enhance the way we handle our stand ups. However this practice may not work for all teams, but as a team of larger size who works a lot in pairs and feature sets we thought these following things would be beneficial to the team organizing there day efficiently. 

1. New & Improved Daily Stand Up Routine
1. Impediments that stand in the way of moving forward addressed first
2. Story Work
1. New or Changed Stories
1. Meeting with Product Owner, Development, QA for new stories should be identified and take place (New Stories only)
2. Identify Story that Pair Programming Team is going to work on, and how they are going to begin
3. Identify the tester who is going to be building the test with requirements
2. In Progress Story
1. Identify the Pair Programming Team
2. Identify the tester who is going to be building the test with requirements, or running the tests
3. Any Impediments related to story
3. Stories that are completed from day before.(Finished)
1. Is it ready for PO to review the story/close
1. Deployed in an Integrated/Customer Level Environment
2. All Tests Pass
4. What was accomplished outside of Stories(and does it need a story)
1. Escalations
2. Large Meetings, Discussions, etc
5. Product Owner Update
1. Change of Directions, Escalations coming our way, etc

At South Florida Code Camp right now presenting with Mike Longin on SWAT at 9:50, and Applying Modern Software Development Practices to UI Automation at 11:10. When all is done, I will give an update on how it went and will attach the power points on our presentation.

Some links to check out in the mean time.

http://sourceforge.net/projects/swat/

http://www.fitnesse.org

as well as devxero.wordpress.com.

Updates will come after 1pm.

Update:

Both presentations went extremely well(minus the demo failure for presentation #2). I have uploaded the slides here.

An Introduction to UI web testing using SWAT

Applying modern software development techniques to UI testing

Thanks for everyone who attended our two presentations. It was great to meet everyone and we look forward to future presentations.

Testing out the new shared content system of Contribute CS4, for being CS4 seems a bit bared bones, but I can see the appeal for ease of user and content updating on simple blogs or php websites.

In the Agile world, adaptation and constant change may be something your use to, but experiencing those changes in the team itself may not. Most people fear change, and not in the sense that change is negative, but it is unknown, therefore comfort zones that have been established will no longer be applicable.

One of the biggest types of changes in a Development world is Team change. As the organization discovers its strengths and weakness it than has to begin adapting the structure to best support the overall mission(deliverable) of the org.

So this affects us, mostly with team level changes, whether that be gaining new members(new to org or transfer), loosing members(experienced team members), or changing leadership(reporting structure).

Now there is most likely many other scenarios that can affect teams besides personnel changes. This also may include environment(team rooms, employees going remote), project(moved to another project, project canceled), etc.

As a Scrum Master in an agile world it is your main responsibility to maintain team communication, quality and velocity. This breaks down to being able to make sure the team communicates with each other in order to meet the second goals of maintaining a quality product and delivering that quality at the highest quantity possible. 

For Example: Team A joins Team B, and looses Employee X to Team C.

The example above is a standard team combination with maybe an overlapping resource being moved to another team, possibly two scrum masters, architects, product analysts, two specialty testers, etc. Team A and Team B most likely have reached a comfort zone if they have been existing teams, and already know there team mates work habits, and are able to adapt to them to continue productive forward progress. However now that Team A and Team B have combined, they have now returned to the “New Kid in School” mentality as they are entering an environment in which some people know each other very well and some may not know each other at all.

In Agile Development it would be accepted that the new team, will be able to spend a sprint or two in learning the team dynamic, adapting to change and transferring knowledge. This is where the Scrum Master’s ability as a team facilitator can be the most useful.

Here is a few things that a Scrum Master can try to do to facilitate a smooth transition and make a positive change to the team.

• During meetings(reviews, stand up’s, planning’s, etc) ask everyone on the team, person by person there past team experiences and the things they liked about there old team and how they would like to see that applied to the new team dynamic.
• Like above, ask everyone one thing they have seen that they would like to see different and what they suggest to improve this on the new team.
• Humor, even thou humor may be considered inappropriate in all ventures its important that you make the atmosphere a comfortable one, whether its being a bit silly or humorous, laughter is the best medicine for a tense new environment.  Remember to keep it non offensive, as jokes which can alienate people are unacceptable.
• Make sure your workspace is conductive for team work(when possible). Sitting in cubicles doesn’t facilitate a team mentality and makes it hard for people to come up to you without the feeling that they are disturbing or even possibly annoying you by interruption. Especially as a Scrum Master you want to make yourself as accessible as possible so your co-workers can come to you with any questions, concerns or anything at all.
• Have a team outing. Some people just can’t open up at work, and doing something outside of the office is a great way to have fun, and enjoy things together as a team. Pick a few ideas or suggestions and have the team vote on a few of them and pick the top choice.
• Take the team to lunch and try to get everyone to sit next to someone they don’t know, sometimes just having someone to the left of you is all you need to start up a conversation and get to know some-one.
• As a Scrum Master, make sure you spend some 1 on 1 time with all members of the team to see how they are adapting to the new team dynamic , and by having a 1 on 1 they will feel more comfortable letting you know something that has been on there mind, whether it be concern of a suggestion for improvement.

These are just a few idea’s that I have tried and there is definitely more ways out there to make change a positive experience for everyone. Remember most importantly that no matter what everyone is equal and by treating team mates with respect and kindness will be more than enough to start off on the right foot.

“Retrospective meetings are the heart of agile methodologies. Scrum teams follow this religiously at the end of each iteration. ” – Agile World

A Quick History on the Sprint Retrospective

“Retrospectives initially were not a part of Scrum at all. There was supposed to be a retrospective part during the sprint review. Over the time it evolved into two separate sections: Sprint Review focused on what and Sprint Retrospective focused on how.” – AgileSoftwareDevelopment.com

Iteration Retrospectives

“Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.” – AgileSoftwareDevelopment.com

Through personal experience with Agile and using a Retrospective as a method to “tune up” team performance and how we as a team handle outside interactions, I have found a few key things to focus on that help improve the Retrospective Experience.

1. At the beginning of the Retrospective before diving into each independent story ask about any large issues that have been impeding the team. Any issues brought up at this time are most likely the main impediments the team has, as they are the freshest in memory of have left the sourest taste in the teams mouths.  Ex. Spikes due to support, Performance, Knowledge, Project Misdirection, etc.
2. After identifying any general impediments move on to the existing impediments from previous retrospectives to make sure that you have been making progress with them, and that they have been in affect removed, or if a continuous issue, forward progress is being made. This gives visibility and helps to insure that issues aren’t being raised and falling to the wayside.
3. After the General and Existing Impediments have been dealt with it is important that we now move on to story level impediments, which usually have a strong focus on process and learning through experience. Ex. How did this story go, and now that I know what I know, what could I have done to done this more efficiently or handle the issues that arose?
4. It is critical that after you have gone through the impediments that you prioritize them and select the top impediment in which you need to remove first out of the teams way. This is important as taking on too many impediments at once will leave you ineffective at clearing them in a timely manner. So focus on what has the most value for the team, and work your way down the list. It is absolutely critical that you remove at least the top impediment from the list to guarantee forward process.