Episode 171 – Beyond Legacy Code with David Bernstein

The Agile Revolution Podcast

Craig is at Agile 2017 in Orlando, Florida and speaks with David Bernstein, author of “Beyond Legacy Code“, and they chat about agile technical practices:

  • Agile does have something to with software development
  • Agile 2017 talk “Create Software Quality
  • The real value of Agile is in the technical practices so we can build iteratively, but still very few people practice them
  • The future is already here, but it is not very well evenly distributed – the same applies to Agile
  • Companies are being consumed by their technical debt and they don’t even recognise it
  • What is always cheaper in the virtual domain is building quality
  • Continuous Integration makes the most painful thing in software development (integration) our greatest asset – this in turn gives us feedback
  • We don’t necessarily know there is a better way to do things – but there is a better way to…

View original post 211 more words


Episode 149: Continuous Delivery with Dave Farley

The Agile Revolution Podcast

Craig, Tony and honorary Revolutionist Pete Sellars are at YOW! Conference and sit down with Dave Farley, co-author of “Continuous Delivery” and they chat about the following

  • There are anti-patterns with doing XP at scale, continuous delivery was born from the learnings from that
  • Continuous delivery is just extending continuous integration to more of the software development practice (and continuous integration requires test driven development)
  • Continuous delivery works because it is the application of the scientific method to software development
  • If you work in an iterative, imperative, experimental way and you take continuous learning seriously and take cycle time as a serious measurement you will naturally drive out agile, lean, systems theory and DevOps
  • YOW! 2016 presentation “The Rationale for Continuous Delivery
  • Most common two ways to introduce continuous delivery to your organisation – need to get cover from senior management to make change or…

View original post 250 more words

Agile Australia Then & Now (AgileTODAY)

AgileTODAY is a publication associated with the Agile Australia conference. In the May 2018 edition I was invited to reflect on one of my past presentations and how it stood the test of time.

Craig spoke on “The Speed to Cool: Valuing Testing and Quality in Agile Teams” at Agile Australia in 2011. Craig is an Agile Coach and Director at Unbound DNA and works as a Trainer and Consultant at Software Education.

In 2011, my talk highlighted the need for a greater understanding of the changing role of testing in Agile environments and the need to build quality into our solutions from the beginning.

Fast forwarding to 2018, the community is improving in this space but still has a long way to go. The rise in popularity of DevOps has helped immensely in this area, although it astounds me how many teams and organisations I work with still do not have some of the basic building blocks in place (like continuous integration or sometimes, worryingly, version control). Many organisations still have a large focus on manually testing via the UI which becomes increasingly riskier and slower as the importance of digital continues to rise.

In my talk, I spoke about what is now referred to as the “three amigos” concept. In the ‘conversation’ around a user story, three key principles outline how to actually implement the work:

  1. When developers and user representatives collaborate we get a better understanding of the specification or the requirements.
  2. When testers and user representatives collaborate we get a better understanding of the acceptance criteria and how we will meet our agreed definition of ‘done’.
  3. When testers and developers collaborate we get a better understanding of quality, but also get the value of pairing on automated testing.

Approaches such as Behaviour Driven Development have risen in popularity and support the above model well but, as I highlighted in the talk, this requires behavioural changes across the team. Mainly:

  • User representatives need to have a greater testing involvement, working closer in real time with testers.
  • Testers need to build technical knowledge and work closer in real time with developers, understanding developer tests and interfaces to avoid rework and improve quality.
  • Developers need work closer with the user representatives on the requirements collaboration, as well as with the testers to ensure that testing artefacts are left behind.

We need to appreciate testing as a team skill set and not as a job or an anchor. While this now occurs more frequently in the Agile community, many organisations still have a long way to go. Testing remains an important skill, but mindsets and skill sets need to change to fully embrace an Agile way of working.

Jenkins Gets a Facelift with Release of Blue Ocean 1.0

Jenkins, the popular open source automation server that is used by development teams worldwide for continuous integration and continuous delivery pipelines, has recently announced the general availability of Blue Ocean 1.0.

Source: Jenkins Gets a Facelift with Release of Blue Ocean 1.0

Episode 120: Microservices & The Lean Enterprise with James Lewis

The Agile Revolution Podcast

jlewisCraig is at YOW! Conference and has a conversation with James Lewis, best known for his work around microservices at ThoughtWorks. They discuss:

View original post 168 more words

Atlassian Bamboo 5.11 Delivers Continuous Integration At Scale

InfoQAtlassian, makers of development tools such as JIRA and Confluence, have just released version 5.11 of their continuous delivery tool Bamboo with a host of new features to help teams scale and collaborate. The key feature in this new release is the ability to scale from 100 to 250 elastic build agents.

Source: Atlassian Bamboo 5.11 Delivers Continuous Integration At Scale

Agile Australia 2011 Day 1 Review

Agile Australia 2011Agile Australia 2011 was held for its third year last week at the Hilton in Sydney. Once again I was honoured to be offered an opportunity to present, be an MC for speaker sessions on both days, moderate a panel discussion and run the end of conference retrospective. The conference attracted 675 attendees and the buzz over the two days indicated to me that the conference was a huge success.

For the second year, it was a great pleasure to be one of the conference advisors. As the conference was brought forward to June, there was only six months to prepare between conferences and lots of suggestions and improvements to implement from previous years. A lot of review, debate and discussion went into putting the program together and ensuing there was a good mix of speakers, variety of topics and sessions for different levels of expertise. More effort was also put into shepherding speakers. A huge thank you needs to go to Rachel Slattery and Zhien-U Teoh from Slattery IT for their commitment to the conference as well as my fellow conference advisors Phil Abernathy, Adam Boas, Keith Dodds, Martin Kearns, Dave Thomas and Nigel Dalton.

The following are my notes from the sessions I attended on the first day.

Keynote: On Beyond Agile – The New Face of Software Engineering

Alistair Cockburn delivered this keynote, the slides are available here.

From Agile Australia 2011
  • agile software development is for wimps
  • cooperative game – invention, communication and decision making
  • projects are in a position, look for strategies to move our position, no fixed formula for winning the game (competitors and the economy are some of the enemies), only three moves to invent, communicate and decide
  • communication – whiteboard discussion provides stickiness over time (can just point back to conversation) as well as proximity
  • need about 3 minutes of video to enhance the distributed conversation, becomes archived documentation to remember user point of view or architect design decisions
  • craft – a lot has changed, software development changes every 5-10 years and you need to keep up
  • people learn skills in 3 stages – shu, ha and ri
  • work in progress is decisions that have been made but have not been shipped and delivered
  • like lean we we want multiple deliveries per day – continuous integration has evolved to continuous delivery
  • in decision making, look for the bottlenecks, the person with the full inbox is the person limiting the work in progress of the whole organisation
  • knowledge acquisition – real moment of learning often happens at the end when the surprise factor occurs when we deliver work, suggest that at the beginning of a project deliver a knowledge curve ahead of the cost curve (a number of small experiments)
  • agile says deliver highest level of business value first but projects tend to always deal with the risks first – learn about your business risk (should we build it), social risk (do we have the right people), technical risk (API’s, performance, architecture), cost/schedule risk (gain knowledge about the solidity of the estimates) – you need to decide whether to deliver business values or knock off some of these risks
  • need to identify the tail to determine whether we deliver business value early or add more features later (Apple are good at this, for example shipping an iPad without 3G initially)
  • self awareness – the team is self aware when the team can talk about the team and where they are

Keynote – Is Business Ready for Agile

Rob Thomsett delivered this keynote, his slides are available here. He advised that he was going to run his talk in two sprints and check the heart beat halfway

From Agile Australia 2011
  • agile is a church of all people – the newbies through to the true believers and a few drooling old people
  • agile is not new – been going for 40 years
  • is business ready for agile? – yes and no – every company in the world is ready for agile, they just don’t know it – how do we develop agile into a broader organisational paradigm
  • we work on a set of models that were developed when the world was relatively stable
  • the average window of stability for an organisation is about 3 months, change is normal and everything changes
  • old business techniques have reached their use by date (Gary Hamel – Management 2.0)
  • 100% of C-level executives believe that project management is too bureaucratic, projects take too long, business cases are poorly developed, transparency is adequate, they expect to be ambushed, steering committees are a waste of time, reports are not accurate
  • in 1968/69 NATO held a conference to address a perceived crisis in software engineering – sound familiar?
  • software is not engineering, wrong paradigm, it is a craft
  • the closest to what we do is not making buildings but making movies
  • summary: we took the wrong model, flogged it to death so let’s throw it out
  • agile is a cultural and disruptive journey – first question to ask is are you up for the cultural challenge, for every company that says no there is one that says yes
  • business approach needs to pass the simple and transparent test – most powerful test to clean up broken processes
  • go back to work and annoy people by asking people if we can make it simpler
  • cultural values are openness, honesty, courage, trust and money
  • the people at the top are the easiest folks to get on board with agile
  • most people link budgeting to estimating – agile demands we move money around more quickly
  • sponsors must get dirty – they must be part of the process because they own it
  • PMO should exist for resourcing, not reporting

Panel – The Changing Role of the CIO

Beverley Head moderated this panel with Jeff Smith from Suncorp, Steve Coles from Allianz, Daniel Oertli from REA Group and John Sullivan from Jetstar.

From Agile Australia 2011
  • key is to turn decision making over to employees and leaders need to become coaches and create a great environment
  • The Corner Office by Adam Bryant gives advice for success – passionate curiosity, battle hardened confidence, team smarts, simplicity, fearlessness
  • role is to understand where the company is going and deliver things for them to succeed
  • relax the old techniques like governance that gave a veneer of confidence
  • need to understand and remove the barriers by becoming an active listener
  • fundamentals like attract and retain the best have not changed
  • learn the business in which you operate and realise the definition of leadership has changed (don’t be afraid to higher smarter people than you)
  • need clarity of purpose, avoid constraint of thought and don’t filter based on your experience
  • resistance at the frozen layer – middle managers are typically the blockers so need to change the communication structure (for example, using Yammer for communication to give everyone an equal voice)
  • distributed teams always need a local decision point like an iteration manager
  • leaders need to eliminate information handlers
  • offshoring value proposition – you need to decide if your assets are a strategic advantage, do not offshore things that are volatile or if the project is too big to handle yourself (which essentially means you can’t explain it to someone else), offshoring is good because it keeps us on our toes to be competitive and continuously improve
  • need to look at outsourcing from a productivity point of view and not just a cost point of view (we are not buying pencils)
  • life long learning for developers – people have to follow their own course, inject talent and different thinking, look back each year and think about what you added to your bag of tricks
  • most people are capable of learning new skills, that’s the beauty of human beings
  • what does quality mean – quality is something that is fit for purpose and testable and maintainable, quality is everything
  • pushing agile into the business – need to agree on one way of working, once you are successful people want to jump on the bandwagon

Agile Architecture & Design

I had the privilege to introduce Neal Ford for this presentation, and his slides are available here. As I had seen many parts of this presentation previously, I did not take many notes as they can be found across other posts on this blog.

From Agile Australia 2011
  • in the software world we deal with known unknowns
  • spikes are your friends, purely informational gathering
  • ckjm – tool for reporting complexity and coupling
  • don’t pay for technical debt that you may never justify

Key Metrics for an Agile Organisation

It was my pleasure to introduce Craig Langenfeld from Rally Software to deliver this presentation (originally scheduled to be presented by Mark Ortega). The slides are available here.

From Agile Australia 2011
  • cumulative flow – look at the top of the line to see what is the scope and how has it changed (total features), then ask if the team limits their work in progress by looking at the time between the boundary of in progress swim lanes, finally look at the lead times and how long it will take to deliver a feature
  • work in progress limits allow the team to move through work more effectively
  • lead and cycle time report – allows you to see where your bottlenecks are
  • stop focussing on the workers and focus on the work product – so rather than lines of code look at the the value delivered
  • productivity – understand your teams velocity, throughout mapping stories that were completed and carried over
  • earned value – useful to measure how much value we are delivering (the difference in agile is we are actually delivering the value)
  • predictability – answering the question of when we will be done – throughput chart can show you if a team is getting more predictable over time, burn up is used to show predictability of meeting scope, release burndown to show meeting a date and demonstrate additional scope being added
  • use cumulative flow to track the cone of uncertainty
  • quality – defect trends and counts, most code altered, number of changes, etc…
  • net promoter score for tracking customer satisfaction and if it is increasing
  • get customers to vote on what aspects of the product they like and don’t like
  • for cloud computing track the features that are actually used

Leading by Serving

Simon Bristow delivered this presentation, his slides are available here.

From Agile Australia 2011
  • a perfect team is one that can do anything, in control, do anything thrown at them
  • lots of teams act in an agile manner, the leader makes the difference
  • Robert Greenleaf – The Servant As Leader – others highest priority needs are being served first
  • bridge the gap – gaps when making a decision which is the unknowns, bridges the gap to the future by seeing the unseeable
  • one action at a time
  • forcing a decision on someone will engender resistance, some you must persuade – need to listen to connect at the grass roots level
  • withdraw and acceptance – step back from the team to allow them to look after themselves and accept that the team know best as they are the subject matter experts and will get the job done
  • facilitate community – need to build
  • lead using art not science – if you turn to science in agile you will turn to process

Soldering Irons, Consumer Devices and Hardware Manufacturing in the world of Agile Software

Dean Netherton and Neil Brydon for DiUS delivered this talk which was one of the highlights of the conference for me. The slides are available here.

From Agile Australia 2011
  • DiUS working on a fire danger smart meter and technology for charging electric cars
  • how do you demonstrate value when haven’t built the device?
  • had to work around the vendor for the smart meter because they had a traditional process for building the device – aligned project plans around hardware drops and had to simulate the hardware in many cases
  • used wireframes to drive design but had to spend longer on design to ensure it was right – for example, can’t add a bigger battery later
  • first drop was an off the shelf component board to kick start the software
  • second drop was a bare board that was the basic board without the LCD
  • third drop was the plastics without the screen as the component had not arrived so replaced with paper
  • challenge on how to articulate stories – had to break stories own technically
  • used Cucumber to test as there was an embedded USB port on the board – helped embedded engineers assist the Ruby engineers understand how the device worked
  • did continuous integration by plugging a device into the build server, had an issue about flashing the device when the code changes
  • hardware engineers slightly change the design with each revision which had affects on software design as well as having hardware for continuous integration
  • built own hardware prototypes and used local suppliers to cut down lead times (China cheaper but added 6-7 weeks to the lead time)
  • used mocking to show users the idea ahead of hardware being available
  • planned for multiple hardware revisions to allow for late decisions
  • these days you can send a 3D model to a design house and they can pop out a prototype, design exercise ensures that screws line up, etc
  • no excuses for automated testing, in the past it was not embraced in hardware, can test the integration layer without the need for hardware
  • no benefit in running tests for the hardware design as you only get a handful of drops
  • use automated test to ensure buttons and light work, good when you get new hardware and good for checking faults on the production line
  • had to learn about the hardware stack early on which challenged whether value was being added
  • firmware development not integrated onto the story wall
  • technical tasks are OK but really understand what done is
  • luckily the stakeholders were quite technical

Putting It All Together – Agile Transformation and Development Tooling

Philip Chan from IBM delivered this presentation, his slides are available here. I failed to see a lot of agile in this talk personally.

  • established teams – communication difficult across timezones but tools make it easy, different tools used in different teams,
  • IBM agile process – 2 week iterations, 2 day inter sprint break every 4 weeks, develop for first 6 days followed by 2.5 days for bug fixing, do acceptance testing for first 6 days and 2.5 days of exploratory testing, showcase on day 9
  • test management very waterfall for audit purposes
  • using automated tests and continuous integration to assist global team optimise processes

Panel – Continuous Delivery

Evan Bottcher, Neal Ford and Martin Fowler from ThoughtWorks were on this panel.

From Agile Australia 2011
  • continuous integration – everyone in the team integrates with the mainline at least once a day
  • continuous delivery is taking the same approach as continuous integration and apply it to the last mile – decision to deploy should be business only with no technical barriers
  • continuous deployment is continually delivering on a regular basis – continuous delivery enables this if you want it
  • rare to find a company that is pulling in the same direction, so you need to automate in pockets and add manual checkpoints and then you can look for ways to automate them
  • risks – need to bring pain forward, which was the tenet of XP, not doing it is much more risky, there is pain and effort to setup, you need to look for a leverage point in your production systems to justify
  • if you do something rarely you don’t get practice, by doing it more often you improve which actually results in a process that is more auditable and gives you more confidence
  • is a good approach to shorten feedback loops, also allows you to give confidence to the business on delivery timelines
  • packaged software makes continuous delivery hard, important to look at the automation of the configuration as well as automated tests, looking for fast feedback to give confidence in delivery
  • need to push software vendors to make things more deliverable (this was a rant by Martin Fowler, that I tend to agree with)
  • make database changes with the same fundamentals – break them down into small changes and combine schema changes with the data migration and string them together into a package, tools have got more specific like dbdeploy and Liquibase support this and Ruby on Rails just supports this out of the box
  • DBA’s are the final frontier because they like to fiddle with scripts, need to bring them in or deal with smaller changes
  • testers tied to manual processing – need to separate the low and high value testing work, fear that they will be replaced by a small shell script, will make their job vastly easier, need to get buy in by demonstration
  • difficulty is always the human element – testers are moved from the backend to the front end of the process, specification by example at the front now, need to look at incentives and make them common between developers and testers
  • key is a business decision of when to delay so you can deal with business change, training, etc…
  • people are now used to the fact that websites or apps on their phones are continuously changing
  • gives the option to deploy to different types of users when they need it
  • Go was built with continuous delivery in mind, version control systems are critical because everything needs to be in there, automated testing tools are also critical, continuous integration servers can help if they have an extra build pipelines
  • Puppet and Chef both allow you to script your environments
  • need to place people in teams who believe things are possible

Other Stuff

At the end of a very long day, it was good to network with attendees at the ThoughtWorks open office.

Also, I have to send congratulations to my colleague Adrian Smith from Ennova on his talk Agile for Startups which I hear was very well received (I have attended previous incarnations of this talk).

Continuous Integration

Earlier in the year, I gave an internal videocast to my colleagues in IT on continuous integration. I finally got around to posting it online and the presentation is now available on Slideshare.

Agile 2009 Day 2 Review

Agile 2009Day 2 of Agile 2009, and Johanna Rothman welcomed everybody to the conference and advised that they had 1,350 participants this year from 38 countries. Furthermore, they had 1,300 submissions that they brought down to 300 presentations.

The sessions I attended on Day 2 were as follows:

Keynote: I Come To Bury Agile, Not To Praise It

Alistair Cockburn kicked off his keynote with live bagpipes, you can view the session or download the slides.

Agile 2009 Keynote Alistair Cockburn

  • software development is a competitive game – positions, moves, strategies
  • conflicting subgoals – deliver software, setup for next game (refactor, document) – moves are invent, decide, communicate
  • situations almost never repeat
  • as number of people double, communications change fundamentally (crystal clear project classification scale)
  • Jeff Patton suggests to video the whiteboard design, rich, 5-7 minutes sweet spot
  • always trying to simulate two people at a whiteboard
  • distance expensive – 12k per year penalty
  • speed – can people detect issues, people care to fix it, can they effectively pass information
  • craft teaches us to pay attention to skills and medium (language)
  • programming changes every 5 years, need to keep up with cycle
  • learn skills in 3 stages – shu (learn a technique, most people learn by copying, one shu does not fit all!, kick people out of shunning box), ha (collect techniques, look for clues) and ri (invent / blend techniques, help guide with ri level responses)
  • everybody is waiting on a decision, looks like a manufacturing queue
  • continuous flow, small batches of work
  • lean – watch queues, not enough resources
  • you want knowledge to run ahead of cost – start of project grow knowledge and reduce risk then business value, need to balance
  • at end of project, trim tail to deliver or delay to get better
  • Tom DeMarco – Slack (agile organization)
  • don’t like end of project retrospectives, too late, inside the project you can change anything, after delivery, 2 weeks can be too often because nothing has changed

Release Planning (The Small Card Game)

I had been recommended by numerous people to get along to this tutorial being run by Chet Hendrickson and Ron Jeffries (one of the original XP’ers and both authors of the purple Extreme Programming Installed) and I wasn’t disappointed.

Agile 2009 Release Planning Game

The session ran sort of like this:

  • we ask the product ogres to put information onto cards
  • this is an important project – managers in clouds who have managers in clouds have stated it must be done in six months
  • sort cards into 6 columns, need all 45 cards done in six months
  • Round 1 – plan out the project for 6 months) – our team just put 6 columns and layed the cards out evenly (8, 8, 8, 7, 7, 7), some teams went a little light at the beginning and end, another team decided to do everything in 4 months, another team everything in 1 month!
  • Round 2-  nature (Chet) said we got 5 out of 8 cards done , so replan the next 5 months (this number was different for different tables). We asked if all stories were of equal effort, but nature did not know
  • Round 3 – nature said we got 6 cards done, so, now, how long will the project take? What if you were told that the number on the upper right hand corner is effort and you can get 10 done per month (we had a total of 90)
  • At this point, some teams put small stories at the end of each iteration and put more valuable stories at the beginning (customer value, we were told, was the number in the lower left)
  • Round 4 – now we need to decide which month to ship (we chose two months)
  • Round 5 – given we now know the value, we were told not to replan, take total and how on a burnup chart to see burn
  • Round 6 – replan using cost and value (we did some maths and got 6:1. 4:1 and 3.5:1, maximum value in column 1 was 75, then 45 and then 30)
  • the team that ships every month gets the same value sooner
  • fewer products cannot meet this than you realise
  • how long will it take us and how much is it worth are the fundamentals
  • value is simple if you use simple values (we used 3, 6, 9)
  • dependencies are far less common than we believe

Facilitation Patterns & Antipatterns

This was a workshop led by Steven “Doc” List from ThoughtWorks and involved some great playing cards that I am still hoping may get sent my way one day.

UPDATE 13/10/2009: About 12 hours after posting this, a deck of cards arrived in the post at work. Many thanks Steven and ThoughtWorks for keeping your promise and sending the cards through!

  • facilitation about leading the group not running the group
  • want to enable decisions
  • leave bias, prejudice, opinions at the door, otherwise get somebody else to do it
  • meetings should be collaborative and enjoyable, but must have an agenda

Patterns (these are behaviours not identities)

  • Switzerland – neutrality, whether facilitator or participant need to decide if you are being neutral, a participant that is neutral not adding value, good value as a facilitator
  • Guide – show the way, avoid potholes and pitfalls, help move through the process by the way I interact with the group and help the group interact
  • Curious George – always aks questions for no particular purpose
  • Sherlock Holmes – seeking data and information to reach a conclusion, passion for information
  • Benevolent Dictator – always for own good, but always taking control, believe have more experience than the rest of team, always believe they know best but with a good heart (like relatives)
  • Repititor – more he tells you, the more likely you will get it
  • Professor Moriarty (the evil genius) – manipulating other people to do work for him, cooerce other people to ask questions, manipulation
  • Gladiator – all about combat, being right is more important than what they are right about, enjoy getting into an argument, always one on one so rest of group usually disengages, loud, active, don’t give up easily
  • Superhero – here to rescue rather than how to do things, bring special skills, knowledge and powers so you obviously want to use them, will always standup or represent you whether you need them to do that or not
  • Orator – champion of not being done, wants to be heard all of the time
  • Conclusion Jumper – smart, mean well, want to move on quicker, jump to what they believe is the conclusion

How to deal with these behaviours, do the facilitation four step

  1. Interrupt – what is relevant to controlling the group
  2. Ask – “Make it a question, do you mind if I ask Charlene…”
  3. Redirect – redirect the conversation
  4. Commit – live up to the commitment
  • ground rules – work agreements, how we choose to behave, usually get 5 or 6 when you ask the group, put them on a wall, need group to be self managing, don’t want to be a policeman, unless you have to
  • starfish – keep doing, start doing, stop doing, do more of, do less of – look for idea clusters, useful anytime not just retrospectives, useful because there is no room for many roles because people are writing things down
  • circle of questions – around in a circle, ask question to person next to you, usually have to cut it as it will keep going, eliminates dominination as everybody gets to ask and answer, pre-emptive or remedial
  • margolis wheel – circle of chairs outward and outside circle inwards. Inside are answers. Each person gets input from 6 people and ask 6 people, can be lengthy
  • parking lot – facilitator does not own it (can’t determine what goes in or out), should ask “should we park this”, must be dealt with before the end of the meeting (see Collaboration Explained – Jean Tabaka)

For more information:

Finally, from some of the questions at the end:

  • remote faciliation is harder, Jean Tabaka has a virtual seating chart, 4 step always works
  • antipattern – people expect the boss to run a meeting, but they always have an opinion or axe to grind

I also found the following blog post on this session: http://www.selfishprogramming.com/2009/08/31/agile-2009-facilitation-patterns-and-antipatterns/

Can You Hear Me Now… Good!

This session was on ways to deal with distributed project teams and was delivered by Mark Rickmeier.

One problem on distributed projects – communication breakdown

  • developers assume requirements
  • testers assume
  • sloppy handoffs
  • waste
  • people working on wrong things or different things
  • management decide on incorrect data
  • breakdown in relationships (people on team make it successful)

Agile processes can solve these issues – distributed requires more effort but agile team and communication processes mitigate the risks

How to organise teams

  • dysfunctional when skills are together in different locations
  • functioning slightly better – developers and testers together and customers and analysts together
  • most effective – cross fucntional teams in both locations (expensive and difficult to do)

Five p’s of communication

  • purpose – dialogue vs discussion – what is purpose of discussion – ideas or to make a decision
  • preparation – plan ahead, agree core hours and don’t schedule outside of that without warning, understand key dates
  • process – have im fallback options because phone systems fail, announce roll call so you know who is on the other end of the phone
  • participation – know, see, hear your audience, interact and share the same data
  • capture next steps, send reminder to ensure agreements are met (cultural wording can cause problems)


  • IM – extremely useful
  • star phone for speakerphone
  • video conference – two camera, one on audience and one on whiteboard
  • web conferencing multi-view
  • interactive whiteboard – skype to take control in blank powerpoint page

All tools improve communication

Distributed release planning – don’t do it distributed, try and get at least a subset of team together

  • share vision from stakeholders and build trust in the release plan
  • get people together to share context and get to know everybody
  • the challenge is that it is expensive to get people to travel – always do at the outset if that is all you can afford

Iteration planning  – planning poker distributed? – planningpoker.com

Sign up for iteration as a team, use online tool like Mingle to update card statues prior to standup

Daily standup – local participant can see reactions of people and can see the card wall

  • have a local team standup and distributed cross team huddles with end of day handoff
  • distribute team standup, cross team huddle and end of day huddle
  • distributed daily standup – use camera, remember that it is about issue identification not remediation
  • challenge that overlap times are not good, beware of the personal cost of people
  • information from standup feeds the entire team


  • hard, can have many us vs them issues
  • worst thing you can do is one location or nothing at all
  • individual retrospectives better if ideas are shared
  • best is collaborative using CardMeeting or Google Spreadsheet – multiple tabs for likely topics, use tagcloud to capture popular topics in Google Docs, get people to write cards ahead of time to save valuable time

Closing thoughts

  • look at staffing
  • get good communications infrastructure
  • kick off team in one location
  • get to know people to move them from them to us

More details can be found at offshore.thoughtworks.com

ThoughtWorks Open Office

My original plan for Tuesday night was to attend that Chicago Groovy User Group with Paul King (but I mixed up the times and did not catch Paul in the corridors), so I decided to get along to the ThoughtWorks open office instead (at their offices on the 25th floor of the Aon Center, the third tallest skyscraper in Chicago).

Agile 2009 Thoughtworks Open Office

Martin Fowler and Jim Highsmith both spoke, and the Agile PMI community was launched. I got to marvel at the original Cruise Control instance that was still running after all of these years and some great conversation was had with the rest of the Australian (and ex-patriot Australian) attendees.

Wrap up from CITCON Brisbane

CITCONI attended the CITCON (Continuous Integration and Testing Conference) in Brisbane last weekend and had an awesome time discussing a range of topics with the most passionate in this field.

Deep in CITCON discussion

Deep in CITCON discussion

I have added my notes to the conference wiki,but my takeaways from the sessions I attended are:

Elements of Enterprise Continuous Integration

Jeff Frederick led a discussion based around the Elements of Continuous Integration maturity model:

  • for teams that are already doing continuous intgration, it gives you a target to obtain
  • is obnoxious after insane (where to for teams that are already at the top level)?
  • tooling makes continuous integration trivial now (when Cruise Control was released many people thought it crazy that you might build on every release, not its a given)
  • the model was developed because people assume what is possible is based around their personal experiences
  • the model shows the industry norms and targets, and if your team is not at these levels you are behind the curve

The discussion branched out around the following ideas:

  • scrum does not prescribe continuous integration, but continuous integration is a good development technique
  • that it should be acknowledged that there is a difference between project builds and full product builds (which can take days)
  • I raised the idea that perhaps there should be an element around team principles, and that things like performance (and more importantly, the team realisation that performance should be monitored and improved) should be an indicator to maturity (there was much debate about this!)
  • a number of industries potentially have their continuous integration processes audited, such as defence, gaming  and financial organisations that have Sarbanes-Oxley requirements
  • it was acknowledged that most large organisations have teams at different levels on the maturity scale (this is certainly my experience)
  • dynamic languages and don’t really build or deploy. This then raised discussion that dynamic languages are not compiling as opposed to not building, and that in many cases one man consultants can manage their deployment process in a much more lightweight manner
  • parallel to CMMI, is there a payoff to getting to insane?
  • maturity is often determined when we move from dropping code to testers versus testing the development build (where testers are writing the code while the code is being developed)
  • where is the line that determines that the build is complete? It should be the entire team, not just the developers or the QA team
  • the QA team is traditionally where much of the auditing happens, therefore many testers are reluctant to change as they have built up processes to deal with audits over a number of years

For the record, the cutting-edge agile teams I have worked with over the last few years were at the following levels:

  • Building (Intermediate)
  • Deploying (Intermediate)
  • Testing (Insane)
  • Reporting (Intermediate)

We still have work to do!

Virtualisation & CI

I used the “law of two feet” during this session, but was interested to hear that many people are using virtualisation very effectively in their test labs, and that it makes getting environments and data ready for testing much easier.

Long Build Times

The discussion was well-established by the time I got to this session, but some of the key points for me from the discussion were:

  • question as to when static analysis checks should be run in the build – the consensus that running them first means you get the quickest feedback
  • longer builds should be run nightly so as not to hold up developers
  • prioritising build queues or using different machines sounds like a good idea, but nobody is doing it
  • you can reuse functional tests for performance tests, but targeting specific tests seems to work better
  • Atlassian use JMeter for performance tests and have a variety of Maven and Ant builds, but use Maven for managing repositories
  • Ant is still well regarded, Idea support is awesome, many people do not understand the power of custom ant tasks or the ant idoms
  • the build should be regarded as part of your code
  • discussion about using a Java build tool, such as Hammer and why we can’t articulate why it seems wrong
  • not enough people understand Maven, usually there is “one guy” on the team
  • Vizant is a good tool to graph the build
  • EasyAnt combines all of the Ant idioms plus Ivy

Is Scrum Evil?

Jeff Frederick led a discussion that he is led at previous CITCON’s around the world

The team first debated why Scrum is Evil. During this discussion I really thought the whole agile movement was done for. Jeff asked the group to finish the sentence Scrum Is Evil because…:

  • it becomes an excuse
  • that’s not Scrum
  • tested as a silver bullet
  • hides poor personal estimation
  • master as dictator, project manager
  • two days to agile master certification
  • daily standup equals agile
  • agile by the numbers
  • is dessert first
  • you lose the baby with the bathwater
  • Scrum teams don’y play well with others including customers
  • it has certification
  • is the new RUP

Jeff then proposed a way to think about Scrum adoption as outlined in Geoffrey Moore’s “Crossing The Chasm”. The early adopters had success while the early majority are putting their faith in training everybody as Certified Scrum Masters (a problem that appears to be a far greater issue in Europe than Australia).

Then, just as though all hope had gone, Jeff asked the group to finish the sentence Scrum is Good beacuse…:

  • people can get it
  • an easy introduction
  • a good starting point
  • it is better than a cowboy shop
  • people can actually follow it
  • improves visibility
  • blockers are highlighted
  • testers can start work early
  • provides a forum for communication
  • can engage customers in a much richer way
  • states there should be a facilitator
  • results focussed
  • makes everybody responsible for end result
  • better communication from end result

The key outcome by the group was “Scrum is not evil… people are evil”

This was a great way of trying to tease out the issues and advantages to using an agile process and one that we may be able to use in the enterprise with teams who have been on training but appear to be resistant to change.

Seeding Test Data

A good discussion about ways to seed test data

  • Erik Petersen introduced the group to GenerateData.com, a free site that generates real adddresses and data based on factors a random amount of times that you can then inject into SQL – the site looks awesome!
  • others in the group mentioned LiquiBase that can be used to version the database, is designed for database management but can be used to seed data
  • Unitils is used to setup data scripts
  • one suggestion was to build a reset database function into the system
  • HSQL (Hypersonic) is a good way to create databases from Hibernate, in memory

The discussion got a little more generic and talked about:

  • Roo, a java Grails-like platform
  • WebObjects by Apple is a lot better than it used to be

Extending CI Past Traditional Dev & Release Process

I led this discussion, and whilst it focussed mainly on different usages that I have been involved with (with assistance from Paul O’Keeffe and Paul King), we also had a good discussion about Tableaux and the build process at Atlassian.


A great open conference attended by people passionate enough to give up their Saturday to talk about continuous integration and testing.