SCRUMLABS - Agile Software Delivery Using SCRUM

SCRUM & Project Management

Gerald — Sun, 11 Oct 2009 16:04:15 +0000

SCRUM is a management framework. True. Its light - very light. It asks that we deliver business value frequently, in sensible chunks. So far so good - because in doing so we are delivering in high priority order, and if we run out of time then hey - we will at least have delivered some value to the business. This is risk mitigation at its simplest. However, SCRUM by itself is insufficient. On a large project we need ways of co-ordinating activities and dependencies between projects. We need someone or ’something’ to drive the projects from a big picture level. Too many times I have heard people say or act in a way that implies management is bad - total freedom to self-organise is good - and ignore the grey lines in between. If we can capture the spirit of SCRUM - the energy that it gives, within a disciplned framework that takes into account the wider organisation then we have a framework that is useful and usable to the business. Agility and discipline - its as simple as that - and that is where solid programme and project management governance come into play.

Transylvania Java User Group

Gerald — Sat, 10 Jan 2009 20:58:15 +0000

On Tuesday 13th and 14th January I will be speakng at the Transylvania Java User group meeting. I visit Romania approximately once a month to work with a clients development team that are based there. They are a great bunch of people and one of the Java Developers has been persistent in asking me to present on the topic of Agile and SCRUM. I like persistence - its a good trait if you want to get things done - and - its amazing what a bribe of a few URSUS bears and sandwiches can also accomplish It also gives me a chance to try out my limited Romanian on a few unsuspecting particpants.

http://jugevents.org/jugevents/event/show.html?id=12638

The presentation will cover Agile and SCRUM, reasons for adoption, Value Stream Analysis, User Stories, User Story Mapping, Product Backlogs, Three Level Estimating, High Level Release Planning, Prioritisation, Agile Myths etc etc and equally as important will touch upon ’Rolling out Agile’.

Sprint Planning

Gerald — Thu, 04 Dec 2008 11:59:53 +0000

My preference is for planning with points during user story workshops, but to change to hours and days etc taking into account the capacity of the team to do the work when Sprint Planning.

Mike Cohn puts it very well.

http://blog.mountaingoatsoftware.com/?p=15

Pair Programming

Gerald — Thu, 04 Dec 2008 11:55:14 +0000

I could not write an article on pair programming better than this

http://accu.org/index.php/journals/1395

An excellent well thought out and researced article on pair programming, the upside and downside. More up than down!

And some great tips here:

http://benpryor.com/blog/2007/01/23/tips-for-pair-programming/

User Story Splitting

Gerald — Tue, 25 Nov 2008 06:35:30 +0000

User stories & Splitting of User Stories

Agile methodologies prefer ‘vertical slicing’ of desired functionality wherever possible. This means building small increments of end to end functionality that allow the developers to exercise multiple layers of the software – e.g. front end through a middle tier to the database and also allows demonstration of end to end functionality earlier in the cycle compared to some less agile methods. In effect, software is built incrementally - User Story by User Story.

A completed user story ensures the business has the opportunity of releasing functionality into production much earlier – and more regularly. This has to be the preferred method in most circumstances – compared to, say, waiting until the end of a development when all is released in one big crescendo – or not - as the case may be.

Awarding points only for stories that are 100% complete according to a Sprints definition of ‘DONE’ encourages a team to deliver complete user stories each and every Sprint. One large user story that is incomplete at the end of a Sprint receives no points on the basis that incomplete functionality has little use from a business perspective – and the potential to release some value into production has been missed.

Splitting a user story is one way of ensuring bite size chunks of functionality are built and is usually recommended in the following circumstances:

When the user story is an Epic - and therefore too large to fit within a Sprint
When part of the user story cannot be estimated, or is too difficult to estimate
When part of the user story has a higher priority than the remainder
When part of the user story is riskier than the remainder

When faced with the need to split a user story – especially when it is large - the natural tendency of individuals within the technical community like me is often to suggest carving up the development on technical lines – Architecture or Component Centric. But this is usually not the optimum way of delivering business value from a user perspective.

So what options are available to split a user story into smaller chunks that satisfy the business?

Roles – sometimes a user story is written with a single role shown – but on further investigation it appears that the user story can be split up into multiple roles and therefore multiple user stories. I have seen this on multiple occasions so it is often a quick win to identify user stories exhibiting this characteristic and to break them down according to roles.

Transactional – e.g. a user story that combines all activities together might be able to broken down on a transaction basis – e.g. Transactions to Create Customer Details, then Read Customer Details, then Amend Customer Details, then Delete Customer Details. Having written the Create transaction before you write the Read Transaction etc is not always the most desired way but often is.
Understood verses Non Understood – when the team has a tough time trying to understand one part of the User Story – but you need to see progress, then one option is to split out what you understand as one user story from the less understood element as a second user story – and to have a task associated with the less understood element to understand it! Sometimes this is called a Spike.
High value verses low value elements within the user story may be able to be split out delivering much desired business value earlier.
Architectural boundaries – often the least preferred method – but sometimes supported with the argument that building on architectural lines is the most optimum way of doing things. The question is – optimum for whom – the Architect or the Business?
And then there is this: Twenty Ways to Split Stories - http://xp123.com/xplor/xp0512/index.shtml which provides further alternatives that will help you brainstorm other alternatives.

A Day in the life of a scrum team

Gerald — Sun, 13 Jul 2008 14:58:51 +0000

Laugh…I nearly…

Lean Links

Gerald — Sun, 13 Jul 2008 08:32:28 +0000

Lean Software Engineering - an excellent blog - check out SCRUM-BAN

Tesco - Software For the Agile Business

Gerald — Sun, 13 Jul 2008 07:58:55 +0000

An interesting insight into the Software that Tesco uses to allow them to move quickly. Tesco needs scalability, robustness, and speed across multiple platforms - the web, mobile devices etc.

Daily Stand-Up Meetings

Gerald — Mon, 07 Jul 2008 19:18:58 +0000

Daily Stand-up – 10 Rules to Inspect and Adapt!

Projects get to be late one day at a time, so it seems logical to have a daily team meeting to ensure you are all on track, to find out any issues that may prevent you from hitting the dates, and to ensure that everyone is pulling in the same direction. It is therefore, arguably, the most important meeting a SCRUM team can have, and bizarrely it seems to be one of the least understood. Am I allowed to do this or that are common questions! So here is a ‘starter for 10’ for the team to inspect and adapt as they see fit!

Start as early as possible, on time without waiting for people – sets the agenda for the day.
Time-box the duration of the meeting to 15 minutes- use a time-out buzzer if needs be.
Stand-up - this encourages brevity amongst the participants and keeps them awake
Location – same place and time each day – publicised - preferably the team room.
Stand in a u-shape next to the task board to provide speaker context.
Flip a coin for asking status – heads go clockwise around the team, tails go anti-clockwise!
Only Team members and the Scrum Master are allowed to talk
Do not ask the ‘three questions’ – simply get into the routine of answering them.
Do not solve problems raised during the meeting – do them after the meeting
Note down impediments on the task board that the ScrumMaster will own and resolve

Etiquette

Firstly, the team are all adult professionals so I would expect each team member to come fully prepared to answer the three common questions which are

What have you done since the last meeting? - Team members explain if they have met their commitments from yesterday
What will you do today? - Team members commit to each other what they will achieve today
What are your impediments? -  Scrum Master writes them down for later resolution (aka ASAP)

In addition, mobile phones etc should be turned off.

Once the meeting is over, team members visit the task board and update their remaining effort on the story cards. The Scrum master collates and updated the sprint burn-down chart, and eventually the release burn-down chart. The team members then discuss any items that arose during the meeting that require further clarification and resolution. Its as simple as that!

SCRUM and Agile in India

Gerald — Sat, 05 Jul 2008 17:48:20 +0000

I visit India quite a lot and an Indian friend of mine suggested I create a ‘India Agile’ Links category. Ok then! here it is. However I will only add something if I believe it is good! If you know of any links then please let me know.

ASCI - Agile Software Community India

Yahoo India - India Agile Scrum

Agile India - Agile Software Development India