Agile is all the buzz these days. Adoption statistics show an 88% increase since 2002, with the use gaining traction in 2014-2015. Now, an impressive 70% of companies are using the methodology. But back in 2016 in the auto finance industry, defi was an early adopter.
Senior software developer Mike Ripplinger explained why in his April 2017 blog defi ENGINEERING: A CULTURE OF ITERATION
- It’s folly to expect that a project’s requirements will be perfect and complete two months after they’re written — or even two weeks later, or maybe even two days later.
- With iteration, we receive feedback from our clients much earlier in the process, and much more often. This helps us to identify gaps between what our clients want and what we think they want as early as possible.
- [Waterfall is] perfect for certain kinds of projects for which making changes after initial construction is very costly, or impossible. But code is the most malleable construction material ever invented. It isn’t cheap to change software, but it’s far cheaper than re-pouring a football stadium’s foundation after its frame is half built.
Historically teams have used either Agile, Waterfall, or often a hybrid of the two methodologies used in both project management and software development. Without a consistent methodology in use, it’s difficult for companies to forecast delivery timeframes. Teams have communication gaps and friction points, and team members cannot efficiently move from team to team.
It’s important to pick one, so teams can:
- Speak the same language
- Hand off projects more efficiently
- Collaborate more effectively
- Ensure all are working toward the same goals
AGILE VS WATERFALL
Waterfall is a linear process in which each phase – requirements gathering, design, development, testing, and delivery – is completed before the next one begins. Eric Evans, a software engineering thought leader, once said waterfall is actually a very good name for this design philosophy as you’re going about your business, paddling down the river, and then one day – boom! You go over the falls.
In Waterfall, client feedback is gathered in the later stages and changes to requirements are managed through a rigorous, sometimes year-long process. With rapid changes in markets and environments, by the time you deliver, it’s quite possible the client needs something different than originally agreed on, or the result ends up simply not what the client thought they wanted.
Agile is iterative. When implemented well, Agile is scalable, predictable, yet quick and adaptable, with relentless, continuous improvement a foundational component. When you’re delivering innovative, SaaS-based products and services these are keys to your success!
In Agile, you complete the full cycle in short, continuous intervals called sprints. Client feedback is gathered collaboratively throughout the process and changes can be incorporated quickly to the backlog and re-prioritized as needed to meet the client’s goals.
With Agile, you deliver, get feedback, adjust, and deliver again quickly so, ultimately, the client ends up with exactly what they want, even though it may look completely different from what they described in the beginning. In addition, because you repeat all phases of the process frequently, you are motivated to make incremental improvements to remove impediments and maximize the efficiency and effectiveness of the team and business.
- Agile projects have ~4 times the success rate as compared to Waterfall
- Agile projects scale (up and down) much better than Waterfall
- Agile sprints are short and the smaller and faster a project the greater the value and quicker the return rate
TEAM PHILOSOPHY
It isn’t only the quick sprints that allow success. The Agile philosophy is as important.
Agile values individuals and interactions, trust and transparency, focus and courage – all things that unify teams across an organization and make all more effective. An Agile team is a group of 5-9 collaborators who work toward delivering valuable products and features. The team is typically comprised of one scrum master, one product owner, and a group of developers. An Agile coach, usually someone with advanced training and expertise, works to increase companywide agility.
Both the coach and scrum master are servant leaders who provide guidance and make sure the team understands the Agile process and how to implement it effectively. They clear roadblocks and make sure the teams are equipped with everything needed to do their jobs.
CASE STUDY: The needs of a struggling team
A development team was recently struggling. Through a series of unfortunate incidents, this band of developers had no manager, no scrum master, and no product owner. Team members were mostly new and still learning about the company, product, and Agile. Their backlog was not healthy, and without lower-level environments they had to wait until code was near production to test, which is very risky and expensive.
An Agile coach started by gaining visibility into their work and challenges, with a goal of first stabilizing and then moving the team in the right direction. Knowledge of their assigned product wasn’t necessary.
The coach was able to guide the team’s thinking and conversations and help them build trust, learn to collaborate more effectively, and continuously improve by addressing process and team gaps and lack of effectiveness.
Together, they flushed out the old backlog, built and prioritized a healthier new one, and built a new test environment.
CASE STUDY: The needs of a high-performing team
It isn’t only struggling teams that benefit. A high-performing cyber security engineering team that handles all things related to protection systems and help desk escalations began using the Agile Scrum processes on their own. When an Agile Coach suggested they needed to adopt the standard Agile language, practices, and reporting so that their projects and results made sense when viewed companywide, they were excited about the opportunity to learn something new.
Although not a traditional development team, they are tied to client deliverables and commitments. Prioritization for this team is determined by the needs and priorities of other companywide initiatives and their work is a blend of ad hoc tasks and more traditional development. They needed a mechanism by which to decide the type of work that qualifies for scoping, grooming and story building, and inclusion in a two-week sprint.
Their process
After one sprint and a retrospective, it was decided that task requests were getting in the way of sprint delivery. So, a new intake process was rolled out that allows all incoming work to be gathered and tracked with a centralized view. The team assigned both a scrum master and a product owner who consult various parties, gather preliminary requirements and an estimation, and assign to the sprint backlog, if over two hours.
Sprints for this team run for two weeks. Additional requirements are gathered, if necessary, stories are prioritized, and planning for commitment to the sprint is done. For tasks, assignment takes place based on which team member has the knowledge and is available. This process develops T-shaped people (with deep knowledge in one area but a broad base of additional knowledge or skills) by partnering team members to spread knowledge.
The shared intent of this team and Agile is that processes keep evolving as needed and, in this case, balancing the needs of task work versus sprint work. The goal is that team members are trusting and transparent about what they need to be successful, which leads to happy and efficient teams that take ownership of how things get done. This team is now aligned with company standards and experiencing continuous improvement.
LEADING TO CHANGE
In following the Agile philosophy, coaches and scrum masters lead teams to change by working through the inevitable skepticism, taking small steps, making compromises to bring people along gradually, and not ripping off the bandage and proclaiming, “this is what we’re doing now!” The teams are not heading toward the “boom! You’re over the falls,” but instead are experiencing the small quick wins that lead to big successes.
