But does it suit every industry? Can risk-averse sectors such as finance also benefit from bringing testing into an agile methodology, or is there simply too much red tape and regulation to allow it to work successfully?

At first glance, agile testing and finance seem incompatible, with the greatest risks appearing to be incomplete testing and slower development. The fear that agile testing will be incomplete testing seems logical at first glance: how could you possibly test everything if you’re working iteratively in short sprints? Agile testing can seem haphazard, but, of course, that’s not the case. In a waterfall approach, a tester will have a list of requirements, which they use to define test cases. Yet, bugs are found with regular frequency in live systems even after these ‘comprehensive’ test cases have passed. Little thought is given to how and where applications will fail – the interest is just that it has passed a particular check. There is a fundamental difference when testing with agility. Testing with agility makes it possible to use modern tooling, gain quick feedback, and execute the same level of checks without relying on heavily documented and time-intensive test cases.

Waterfall vs. agile

The second fear, that testing will slow development, can be true – in a waterfall approach. Managers who only know testing from waterfall will think of testing as a long process. Testers write a test plan and approach based on the requirements, followed by test suites and cases to meet the coverage demand. It’s a very labour intensive process. Bottlenecks are created when the development and testing are not done in parallel, and then at the end of a lengthy test period, the development team are presented with a long list of problems to resolve. This process is repeated and repeated as code changes introduce more, new and different bugs, leading to increased costs and missed delivery dates.

But agile testing takes the opposite approach. Testing with agility produces frequent feedback based on shared models and information, and constant questioning as development is ongoing. Even simple changes to the development cycle, such as testing on development branches, allows testers to give frequent feedback, which developers can immediately incorporate into their own work to produce effective results.

Mind maps can be an excellent aide memoir, and extremely useful alternatives to writing out full test cases. Recording exploratory journeys can provide useful evidence and the ability to replay this execution can give a greater scrutiny to spot problems. Where possible, replacing manual test cases with automation will reduce the need for manual testing for regression.

Testers can also ensure good unit and integration tests are used and new ones added when code is changed and bugs are fixed, to avoid future regression.

Sprint planning

A noticeable factor in the finance industry is its reliance on reports – which is at odds with the agile manifesto’s ethos of ‘working software over comprehensive documentation’. Bringing clients into the agile process is the best way to help them realise that they don’t necessarily need or want highly detailed documentation and that sharing knowledge with minimal documentation actually speeds up development and creates a culture of action and accountability. By being involved in the project from the beginning, finance clients see the efficacy of our testing, they understand how and why we’ve tested, and they have the confidence to be able to replicate similar tests if they do any more development in the future.

We want to avoid over-documenting and we need to feel confident that we can share the right knowledge with clients and other testers who may work on the project in the future. Projects need to uncover what information is valuable or useful. Bug counts will tell you little about the state of the application, but providing usable software to demo and use can display progress – and also build confidence that you are building the right thing.

The traditional view of testing is that it follows on from development: it’s a final quality check before the code is further developed, or released. In a regulation-heavy industry such as finance, this presents a real risk for development. Bringing testing in early gives your project a high level of quality and confidence from the start. If you’re working in two-week sprints, you’ll immediately see the benefits of starting testing in the first week, instead of in the middle of week two. Bugs will be found and driven out early in the cycle, smoothing the delivery towards the end of the sprint.

Testing with agility is not only suitable for the finance industry, it’s critical. It’s the best way to deliver robust, reliable software, and an essential part of any financial software development.

Written by Head of Testing, Scott Logic, Laurene Pisani

The post How to conduct transformative agile testing in a risk-averse industry appeared first on DevOps Online North America.

To start a new project for a new account, the “agile way” is the “simplest thing” an IT vendor can do. Nevertheless, life becomes tough when they have to do an agile transformation. Yes, this is very cultural and needs a very good ecosystem to succeed and flourish.

New agile kickoffs are easier than transforming an existing delivery system to agile way.

Before I even talk further about challenges and the solutions, an IT vendor first needs a good Agile Coach, who can bring the spirit of agile into the organisation. Just forming a team and training them on agile and engaging a Certified Scrum Master (CSM) will not help.

Agile challenges

Agile transformation can pose challenges in many places of the life cycle. The picture broadly below depicts that:

Challenge 1: If the wrong person is a Product Owner. The Product Owner should be empowered to take decisions on functionalities and should truly represent the Business. Engaging a non-empowered person as Product Owner will complicate development and will increase cycles of production and thereby its cost.

The BEST THING is to have the Product Owner from business. He/she should have a vision for the application developed. He /she should be able to take call on the features, as well as should be able to clearly prioritise features. The NEXT BEST is to have a person who has got full business buy-in on the application being developed. Still, the risks are too many if the Product Owner and business are disconnected.

Challenge 2: Long sprint durations. When migrating from legacy/conventional delivery lifecycles, some people are uncomfortable to work in 2-week sprints. They decide to have longer sprints and duration the more comfortable they are. This will be counter-productive. Spirit of agile is to deliver working software ASAP! 

Here is a very interesting article of Cognizant that elaborates about various impacts of the sprint duration. Agile teams should be ‘self-managing teams’ and by giving too long duration sprints decreases the agility and subtly encourages lethargy. The agile team will be more than happy to commit to meaningful/short sprint durations when “done” definition is clear. A hazy “done” description leads to thoughts of longer sprints.

Challenge 3: Daily scrums will be effective only if they are timeboxed like the sprint. When migrating from a legacy lifecycle, which has a longer duration but less frequent reviews, people tend to overeat with their updates. This would make daily scrums lose focus and not get full visibility of what’s happening in the team.

There should be a very effective Scrum Master who can articulate well and ensure a very effective Daily Scrum. Any points that could go beyond the 15 minutes duration of the daily scrum can be taken into the sidebar for later discussion.

Agile transformation

Various other points that would pose challenges in an agile transformation are:

• Billing model for agile – remember ‘requirements are evolving’
• Resource utilisation – remember ‘everyone is responsible’
• Team bonding – this decides many successes
• Servant leadership – enabling the team to perform
• Senior management appreciation for agile style
• A clear understanding of ‘ideal hours’
• Careful re-prioritising when the sprint is running
• Being fully focussed on ‘delivering value’

There is a very interesting read on agile obstacles by Michael James. Read through it to know the western challenges of agile; some of them apply very much for Indian IT Vendors as well…!

So, Agile is in, and to get the best out of it, we should adopt it carefully so that the full benefits are reaped! 

Written by Ramkumar Ramachandran, Director & CIO at Tevel Cyber Corps

The post Challenges agile transformation can pose appeared first on DevOps Online North America.

Organisations need to ensure they’re looking out for competitive threats, as well as new market developments. This is where agile comes in useful, helping identify experts and guide teams to tackle issues quickly through decision-making.

A healthy work culture plays a significant role in any workplace. It’s important to know where agility matters the most, as teams work on new products, strategic initiatives, or with clients.

Scrum meetings

In order to be agile, stand up meetings are critical, which is typically referred to as “scrum meetings”. Meetings usually take place every two weeks, at the end of the sprint. A sprint typically takes 1-4 weeks of a development lifecycle and consists of demonstrating features about the end project. Meetings should be at least an hour long, and consist of a number of goals to be achieved before the deadline date.

Before the meeting, a Product Owner will usually explain the user stories and use cases to the rest of the team, giving employees the chance to ask questions for clarification, in order to prevent confusion.

The team will then typically begin effort estimation using the method of “planning poker”. Once effort estimation is done, user stories are assigned to individual team members and work begins.

Team members can still add a new user story or task after the meeting, although new ideas must be communicated to the Product Owner if it isn’t originally a part of the plan.

Planning walls, also known as a scrum board, can be useful at this stage. A “board of progress” can easily be changed when something has been altered within a product. This ensures that all employees are aware of what stage of the development lifecycle the product is at.

Common pitfalls

Nevertheless, common pitfalls may arise which must be avoided when working towards agility. Different disciplines must be separated to steer clear of communication silos. Also, work must not be estimated by hours because it’s easy to fall into a trap of a small scope.

Another issue is reporting roadblocks, even when facing difficulties when working towards the deadline date. Reporting early is essential – in the long run, it will cost less and the end product will, without a doubt, be more effective.

New System Architecture can also be problematic, as it often involves new hardware components, different layers of an organisations IT infrastructure, as well as software applications that may be unfamiliar. In-house and third-party applications must be able to be built on, and security must be implemented accordingly.

Not forgetting, testers must test before the code. It’s not all about ensuring the code is stable and working properly, it’s about being focused on achieving the smallest thing possible in order for a test to pass.

As long as a structure is in place, projects are planned properly and communicated well, success is reviewed, and important aspects are adjusted when needed, then you should reap those benefits when climbing towards agility!

Written by Leah Alger

The post Climbing towards achieving agility appeared first on DevOps Online North America.

Rook spent the last seven years at Vodafone as the phone company’s chief executive in IoT division.

According to The Register, he now aims to become Sprint’s senior vice-president.

Rook said on IoT matters: “My focus will be on developing secure IoT solutions for our business customers and all people who want to make the best of the digital revolution.”

Tom Rebbeck, IoT research director at analyst firm Analysys Mason, added to The Register: “Sprint has struggled in the shadow of Verizon and AT&T in the US IoT market.

“Both Verizon and AT&T will earn US$1billion from IoT in 2017; Sprint much less. Sprint has also been slower to roll out.”

Written by Leah Alger

The post Vodafone’s IoT boss moves to Sprint appeared first on DevOps Online North America.