SEYFARTH SHAW has been a strong exponent of knowledge management (KM), investing heavily in its knowledge solutions. The firm's unique SeyfarthLean program, which marries elements from Six Sigma and Lean with the practice of law, naturally involves a wide range of knowledge management efforts. Either directly from our SeyfarthLean program or to support those efforts, Seyfarth has revamped its intranet[1], launched enterprise search, built precedent libraries, created a slew of dashboards and other control mechanisms, and developed a vast number of other, more Seyfarth-specific applications. Each solution brought new ideas; and each tool changed the firm's collective expectations about how technology could help address important KM challenges.
These expectations built to crescendo in 2012. The aforementioned projects, the changing technological climate outside of the firm's walls, the expansion of the firm's SeyfarthLean program, the firm's growing recognition as an "Innovation Idol,"[2] and several other factors merged to create a sea change within Seyfarth. The firm made a strategic decision to repoint its knowledge resources and custom development group, making them 80+ per cent client-facing. As part of that change, the Legal Technology Innovations Office (LTIO) was born, and our Application Development Team almost doubled in size. The goal of these teams, with help from our Legal Project Management Office, is to create and apply new technical and knowledge solutions that can be touched and felt by clients.
This change in focus brought a host of new challenges. First, we knew we would have to be extremely opportunistic. The market was (and is) changing quickly, and we needed to react swiftly to meet demands. We expected frequent changes in priority, focus and scope. Second, client-facing solutions would bring a host of technical problems that were either new or deeper than previously encountered. Up-time, feature-sets, ease of use, privacy and security were merely a few of the blips on our radar. Third, we realized we would be operating as a software company tucked inside of a law firm. Instead of 'projects', we now had to think in terms of 'products'. Fourth, there would be more complexity to what we were going to do than ever before. To make our solutions relevant, we had to address pain points not already met by the market. Though we would strive to make things simple, they would not be so underneath the hood.
Making the move to Agile
To respond to these challenges, we restructured our internal processes. No longer would we be locked into five to six month projects. We had to break sooner and with less pain, if the opportunity were right. We wouldn't have all the answers from the outset of a project. In the past, we would start projects with a twenty, thirty or forty page requirements document. They were never right, seldom referenced after the initial stages of the project and took a considerable amount of time to build. On the whole, we would have to depart considerably from our typical processes.
All of this led us to Agile and, more specifically, Scrum. Agile is an iterative and incremental means of executing on a project. It is different than the way traditional, 'waterfall' projects flow. In Agile, responding to change is valued over strict adherence to a formalized plan. Requirements and solutions evolve through heavy dialog and collaboration between self-organizing, cross-functional teams. Scrum is a flavor of Agile that is used heavily by software companies. Scrum is not an acronym but is named after a rugby activity where play is restarted by binding players together to compete for the ball. The goal of the Scrum methodology, ultimately, is to increase speed and flexibility in software development through greater collaboration and teamwork.
Scrum introduced new terms, roles, artifacts and patterns of communication to the way we worked. Product Owners, Scrum Masters and the 'Team' were the new roles staffing our efforts, and each would work to bring products to life.
The Product Owner represents the voice of the stakeholders, and, in our case, is the voice of the client. This role helps determine general priority of features and works to ensure the highest value items receive attention first. Product Owners advise on both explicit and implicit need, and, sometimes, they are at odds with general lawyer inclination.
The Scrum Master helps facilitate the process. They assist in removing impediments and ensuring there is a continuous flow of work. The Team is the rest of the folk involved in the effort. In keeping with Scrum principles, we assign people to a project, and then allow them to self-organize. As many of our efforts are without precedent, we do not know the best mix of skills needed to execute on a project. We try to have several competencies on the project. The meat of the project's delivery is undertaken by this self-organising team. They work together to determine how a feature set is going to manifest itself and then put the time in to make that a reality.
'Epics', 'User Stories' and 'Tasks' dominate the definition of what needs to be completed. User Stories are of particular importance, as they simply and succinctly define what is to be done, for whom and what the outcomes should be. All of the known user stories are put into a list called the 'backlog'. Unlike most planning elements of the past, they don't have to be entered into the queue in a linear fashion. Once a user story has been completed by the Team, it is reviewed by the Product Owner and immediate feedback is given for any additional changes. As need for new functions arise, new stories go into the backlog. They're then reprioritized frequently for execution (every week, for us).
Planning and communication have a different flavour. There are daily stand-up meetings, sprints of 'timeboxed' work, meetings to frequently groom the backlog, retrospectives to determine what went well and what didn't within a sprint. Those meetings force communication in a more frequent pattern, but, that's not the only time the Team meets. There is constant informal dialog between those executing on specific user stories.
Picture Caption: Our Scrumban board or "Scrumboard" - showing user stories that are in motion and what stage they're in ("to do," "doing" and "done").
The attributes of Scrum couldn't have been a better fit for our needs. The more we researched, the more it seemed to address the coming challenges and blunt some of our past frustrations. However, moving to Scrum was a project of its own. It ran contrary to many years of past project work and didn't come to us naturally.
In the beginning, we tried to educate ourselves and dive in head-first. The first attempt wasn't successful. Past modes of practice and various personalities clashed and frustrated our progress. However, though all involved would say it was a false start, there were glimmers of hope that kept us focused. Instead of abandoning after a single pass, we went back and retrained our teams. Between the LTIO and the Application Development Team, we had eight team members trained as Scrum Masters or Product Owners. We tried again, built on what we learned and haven't turned back.
We now have a process that's firing on all cylinders. To date, we've authored almost 1,000 user stories, and we've completed over 300 of them. Our cadence has increased considerably too. We release new code every week - adding functionality, improving performance and fixing bugs. Further, we now shuffle the deck of user stories every week, with a focus on having everyone's time directed toward the highest and best use based on the world as we know it that week.
Applying Scrum to KM Efforts
Wisely or not, we first applied Scrum to the largest custom development project Seyfarth had ever undertaken. In dealing with our off-the-shelf extranet, we ran into extreme limitations. We had a lot of extranet experience, having built over 1,700 unique sites in that legacy platform. It couldn't meet current demands, and it wouldn't keep pace with the firm's general trajectory of innovation.
To put our firm in a positive position for the future, we set off not merely to replace our prior platform but to fully eclipse it and to create a launchpad for future client-facing solutions. We reimagined what client collaboration should be. Though 'extranets' were our closest analog, we aimed for something different, something deeper. In addition to basic extranet functionality, we wanted to enable better reporting, provide more financial transparency and provide vehicles for executing on larger 'portfolios' of work. It was an aggressive project, and its name is 'SeyfarthLink'[3].
Picture Caption: A screenshot of the welcome page of SeyfarthLink.
To start the project, we began with several 'epics' - large buckets of work that needed to be completed, focusing heavily on the 'must bes" of the system. We reduced those epics into user stories, and broke into sub-teams to complete larger portions of the platform. Each section was a separate application and had a Project Owner and an associated Team. However, each section needed to fit contiguously into a broader picture, which required planning at a level above the individual sections.
Midway through the project, we brought on an outside quality assurance (QA) company to help us test our work. We found that the user stories not only helped us build the system, but also made for easier test scripts and feature footprints that were easier to validate. This QA resource worked on off-hours, further speeding the time to review our work and, ultimately, get it into production.
After about six months of iterating, we had a 'minimum viable product' (MVP) for early adopters to explore. As with all things new, it was imperfect, but we were able to learn and learn quickly. Over the next few months we iterated through a series of performance and feature enhancements. We now have a contemporary, feature-rich platform that has met the business objectives we set out to achieve.
Product Impact
To date, SeyfarthLink has been a central point of over fifty client pitches, and is tied to many wins on the business development trail. Direct feedback from clients has been inspiring. We routinely hear things like, "Why aren't my other outside counsel doing this?" and "I want to apply this to everything we do together; in fact, I'd love to apply this to all of our work, in general." Further, this has opened a door to better dialog with our clients about what they would like in the future, what their pain points are, and how to further expand on what is working. As a firm that prides itself in continuous improvement, this is key to our long-term success and, possibly, survival.
In addition to bringing new capabilities to the firm, SeyfarthLink has captured imagination and excited our attorneys in ways that surprise even the most bullish of us. Once an engagement has been secured, it has provided an opportunity for Legal Solutions Architects, a team of technologists who happen to be lawyers/attorneys, to work as consultants on client-facing projects. These resources have helped bend the platform around our engagements, buttress what our Legal Project Managers are doing and significantly improve usage patterns when compared to our legacy platform.
And, we're now iterating toward features that are even more compelling. Document automation, workflow, mobility, decision trees and many other features are starting to bloom within the product. As a consequence, KM and technology have more prominence at the firm than ever before.
Conclusion
From afar, Scrum may seem like an interesting social experiment and little more. We can confidently say that isn't the case. The benefits we have gotten from that approach have been significant. Though we have delivered on several projects and have gained a significant amount of momentum, we have stood before upper management and stated that it is our process that is the key and not one of our products. The product is merely the output of our Agile program, and, fundamentally, it's that Agile methodology that is the jewel. Without the change from Waterfall to Agile, we couldn't have delivered on what we have to this point. And, it is Agile that makes us even more confident and excited about Seyfarth's KM and technology future.
References:
1. Seyfarth Shaw LLP won SharePoint Innovator of the Year in 2010 from the International Legal Technology Association (ILTA) for its intranet, “inSeyt.”
2. See BTI’s 2012 and 2013 Brand Reports for a list of Innovation Idols, as determined by a broad survey of in-house counsel.
3. Seyfarth Shaw LLP won Innovative Project of the Year in 2013 from the International Legal Technology Association (ILTA) for its work on SeyfarthLink (http://awards.iltanet.org/2013-winners.html).
