Daily Stand-Up Meetings

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!

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!

SCRUM and Agile in India

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

Emergent Architecture - yes or no?

I have worked on some massive Programmes of work over the years. In one case the Architecture team for the programme must have been about 15 people, and the development community hit about 400 people. We waited for requirements, those requirements changed, we re-architected etc. The waste must have been huge. The cost certainly was. One ‘wag’ said ‘never in the history of IT has so much been produced by so many for so high a cost,only to have been re-worked’. What he forgot to say was that the supplier was on a time and materials basis and was winning all the way to the bank! We collectively dug a hole, and we got out of it by using techniques that are commonly called RAD - one of the roots of SCRUM (IMHO). The project went on to be a major success but it could have been so much easier. Lesson learned.

One argument in favor of emerging architecture employs industry statistics that show 35% of requirements change during the project - along with the other fact that over 50% of them are rarely or never used. You only have to open up Microsoft Office to figure out that statistic is probably true some of the time. So - if requirements change so much - why bother doing all that hard architecture work up-front! Be careful! the statistic being banded about seems to refer to large projects i.e 100K function points and above!

I have also worked with people who seem to be in a ‘features war’ with competitors, and are afraid that if we do not have this bell or that whistle that the customers will leave. Ask them to quantify it and you will be amused at some of the answers. So even more ‘evidence’ in favour of the argument. I have certainly seen projects that are a ‘must’, only to have been proved to be a ‘maybe’ in which case virtually all the requirements were a waste of time. Hmmm ..business case anybody?

The flaw in the argument is that these statistics are an average (for large projects), and your project may well be different e.g. a straight code conversion project would have a simple requirement - e.g. ’same functionality, in C++ and 10 times faster’ - and hardly a user in sight - since it is pretty much a non-functional requirement - even if it emanates from a department that might want something to be faster for good business reasons (faster = can process more with less = cheaper etc).

SCRUM - or at least Ken Schwaber is a proponent of emergent Architecture and Design. Even though SCRUM does not propose engineering practices this proposal does smell like an engineering practice to me

build at least one piece of business functionality every Sprint
build enough of the Architecture and Design to support that business functionality
build adequate architecture and design to meet the non-functional requirements

Then, every subsequent Sprint, more and more of the Architecture and design emerge, in response to more and more business functionality. A friend of mine refers to this as ‘make it up as you go along’ haha. However its not meant to be that, but it is certainly a hard sell - especially to architects (I used to be one so maybe I am schizophrenic on this!).

The purpose is to build sufficient architecture and design in response to actual, high priority business needs, to prove the business need can be satisfied by the Architecture. If the architecture team state that is not Optimal then I refer to Steve McConnell on this ‘Optimal for who? - the business or you?’.

However, if you do use this approach you need to be very careful indeed. The aim should be to ensure each Sprint ends with code that is clean, commented and refactored. If you do not do this then you are into delivering more technical debt which will become a burden over time. Spaghettii Architecture anyone?

Some methodologies e.g. DSDM propose prototyping prior to getting down and dirty with a full team. There are a lot of advantages to the prototype approach - you get to figure out what you want before you commit too much resource and then you build it - ’safe’ in the knowledge that you have ironed out most of the issues early on in the process. I must admit to preferring this approach. Then I get clobbered with - ‘A SCRUM sprint is like a prototype but with ’shippable code quality’ at the end of it’.Heres a link to Sutherlands Blog which also discusses this:

Scott Ambler has written an interesting Blog item on ‘Agile Architecture’ and the approach. I believe it is a more ‘workable’ and considered approach to Agile Architecture than the more XP type views.

In the book by Stephens and Rosenberg ‘Extreme Programming Re-factored: The case against XP’ there is a whole chapter devoted to the debate around Emergent Architecture and Design. They address the fear of Big Design Up Front (BDUF) head on and state that the customer can get to see visible progress early on and easily:

1. Break the design into iterations, produce a high level design (architecture) that can then be divided into sub-systems, each of which is then designed in more detail. The Subsystem may be designed and implemented concurrently, or sequentially in separate iterations.
2. Showing the customer the early prototype. Remember the ‘prototype’ may be many disparate pieces of code, each intended to explore a different area of the design.

The authors argue that Emergent Design is useful when used in moderation and under the correct circumstances. They also argue however that XP appears to be stuck in the initial “on the face of it” reaction to design - almost echoing my friends comments of ‘make it up as you go along’ or - “jump in and repent at your leisure”. The authors also argue that it is possible to get a design close too correct - i.e fairly stable - if you use the right approach recognizing that it will then emerge. For what its worth, I tend to agree and have been in the fortunate position of having done it. I think the argument for Emergent Architecture could win fans if it simply was not so extreme!

Work Environments & Productivity

Google is the number one place to work in the USA. One million applications chasing 4000 jobs each year. Free food served in ‘gourmet’ canteens, and a belief that ‘hierarchy is bad’ etc have attracted many of the brightest and the best. It has a killer application that makes a mint. Is Google successful because of the organisational culture alone? I doubt it. But they are making a mint and good luck to them! Whets my appetite! Oh and by the way, the Google Ads guys which is the big money  making arm of Google - they use SCRUM.

 

What is SCRUM

This is a great sell for SCRUM - I love it! Only thing is the first guy reminds me of the main character in the American Version of the office - so it came across as a Spoof…hehe

SCRUM Links

Here is a list of Useful links relating to SCRUM. I will update frequently – if you have suggestions then please feel free to drop me a line for inclusion. Well spotted - it is my own version of DMOZ but for me

Scrum (Development) – Wikipedia Site on SCRUM

Scrum Alliance, Inc. – links to courses, resources, individuals and organizations

Advanced Development Methods, Inc. – Where Ken Schwaber hangs out

The Scrum Development Process – where Mike Cohn hangs out

Scrum Log Jeff Sutherland – where Jeff Sutherland hangs out

Inventing and Reinventing Scrum in Five Companies – Jeff Sutherlands experiences with 5 companies

CodeBetter.com: Scrum – Contains some useful summaries and links to some interesting articles.

Implementing Scrum - reviews Scrum using comic strips and commentaries.

Scrum Development on a Page - Links to one page overview diagram, Scrum Development Process.

Yahoo Groups: Scrum Development Users - Active discussion forum  

High Moon Studios  - Article on how game developer won award for HR programs etc

Before Implementing Scrum, Consider This - Article on Implementing SCRUM

RUP in the Dialogue with Scrum – SCRUM and RUP together

Agile Project Management with Scrum - Method for small, multidisciplinary teams working

Managers Manage - Scrum and Extreme Project Management use close quarters

Wicked Problems - By Mary Poppendieck.

Agile Tools - Tom Perry

Scrum Failures - Blog Mark Levinson

 

Certified Scrum Master Day 2

Well day 2 of the Certified Scrum Master course is now completed and I am sat here in the Oslo executive Lounge and very nice it is indeed although the view is naff. Scandinavian chic at its best within the lounge. I was lucky enough to share a taxi to the airport with  a nice Lady from the North of Norway - just above the arctic circle whose English can only be described as superb.   The total price for the taxi was a ‘cheap’ £65 split two ways. I am told that it can often be £110 for a one way trip depending on Taxi Service. Access to Wi-Fi in the Airport costs an arm and a leg and Norway has had enough of my money so I am doing this offline J Before I tell you more about the course I will discuss the Indian restaurant I ate at last night.  Very good food indeed was to be had at the Jewel in the Crown in Oslo. However the prices – my gosh – about £27 for a main meal – and that’s before you start adding Nan Bread at £5 etc –Oslo must be one of the most expensive cities in the world and I am reliably told by the locals that it keeps getting more expensive. A pint of Cobra was £7 and then they add a suggested 25% gratuity to the bill that they hint should be spent. And you’ve guessed it – there were several other British guys in there away on business eating our favourite food! Enough!

Day 2 started with everyone changing seats to be in new groups. Today was again a period of lectures, anecdotes and exercises. “Scrum is full of holes” we were told by Ken. Ok, in the context of what he was talking about it made sense and I am not into quoting people out of context! SCRUM is a wrapper for engineering practices – and the ones you choose to implement are up to you. We created a product backlog, prioritised it, ordered it, worked out our capacity to do work, fitted it into a sprint within a release and generally agreed that recording historic estimates at a requirement level to come up with future estimates was so prone to error that it was pretty much pointless.  We lightly touched upon team psychology, implementing scrum within an organisation, the concerns about Scrum Masters also working as developers etc and the new roles for Project Managers. We also discussed Sprint retrospectives and so on.   Nothing was new to me as I had used or come across this stuff over and over again over the last 20 years but once again it was the perspectives from the participants that made you think hmmmm that’s a bit different! Many came from organisations that had implemented SCRUM in different ways, different flavours and so on – I wondered if anyone was actually using SCRUM as it is supposed to be (whatever that means!). “It’s all about common sense and we need to look to the Sprit of SCRUM for guidance”. Thanks Ken! That last bit might be a hard sell to hardnosed CEO’s so – note to self – do not mention spirit of SCRUM   to the CEO just mention the hard numbers that you know about, and fortunately there were some hard numbers I can use linked to from within the course material! I feel a much needed business case coming on to support the implementation of Agile!

Personally, I think SCRUM is best explained within the parameters of what AGILE Software Management is - and if this is done then it sells itself – with people usually saying – yeah well that’s common sense – to which I reply – ‘so why are you not doing it then’. Am I glad I hopped on a Plane, flew to Oslo, paid for the course, hotel, expensive Indian Meal and travel out of my own pocket. Yes I am actually – I suppose that says it all – but next time I’ll take my own sandwiches!

 

SCRUM Papers

Jeff Sutherland is well known in the Agile Software Management Community. This paper on SCRUM is full of useful information  and might save  you buying a book or two!

Certified Scrum Master Course Day 1

Well, here I am in Norway and back in my hotel after spending the first day at the Felix Centre on a course with 60 other people interested n SCRUM, Yes I did say 60 other people. I was expecting a small class and my jaw probably dropped as I entered the room 5 minutes late - the Norwegians seem to be good on time-keeping - but my excuse is my taxi driver who could not understand my map after I got ‘lost’. Maybe. Yes I did pay the equivalent of £10 to go what could have been 100 yards - he did drive around for a bit…hmmmm - and it was only on walking back to my hotel I thought - hang on a minute! Anyway - I’m walking all the way tomorrow. And the cheapest fair from the Airport - 600 krona - which is over £65…crikey - the train would have been cheaper but I arrived late at nght. Anyway…the course…

The course

The course started with the warm up act - “what do you expect to get answered from this course” - and the questions got posted on the walls around the large room in the basement - with the intention of answering them over two days. My particular question was ‘where are the hard numbers and evidence on productivity gains to prove that SCRUM is worth doing’ - that could be fed into a business case to satisfy a demanding CEO - a fair enough question - and one I would be asking if I was the CEO if presented with a fuzzy - “this scrum stuff seems to work lets give it a shot” kind of argument!

The course is well structured and the hand out materials are fine. You can get most of the materials from within the two books written by Ken Schweiber - who was giving the course - dressed in a New Zealand All Blacks Shirt with Scrumalliance on the back! Being of Welsh Origin I thought - do not remind me! Ken is a very personable chap and very experienced in the industry - and this came through in his responses to the questions. I got the feeling that some of the participants thought SCRUM = Agile. Period. Whch it isn’t. The teams were arranged into groups of 6 - therefore 10 teams - I was number 61 - and was not even on the list - although I had received confirmation. Organisational hiccup.

The exercises were always time constrained - time-boxed I guess and were there to prove a point. There is never a right answer - and covered the usual suspects - keeping customers happy, prioriritised product backlogs, sprints, when does ‘done’ = done and so on and the importance of quality.  It was the questions from the participants that brought SCRUM to life. There were sometimes contradictions - for example - the Product Owner prioritises - optimally according to ROI - contrasted with - its up to the Product Owner what he wants even if it is not opimal - verses the need to be transparent to the business. Now if I had a Product Owner who kept picking non-optimal stuff with the Lowest ROI I would not be happy - and  would need to be pretty transparent with the business on what was happening…but that’s me - I like the numbers to make sense.  Could this happen - err…I think you will find that it can - its called pet projects.

The participants covered developers, testers, managing directors - you name it - they seemed to be there. When it comes to who owns the business case the answer was that the Product Owner prioritised against the business case and can cause the Project to Stop if necessary - because it costs more than originally planned, or because you are going to miss the date etc - i.e the ‘control/reporting’ job usually taken by the Project Manager. The Self-organising team concept ws stressed over and over again - so Project Managers might need to re-assess their roles in the future. This then leads to who leads the team  - the answer is the team is self-organising and the SCRUM Master is the facilitator. Well - yes I know that - but you could see the looks on some of the faces - contorted with a strange - hmmm - does that mean my job is ..er….hmm.. and so on. Its a paradigm shift.

The other burning question was one of emergent architectures. The need for up-front architecture verses one that unwinds as the project progresses. Ken gave an example that made sense for emerging architecture - but having been an architect in a former life I did not buy it - at least not fully - so this is something I will certainly write in the next few weeks. Interestingly he said that Motorola practised emerging architecture - but Motorola ia a big company - and I would be surprised if..and..if..and…get it!!

Day 1 over - I am off for a curry - yes I did see an Indian Restaurant in Oslo - good british food

Implementing SCRUM in 10 Easy Steps

I liked this - although it is only part of the picture.

 I am working with a company at the moment that wants and needs to become more Agile. SCRUM is just one part of the jigsaw but it is attractive because it is simple. However, do not underestimate how hard it is to make things stick. We are talking organisational change here!

Next Page »