Scrum Software on the iPhone.

Our Scrum Team recently gained a new member and I came to the stark realization that everyone in our team has an iPhone!  How awesome is that!!  (Yes, the sceptics amongst you who have not converted to the Church of Apple may scorn all you want! but we don’t care :D)

First up is Planning Poker.  Gone are the days of having to sort your Poker Cards into each individual set so that every member of the team has their own set of cards.  Only for someone to shuffle them before you use them (Yep, weve all done it).  There are a few software developers who have taken Planning poker into the future.

James Williams has created a pretty little application for the iPhone to mimic Planning Poker called Agile Poker.  The user is presented with a really easy user interface and coupled with the touch screen on the iPhone it couldn’t be easier to select your estimate.  The nice graphics and slick animation that is shown when a card is selected is pretty cool too. Available Free on iTunes here

Options ScreenCard UI

Card SelectedCard Selected

Next up us Planning Poker from Francois Baronnet.  A similar Planning Poker application but it is a little more bland graphics wise and a little cluttered.  The user interface is a little more complex too with the user having to tap twice on a card to select it.  There are 2 modes to display your chosen card.  Fast, which shows your chosen card instantly or there is the “Flashy” method, which turns the card from face down to face up.  Overall, it is a little complex but it does what it says on the tin. Available Free on iTunes here

Planning PokerWelcome ScreenCard SelectionCard Shown

Agile Poker by Hortis is a silverlight looking application that offers a good help section with some tips on carrying out Planning.  The application its self is different from any other planning application on iTunes.  It has all of the cards in a straight line that the user must scroll through.  The sensitivity of the scrolling mechanism is a little high and selecting a card can be a bit of a chore (you often skip the one you want).  The animation is pretty slick, but the way that the card is displayed really lets the rest of the app down.  It does what it says on the tin though. Available Free on iTunes here

Start Screen

Card Chooser

Help ScreenCard Selected

Planning Poker by Unboxed Consulting is a pretty good Planning Poker Application.  It has a simple layout and easy one touch card selection which triggers a simple but effective animation.  The only thing is that you need to shake the iPhone to cancel your card selection in order to continue (this is a setting that you can switch off tho).  This application also has a configurable timer that allows you to time your planning session.  It is also tailorable to suit different types of planning, from the fibonacci to Binary.  This is a very effective application. Available Free on iTunes here

Home PageCard SelectionTimerOptions

Last but not least for the Agile Planning Poker Apps is an app by Greg Paterson called Agile Planner.  The user selects an estimate from a scrollable list and then clicks hide  This then hides the estimate from view.  The user then has to click flip to show their estimate.  Its pretty basic.  But I don’t see why it couldn’t be used. Available Free on iTunes here

Main PageChosen card

I also found an app from Scrum wall that lets you control your agile project by using Scrum Wall.  I will need to look into how this works and update you all later 🙂  But it is Available on iTunes here if anyone wants to look.

Hopefully I have given you enough insight into making your planning more effective and fun at the same time.  If you don’t have an iPhone.  Go get one!

Allan

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

Tight Deadlines in Scrum

I have found the issue of producing a substantial piece of functionality with a tight deadline an issue with Scrum. I shall set the scene.  We conducted our Quarterly planning and prioritized our work for the Quarter. 

A few days before the Quarter began a new piece of functionality was dropped on us from a great height.  The deadline for this piece of functionality was 1 month away.  We knew that it would hit us soon, but not as soon as it did.  It was a high revenue earner and due to the fact that it was to be completed within one month it took precedence over all.

One problem with this new piece of functionality is that it is deemed to be greater than one months work.  Also it is .Net heavy, so the Flash developers in our team will be light.  So the Product Owner will need to promote stories for them to work on (Cross Skilling was an option, but we have some Flash work that needs completed this quarter anyway).

The second problem is that we have moved to a new 3 week sprints.  We have no idea of our average velocity as we have just made the transition to 3 week sprints.  Our average velocity for 2 week sprints was 31 Points but we have yet to find our average velocity for 3 week sprints.

The Third problem is that we have 1 full iteration and 1/3rd of an iteration to complete the stories that have been identified.  For the sake of visibility and to gauge whether we are on track or not, I have added all of the stories to the Story Wall.

I have a feeling that this has turned into a Mini Waterfall / Scrum method in some aspects of development.  As all of the stories need to be worked on and pretty much completed within this Iteration.   I have to put all of the stories on the wall as I feel that this would give us better visibility of what we have done, what we are doing next and what we have still to complete and will help us as we know exactly where we stand.  Also with all of the stories visible on the story wall, I am able to create my Burndown Chart to map if we are likely to meet our deadline or not.

We cannot really be iterative in development as we have to have the work completed in one iteration.  We have prioritized the ordering of the stories on the wall with the most important at the top of the board so we are completing the stories in a logical order but the main worry for me is the Teams Velocity.  I have always been under the impression that you should use your average velocity wisely.  If you manage to complete more story points you should adapt your velocity to map this and on the flipside if you complete less story points you should adapt your velocity to account for this for the next iteration.  We have a case where we need to complete nearly double our average velocity for 2 weeks, in a 3 week iteration to meet the hard deadline.

How do you guys feel about this.  Is this an effective way of working?