April 08
7 ideas to help you successfully adopt Agile in your New Zealand software development team
Are your software development teams using Agile in name only and finding it difficult to make it work in reality?

Having spent 4 years helping our own teams adopt and evolve Agile software development approaches I can tell you that Agile adoption is hard. But with perseverance it is also incredibly rewarding.

Many New Zealand teams underestimate the difficulty of adopting Agile software development approaches. Unfortunately some of these teams give up as they hit hurdles and revert back to what they know. As such, Agile does not always have a great track record in New Zealand, despite the very real benefits that high performing Agile teams can deliver to your organisation.

In this post I share some ideas based on what has worked for me in the role of Software Development Director as we have adopted and continuously evolved our use of Agile at Equinox IT.

1: Adopt using a small-cycle incremental approach
It seems ironic, but our observation is that many New Zealand teams use a waterfall approach to adopt Agile. Given Agile adoption is hard, it is highly unlikely that Agile will work as intended first time, unless there is a good history of assimilating change in your organisation. Instead adopt Agile incrementally; starting small and then learning, evolving and continuously improving through each cycle.

2: Work within your organisational context
We are supporters of Agile software development approaches such as Scrum. But we have also found that any given best practice approach may not apply to your organisation’s unique context. At Equinox IT, we have continued to evolve our approach to software development, incorporating elements of Scrum, Lean, Kanban and Design Thinking as our understanding of our context has emerged. Your organisation will be the same. Don’t blindly follow best practice, but use what works the best, based on your experience of applying different approaches in your organisational context. In other words, solve your own problems.

3: Never give up in the face of resistance and chaos
You will face resistance and chaos as you adopt Agile. Resistance to change is human nature, so expect it. According to the Satir change model, from resistance performance will descend into chaos – even for the most well assimilated change. While this is difficult and uncomfortable, understand that it is a necessary part of any change and that past behaviours may no longer work in the changed context.

When in chaos, look for a transforming idea that your people can align with to help pull them out of the chaos. In our case at Equinox IT, it was the concept of ‘sustainable pace’ - the view that Agile adoption might ensure ‘normal’ working hours rather than the enormous hours that some project teams in our industry work, driven by immense pressure to deliver.

Once through the chaos your team can then optimise and move towards a new status quo that delivers higher performance to your organisation.

Satir change model provides useful insight for New Zealand agile adoption

4: Change your environment
According to Lewin’s heuristic ‘behaviour is a function of people and their environment’. Often it is easier to change the environment than your people. Moving your teams into collaborative work spaces may help facilitate the adoption of Agile. Alternatively, dropping an existing high performing Agile team into your environment, who your team can work with, will likely fast track your team’s successful adoption.

5: Manage business expectations
In a recent Equinox IT webinar, participants indicated that the biggest issue they face with Agile projects is business fatigue. Successful Agile teams require high involvement from the business throughout the duration of the project. Delivering the results the business needs relies on this involvement and the business needs to understand their important contribution and needs to commit to being available.

We’ve found that intentionally designing and iterating how you conduct your project’s interactions with your business, such as reviews, can yield a much greater degree of ongoing participation. Start with empathy and iterate from there.

6: Be deliberate with your structures and roles
Ideally an Agile team is structured as cross-functional (all the skills you need to deliver the project) and self-organising (the team has the ability and authority to make decisions). How closely you are to this ‘ideal’ will depend on your organisational context. Our research shows that many New Zealand software development teams are still structured in functional groups and most project tasks are assigned by a manager role rather than the team self-organising these.

Be aware of what structure works within your organisation and the roles that are required for each structure. If your team is functional and managed, then you will need a management role that makes decisions and allocates work. As you transition to cross-functional and self-organising teams then you will need different leadership roles such as a coach and ultimately a facilitator. Bear in mind that in certain unexpected circumstances, such as a crisis, your self-organising team may not perform well, and in these instances a manager will need to step in and manage until the crisis has passed. Obviously the focus at this time would be to spend the least amount of time in crisis mode and return to self-organisation quickly.

7: Keep your performing teams together
The Dreyfus model of skill acquisition shows that people start off as novices and incrementally get better, ultimately becoming experts after many years refining their specific skills. The first time your team undertakes an Agile approach together, they will collectively be novices with regards to their interactions with other team members and how an Agile approach best applies in that context. Novices are not high performing, so avoid judging the success of your Agile adoption on the first few attempts.

Once your team does start to perform, do your best to keep the team together. Your team’s skill at interacting with their teammates in an Agile context matures through usage and the continuity allows you to build ‘expert’ Agile software development teams over time.

New Zealand software development teams often give insufficient time and attention to the process of adopting Agile. We see many teams that are positioned as being Agile but in reality are not achieving the real benefits that high performing Agile teams deliver. Adopting Agile is a serious change management process as shown in the 7 ideas presented in this post. Hopefully these ideas will assist you in making Agile more successful in your organisation.

Watch the recorded webinar 'How Agile teams succeed'

March 20
Get the benefit of agile requirements practices on any project
Want to improve your project results without boiling the ocean?

At Equinox IT we are not zealots for any one particular software development methodology. Instead we take a very pragmatic approach, using various agile, lean and design thinking practices that work for us, and we continuously evolve these based on what we learn through each iteration.

Start small, start today

What we have found is that there are a number of agile and lean practices that you can use of any type of project. You don’t need to become an agile evangelist, undertake a significant change initiative and get management buy-in to start making improvements to your current projects. You can simply start today by trying a practice or two that you think will help you to achieve better results. We refer to this as agile with a little ‘a’ – the pragmatic use of agile practices where it makes sense to do so.

ATDD is not as scary as it sounds

One practice that we are particularly fond of is Acceptance Test Driven Development (ATDD), which is also known as ‘specification by example’ or ‘example-driven development’. The name often throws people off, thinking it is intended for developers or technical testers. This is misleading, as the real benefit of ATDD is in minimising the likelihood of misinterpretation and ambiguous business requirements, thereby helping the project deliver more successfully to business need. As such, this practice is highly relevant for business and systems analysts and anyone else involved in software project requirements. While ATDD is an agile practice, we believe that this practice can provide benefit for any type of project.

How your project will benefit from ATDD

With traditional requirements activities, a requirements document and specifications are written and then from this the test scripts and software code are prepared. What we find is that the requirements may not always reflect the business need. Also testers and developers may interpret the requirements in different ways as they undertake their steps. This can result in a software solution that is not matched to what is being testing, not matched to the original requirements and not matched to what the business needs.

Using ATDD a different approach would be used. As an analyst you would write the requirements in the form of an acceptance test. This leaves much less room for ambiguity between the business representative, analyst, developer and tester (who on our projects is the same person as the analyst). Each scenario is documented as an example stating the pre-conditions, action and expected result. A structured yet business readable language is used. At Equinox IT we use the language Gherkin, using the structure ‘given-when-then’ to describe the pre-conditions, action and result.

So using ATDD, an example Gherkin script could read like this:
Example ATDD Gherkin script for agile requirements
While, this is example is for a calculation, ATDD can also be applied to non-calculation requirements. The structured human language script can be validated with business representatives. It then forms both the documentation of requirements and test specifications. Testing of these scripts can be automated and used to confirm that the software works as expected. Ultimately, we find that the software solution delivered is much more consistent with the business need when compared to traditional software project requirements approaches.

Then continuously improve

Whatever type of project you are working on we encourage you to give ATDD a go to help deliver working software that meets the business need. As you get better at this you may find other agile, lean or design thinking practices that can help you continuously improve your project results. If you would like any advice on this, please get in touch.

View our free recorded webinar 'Managing requirements when agile is mainstream'

March 20
Webinar invite: How Agile teams succeed - 27 March 2014
Deane Sloan, Equinox IT Software Development Director, How Agile Teams Succeed12pm NZDT, Thurs 27 March 2014

The 2013 Scrum Alliance research on The State of Scrum concluded that Scrum is easy to understand in concept, but hard to make work in practice. This supports our own views from providing advice and delivering training to many Agile teams. A lot of people have picked up their ScrumMaster certification or attended other Agile training. Many projects refer to themselves as delivering using Agile or Scrum-based approaches. However, many Agile teams are not delivering the full business benefits from their projects.

In this free webinar, Equinox IT Software Development Director Deane Sloan will discuss some of the common issues that constrain the success of many Agile software development projects. He will then give insight into how Agile teams can be developed to succeed, based on Equinox IT's own experience of adopting and succeeding with Agile, Lean and Design Thinking approaches to software development.

Register for this webinar

March 06
The 5 key challenges to using cloud computing
In 2013 over US$130 billion was spent on cloud services. Cloud is fast becoming the preferred method for IT service delivery for many organisations.

Cloud services have many benefits, but like any serious IT initiative you need to follow a disciplined approach to cover off the risks and challenges with these complex technologies.

The 5 key challenges to using cloud servicesThis post explores the 5 key challenges we believe you need to be considering when you are exploring any type of cloud service, including platform as a service, infrastructure as a service and software as a service. These challenges exist for nearly every organisation considering cloud as part of their overall IT services portfolio.

Procurement challenges
Procuring IT services traditionally involves one-off purchases of expensive hardware or software with additional support and maintenance costs. Cloud service models allow you to avoid these up-front costs, but instead you will pay a recurring and often variable service charge. Your organisations financial processes and funding arrangements need to capable of supporting this model, which often involves a move of funds from CapEx to OpEx.

The traditional process of issuing RFPs and selecting providers that match detailed requirements is also a poor fit for the cloud. Consumers of cloud services have limited control over the functions of the service and desirable service providers do not always respond to RFPs, especially in smaller markets like New Zealand.

Delivery challenges
Typically a software development lifecycle (SDLC) starts with a detailed requirements gathering phase, followed by solution architecture and design. The solution is then built and tested, and finally delivered into production where it is operated and maintained. Since many types of cloud services, such as Software as a Service, are already pre-built, the classic SDLC approach may not be suitable. Adhering to this approach for cloud may add unnecessary overhead and delay to service delivery. In addition, some providers will not disclose the information about their service necessary to complete typical artefacts like a Software Architecture Document.

Service agreement challenges
The service agreement defines the commercial and operational relationship between the cloud service provider and the consumer. Omitting key criteria from an agreement exposes the consumer to a range of risks including information security incidents and the loss of ownership of their own data. The ability to negotiate individual terms is often limited, especially with larger offshore providers who rely on pre-canned service agreements.

Risk challenges
One of the most important, yet poorly understood aspects of cloud services is the identification of risks and the ability to management these in the cloud. Like any technology, cloud offerings expose an organisation to a range of potential risks. While most of these risks exist within on-premise solutions, the exposure of data to untrusted networks (the internet) tends to increase the likelihood and impact of these risks. All cloud services have risks associated with them. Many, such as storing data outside the organisation boundary, will be common across nearly all cloud services, while others will be specific to a particular client or service offering.

Integration challenges
Feedback from Equinox IT’s own polls show that integration is the biggest challenge that organisations in New Zealand are facing as they increasingly use cloud services. The ability to share data between cloud services and on-premise applications is becoming increasingly important as cloud services rise in popularity. Cloud services typically do not exist in isolation from other enterprise applications and business processes. Organisations need to control how data flows between the service and their existing enterprise systems if the full benefit of cloud services are to be realised.

Equinox IT is a sponsor of the MIT Sloan Center for Information Systems Research (CISR), who have undertaken excellent research into the imperatives for preparing for the cloud.

Equinox IT is also a major contributor to the creation of the New Zealand Cloud Computing Code of Conduct, and we were subsequently the first IT consultancy to become a signatory to the CloudCode.

Invite to watch the webinar 'cloud services are like a bungy jump'

February 13
Webinar invite: Cloud services are like a bungy jump - 27 February 2014
1:15 pm NZDT, Thurs 27 February 2014

Elastic, freeing, and exciting, but make sure you check your bungy rope before you jump.

Greg Hunt, Senior Consultant, Equinox IT, Cloud services architectureIn 2013 over US$130 billion was spent on cloud services. Cloud is fast becoming the preferred method for IT service delivery for many organisations.

While cloud services offer many benefits, it is not a silver bullet for all the complexities and risks that are associated with traditional technology services and operations. Like all IT implementations, cloud requires a disciplined IT architecture and governance approach to successfully achieve the results your organisation is seeking.

In this free webinar, Equinox IT Senior Consultant and practicing architect Greg Hunt will discuss some of the key architectural and organisational considerations that must be addressed and managed as you look to start or mature your use of cloud services.

Equinox IT is the first IT consulting company to become a signatory for the New Zealand Cloud Computing Code of Practice.

Register for this webinar

1 - 5Next

Equinox IT

Find us


Level 12
Equinox House
111 The Terrace
Tel: 04 499 9450


Level 5
Shortland Chambers
70 Shortland Street
Tel: 09 307 9450

Connect with us

Work for us

VacanciesWe work at Equinox IT for the autonomy, collaboration, knowledge sharing, learning and balance. Why not join us?