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!

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.

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.

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.

 

Theory of Constraints

I know I bang on about this time and time again! However if you want to get Agile you need to find the constraints within the organisation. You need to remove them as quickly as possible if you want product - i.e software to flow. Frameworks such as SCRUM are but one part of the Agile picture. When you attend a daily meeting and are asked for the impediments affecting your progress - think constraints.

Agile Testing

Agile testing. This should keep the QA guys happy. Sorry I mean the Test guys Happy. I don’t understand why some companies call the Test department ‘QA’ or quality assurance. Sure they are acting as a gate on the software but who is checking the testers are doing a great job? Would thatnot be the QA department. I.E to me, the QA team should look across development/testing etc to ensure they are doing a great job - more of an audit role I guess. Anyhow - Agile testing - worth a view…

Agile Team Sizes

Occasionally I find a Video that does not fit into any of the small number of categories I use. Here is one that is quite interesting, and also often asked. How big a team can you have working on an agile project?

Next Page »