Through my continued association with the Toronto agile community and as an organizer with the AgileTO meetup team, I thought I’d share my thoughts on Agile development methodology. These thoughts are based on my experience on embracing Agile practices in building software products for better business outcomes. It’s clear to me that any successful project I’ve been involved with has embraced many aspects of Agile development already, such as constant communication, focus on quality, increased alignment and visibility between the business strategy and the work that is being done, and the spirit of constant planning as a way to embrace the inevitable change that occurs in software development. But Agile methods and thinking takes all these ideas a step further.
Doing Agile versus being Agile
Agile for software development is very much a philosophy and approach, not a process or even a framework. Scrum, as a framework, can be helpful, especially to teams trying to adopt the Agile philosophy. But when I talk about Agile here, I mean the thought process and mindset of Agile. I’m referring to things like iterative development delivering working software, ongoing learning planning, and collaboration, reflecting or retrospecting to improve, and of course, breaking things into small, bite size chunks and just getting started on solving a problem.
Agile development can work for nearly everyone, particularly those building software products, because Agile adapts to change. In fact, Agile thinking embraces change. Change is a fact of life, and pretending we can see into the future and build to a single, unchanging goal has been a fantasy of the IT industry for many years. We’ve all realized it just doesn’t work that way, and the pace of change in many business and technical environments is increasing due to changing markets and competitive pressures. Accepting and dealing with this fact is one of Agile’s greatest strengths.
More creativity and better problem solving
Agile supports the creative process and the challenge of tackling complex problems. Software and technical solutions development, whether you like it or not, is almost as much of a creative process as a scientific one. Software development is also almost always a complex problem to solve, in that inherent differences in software, skill sets, and the target solution make understanding cause and effect (outcomes) very difficult. Complex problems and creative processes are hard to predict, hard to model, and can’t be shepherded along by fixed, predefined steps. They require experimentation and incremental understanding. Agile allows for the creative process and problem solving to occur within teams through collaboration and focus on the team and the individual, rather than on process and methodology.
Agile allows every team to function with more autonomy and independence. Agile’s focus on the team, and its ability to deliver end-to-end value in an application, makes each team more independent in terms of affecting change and delivering value. Combining this with a product or service focused approach can result in some very successful outcomes. This is especially true when the teams follow solid software engineering principles like continuous integration, test-driven development, and low dependency architecture.
The idea of ‘Big IT’ is one that is finally starting to fade. A new breed of companies have realized that massive groups of departmentalized people are often less effective and more costly in delivering business value than smaller, ‘flat’, cross-functional teams. This is true even in larger and more traditional ‘command and control’ or hierarchical enterprises who are all keen to make changes to benefit from the business agility and adaptability afforded by Agile ideas.
More transparency and accountability
Agile makes it more difficult for those comfortable with anonymity or apathy to work to continue to coast in their roles. We’ve all seen these people in ‘Big IT’ groups, that coast along delivering little and often leaving chaos in the wake of their apathy. They manage to hide in the noise and chaos of the large corporation. Sometimes those people are stuck in this mindset due to the lack of empowerment or a sense that they have no control to deliver effective work. In an Agile team, it quickly becomes apparent if a team member is not involved or isn’t doing their best to deliver value. The best part is that Agile can help people who might be struggling with their skills or understanding and who truly want to deliver value – by giving them the opportunity to do so. Agile demands a lot from a team member and will bring out the best in a team if employed well. In my experience, teams are effective in identifying when someone is not a fit with their team or the product or service they’re trying to deliver, so we tend to end up with more effective teams who are able to all contribute to the work in positive ways.
Agile allows for team building – real human team building. Top level down, structured processes often don’t work for people. It’s hard to build cohesive teams with hand off responsibilities between members – these kinds of roles and processes foster the ‘it’s not my responsibility’ mentality. Agile methods work differently by focusing on the team, and having them succeed or fail as a group. This makes Agile a more human-centric approach.
Agile removes ‘us versus them’ islands. By including the business and other stakeholders directly in the project (in the role of product owner and at the end of sprint demonstrations), the business is constantly engaged and has clear visibility into a project. Being able to see what’s happening and have a say in what’s next increases the level of engagement and removes the common feeling of division that occurs without visibility. There’s an understanding that a client who is more frequently consulted will be happier with the results, regardless of the level of success. In addition, a sponsor or stakeholder who can really see what’s occurring with a project team is more liable to trust that team and understand when they’re asking for too much. These ongoing contacts and discussions also enable the vital step of relationship building between those different people who, after all, are working together to deliver an outcome.
Continuous improvement and learning
Agile helps to remove pain points. By seeking continuous improvement, constantly removing defects and having input into what’s next, many smaller ‘pain points’ are removed. When a business owner and application user sees frequent deployments that constantly remove issues in the application, they’re more likely to be more comfortable accepting whatever features are still missing. By removing those smaller pain points, they can see the bigger picture and accept that change is ongoing.
Agile encourages learning. We don’t know everything, and we certainly won’t know everything that we need to know up front. Agile encourages a team to just get going and figure things out as you go. While this can be somewhat un-intuitive (and even a bit scary at first), it really, really works. And yes, when done properly there is still an enormous emphasis placed on properly defined and understood requirements, user experience design, architecture, quality and change control – all the mainstays of traditional enterprise software environments. It’s just that the work is accomplished in a different way.
Agile is not a silver bullet
Agile teams can clearly still fail, for many reasons, and often predictably. We have learned a lot over the years about what’s required to make it work, and why it can go wrong. Agile software development depends heavily on the right engineering skill sets, mindset and discipline. Unfortunately, that’s still not how a lot of developers really operate or think yet.
There are also a lot of Agile coaches who operate at a very theoretical level, without the deep experience and background required to really help a delivery team understand and practice the new methods effectively. Coaches are needed to demonstrate and assist the team in the hands-on tasks like story creation and backlog pruning, as well as ensure the team members are learning and practicing the engineering discipline needed – this kind of coaching support is often left out and teams are underserved in this area. Failure here has in some cases given Agile a bad name – but similarly when teams get these fundamentals right, the results can be fantastic.
We have seen over many years that embracing an Agile mindset, executing Agile methods properly, and ensuring a healthy dose of software engineering discipline will greatly increase the likelihood of success over more traditional methods.
So what’s next?
Training, coaching, and ongoing exercises are always valuable. Even successful teams can benefit from these things, especially as team members and as their work changes over time. Like any complex system, maintenance and tuning always keeps things running better. Introducing teams to new ideas, skills, and approaches is critical whether they’re kicking off a new product or service, or have been working on the same one for a number of years.
Uniquely, Solsys can help companies by identifying and introducing coaching and training. We have a variety of services to support organizations trying to embrace Agile methods and thinking, and who are moving to product and service teams. We have a strong history of building and working with product and service teams that deliver effective business outcomes, and we would love to talk to you about how we can help you use or improve your adoption of Agile methods to improve your business agility.