Tesco - Software For the Agile Business

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.

The Role of Leadership in Software Development

An interesting video on the role of leadership within Software Development. Mind you its a bit of an epic so you might want to get some popcorn, and a few beers before you listen!

Challenges of Agile Adoption

Some interesting thoughts on how to implement agile. I actually found this very thought provoking. I will watch this one over and over! Can you go too fast in implementing Agile?

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?

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.

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.

Agile estimating

I have read Mike Cohn’s book an Agile Planning and Estimating Several times. Its well written, In the meantime these videos will help. In my opinion, Poker Planning is a version of the Wide-Band Delphi estimating technique.

Agile Retrospectives

Project retrospectives or ‘Lessons Learned’ events helps the project team examine what went right and what went wrong on a project. The advantage of Agile Retrospectives is th frequency with which the increments take place - so you get to refine and adapt much more quickly i.e you get to do continuous improvement as you go along. Lessons learned at the end of a traditional project is usually too late!

Method Agility Ranking

I often get asked which Method is the most Agile. I always say Scrum because it is a framework - a wrapper - into which you can roll engineering practices that suit your organisation. Boehm and Turner in their book - Balancing Agility and Discipline have made an attempt at ranking the methods.

 

Next Page »