Several years ago, a company I previously worked for hired a team of developers to redesign our outdated website. The website had been built for a previous decade when our company, a membership-based professional network, was a free resource. Times had changed, however, and as we had decided to convert to a subscription-based model – and were now contending against formidable competitors including Facebook – we needed a redesign and new features to enhance our customer experience. Our visionary CEO had numerous ideas, and getting our website right (a bet that now included building a portal to accept credit card payments) was the key to executing on all of those initiatives. We found a development company that shared our vision, and we were excited for the future.
The lead developer and I established a two-week rhythm of “sprints” in which the developers would tackle a to-do list of new features, spend time toward the end on quality assurance testing, and then, following my non-technical team’s final review, push the features live. The team began to work on the website, but it turned out that the original code was very brittle and would require extra care to fix.
We quickly realized that we would need to revise our approach. If something on the website broke in the middle of a sprint, we did not have a good mechanism to fix it without completely disrupting our workflow. Through some trial and error, we agreed upon new communication strategies that enabled more frequent exchanges as well as workloads that empowered the team to quickly adjust to urgent situations or changing requirements. The good news is that we were able to eliminate the bugs in the code, and the company has been on strong footing ever since. As I have subsequently become exposed to formal agile methodologies, the experience has also sparked my thinking as to how a more agile approach could have really benefited us.
What is agile?
The Agile Methodology proposes an alternative to traditional project management. It was initially designed for software to deal with unpredictability and avoid either “analysis paralysis” or an end product that seems like a good idea on paper but is unusable in practice. On a broader level, agile is about a way of working that always starts with the outcome in mind, with iterative methods along the way. Speed and simplification are key principles, as are close collaboration among team members and stakeholders, and trust that they will get the job done. The Agile Software Development Manifesto includes a set of principles that a group of software developers agreed on when they convened in 2001 to discuss lightweight development methods.
While agile is not brand new, it has expanded beyond the software realm and today includes a wide variety of resources such as a certification program for a methodology called Scrum. When I arrived at IBM last summer, my first set of projects involved fairly independent projects and a geographically dispersed team, but out of curiosity I sought to make connections with colleagues across marketing who employed these techniques in their day jobs. Needless to say, I was equally enthusiastic when my team, an internal consulting group tasked with helping our leaders understand the market, begin to explore using agile, too.
The experiment
Since my team is not colocated, this made it all the more important for us to leverage technology in implementing agile. First, we selected Scrum in particular to focus on – this involves 15-minute calls for everyone to share what they have accomplished, what they plan to undertake and any impediments they are facing. Second, my team created a working agreement that includes a set of principles for working together and delivering quality results. One rule of Scrum is that there is no concept of “partial completion;” work is either 0 percent or 100 percent complete, so while this is something we are still figuring out in practice, ideals such as “failing fast,” learning and trusting each other are some of what we have agreed to. Two months into this new rhythm, I have a much better sense than before of what my colleagues are working on and where we might find additional opportunities for collaboration.
In addition, a teammate and I currently meet daily to work on a specific project, which involves weekly sprints to create a series of presentations for the business leaders we are advising. We speak at 9:30am in the morning and this sets the stage for the day, ensuring that we both have clarity on our overall vision and next steps. Throughout the day, we may also chat on IBM Sametime to share files or exchange questions or insights. My younger self might have been daunted by the thought of trying to complete such a project in a week (in fact, less than a week when I factor in my other projects), but this approach has enabled us to address any roadblocks very quickly.
In yet another project, my team has been tasked with conducting in-depth research across three different industries. In a traditional approach, we might have divided and conquered to deliver this work. Instead, we are all doing a deep dive into one industry for the first month, then will move onto the others. Based on the learnings and the relationships cultivated in the first phase, which we are about to complete, I believe that we will be able to tackle the next two industries much more quickly.
Is agile just a fad?
As with any related methodology, agile has its detractors who are concerned about lack of true team effectiveness or collaboration, or worried about costs. According to Steve Denning, who writes on radical management, “Agile is the solution to a particular problem, namely, reconciling disciplined execution with creativity and innovation.” Agile is not meant to add a layer of bureaucracy – rather, it thrives on transparency and, at its best, gives employees great freedom to be highly creative and productive. To truly be agile, this requires organizational buy-in. At IBM, Ginni Rometty recently spoke on agile and the need for ”restlessly reinventing yourself and how you do your work.” Whether or not we continue with these methodologies or replace them with new ones down the road is to be seen, but our leadership team is offering abundant resources to help everyone get up the curve.
If the faces of my teammates on a recent Scrum call are any indication, we are enjoying the experiment, too.
Has your team experimented with agile methodologies? What has been your experience so far?
