• How can scrum be applied to an organisation where they do not use develop their own software but rather develop custom solutions for their clients? – It doesn’t matter what type of software is being developed, SCRUM is a set of principles that can be applied to any type of situation, its not necessarily the easiest framework to adopt.
• How can scrum be applied to projects where projects can be as small as 1-2days of development time to projects that can take several months? - Ideally SCRUM sprints should be between 2 – 4 weeks and the team should be dedicated to that sprint, if there are multiple projects happening at the same time, the question comes down to, should we have separate teams to deal with these separate projects? perhaps a BAU or production support team dealing with BAU work and the other teams focused on project work? It is far more efficient to have a team dedicated to a sprint, complete the sprint then move onto the next piece of work.
• What tools are best used with scrum from a project management perspective, does Microsoft Team Foundation Server 2010 handle scrum better? - Yet to be answered, perhaps this will turn into a internal project for me to find out what TFS 2010 has to offer?
• What can I expect when trying to change a whole team of developers who use a combination of different software development methodologies? - Hard work, resistance to change, have to be patient and determination.   SCRUM will show transparency within the organisation, be prepared to to face challenges when education team and management about SCRUM.   Fully SCRUM teams/projects within an organisation can take up to 2 years.
• What can I expect when trying to change  an organisation who has developed their own software methodology built on years of trial and error? – From the above answer, resistance, will need buy-in from management, but most importantly that SCRUM will highlight issues that exist in the organisation and its up to the team and management to accept that there will be the need for change.

• How can scrum be applied to an organisation where they do not use develop their own software but rather develop custom solutions for their clients?
• How can scrum be applied to projects where projects can be as small as 1-2days of development time to projects that can take several months?
• What tools are best used with scrum from a project management perspective, does Microsoft Team Foundation Server 2010 handle scrum better?
• What can I expect when trying to change a whole team of developers who use a combination of different software development methodologies?
• What can I expect when trying to change  an organisation who has developed their own software methodology built on years of trial and error?

To be continued…perhaps I will know the answers in a few days time!

Abstract

“A competitive advantage comes only with superior IT.” – (Aetna Healthcare Chairman/CEO Richard Huber)

Organisations are faced with difficult challenges when strategic decisions are made to upgrade, migrate, integrate or even re-develop their information systems.   While business processes are forever changing so does the need to keep their information systems functioning to the required specifications.

“Better! Cheaper! Faster!”

During the 1990’s this was the theme for IT project management.

“To produce better and cheaper products or services and get them to market quicker requires better, cheaper, faster processes.”

In today’s information systems, the model has matured and we factor in the following themes:

• Do it right the first time
• Do only manageable portions at a time
• Do it in a reusable and adaptable manner

Agile Practices (AP) and Object Oriented Analysis and Design (OOAD) include these themes in managing the development of information systems.

In this paper we provide a solution to help IT managers execute an efficient and agile way of managing the process of upgrading/developing their information systems.

References:

Tim Brown – Guidelines for Managing Evolutionary Information Systems

User roles

User roles are the type of user who will be using the application.   Typically we write requirements based on a user, but we should brainstorm the type of users and consolidate them into different user roles.

For example, we are developing an Online Cemeteries Web Application that allows users to search where people are buried etc.

We can brainstorm the different types of users who potentially could use the web application:

• Genealogists
• Grand parents
• Family tree experts
• Younger generation

We consolidate them further

• Genealogists/Expert family history
• General Public

Finally we refine and came up with one user role as there will be no functionality to have a separate area of Genealogists in the system.

• User role: General Public

User Stories

Mike talks about the acronym INVEST

User stories should be:

• Independent
• Negotiable
• Valuable to Purchases or Users
• Estimable
  
• Small
• Testable

Typically user stories are written on cards with the front side having the story and any recorded “reminders” that summarise what developers have discussed with the client.  The back side describes all the test cases that will meet the client’s expectations about the story.   The more test cases are made before the code is written the better the developer can factor this into their code.

Here is an example from when we developed the Online Cemeteries Web Application:

Story: The general public can perform a simple search entering a first and last name which returns a list of results

Test Cases

• What happens when the general public enters no first name or last name?
• Can they enter 1 or none?

Story: The general public can perform a advanced search entering several parameters which results a list of results

Test Cases

• What happens when the general public enters no parameters?

Story: The general public can view an individual cemetery record which consists of several cemetery specific items

Story: The general public can go back and change their simple/advanced parameters to perform another search

Test Cases

• Does the system remember the general public’s input so that they can come back to the website and get the same results?

Tips – Here are some tips to building better user stories:

• If a story is too long and have too much detail, break the story down into smaller stories (keeping in mind they should run with the INVEST attributes).
• Don’t be technical! This is written from the client’s perspective!
• You can also write down non-functional stories!
• Try to not include any UI specific details as this can cause confusion later on during implementation

PART 2 will be on estimation and planning using “User Stories”.