The Agile Manifesto

The Agile Manifesto is a statement of the principles that underpin agile software development.  The Manifesto was derived by representatives of various new methodologies such as Scrum and extreme programming where they saw the need for lightweight methodologies to replace the traditionally used heavy weight ones.

The 12 principles of the Agile Manifesto are:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

I can relate to most of these manifesto rules by relating them to the way that we work today. We strive to keep the customer happy and we work together as a team to achieve this. We also look to release working software within a 2 week cycle which is also a marker for our progress. If you compare these to the way that you work using Scrum, you will see that you are following the agile manifesto.

The Product Backlog

The Product Backlog is like a a wish list of requirements.  The Backlog is like a living list that is always changing as stories are added, prioritized and deprioritized daily.  It is the Product Owners job to keep the Product Backlog Items prioritized and constantly groomed to to allow maximum efficiency.

Not only is prioritization essential but story quality is essential too.  Stories that are well defined will be prioritized towards the top of the backlog.  Stories that are cumbersome and undefined will be held at the bottom of the backlog awaiting breakdown.

If we look at the Backlog as being an ice berg.  We all know that the largest part of the ice berg is under the water and the smallest part of the ice berg is above the water.  We can compare this to our Product Backlog.  Our largest stories are at the bottom and are therefor under the water line and are unable to be worked on.  The Smaller stories are above the waterline and are able to be broken down and worked on.  Once these smaller stories are completed, more work is brought up from the list, just like an ice berg!

In general, the product backlog is the ‘What’ of the system.  They are the functional requirements, non functional requirements and issues which are prioritized in order of importance to the business and then estimated.  It is important that the Product Backlog is prioritized and kept up to date frequently by the Product Owner to reflect any changes in business priority effectively.

Allan

Daily Scrum Mistakes.

After researching techniques that would improve my Daily Scrum.  I thought I would highlight some mistakes that can occur within a Daily Scrum Meeting that you can further improve to make your Daily Scrum more appealing.

I read an article on “Scrum from the Trenches” Daily Scrum Mistakes  that echo’s some of the sentiments felt by myself.

The first mistake that people often make are to over run the allocated 15 minutes.  This can cause people to lose focus on what the Daily Scrum meeting is truly about.

The second mistake that people make, and I myself allow this to happen on occasion, is that Team members are effectively Reporting Status to the Scrum master.  Many people look at the Scrum Master whilst giving their status rather than giving a status report to the whole team.  I try to not make eye contact with the person speaking as to avoid it being a status update aimed at myself, rather than to the whole team.  The Scrum Master is part of the team and holds no managerial authority, so therefore a status update should be aimed at the whole team and not just the Scrum master in general. 

Leading back to my first point about the allocated 15 minutes. Remember the Daily Scrum is a status meeting.  It is very easy for a Daily Scrum to become a design meeting when one person is describing difficulties that they are having.  The Scrum Master has to be aware of this and limit technical and design discussions.  encourage Team Members to take their discussions “offline” and discuss the possible solutions after the Daily Scrum. 

The best possible way to conduct the Daily Scrum is to have the attendees standing up.  If the Team are sitting down, they become more formalized and meetings tend to run over.  If the Team are standing the meeting becomes more efficient due to people wanting to have the meeting done and dusted quickly so that they can sit down again! 

One problem that I had in the past with my team was that we were always being drawn into design and technical meetings in our Daily Scrum.  The Scrum Master must be firm on this.  I see myself as a nice guy, but at the beginning I was too nice for my own good.  I was worried that continually interrupting these meetings, would see me as being labeled rude.  But I soon realised that the team were labeling the meetings as laborious as they continually over ran.  So therefore I had to step in and limit the design and technical discussions until after the meeting.

we now have a designated time where we allow converse with interested parties after the Scrum meeting where Team Members can gain clarification on requirements of discuss problems with other team members.  I would say that this has improved our efficiency overall as the Daily Scrum is useful again and not laborious.

Google Tech Talk. Agile Testing

Google Tech Talks
December 9, 2005

Elisabeth Hendrickson

ABSTRACT
As more teams are adopting Agile practices such as XP and Scrum, software testing teams are being asked to become “Agile” as well. But what does that mean? Is the Agile label yet another buzzword? Or could it be Agile practices are actually changing the way software is built? In this talk Elisabeth Hendrickson shares her perspective on how test teams can be more Agile based on her experiences working as a tester on Agile teams. Along the way, she’ll provide an overview of how Agile practices differ from traditional practices and discuss what those differences mean for independent test teams. Credits: Speaker:Elisabeth Hendrickson

Prioritizing :)

I have been on holiday from the world of Scrum for the past 3 days!  It has been a welcome break from the hustle and Bustle from the Scrum Team! 🙂

Without knowing it, I basically used Scrum to plan out my holiday.  As it was the first time I have been off this year, I had a list of things that I wanted to do with my time off.  All of which wouldnt fit into 3 days.  So therefore I put all of my tasks into a list and prioritized the list like a backlog and split the top priority activities out over 3 days (Sprint Backlog)

I managed to get all of my top priority interests completed and then I managed to pull in some activities that I thought I would not get round to.

There we have it, Scrum in Practice 🙂

Handling Bugs in an Agile Context

Handling Bugs in an Agile Context

This is an interesting article that was passed to me by a friend, thanks Mel!  The article is based around the handling of Bugs in Agile Development.  This has made me think about the way that my own team handle our Bugs.  As QA and Scrum Master for my Scrum Team i am always on the look out to improve my skills in QA.  Ill be taking some of the points contained in this article into account when performing QA on our team.

An important one is  “Done means implemented, tested, integrated, explored, and ready to ship or deploy. Done doesn’t just mean coded, Done means finished, complete, ready, polished."   This doesn’t only mean that the software works, looks good and performs the way it should, the software should be fully QA’d and known bugs fixed.

How to fit QA into Scrum

 I read an interesting article that addresses some of the problems that my own team has encountered with trying to fit QA into Scrum.  We have found that on some occasions coding new functionality for our site can take up a large part of the sprint, which can have a knock on effect on the time that QA has in the sprint.

We know that this isnt exacly the scrum way of doing things as we should be testing early in the iteration and leaving the testing till late on in the iteration can seem like a waterfall practice, but sometimes needs must.

The article below explains a process that my Scrum team has carried out.  We basically move our QA’ing of the stories into a separate story and have this prioritized in the next iteration thus allowing us to complete the QA without falling behind.

How to fit QA into Scrum

This also leads onto a future article on Automated testing in Scrum 🙂

How Scrum has improved our QA

I have worked at a web based startup company for the past 3 years.  Before we implemented Scrum just  under two years ago now, the QA team, of which I was a part of was a separate unit from all other teams.  We worked with the watrerfall method of development which meant we were involved in testing our functionality late on in the project.

One problem with this was that if the project was over running, then our QA time was cut and we had to work hard to make up the time lost in development by staying late on occasion.  This seems to be a common scenario with testing in the waterfall method.  Another scenario that I found was that the team became stuck in a rut with testing.  We became stuck in a rut of testing products in linear fashion that it felt as though every cycle was like groundhog day.

When we adopted Agile Development we had 4 main areas of expertise that were split into 4 main teams.  The ratio was around 1-5 (QA-Dev / Flash) and QA is part of the Scrum development team.  The Business side is driven by the Product team and our sprints are 2 weeks long.  This was the start of something new for our QA department.  Rather than being stuck at the end of the process, we were now included from the planning stage with Scrum.

We could now see the criteria being set down by the customer in the user stories that were provided to us by the Product Owner and any prototypes that were supplied. We now had an insight as to how the product should look and feel before the planning stage.

At first the planning stage was alien to us.  We had not been involved in any planning before with the waterfall method.  We had usually been given a product spec to write our test cases against before we were given the product to Test.  By the time we got our hands on the final product most of our tests were useless and had to be reworked. Being part of the planning stage felt as though we were now part of the team, rather than something stuck onto the end of a project to make peoples lives a misery.

Taking part in the planning meetings allowed us to gain a more in depth insight into what the product being developed would be expected to do.  Listening to both development sides to our teams plans on how they were going to code the functionality and how both Flash and .net would link together gave me an insight into any problems that may occur that could cause bugs in the code.   I would then be able to ask how I could go about testing these areas and include this in my test case.  This means that we are able to write our test cases earlier with the help of the User Stories and the developers.

Being part of the team during the development means that we are able to test earlier in the process. We have our own development environment which is updated regularly with new builds of the code base.  Once these new builds have been installed we set about testing them and raising bugs.  By testing against the criteria set down in the user stories and in our test cases earlier in the process, we can then find bugs early and have them fixed earlier thus meaning that we are not rushed off of our feet come the end of the iteration or the end of the project, had we been undertaking the waterfall method.  With this in mind QA can help in the process of “defining DONE” for each Sprint which helps to keep the project on track.

Overall I have found an improvement in our working practives by implimenting Scrum.  We have become part of a team rather than a seperate entity which helps us in our goal to try and have fully functioning software that is free of bugs.  Being involved in testing earlier in the project has helped break the ground hog day effect as with the nature of Sprints, we could be testing more than one product at the same time, so this can break down the boredom factor of working on the same product for a long time.  I have certainly found that our products have been going live with less bugs than before Scrum, so identifying these bugs earlier in the project has helped us.

Allan

The Mythical Product Owner Role

I was forwarded this article by a colleague.  It basically describes the product owner role and categorises the different types of product owner.  As a Product Owner could interpret their role differently depending on their ‘Day Job’ role it means that there can be different types of Product Owner depending on their role.

Take for instance, a product owner who works as a release manager, would be different to a product owner who works as a project manager.

It is an interesting read.

Scrum The Mythical Product Owner Role