- Job Vacancy: Senior PM at Foolproof
- Job Vacancy: Programme Manager at Foolproof
- Job Vacancy: Senior Designer at Foolproof
- Job Vacancy: Account Manager at Foolproof
- Job Vacancy: Software Engineer in Test at Axon Vibe
- Job Vacancy- EIRA Knowledge Exchange Fellow – EIRA Network (3 Posts)
- Job Vacancy- EIRA Knowledge Exchange Manager (Three Year Fixed Term Contract)
- Job Vacancy- Front end developer at Zipline
- Job Vacancy- Data Architect at Axom Vibe
- Job Vacancy- Digital Marketing Manager
A look inside Agile Cambridge conference, 27th-29th September 2017
What is Agile Cambridge?
Agile Cambridge is “England’s premiere hands-on Agile software development conference, set in picturesque Cambridge. The conference has a strong practical focus and attracts industry practitioners and decision-makers who want to improve their success with agile and lean methods. The event provides three days of inspiring agile and lean learning from a dynamic mix of stimulating keynotes and practitioners working on the front line of the industry.”
Why did I go?
Well, initially it was because Paul asked me to, as Naked Element is wholly based on agile methodology and as a relatively new member of the company it was a way for me to be completely absorbed in agile for a few days. When I looked at the program of speakers and started engaging with the attendees on social media, I started to understand the importance of the event, with international speakers and delegates travelling from the US, Norway and France to attend.
What did I learn?
The answer to that question is many things!
One of the first things that struck a cord with me was The 3 C’s to consider when looking to outsource software development. I liked this one as I thought Naked Element would score pretty highly. The 3 C’s are:
Cost – Take into account management overheads, the cost of visits and hosting fees, as well as the cost of the software development itself.
Naked Element visits clients initially so that they don’t have to travel. We project manage the development and break work down into iterations (usually two weeks). We plan an iteration with the client, mostly on Skype or another online platform, and review at the end to gather feedback. Working on software in small chunks means there isn’t a massive testing and training overhead at the end of the project and we have learnt very quickly at the start of the project what the client likes and dislikes. Working in iterations also means invoicing is broken down into small chunks too.
Culture – This includes the language the third party uses, their problem solving skills and open communications. But also, do they have the right tools to do the job and are the management committed to training?
We believe that working with us should be a transparent, jargon-free and enjoyable experience. We run our User Story Workshops to capture software requirements and what really matters, then record it in a way that both our clients and our developers can understand. Alongside development, we support our developers with training and expanding their knowledge, working in pairs on projects to knowledge share and work together to solve problems. Every project can be a learning opportunity too.
Capability – Have the third party got the right development skills for your particular job? And for a potential long term engagement? Do your visions for the future align?
Naked Element have the skills to develop websites, mobile applications, software and enterprise software applications. The specialist skills that we have means we are particularly prepared for solving complex development needs, like handling lots of data with dependencies, creating systems incorporating multiple workflows and managing processes for multiple types of internal and external user. And our can-do attitude aligns well with innovative companies looking for an edge.
And then some real discussion on Agile. Over the last few months I have networked with software development companies and in-house developers that would love to work in an agile way but, due to management or legacy systems, are unable to. Conference discussions looked at how to change from a traditional software development approach, to an agile one. “Every agile adoption is pointless if there is not a corresponding shift in the organisation’s mindset”. This came through strongly from several presentations. Companies like the idea of agile working, but don’t commit fully because it’s a big change that requires investment in time.
Following on from this, the theory of The J curve was introduced. As you embark on a period of change, expect results to decrease before they increase and bring the return on investment that you hoped for. This is because there is an initial learning and adaptation phase, which will slow the process down before it brings benefits. Have the end goal in sight and plan for the downward trend before you embark on the change. It’s less stressful for all involved. This could apply to any change within an organisation.
And finally, part of any software development project is estimating time for a piece of work. Some people are good at this and others not so much. Introducing a probability score into the estimating allows internal teams to better understand where the risks are, and investigate in order to minimise it.
So, all in all, Agile is about more than just a way to develop software. It is about who we are as people and how we interact with each other, our behaviours, our environment and leadership. It’s about finding new ways of working together, tearing up the rule book and creating new structures that work for our people.
Agile Cambridge, I will be back!
Words by Emma Gooderham
Originally posted on Naked Element