Archive for 23/10/2009
Day two of Agile Australia kicked off with a breakfast to discuss facilitation of the open space sessions later in the day, that I was lucky enough to be invited to participate in.
Once again I would have liked to have attended Phil Abernathy’s discussion on agile governance (video), Lachlan Heasman and Jody Podbury’s discussion on Agile Business As Usual (presentation) and unfortunately I was scheduled at the same time as Rowan Bunning’s talk on Agile Mistakes and How To Avoid Them (presentation).
Here is an overview of the sessions I attended:
Keynote – Increasing Business Value Through Simplicity
Jeff Smith, CIO of Suncorp gave this keynote, and whilst I have heard a version of this talk a number of times, it never fails to inspire!
Some of the quotes from the talk included:
- “There is no technology constraint. The only constraint is constraint of thought”
- “Every product can be copied, but you can’t copy culture”
- “We don’t do any actual work as leaders, we create the environment for others to do so”
- “Leaders must important work is to create a productive environment”
- “When selecting a team, availability is not a skillset”
- “Leaders should use passion instead of fear to get things done”
- “There is no skills shortage, there is a shortage of leadership”
- “Productive Partnerships – work with people you inspire to be like”
ZDNet also summarised this keynote: http://www.zdnet.com.au/news/software/soa/Free-interns-boost-Suncorp/0,130061733,339299090,00.htm
Lean & Agile In The Large
I have seen this talk by Dave Thomas before as well, but wanted to enjoy it again!
Some of the quotes from the talk included:
- “Smell is a valid engineering term and will soon be a valid business term”
- “You know you’re agile when you no longer have DOORS, Mercury or MS Project“
- “You can only improve what you can measure”
- “To be agile all the way up you need to be lean all the way down from the top”
- “You need to have someone on your team who’s seen the movie before to be successful”
- “You must reach outside your own circle of influence to build a community”
- “If you happen to think that UML is useful then generate it from your code”
- “Learn your tools. You can’t do TDD unless you know keyboard shortcuts”
- “ Done = Acceptance Tested!”
- “A story is a wish unless it has acceptance criteria”
- “Architecture is a role not a job”
- “The ultimate expression of process is a culture where building software is more like playing jazz. People just do it!”
- Definition of SWAG – “Software Wild Arse Guess”
Understanding Just In Time Requirements To Support Lean Software Development
Martin Kearns from Renewtek delivered this presentation. My key takeaway was to remember to scout ahead to be successful.
- grow change – yourself -> team -> organisation, need to influence your team, change your world and the world around you
- Toyota production system – two pillars including Just In Time (JIT), falls down without it
- JIT is about a need – teams want to understand what they are delivering beyond the sprint
- takt time – theoretical figure on how long it takes to make a product, compare to total cycle time to look for waste (eg, 2.5 days to build car and 4 weeks to deliver, where is the waste?)
- continuous flow processing – re-arrange for work-piece flow, kaizen to solve bottlenecks
- one piece flow helps identify quality, ask these questions in retrospectives
- batching – push process
- kanban – pull the work – get team to dictate what they need and when they need it, gets team commitment when you supply their needs
- power of team based approach – able to direct each other and influence the organisation
- Ron Jeffries Three C’s – card, conversation, confirmation
- be aware of never ending stories – chasing tail, not sure what we are creating
- need to scout ahead – to be productive in the now, need to spend time looking ahead to manage uncertainity
- 5 levels of agile planning (Rally) – 1) visualise what we want to do 2) need a roadmap to know when things are coming so we can focus on the now, need to trust and challenge the roadmap 3) release – incremetal focussed on an outcome, reflect and recalibrate 4) sprint try to get sustainable pace 5) course correct daily
- project bridge – how are people going to critique our work
- people want strategic direction – put a date range around release dates
- understand concept, then formulate a high level design (can be photo on a wiki), should not be done in sprint planning because it can bring uncertainity, implementation, specification
- concept – visualise accomplishments and how to communicate to the team
- need trust and openness – barriers is not a team
- take baby steps and work your way through dysfunctions
Lean Thinking for Lean Times
Jason Yip from ThoughtWorks and Alan Beacham from KM&T delivered this presentation. The slides are available here. It was a good overview of Kanban (it allowed me to get that a-ha moment in relation to measuring flow).
- best source of information is Kanban vs Scrum by Henrik Kniberg
- most agile shops already have a wall with steps, kanban trying to show full process and make explicit, visualise hand off points, set limits on the capacity (otherwise burden people and nothing actually moves)
- Corey Ladas – Why Pull Why Kanban – JIT backlog – only do what you can do, lean has articulated what XP folk were talking about
- event triggers – order point to trigger upstream process so not starved of work
- size of cards now hard to relate back to customer value (software by numbers – minimal marketable features), so track both on wall (feature and then stories and tasks)
- standardise size of work items instead of estimating (so just tracking work estimates) – at ThoughtWorks Jason determined everything is 2.25!
- Kanban – means card or sign – referred to as signboard in a pull system
- allows to understand consuption rate (how much work in progress)
- manages amount of work, flow of materials and understand when people work
- left to right thinking not the way, donlt understand the problem when you start, usually do 80% of project in last 20% of time, kanban brings to the front
- schedule from right to left, process goes left to right, fixed date and desire, requires innovative thinking
- kanban is growing trend, challenges fundamental concepts (eg CSM training), has to be suited to the type of work
The Inter-Sprint Break
- Aconex – have a break between sprints
- Scrum is unstopbbale momentum
- a holiday or time to kick back – no!
- 3 week sprints, sprint planning at start and demo at the end
- start sprint on Tuesday and finish on Thursday – so 2 day break
- benefits – teams were stressed and burning out but then got extra benefits
- track at retrospectives the mood-o-meter and stress-o-meter – mood started high, dropped low throughout sprint and raised at end of sprint again and stress low but raises at end of sprint
- team used to have 6 month releases, now they think 3 weeks is too long
- asked team to draw pictures on how they thought sprint went
- were looking for consistent level of mood and stress
- distractions and flow – always other stuff during the day not related to doing sprint work, when you take somebody away from task there is waste as they ramp back up, made rule that meetings were moved into inter-sprint breaks such as management one on ones, brown bags still run at lunchtime because it is useful
- collaboration – classic IT/business divide but also discipline silos (test, UI, middleware) – moved to a cross functional team, used scrums of scrums
- in intersprint break – strategic planning, technical debt for discipline, information sharing, improvements in tools (changed toolset from JUnit to TestNG in two days and got immediate improvements)
- paying down technical debt – argue that if technical debt is important it should be in our sprint backlog, but this only allowed them to focus on parts of the system they were changing and not the system as a whole
- war on warnings – complier warnings
- testivus – refactor or add new tests
- QA deathmatch – find a bug get a point, fix a bug get a point and prizes for most points, fun activity and some competition, keeping the garden free of weeds
- innovation – need time to breed creation
- hackathon – like Atlassian Fedex day – can do anything with any technology for any purpose, demo something that can improve product or look at new tools, gets creative juices flowing, lets IT show the business we can tackle anything
- extended to researcharama – like hackahton but not to produce prototype but present research to increase knowledge of teams
- looking to do howhardi gras – answer question how hard would it be? response, take some of those questions to pick it up and have a crack at solving it
- things you get for free – product reflection, think about team actions from retrospective, admin catchup
- things to watch – don’t make it too long or sluggish to get back to sprint, activities for all, clear outcome and purpose, have a champion
- during the sprint keep sustainable pace and don’t use intersprint break as excuse to leave things
- sell to business – constant sprinting understood and can cause burn out, started with hackathon to demonstrate importance
- draw a map of sprint to find major events (PC broken, etc), then get team to draw their mood on top
- use a thumbs up, thumbs down, OK in standups
- sprintometer – identify how we are travelling visually, get somebody to move this at the end of the sprint
- called Gatorade Breaks elsewhere
- have already determined the game team will play in the break, maybe should ask team what they want to play, been based on what has been going on in the organisation
- have a tendency when sprints go bad to use break to catch up , champion needs to ensure that they get the activity done
- transparent and business aware of release cycle and to use break for distractions, trying to hammer distractions and bad flow
- prioritise BAU work in backlog, must talk to Scrum Master, for silo teams have to constantly remind managers that speaking to a team member affects productivity
- all sprints synchronised, originally thought it was good idea to stagger for room bookings, etc, but all teams together ended up working much better
After The Consultants Leave
Adam Mostyn from BT Financial delivered this presentation. The slides are available here. It was interesting to hear the successes and failures in what I thought to be an environment that would not be receptive to agile.
- Phew, go back to what we did before
- started in 2006, not looking for agile but for bright people to attack a skills shortage
- showcases worked well (especially beer and pizza to get people in!)
- storywall worked well to see progress
- user stories, standups both stuck
- product owner did not stick – went back to old way of handing requirements over, showcases fell by wayside, sprints fell by the wayside because not ingrained in culture
- did not have education and understanding what agile meant – business had thirst but projects started to fail
- have resistance from business – need to convince it is a methodology that has rules
- need to convince that agile is a journey and not a switch
- ensuring that they have qualified Scrum Masters on every project team, otherwise will fall into same hole
- trying to define the role of product owner
- fun, so engages and empowers staff
Achieving Project Success With Agile
Agile Open Space
I facilitated a session on agile technical issues (amongst 13 simultaneous discussions). We discussed TDD, automated testing, pair programming amongst other topics.
I must admit, I turned up to the inaugural Agile Australia conference with no idea what to expect, but a good range of Australian speakers (including myself!), keynote speakers and a healthy number of attendees, the conference exceeded my expectations.
There were a number of sessions I would have liked to attend that clashed with those I attended, such as Shane Hastie on Agile Transitions (presentation and video) and Julian Boot and Marina Chiovetti and their talk Show Me The Money Honey.
The sessions I attended on day 1 were as follows:
Panel – The Journey Towards The Agile Enterprise
This was the kickoff panel featuring Beverley Head (BH) (Journalist), Nigel Dalton (ND) (Lonely Planet), John Sullivan (JS) (Sensis) and Katy Rowett (KR) (Suncorp). My key takeaway was the acknowledgment that you need the right people (“the bus”) and the retaliation that the journey continues.
- BH – agile is “in your face computing”
- journey not for the faint hearted
Why did you begin on a journey to the agile enterprise?
- ND – major event of waterfall failure, so much so the owners sold the company, could actually sell them on “anything but waterfall”
- KR – Suncorp started with one mans vision as part of synergy savings of merger of Suncorp and Promina, needed to do something different in IT to meet the timelines
- JS – changes taking to long to get into the market place
- KR – has not been an easy road to success, still a way to go, social change in the way people are being asked to collaborate and work, productivity initially took a dip as they learnt a new way of working
- JS – agile breaks the barriers, but the types of people you want to do this with are not the people that you started the journey with (essentially you are starting the journey with the wrong people on the bus), last time on a panel he controversially said “sack their arses” but nicely that means “move them to a different bus”, its all about moving people from punch in and punch out to giving people a career
- ND – thank god for big banks and Sensis who took the people who were failing at Lonely Planet!, some people are not great at working in this environment
- JS – whole company has to go for the journey, from the person who organises desks to the people who put the walls up, didn’t follow the agile books and got IT into the business (not relying on people coming to them), need to understand the business
- KR – relationship is crucial, luckily the relationship was already there as it allowed to take first step with blind faith, worked less well where this was not there, ramming agile word down their throat, need business to steer solution and IT will bring intellect to the table, when business see something they can make sense of they are along for the journey, prioritisation and politics an issue for a large organisation
- ND – prediction – in two years time the theme of conference will be product management in an agile way, had huge failure with seagull product managers
Skunkworks approach to agile?
- KR – not in Suncorp, was the way before Jeff Smith came along and then he tipped the boat over, Jeff Smith is a visionary who surrounds himself with people who have passion and energy
- is agile a generational thing for the next age gap of CIO’s?
- JS – in two years time we will be talking about how to do data warehousing in agile, the tools support doing web-based front-end applications very well, need to support back end process and get the developers to signup to the principles and practices such as automated testing
- KR – agile is whole of system approach, Suncorp has lots of legacy, extends to mainframe, web and product support and maintenance
There were then some questions for the panel.
Introverts vs extroverts, we would like to bring as many people on the bus, how do you bring the introverts along?
- ND – as an introvert, have learnt one or two practices to move from introvert to a mile-high extrovert, introduced “the red button” to identify issues, agile is a massive opportunity to learn IT and networking skills and has flattened the team out so everybody gets their say, more respect than traditional teams
- KR – there is always something that motivates somebody or pushes their buttons, this is contagious in agile teams, in the Melbourne office you could originally hear a pin drop but now you can’t hear yourself talk
Jim Highsmith says you get the customer happier, faster?
- JS – under promise and over deliver, builds trust
- KR – business wanted a Lamborghini but as the system was being built they were happy with the Commodore, then really happy when they got the extra feature!
What do you do with skilled developers who do not want to fit the mould?
- JS – building a team, these people are disruptive to the team, you end up getting rid of them anyway, have to identify that while these people are brilliant they are counter-productive, spend way too much effort trying to harness it or find them something in the skunkworks
- ND – have tried to put them on a spike, but in the end you still wish you could have paired so other people know what is going on, agile is doing extraordinary things with ordinary people
Finally, the wrap up!
How long does it take?
- KR – joruney never stops, Suncorp has been doing it for 2 years, have a baseline of success and failures (which are deemed as successes), currently assessing where we are and how we can be better
- ND – two years with BBC ownership who are big on agile, as they have matured the have realised it is a learning, how you learn is the killer outcome of agile
- JS – three years, originally got up and running in 8 weeks after throwing a big bucket of money at it (rather than taking the journey), went from 12 people to 60 people in a 4 week window
What has it done for the business?
- ND – for R&D, who believes that the agile cult is the barrier to high speed innovation, his response is prove it
- KR – Suncorps new CEO Patrick Snowball said BT is our biggest asset and our goldmine
- JS – it’s bloody expensive!
Keynote – 12 Agile Adoption Failure Modes
- roadblocks to agile success – think about growth, business wants results straight away, but we don’t pay attention on what it takes to do it, hence we get failure
Benefits you’ll derive:
- stop denial that waterfall is actually delivering
- put on reality goggles – this is the truth of it and agile will help us get there
- seek out insight pools, will allow more collaboration
- create your own reality – core value at Rally, can help individuals which then moves throughout the organisation
- all of these together deliver customer value
Checkbook commitment failures:
- CEO/CIO level, have a problem and agile will solve it
- unengaged – “just do it”
- looking for immediate results
- have not commited to organisational change that is required
- same metrics – everybody still reporting the same way up and down, continues the illusion that software development is deterministic
Culture that does not support change failures:
- everybody expected to follow a plan, how well are we doing on a plan we created a year ago?
- they enforce standard of work to ensure we get to the plan (governance = conformance), standard of work static, everybody works the same way
- success mode to ask each team what the best practices are rather than declaring them up front
- belief that more documentation will enforce standard of work – need to create knowledge creating companies, rather than declare standards across the organisation, tacit knowledge creates implict knowledge which in turn creates tacit knowledge
- PMO as enforcer in failure mode, should act as broker for knowledge
Ineffective use of retrospectives failure:
- what are we doing well, what’s not serving us as a team, what can we change to improve?
- if you want to fail, don’t do any at all
- retrospectives ignored, team gives lots of ideas but facilitator explains why none of them are correct
- no action on retrospectives
Ignore needed infrastructure failure:
- no sustainable or stable environment
- TANSTAAFL – There Ain’t No Such Thing As A Free Lunch – need to be able to have the money to invest into the infrastructure, leads to dangerous practices
- need to be desperate for tooling for testing, CI
Lack of full planning participation failure:
- act collaborative and want insights, but save money and get a few people to do it who are well meaning – means teams are not committed to tasks and estimates – how can we march to the plan?
- waiting for decisions – waste – if we do not have the right people in room we cannot make decisions in an expedient amount of time, lean is about eliminating waste
- osmotic conversation – creates better commitments and better plans which means better insights – learn from all of the skillsets about how we can measure ourselves against the plan
- commitment – have run planning sessions with 100 people, a 2 day event, people thanked at the end for being involved
Unavailable product owner failure:
- not available when trying to go faster
- too many product owners
- agile asks a lot of product owners – usually they are too busy to do the communicating, will suggest that agile is too hard to get engaged in
- need them engaged to agree on priorities
- when they are engaged they are commiting with the team, want product owner at standup asking where are we with the commitment and how can I help?
Bad scrum masters failure:
- want somebody facilitative, not dictatorial playing the scrum master, does not need to be a master of the domain but a master of the process
- do not have role of command and control – hard for existing project managers
- command and control lowers morale and lowers IQ – when kids ask you what you did at work today, tell them you lowered peoples IQ’s!
- serve and facilitate rather than command and control – need to be Superman and help you raise your IQ
- need someone who serves and facilitates and removes impediments – cleans up mess, is committed to help team meet their commitments
Not having an onsite envangelist failure:
- if distributed, need one in each location, otherwise team do not believe anybody cares about them, this leads to remote roadkill (on your own and if you get run over by a truck that is your problem)
- can’t reap the benefits if you leave them on their own
- need to advise, motivate, protect and serve – bring in their insights rather than pushing insights on them, help them be successful
Team lacking authority failure:
- don’t empower team and leave them to deal with the red tape (difference between Toyota in Japan to the USA, western culture less successful at empowering teams)
- TED Talks – Birth of the Computer, Motivations
- motivation – understand how teams work, takes work to be a high peforming team (first form the team, invite conflict into the team, converge insights, then you hopefully get a norming team who just get things done)
- empowered team amplify learnings – individuals to organisation and back again
- inspect and adapt to get better at delivering – high performing can speed up and continue to deliver
Testing not pulled forward failure:
- do not invest in infrastructure, do not believe necessary, do not have the appetite (do testing in subsequent iterations or do one iteration for planning, one for code and one for testing)
- need to look at capacity utilisation, agile optimises the process, some people think it looks like wasted utilisation but what we do is create more defects when we are pushed to 100% capacity
- piled up technical debt if coders coding at 100% capacity in an iteration, slows down ability to deliver
- need to stop the line, don’t emphasise 100% capacity but emphasise quality (when you find a defect stop), Toyota showed this at a GM plant, fired everybody then hired them back by changing the measurement of success from number of cars to the defect level, first day made 2 cars! but ended up doubling the output of the plan
Managers yearly expectations failure:
- eliminate performance appraisals – get in the way, evaluate teams working together, do not reward individual heroics
- teams evaluate each other, called 360’s at Rally
- how did you bring level of skillet of this team up? – reward team contribution
Reverting to form failure:
- change is hard, but at least we understand waterfall!
- Kathy Sierra created a chart showing the suck threshold through to the kicking ass threshold
The wrap up:
- call to action – pick one of these, hold a self retrospective in 30 days
- when do you give up? – if teams not getting there after 6 months, Mike Cohn will just say “you can’t do agile so just give up” – after 6 months look at failure modes and run a retrospective, need to be prepared for a 2 year journey up the organisation to scale and mature
- ensure balance of tech lead and scrum master – hired to be the brightest guy on the team, need to decide that you want to get smarter by increasing the IQ of the room, move from how smart I am vs look how smart team the is – see Good To Great (Level 5 leader takes ego and turns it to look how good team is)
7 Habits Of Highly Effective Agile Developers
Steve Hayes presented this talk, the slides are available here. My key takeaway was the idea of the emotional bank account (and the build story!).
- hard to build effective teams from ineffective individuals
- individuals always know the answers to why projects are going wrong, but don’t always speak up
- developing effective individuals required for agile success
- showed Dan Pink at TED – use of financial incentives – mismatch between what science knows and what business does, Atlassian Fedex days to Google 20% time to CultureRX ROWE (Results Only Working Environment)
- management may not be natural but leadership is – need to engender trust and faith
- talk based on Stephen Covey – 7 Habits of Highly Effective People
- be proactive – take responsibility for own life, don’t lay blame, many organisations use reactive language (eg. I have to do this), proactive people trying to increase circle of influence
- begin with the end in mind – need vision on what you are trying to achieve before you can achieve it, create your own mission statement (personally and organisationally), does my mission statement match my teams mission statement (am I in the right place?)
- put first things first – urgent and important, most underused word in professional life is no (what would you like me to not do?), delegate (go’fer delegation and stewardship delegation), self management and self supervision is hard but agile demands it to work effectively
- emotional bank account – make deposits and withdrawals, too many withdrawals and you will go into overdraft, understand the individual, meet commitments, make apologies for withdrawals, etc..
- if you aim for win/win, you need to be prepared to walk away if you cannot win
- seek first to understand, then to be understood – Indian talking stick (don’t give up the stick until you feel you have been understood, understood if people can repeat your position and you can answer yes), use your opposition as input to your position or as an option you have not considered
- sharpening the saw – need time to recover production capability
Finally, Steve told the story about standing on the desk and shouting at the developers at Lonely Planet about the red build light, which was a great story and repeated throughout the conference. The only reason he could do this was because he had the build credit in the account first.
People Driven Agile Transformation
- started in May 2006, hand picked a new team and formed a company (Majitek), then rolled out across 80-150 people across Sensis
- have developers that are really good architects that can cut code
- agile manifesto – it’s all about people not about the methodology, the agile luminaries would have definitely prioritised the list
- assess thresholds – organisational change – will always be thwarted, companies focussed on a threat will not have the appetite as you need people to learn new things, tried to introduce pair programming at a bank but the union thwarted it because everybody needed a corner desk, etc…, currently at Sensis have a big battle about where to put story cards (because board members walk passed and thought they looked unslightly)
- assess thresholds – people change – too many people in IT punch in and punch out, can change people but it takes time that most companies can’t stomach, might need to move people out, want to challenge people to do better tomorrow, most people don’t want to learn something new because it makes them anxious
- assess threholds – technology change – change the architecture to get people interested (eg. introduced Ruby On Rails to give an option to hire interesting and good people)
- movements need committed people – need to get people on the bus, where are you today and where do you need to go and why, ask people to write down what they would like to be as an industry luminary, need to make people understand why we need to do this, once you have buy in you need to action very quickly and slam people with actions
- technology – most agile teams favour XP practices (they are common sense), use the threshold to decide what tools to use (Ruby on Rails is all hype, get professionals to pair, throttle back on some of the cutting edge technologies that consultancies try to sell you on), simplified architecture (rule that all applications had to go onto an application server – why??)
- lease the process before you own it – get the right team of experts in to establish experts, learn from them and get them out as soon as possible
- build relationships – IT people like screens, go to the business, don’t make them come to you, talk to them in their language
- can trust an agile advocate as much as you can trust a real estate salesman – need to learn from failures, build trust, IT willing to sell success but mask failure, Dr. Jeckyll and Mr Hyde (front up whether good or bad), take the how out of estimates, just write down what outcome you want to achieve and how much it will cost, agile can be overstated (does not make risks disappear but it highlights them and lets you fix them), you could do an agile and waterfall project in the same time (you will just get the features you want to Production sooner), physically more expensive to do agile but the outcome is better
- don’t care about process, need the right people to do the right job
- agile does not sit well with people who want to coast – Sensis is competing with Google!, it is not a job it’s a career, most organisations are setup incorrectly
- want master craftsman, inspire people to do better every day
- worked out ways of influencing change, could not change everything so worked out ways to work around the roadblocks
- don’t use term agile anymore, originally was a fascinator, now it is all about self improve
Taking The Leap Of Faith
Mike Allen from Racing and Wagering Western Australia (RWWA) gave this talk, slides are available here. My key takeaway was the sotry about how their investment in agile allowed them to replace 15 year old legacy totaliser machines in 5 iterations.
- RWWA – mainframe shop – hard to get developers, licencing costs high, time to market too long
- educate on agile – had to dispell myths – no design (do it all the time, more than waterfall, every iteration), no planning (plan everyday)
- establish a tempo – 3-6 month releases, have showcase at the end of release
- plan at the right level – has a Gantt chart, can tell you that on 15 March next year that developer “James” will be doing development, which is all you need to know!
- hire the right people – biggest secret to agile success, need open people, want to be challenged, not possessive or obsessive about code, cap the hours at 40 hours per week, have external activities, most people at RWWA contractors, agile is infectious
- create the right environment – spent $175K and ripped the existing building infrastructure apart, smaller desks, greater density, lots of wall space (hide nothing, transparent about everything)
- start producing software – start to see functionality grow week by week the way the customer wants
- Mike’s Balls – variant of a burn down chart – demonstrate scope vs progression, different colours for different teams, can see where progess is being made
- don’t fight everyone – big organisations sometimes want to use tools that cost lots of money
- deliver high quality software – quality should be immutable, zero defects (means for the time we spend testing the system we will fix those bugs), replaced 15 year software at TAB in 10 weeks (5 iterations), RWAA have been good at giving the customer and empowering them to make decisions
- produce good documentation – produce right at the end, a DVD player comes with technical guide and technical specifications, written at the end, long running documentation should be produced at the end, tossing the requirements out after the project is done is still a battle
- have some fun too – a good agile project should be about fun
Some questions at the end:
- scope, how much will it cost? – captured a card for each functional area (too high to estimate), then broke down to smaller cards and got development estimates in developer days, then add up and apply a sophisticated formula (multiple by 2 to allow for testing and BA resources!)
Better Software Faster
- originally a LAMP stack with Perl
- requirements hell – high cyclomatic complexity, tool 9 months to choose a colour picker!
- top down approval for agile rollout plus bottom up readiness
- pair programming – did coding dojo (tight time frame 6 minutes per pair at 1 station), learn new skills
- Perl to Ruby and vi to IDE – Ruby has more buzz which attracts better people and energizes people
- BDD – Business Analysts and Test Analysts own the stories in this way, CI (confident it works), BA’s understand the behaviour
- iterative development – transparency when running a showcase
- track progress – with pen and paper, can walk up and see what is going on
- retrospectives – small issues are visible, clears the air
- project delivered, happy business, strategic success to core website
- failures – one big release (not small releases), when iterations have failed (hard to celebrate, but have to realise you have failed fast), still trying to determine how to deal with product management (still fall back to waterfall practices)
Atlassian VIP Tour
I skipped the last two sessions to take the opportunity to tour the Atlassian offices with Nick Muldoon and JC Huet. The work environment was incredibly impressive and it was great to talk to some of the developers of Jira directly and its future along with GreenHopper sounds exciting. Oh yeah, they’re hiring as well!
ThoughtWorks Open Office
Most of the conference headed on over to the ThoughtWorks Sydney office for drinks and conversation. Plus myself, Rene Maslen, Tammy White and James Couzens won the agile trivia competition!