Typing “Agile Development” into Google search brings up 123,000,000 results. Sift through the first 5 pages, spend 3.5 hours reading through webpages that all seem to be the exact same copy of each other with cosmetic edits, or worse, websites that say the exact opposite, and be nowhere nearer to understanding what an agile transformation is. Been there done that.
We have tried, and we have failed, and this is what we have learnt – to save you all that computer eye strain, mouse fatigue etc. 🙂
Speaking to Titaners across teams, we bring you the differences in work practices after our Agile transformation, broken down into the main areas of:
AKA “doing the first thing first”. The Pareto principle states that roughly 80% of effects come from 20% of causes. In the context of agile product development, it would run along the lines of, 80% of the product value comes from 20% of product backlog items.
The prioritization process takes place on two levels – on a product level, to determine what features of the product could better contribute to achieving the main goals of the project, and a task level, to define what pieces of work (user stories or tasks) must be realized, and in what order, during the software product development process.
Some real-life feedback from implementing the prioritization process of agile development includes:
“Proactively looking for user data instead of waiting on requirements from stakeholders puts intended users at the centre of design and development, ensuring that products delivered are validated with a true market value hypothesis.”
“Product Owners and users get to play a more important role in development.”
“Minimum Viable Products (MVPs) allow us to prioritise and deliver items with the least possible amount of effort and time, to validate hypothesised value with users, act on market feedback and work on the same user story multiple times to get iteratively closer to a better solution for the market – all that in a shorter span of time.”
A heavy reliance on continuous iteration of concurrent development and testing, unlike the traditional waterfall model, means that a readjustment of testing values are required. Some of the main agile testing values include, placing importance on individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.
Traditional software testing methods can still be utilised, with varying degrees of priority and necessity, but there is definitely a need to embrace the agile attitude when considering their implementations. Exploratory testing is a common approach in Agile software testing that at its base, consists of concurrent simultaneous learning, test design and test execution. Some examples of agile testing methods includes:
“Pair work and code review instead of quality assurance checks – no more bottle necks waiting for review.”
“Time is saved with the adoption of automated and unit tests.”
“The adoption of automation test, clean code and refactoring improved our code quality.”
In the spirit of Agile development, specifically the Scrum methodology where user stories (functional items in the backlog) which are too large to fit in a single sprint needs to be split up into smaller tasks, we are splitting this article highlighting the major differences of agile work practices up into, well, smaller ones.
So keep a lookout for the second part of our article next week!