A look at how BA is promoting Agile in its IT operations
The Scrum LEGO City Game is about building a nice city with Lego bricks – not a new idea till here – and doing it using as much as possible what learned during the Scrum Training. To create the sense of urgency, agile42 presents the “Product Vision” as to prove to the world that it is possible to build a LEGO city in only 20min. of working time…
This starts off with Planning poker
Google Conference: Agile Estimation with Mike Cohn
An informative article on how to hold the Daily Scrum Meeting.
The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. How do you conduct the Daily Scrum and how do you know if the Daily Scrum is achieving its purpose?
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’”
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?
If you work as part of a Scrum Team, then you would have heard these words at some point in time. I can guarantee you!
“There are too many meetings during an iteration and we cannot get enough work done”
Here is an article that tries to deal with this.
How do you try and deal with this within your own team?
A certified Scrum Master course for me was a great experience and really boosted my confidence when I returned back from the course to work with the Scrum Team. It was a different learning experience than what I was used to as it gave me a practical take on Scrum and also the knowledge needed to put my training into practice. I read the article that I have linked below that outlines what a Scrum Master should know after a CSM training course. It is very interesting and I can say that I have learned a lot, but in regards to Scrum, it is only the tip of the ice berg.
I remember reading an article by Stacia Broderick a while back on Daily Scrum Meetings. Thankfully my team are not like to one described but it did make me think about the way I conduct my Daily Scrum Meeting at the moment.
This quote in particular was interesting.
Many teams really, truly believe that the purpose of the daily standup* is to “just answer the three questions without exceeding fifteen minutes.” Maybe it’s that the questions seem so simple. They are not. There is so much underneath the surface of the three little questions. Coach your team to think about these questions and come prepared to the daily standup. In other words, think about the tasks, the accomplishments, how it may impact John’s work or Mary’s next task, and keep in mind who you are working with to complete the task. Go into the daily standup with answers to the three questions that are meaningful, insightful, and proactive.
Maybe I will task my team to come prepared to the Daily Scrum to apply more detail to the tasks, accomplishments and problems that they have and how this would effect others in the team.
I think this would also work well for us as our Product Owner is based in Boston and the team is based in Glasgow, so the more useful information that is given, the more informed the Product Owner will be.