Intersection

At the beginning of the year, I made a few predictions in my post The Future of Business Analysis. (One of those predictions has already come true.)  In this post I’d like to share some evidence of another prediction: continued interaction of analysis and agile communities. This interaction primarily comes in the guise of paying more attention to building the right thing along with a continued view toward building the thing right, the implicit focus of the original agile approaches. I’d like to point out three examples of the greater focus being placed on building the right thing (or determining whether anything needs to be built at all).

First, most of the truly worthwhile endeavors in the agile community seem to start up organically and involve establishing shared values and principles. This initially happened in February 2001 with the Manifesto for Agile Software Development, followed in 2005 by the Declaration of Interdependence, and in 2009 by the Manifesto for Software Craftsmanship. It happened again in 2013 with a group of people who got together in London that February and then again in May in New York City to discuss ways of ensuring that a team and the entire organization are building the right thing.  I was not able to make the London meeting, but several of the attendees shared their thoughts online, which I summarized in another article.  I was able to make it to the New York discussion. Elena Yatzeck describes some of the key topics from this meeting quite nicely. An outcome from these meetings was the formation of Agile Alliance’s Analysis and Product Management in Agile (A&PMiA) Program.  We formed this group as a way for practitioners in the business analysis and product management communities to share stories, questions, and puzzles about using those skills in an agile setting.  To help facilitate these discussions, we organized an Agile Open Jam at BBC2013 (here is an overview of the discussions and a summary of the discussion results). This year, the group will be seeding additional discussions in the Open Jam at Agile2014 and possibly other business analysis and product management conferences this fall. The group has also established a virtual community for discussions and idea sharing.

The second example is the establishment of International Consortium for Agile (ICAgile) and its Learning Roadmap, which contains a set of learning objectives across eight disciplines of agile practice.  These learning objectives provide a methodology agnostic view of agile that help organizations determine what they need to learn in order to understand and apply agile.  The importance of ICAgile to business analysis practitioners is the inclusion of Agile Value Management as one of the eight disciplines.  The learning objectives in this discipline highlight how business analysis techniques and practices are applied in an agile setting to help teams and organizations ensure they are building the right things.

A final example is the increased focus on applying agile at an enterprise setting, and the resulting creation of processes and techniques, through the Scaled Agile Framework (SAFe).  While SAFe is primarily focused on applying lean and agile practices at the enterprise scale, there is an increased focus on business analysis activities. These activities tend to be even more essential when dealing with the complicated nature of software development in an enterprise setting. Even though the specific role of Business Analyst does not show up in the SAFe “big picture” (the common graphic used to summarize the method), there are several roles that extensively require business analysis skills to be effective.  Those include the Product Owner at the Team level, Product Management at the Program level, and the Epic Owner at the Portfolio level. While SAFe has its skeptics (I am occasionally numbered among them) and tends to focus on practices more than values and principles, it does contain a lot of ideas that are very useful, including a greater emphasis on how decisions are made about what to work on and how that work is organized. The original agile approaches do not place as much emphasis on this.  It is these type of activities where business analysis techniques can be very helpful, and represent true analysis of the business. It’s also these activities that people with business analysis skills should become experts in while coaching all of their team members on the more tactical tasks of eliciting and documenting requirements.

These are but three of examples where business analysis techniques are becoming more prevalent in agile setting. There are others that are harder to find because business analysis is rarely mentioned by name.  The key is to remember why you use business analysis skills and techniques.  Once you use that perspective, you’ll see there’s a large intersection between analysis and agile that benefits both communities. I encourage you to check out the examples I mention here, keep an eye out for more. Please share any that you find via the comments below.

Pin It on Pinterest

Share This