Online Scrum Wall

This is my first blog post in a while.  I have been taking part in some really interesting Iterations recently that have pushed the boundary of what I have learned and really pushed me to learn more.  The one thing I have learned about Scrum is that you don’t stop learning about Scrum 🙂

I work as part of a team that are based in different locations.  Our Product Owner is based in Boston and our team are based in the UK.  One of the main problems that was highlighted at our retrospective was that the Product Owner could not see our Scrum Wall and therefore did not have a guage of how things were going.

We communicate with our Product Owner through webcam using Skype at the moment.  Unfortunately the webcam that we use (which is pretty high spec) cannot focus in on our Scrum Wall and therefore he cannot read the tasks.  I then set myself a task to investigate an online Scrum Wall application that would allow our PO to view the wall.

I investigated all of the different types of Scrum Wall.  Some were paid for, some were free but insecure.  I found one site that offered an online Scrum Wall here Scrum Wall.  The product is in Beta at the moment with trialists recieving a free 6 month trial after the product has been launched.

This should give me enough time to investigate whether our product owner will actually use this product and to find out how useful it is to him, without spending any money.

It is really basic and easy to use with clear graphics.  We will contunue to investigate this software and I will post back any other software that I find.

Allan

 

Tips For First Time Scrum Masters

Tips For First Time Scrum Masters

I find this part of the article interesting.

Plan the demo and demo the plan

If you happen to be the ScrumMaster of a team that is ushering in agile to the organization, your sprint plannings, standups, reviews, and retrospectives could garner interest and attention from many quarters. You may even have distinguished members of the organization sit in such activities occasionally. This is definitely good news, an indication that the organization is taking this new approach seriously. At the same time, though, it puts a little extra pressure on you to have your meetings, and especially your demo, go smoothly.

Just as actors have rehearsals before a performance, your team may need to practice before the live demo. Planning and rehearsing the demo would also help to uncover problems before they happen in front of a live audience.

Clearly, a rehearsal would be nice, but you do not want to spend much of the team’s valuable time on just this activity. They are busy executing the tasks in the backlog, right? So, spend some of your own time chalking out a plan for the demo. You have the backlog items already. Arrange them in a sequence you thing fit. Help setup a demo machine yourself, if need be. Then let the team members for each backlog item decide who will demo that feature. Since the members of a backlog item know the feature the best, they would hardly need any more time to prepare for the demo. You need to keep control on the sequence of the demo, the setup and the support. We have found a short plan that shows the list to be demonstrated and a quick meeting the day before the demo makes the review session a reasonably smooth sail. Also, keep backup plans, in case something fails at the eleventh hour (the “demo effect”).

Yesterday I was busy working alongside the Product Owner and the team evaluating the stories for next iteration, that we forgot that we had a Sprint Review.  We were ill prepared because we had not planned anything.

I have now taken steps to factor in a “Rehersal” meeting that will allow us to prepare thoroughly for the Sprint Review so that this does not happen again

Incrimental Agile QA

An Article on how QA. Incremental QA is highly desirable in Scrum. Scrum does not distinguish between development and QA as in waterfall model. It expects that the product feature you are working on is designed, developed and tested by the end of a sprint – One sprint does it all.

This article touches on the background that all Development and QA should happen within the one sprint. I can relate to some of this article. I have found that by using scrum we in QA are involved in close communication with developers on how products are progressing through the Daily Scrum and being part of the team alongside the developers rather than being a separate entity as we were before. We communicate better with the developers, find out which areas of functionality are available for test and any areas require special attention.

By working as part of the team we are also able to start our automated tests earlier. We previously used QAWizard for this but we have progressed to selenium which is more efficient and better suits our needs.

 I would say that a lot of the good points that are highlighted within the article are evident in the way that we work as a team. See how much this relates to your team.

Incrimental Agile QA

Agile Practices Are Not Just About Management

I came across this article by Mike Hadlow via Twitter.  I found that I could relate some of what was described in the article to my own company.  It is well worth a read

“Once the software gets part a certain size and age, it becomes almost un-movable and a real hindrance to the business. Often the response is to start from scratch, but this just makes things worse as the new system gradually goes the same way as the old, and in many cases never fully replaces it. Then there is the additional task of integrating the old and new systems, usually as a ‘temporary measure’”

Agile Practices are not just about management