Devbridge prides itself on delivering world-class solutions to clients. In our quest to produce successful software projects, we've adopted agile as our primary philosophy in designing and building software.
I describe agile as a philosophy because it is not a rote set of processes that we rigorously adopt and follow. We are committed to the idea of constantly improving our processes, finding the right tools to help improve and enhance our ability to set expectations, then delivering. I'd like to talk a little about how we've chosen to adopt agile software development and scrum to fit our needs and provide benefits to our customers. First, the day-to-day process of scrum:
Scrum across the globe
Devbridge is globally distributed. The teams in Lithuania and Chicago are separated by eight hours, meaning the overlap in work hours can be minimal. This can make the execution of traditional scrum ceremonies complicated. While the time offset has tremendous benefits in our ability to deliver products to our clients, it creates challenges for us as product managers (PM) to balance, especially when we are working with multiple projects and project teams. As such, we've adopted the traditional scrum ceremonies to suit the needs of each PM project, and team. Each team and PM decides together how to tailor scrum to best fit their needs. For most, this means having backlog grooming sessions for the next sprint in the middle of the previous one, offset by a week. For others, this means having multiple grooming sessions throughout a sprint, allowing product managers to be spread across multiple projects by limiting the time spent with a given team in a given day.
In terms of tools to facilitate our projects, we're pretty tool-agnostic too. Whatever tool will best enable a team to succeed, we'll use. Whether it is a more formal agile/scrum tool like JIRA or Rally, or something much less defined, such as Trello or Google Docs. As a team, we're committed to continuously improving our ability to deliver quality products to our clients. As a PMO group, we spend a significant amount of time each week working on improving our process. We even have our own Trello board just to track potential improvements we want to make to our own processes! But how does agile benefit our clients more directly?
Educating clients about our process
Many of our clients are used to more traditional waterfall processes for their large software projects. The agile software development philosophy has gained widespread acclaim and acceptance, but it's still a relatively new concept to many of our clients. Yes, they've chosen to work with us, but how does agile actually directly benefit our clients? Why should they care if we're using agile? As a PM, it is imperative that we educate our clients on how we intend to work, what that means for them, and how that will benefit them, both during the project and afterward.
For agile projects, we ask clients to identify a point person from their organization to work closely with the PM and the development team. Oftentimes, this commitment can equate to up to 15 hours of work per week from the client, depending on the project. But for this investment, the client gets a few key benefits:
Assurance that business logic is being translated correctly
Ability to direct the team on priorities
Keen understanding of what is in progress at any given time
By involving clients in as many scrum ceremonies as possible, we can show clients the value that they're getting every step along the way of a project. The majority of our scrum teams are working in two-week cycles on features as prioritized in collaboration with the client. That means that a client gets to see tangible progress every two weeks. Features are being completed and delivered every two weeks instead of after months of development. The opportunity exists to gain feedback on completed features continuously within the development process. All these things are the benefits of you'll experience when working with Devbridge on a scrum-based project.
This is not to say that we can dictate to clients how projects will be managed–that couldn't be further from the truth. Together, a PM and client will collaborate in determining what approach will result in a successful project. For example, with backlog grooming, the level of a client's involvement can vary:
Direct client involvement in backlog grooming
Setting up a Trello board or basecamp that the client checks for questions
Separate weekly meeting between PM's and client to review stories and set priorities
These are all viable methods for getting stories defined and prioritized. Which methods are used are up to the PM and the client. Note that the cycles on all those ideas are short - a few days, a week, two weeks at the most. Short cycles allow for iteration and just-in-time refinement of requirements, but it's usually an adjustment for clients to understand that while that means we can start development more quickly, create demo-able products faster, and shorten the feedback loop, it requires an explicit commitment of time from the client. Our process has huge benefits to clients, but it requires commitments from them too.
Agile gives us the ability to deliver on a consistent cadence, building trust with clients as they see working code get to them earlier than they've experienced before. As that trust grows, barriers fall, processes evolve and success becomes routine.
Why agile software development? Why Devbridge?
We are committed to delivering successful software projects. How we get to success is dependent on the project, and dependent on the client. Scrum, Kanban, Waterfall—the needs of the project dictates the methodology instead of Devbridge selecting just one. Agile isn't about enforcing a specific set of processes, but rather finding the ones that will best help us and our clients be successful. We've identified some processes that work for us and provide tremendous benefits to our clients, but we are still committed to continuing to improve as a team and finding even better ways to deliver value for our clients.