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?

Dealing With The Problem Of Too Many Meetings

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.

Get Serious about your meetings

How do you try and deal with this within your own team?

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

Prioritizing the Product backlog.

An interesting article on Prioritizing the product backlog with a few exercises on how to prioritize.

Prioritizing the Scrum Backlog

I found this technique most useful 🙂 The advanced technique to tackle less reasonable Product Owner who tends to say “everything is important”. Give them one “1”, a limited number of “2”, and as many “3” as they want.

Retrospective Technique: Playtime

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


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.


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


    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.


    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.