Error getting theme layout

Agile in a Professional Services Environment

Posted @ 10:06 pm by Chad Iverson | Category: Web Development Process | 0 Comments

This post describes the agile development process we follow in the Social Business Practice. Below, I describe elements of the Scrum method that we have found suitable for professional services, and of course, the type of work we do. If you are working with or on a professional services team and considering agile methods, this post is for you.

Scrum Process at SolutionSet

Find a methodology fit

Agile software development can take many shapes and forms. One approach to adoption is the path of least resistance, adopting only the activities that easily conform to an existing process. I recommend making an effort to adopt some of the more challenging elements of an agile method. Often this is where the real benefit can be found. What’s important is finding an agile method that works for you; this will not happen overnight. We are not agile experts; nonetheless, our experience with Scrum has been positive.

The key elements of agile development fit naturally into our engagement methodology. As we follow this methodology, blended iterative activities and cross-discipline, self-organizing teams naturally emerge. For each of our projects we have a strategy and definition activities that occur before development begins. This is typically where high-level architecture is developed and visual design is handled. The strategy and definition phases set the stage for the Scrum sprints by producing the backlog as well as identifying the product owner and development team members. From there projects move to the design, develop, and deploy phases. The sum of these three phases constitutes our Scrum sprint. This is where the majority of the work gets done.

To ensure that we can deliver potentially shippable product with each sprint, a cross-functional team is a must. On a recent project for a new professional networking community, we drew great benefits from having the designer participate in the first sprint. Working as part of the development team, the designer could see the design come to life and course correct as the design was applied to working software. If the designers were not part of the development team, the web developers may have fine-tuned the design in a manner deviating from the original designer’s intent. No two sprints are alike and the nature of the sprint changes as a product nears release readiness; I will elaborate on this in a separate post. We found, with this project in particular, that the traditional big upfront design is less likely to deliver the same product quality.

To find the deeper agile adoption opportunities it is helpful to recognize real constraints. Many clients have limited experience using agile methods, while others strictly follow a method inside their organization. In a professional services environment clients often expect some degree of up-front planning, even those already practicing agile. In addition, some clients need significant strategic consulting, many projects incorporate services from multiple vendors, and certain projects are exploratory in nature. These factors extend the duration of the strategy and definition phases, which occur before the first sprint. From a Scrum viewpoint, this translates to spending more time grooming the product backlog and planning each sprint.

Deliver early and often

In our experience, clients are interested in working software as early as possible. Often this means producing smaller statements of work and in some cases a proof of concept makes the most sense. This allows us to focus on the deliverables with the highest business value, establishing a prioritized backlog with the client.

When producing use cases or user stories that make good product backlog items (PBIs), clients should look for the characteristics of quality defined by Wake (2003) using the INVEST acronym.

High-quality PBIs enable our team to develop thin vertical slices of end-to-end working software. This sliced approach makes it possible to deliver a potentially shippable product with each sprint. A thinner slice can reduce the length of a sprint and help us put tangible results in the hands of a client earlier in the project. These shorter delivery cycles also reduce risk by preventing work in progress and technical debt from accumulating.

Be adaptable not predictive

Big up-front planning and design aligns with projects where the work can be easily predicted; we rarely see that type of work. Our entire engagement methodology is built around adaptability. This supports efforts to manage uncertainty common in software development work. Predicting every task in a project plan rarely benefits the team during execution. Likewise, trying to predict exactly how people will use software can be a waste of time. We have found that some of the most important product requirements are discovered during sprint review meetings, not predicted during product planning. Our experience tells us that user behavior can only be approximated, not predicted. We know business software requirements can change rapidly. Using agile methods increases our ability to respond effectively to these changes.

Over the course of a 1-4 week sprint we try to produce what Cockburn (2004) refers to as a walking skeleton. To do this, we bring as much testing into the sprint as possible. Each sprint review meeting typically includes a demo, offering the product owner and stakeholders a chance to provide feedback. This process gives us continuous reassurance that business value is being delivered.

Recognize that every client is unique

The client partnership is critical to our success. We acknowledged that requirements change often, but that is not enough. Adaptability is not a one-size-fits-all proposition. Not every client is prepared to give up on plan-oriented approaches. Each client brings their own experience with software development and each product owner has a unique vision for their user community. By recognizing that every client is unique, we position ourselves to learn from all engagements.

As we work through each project, we are guided by the principles of the Agile Manifesto (Beck et al., 2001). We do not do pure Scrum or XP and do not pretend to; although, leveraging elements of Scrum has served us, our clients, and the users well. Our agile development process makes it easier to identify obstacles early, it provides transparency into our work, and keeps the deliverables aligned with business value. Clients are continually demanding more from their social business solutions. To meet these demands we will continue looking to Scrum and other agile methods for opportunities to deliver in an environment of change.

 

Chad Iverson is a Software Architect on the SolutionSet Social Business Practice team. He is also a Certified ScrumMaster.

 

References

Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Principles behind the Agile Manifesto. Agile Alliance. Retrieved from http://agilemanifesto.org/principles.html

Cockburn, A. (2004). Crystal Clear. Media, 435(7046), 1138. mitp-Verlag. Retrieved from http://dx.doi.org/10.1038/4351138b

Wake, W. (2003). INVEST in Good Stories, and SMART Tasks. wwwxp123com. Retrieved from http://xp123.com/xplor/xp0308/

 

Leave a reply

Error getting theme layout