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

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.

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!

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

ASCI - Agile Software Community India

Yahoo India  - India Agile Scrum

Agile India - Agile Software Development India

www.DSDM.ORG - Official site for DSDM and DSDM Atern

www.Rational.com - Official Site doe RUP Iterative Process

www.agilealliance.com - The Agile alliance Official Site

People:

www.craiglarman.com - Author of Agile & Iterative Development

www.alistair.cockburn.us - Inventor of ‘Crystal’ methodology and author of several books

www.Jimhighsmith.com - Inventor of Adaptive Software Development Method

www.martinfowler.com - In early with the XP method

www.gilb.com - Tom Gilb’s website - EVO method

www.agilemodeling.com - Scott Amblers Website

http://www.jamesshore.com/Blog/ - James Shore Blog

• ‘We’ll do it in the next release’ – that never comes.
• The project got delivered – along with a maintenance team.
• We did it for good business reasons.
• “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
• “To get anything released to production is a nightmare - we have to regression test the whole system”.

The third argument is especially common when you are a young company and you have very little to lose by getting stuff into production - so you just go for it. But when you have thousands of customers the stakes are then much higher. It is no surprise that you hit a brick wall and end up in release hell.

An excellent article on Technical Debt by Kane Mar :

And another excellent article by Steve McConnell:

…

One approach to reducing technical debt is to have a technical debt sprint at the end of several business focused sprints. The argument that is put forward to the product owner who has responsibility for prioritizing each release is that reducing technical debt will increase your velocity on subsequent sprints more than the cost of refactoring during a TD Sprint.

The presentation hints at what it did, what it could do better and so on. The company is called Salesforce.Com. If there is one presentation deck that you should watch with regard to implementing SCRUM then this is the one.

| View | Upload your own