Aconex is a software development company. We build our own products and we demand passion from our people, how come they're not in the office on Saturday (or Sunday) killing themselves on the next release? Don't they care? What are we doing wrong?
As both a tester at Aconex and a member of the Test Engineering Alliance of Melbourne (TEAM), I was extremely proud to see Aconex partner up with TEAM in order to bring to life the inaugural Australian Testing Days conference. The TEAM group was founded less than 12 months ago and has been holding regular meetups and workshops in order to bring knowledge and networking together with pizza and fun.
I write automated software tests for a living. My job involves programming but I don't develop software, I write programs to automate processes in web apps. I have been using Java for web automation for the last five years and I currently use Ruby for the same purpose.
I recently attended RubyConf India 2016 at Kochin, Kerala. Sadly, there was negligible participation from the QA community in this conference. And it left me asking myself a very important question:
Aconex Engineering values team autonomy and independence in order to ensure we continually deliver quality software to our customers. We place a big emphasis on agility, adaptability and teams having full responsibility for their work.
Aconex, the product, helps numerous stakeholders collaborate together on real-world projects ranging from airports, dams and bridges to roads and commercial office towers. Given that our software focuses on collaboration, it’s worth taking a look at how we, the engineers at Aconex, collaborate on building our software projects.
The Heart of Agile is about simplifying our thinking and focus.
Alistair Cockburn, Agile Manifesto co-author, presented his Heart of Agile presentation to some of the team at Aconex headquarters in Melbourne. He reflected on what’s really important within the principles of agility and what we should be thinking about when we seek improved product and business outcomes.
I am writing this description in response to Mike Cohn's description of a Product Owner. Mike's description isn't wrong, but it is almost ten years old and could maybe do with a refresh.
I'll qualify my take on this by saying that there are actually many incarnations of the role, and my view is locking things down to one model is useful for recruiters and beginners, but should quickly fall away in deference to the context and strengths of the people in play on any particular team.