Software Classic Mistakes 2008

The Software Project Survival guide and Rapid Application Development penned by Steve McConnell are the most thumbed books I own. I have even been known to order one each or all my team and some neighbouring teams so that they can use it. Some do. Some don’t and as  a Test I know which guys I would hire in the future

It makes the comment that the differences in productivity from one programmer to the next can be of the order of ten times. I believe the statistic as I have seen it with my own eyes at first hand. I have worked in teams that believed they could have gone and on and repeatedly delivered to a high standard of performance irrespective of the technology. This latter point is becoming more acceptable and believable as the IT Industry matures.

Of interest is that McConnel has updated his ’Software Classics Mistake’ work and he has made it available.  Click the chap for more information

He states

‘”The raw survey results are interesting and so are some of the general trends. One conclusion is that two of the mistakes added in 2008 (i.e., that weren’t in my 1996 book Rapid Development) made the top 10:

• Confusing estimates with targets
• Excessive multi-tasking

Confusing estimates with targets! How many times have you heard ‘the estimate is not accurate’. And as for multi-tasking I wonder if the increase use of the Web, Email Interruptions and the need to get more out quickly have exacerbated problems. Less haste more speed perhaps?

Of note, shortchanged QA is still right up there, and that means at some point you will hit re-work which will cost you. As the old saying goes - if you did not have time to do it right first time, what makes you think you will have time to do it second time around?

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

Project Rooms and Productivity

Demarco’s book - peopleware - hints at organisations who ensure that the environment is set up so that - and I am paraphrasing - the office facilities people can get around the desks easily so that they can clean them etc. Great productivity for the office cleaner, bad productivity for the expensive agile knowledge worker. Click the chap for some analysis :

Capers Jones in his latest book (2008) - Applied Software Measurement states “It appears that for knowledge workers such as software professionals, the impact of physial office environments on productivity may be as great as the impact of the tools and methods used. Open offices and overcrowding tend to lower productivity, wherease private offices and adequate spaces tend to augment it”.

When advocates of Agile Methods quote dramatic increases in productivity it would be more than interesting to determine how much is due to the effect of having co-located office space, and how much is due to the framework, methodology, or engineering practices being used …food for thought.

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

 

The Impact of Methods and Techniques on outcomes from Agile Software Development Projects

The Impact of Methods and Techniques on outcomes from Agile Software Development Projects

It is quite difficult getting hard facts on whether Agile offers improved productivity etc as the evidence are often anecdotal. However, based on a 2006 survey by Scott Ambler, David Parsons, Hokyoung Ryu and Ramesh Lai further analysed the raw data collected via an online survey to see if they could glean any more nuggets of information with respect to effectiveness of method combinations, and technique combinations in the Agile Space. They concluded

·         Adoption of at least one agile method improves outcomes in terms of quality, satisfaction and Productivity over the use f Non-Agile methods without a significant increase in cost.

 

·         The most effective way to apply agile methods is to combine more than one method together - two is optimum.

 

·         The most effective combination is SCRUM and XP –  they blend well since SCRUM is a framework or wrapper within which XP or other techniques can slot into

 

·         Pair Programming and Co-Location are the two most significant techniques for positive outcomes across all Agile Methods

 

·         Across XP, most important techniques are code re-factoring, collaborative working and TDD

 

·         At least five of the core XP techniques must be used to gain the full benefits of adopting XP

Successful adoption of Agile requires blending complementary methods. It is better to select the techniques that provide the best outcomes rather than the easiest ones to do! There is a critical mass of techniques that need to be adopted in order to give a project the best chance of success. Companies should carry out their own performance metrics on what works.

The full article can be found here:  Article

Note: Scott Ambler’s original surveys can be found here:

·     Agile Adoption Rate Survey (March 2006) – the basis of the further work above

·     Agile Adoption Rate Survey (March 2007)

·     Agile Adoption Rate Survey (February 2008)

 http://www.ambysoft.com

Organisational Change - Implementing ‘AGILE’

Wanting to be more Agile is the easy bit. Figuring out how Agile you want to be is a bit more difficult. Choosing the methods you will employ in being more Agile is harder again. But the most difficult bit of all once you have decided which way you want to go with Agile – via creating a business case - is implementing it through organisational change.  The reason being that people hate change. Even if they say they do not, they often do!  Ken Schwaber quotes in his book ‘The Enterprise and Scrum’ a guy at Ford who has pinned the notice ‘Culture eats strategy for breakfast’ to his wall. He got that right, and that is what you need to overcome!

Team Work

When you try and implement change into an organisation you soon find out the fiefdoms, lines of demarcation, boundaries to cross etc that will not make you Mr Popular in a popularity contest. You can persuade yourself that flagging up issues across the organisation such as poor quality, difficulty in building environments, lack of resource at key points in the software delivery chain etc will help – and that you are helping – after all you have found something that needs fixing – that’s a good thing right?  Well, it will help the organisation if the guys on the ‘receiving end’ want to work with you as a team in fixing the problems. If they do not then you have an uphill struggle on your hand and that’s why change must be supported from the top. ‘You are either on the bus, or you are off the bus’ is apt when implementing big changes. A weak central figure required to hold the change team together will result in a weak ineffective rollout, and in an immature organisation the bell may well  be tolling for whose head is going to roll as a result of a less than optimal  change initiative.  I remember a colleague of mine once saying ‘if the King is not strong then the Princes will fight each other’ – and that comment is very true – especially if the Princes are all fighting or plotting to be King sooner rather than later.

You need the equivalent of a Political Chief Whip in ensuring that everyone falls into line to make it a success – otherwise the ‘good guys’ may well get shot in the cross fire and the bad guys get promoted as part of the ‘told you so’ brigade – and that is the end of the rollout, and over time probably the company – a weak and short-lived victory for the blockers to much needed organisational change!

Using SCRUM as a vehicle for Agility

SCRUM is a simple yet at times painful framework for implementing changes. To be successful the process of using SCRUM needs to be supported by a Change team or ‘guiding coalition’ that have four key characteristics as explained by John Kotter in his excellent book – Leading Change. These are

1.    Position Power – key players, e.g. Directors and Functional Heads – need to head off at the pass those left out so that they cannot easily block progress.

 

2.    Expertise – various points of view in terms of discipline, work experience, nationality, relevance to the task in hand and adequately represented across functions so that informed intelligent decisions can be made.

 

3.    Credibility – the team should have sufficient people with good reputations so that its pronouncements will be taken seriously by other employees within Betfair.

 

4.    Leadership – the group needs enough proven leaders to be able to drive the adoption of Agile Software Management practices.

 

Leading Organisational Change

Kotter outlines an eight stage process for embedding change. It is sequential, no steps should be skipped – it is not a ‘pick and mix’. The sense of urgency is a particular favourite of mine – if you don’t have one then you certainly will not have the’ oomph’ to get the organisational change on the road. In order to create a sense of urgency you might want to stress how your competitors are chasing, catching, and want your business space. You might then want to tie in the personal objectives of successfully implementing change to the reward system and so on. The book is well written, easy to assimilate, and the anecdotes alone are worth the money. For a Professor at Harvard he writes like a Journalist on the Times – and that’s a complement to both organisationsJ. The framework is:

1.    Establish a Sense of Urgency

a.    Examine the Market and Competitive Realities

b.    Identify and discuss crises, potential crises, or major opportunities

 

2.    Creating the Guiding Coalition

a.    Putting together a group of people with enough power to lead the change

b.    Getting the team to work together like a team

 

3.    Develop a Vision and Strategy

a.    Creating a vision to help direct the change effort

b.    Developing Strategies for achieving that vision

 

4.    Communicating the Change Vision

a.    Using every vehicle possible to constantly communicate the new change

b.    Having the guiding coalition role model the behaviour expected of employees

 

5.    Empowering Broad Based Action

a.    Getting rid of obstacles

b.    Changing Systems or Structures that undermine the change vision

c.    Encouraging risk taking and non traditional ideas, activities and actions

 

6.    Generating Short-Term Wins

a.    Planning for visible improvements in performance  or ‘wins’

b.    Creating those Wins

c.    Visibly recognising and rewarding people who made the wins possible

 

7.    Consolidating Gains and Producing More Change

a.    Using increased credibility to change all systems, structures and policies that do not fit together and don’t fit the transformation vision

b.    Hiring, promoting, and developing people who can implement the change vision

c.    Reinvigorating the process with new projects, themes and change agents

 

8.    Anchoring new approaches in the Culture

a.    Creating better performance through customer and productivity oriented behaviours, more and better leadership and more effective management

b.    Articulating the connections between new behaviours and organisational success

c.    Developing the means to ensure leadership development and succession

 

So why is using SCRUM painful? Simple – because SCRUM highlights the inefficiencies and critical constraints all along the software delivery chain that hinder software getting into production. You have to stare hard at the realities of what you are confronted with by the teams trying to deliver and you have to act upon them. If you do not, then issues and constraints will get flagged continually – like a stuck record – and you have to make a case for fixing them or not fixing them.  If you choose not to fix the big issues then it is likely your implementation of Agile will fail – and your competitors will love it. If you do fix the issues then expect to see an improvement in delivery times, quality, and cost base compared to your competitors. You will see an improved time to market – and you can compete on the basis of speed. And that means higher profit for your organisation.  However remember to be brave – if you have ever watched the film ‘Zulu’ then expect to come under fire – but hold your nerve – it is worth fighting for.

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!

Competing on the basis of Speed

This is an interesting if only mildly thought provoking video. I am currently working with a company in the betting and gaming industry. Sports events happen all the time - an you guessed it - the company needs to move fast according to the up and coming Sports Calendar in order to have products out there competing with others in what is fast becoming one of the most competitive industries around.

One thing that competitors can do, particularly in the online industry is to copy your products quickly especially once they are up and running. However it is much more difficult for them to copy your internal processes and procedures. If your company is continually looking for ways to increase its efficiency along the value chain, then you become much garder to compete with. You drive your speed and cost to serve the busness down, and this gives your sales force an edge in the market. Or you could just look the other way whilse your competitors catch up. Your choice.

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

Next Page »