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?

What You Should Know After A CSM Course

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.

What you should know after CSM Training

Daily Scrum Withdrawal

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.

Daily Standup Withdrawal

Retrospective Technique: Playtime

Title:  ‘Play’ with iteration products to remember what happened during the whole project

Use:

1) What kind of retro is it best suited for?

    Milestone, End of Project

2) What phase of the retro would you use it in?

    readying, present, future

3) Purpose

    If the software product has been developed iteratively, then each

    iteration (or release) is supposed to have at least partially working

    version of a product. During the readying of the retrospective it is

    good to consider, if these products could be used during the actual

    retrospective workshop.

Length of Time:

    5-15 minutes to allow brief playing or usage of each iteration’s software product(s).

Short Description:

    Playing or using each iteration’s product briefly before other retrospective exercise such as building part of a timeline makes it easier for participants to remember their significant tasks and other issues of a certain project phase than it would be without these artefacts.

Materials:

    At least one computer (and possibly a video projector, if the group has more than 3 people), and each “iteration release” of the product.

Process:

    Especially in the case of reviewing longer periods of time (more than 6 months) it may be necessary to bring along some of the iteration products to get the discussions “flowing” naturally. If the various releases of the products can be used briefly and the retrospective’s time limit allows “playing with iteration  products” before more detailed discussion about the team’s learning related to certain period of time, then use those.

Variations:

    Instead of working software some other concrete artefact such as iterations evolving paper prototypes, ER-diagrams etc. could be used, if the project has more systems design and development than only software development.

Resources: None.

Source: Mauri Myllyaho

I find this techique interesting as sometimes I feel that the Team can often forget some contributons that were to the iteration.  Playing with the product can often bring out these small reas and any conflict, improvements and impediments that may have occured during the sprint but were forgotten about at the retrospective.

Scrum at CNN

I found an article that documents the development change at News Network CNN from the waterfall method to Scrum.

The article documents the reasons on changing from Waterfall to Scrum, the challenges, the benefits and the outcomes.

Its surprising to me that CNN would use Scrum as I never really thought that they would have much development needs, but I suppose in the world of news where nothing stays still, Scrum would be suited as the possibility of having working software in a short space of time far outweigh the Waterfall method of having working software after a long wait.

Available for Download from the Scrum Alliance site.  Scrum at CNN

The Accidental Scrum.

I was flicking through the Scrum Alliance site when I found an article entitled “The Accidental Scrum”.  It was written by Royal Navy Logistics officer who was posted to a Ship that had to leave port sooner than expected.  He had to have the ship ready to leave port in 5 days time when origionally he had been given a few weeks to prepare.

He describes the common sense approach that he took to prepare the ship for deployment.  Coming from A software development background before being deployed to the Royal Navy, he knew nothing of Scrum and how it works.  It was not until later that he would find that the method he took to get his ship ready was infact Scrum.  He describes Scrum as a common sense approach, which when you think about it, scrum really is all about common sense.  He describes in basic terms how he tackled getting the ship ready for deployment in a short time using Scrum.

“Without knowing Scrum at all, I had set a sprint goal (“We have to be shippable, quite literally, in five days.”), developed the product & sprint backlogs (our deployment requirements and daily priorities), and established a daily scrum. I knew intuitively at the time that we had to come together at least daily to monitor progress and that any issues affecting the sprint goal had to be resolved by me, so that the team could be left to deliver. Now I understand that what I was doing was setting up daily scrums and acting as ScrumMaster for the team.”

This is an interesting article for me, as up until recently I have only been focusing on Scrum in a Software Development sense.  I think that when you look at Scrum as a bigger picture you begin to understand it more.

The Accidental Scrum

Terminating a Sprint

I have been researching the theory of terminating a Sprint. I have never encountered an occasion where I have had to terminate a Sprint, but I thought it was always good to research why Sprints would be terminated, and how the Team would deal with a Sprint Termination.

The Product Owner is the only member of the Team who can terminate a Sprint. Sprints can be cancelled before the allotted Sprint end date but it is often looked at as a worst case scenario. Sprints may be cancelled because of changes in business, competition or if the technology needed to carry out the work is not available. more often than not, the Sprint Scope is evaluated and adapted to meet the change encountered, rather than Terminating the Sprint.

If a Sprint is terminated before the sprint end date, the team must start the Process of starting a new iteration again. They must hold a new sprint planning meeting where the reason for terminating the Sprint is reviewed by the team and any outcomes from this meeting documented.

 The team will then start a new iteration as normal.

Retorspective Technique. Weather report

I have conducted a few retrospectives using the weather report as a sort of break in method to try and help the group engage with one another more and find out their mood.

I printed off some cards with some symbols printed on them to represent some weather patterns.  Sun, Sun / Cloud, Thunder and Rain. 

I then explained that these represented their mood for the past iteration. 

Sun = Brilliant

Sun / Cloud = Good

Rain = Bad

Thunder = Terrible

I then set out a Grid and split it into each of the sections above.  I then asked each Team Member to pick a card that represented their feelings about the last iteration.  This gave me a quick check of how the last iteration went.

You could practice this method often and keep a record of each Iteration and you could chart when the Team are happy or Sad 🙂

Here is the Technique explained.

 1)  What kind of retro is it best suited for? 

I use it in iteration retros but could use it all kinds of retros

2)  What phase of retro would you use it in? 

I use it in history, but could also use in readying.  I used it also as a short reflection on the retrospective itself.

3)  Use: 

Best suited for iteration retrospective for getting a sense of the mood the team is in.  I find it important to repeat this exercise on a regular basis, e.g. in every iteration retrospective.

Length of Time: 

For only getting a sense of the mood:  a couple of minutes, if you want to use it in the readying you might use this as a start for a discussion or other exercises.

Short Description: 

Every participant answers the question:  How was this past iteration for you?  The possible answers are: great (pure sunshine), good (sun half covered by a cloud), bad (rainy), miserable (thunder and lightning). The participants answer by placing a sticker in the area of their feeling.

Materials:  flipchart, marker, stickers

Process: 

We capture the weather report every iteration and develop a team satisfaction thermometer from it.  At first it gives you a sense of where the team is currently.

Variations: 

You can use the weather report also as an opener for the history part.

Resources: 

none.

Source:        

Jutta Eckstein