Yup, got another certification on a software development methodology 🙂 . It’s called Scaled Agile Framework or SAFe for short. In case you haven’t heard of it, this post should provide you some context, as to where it fits into the larger scheme of things. At the same time, I have penned down my journey over last few years with respect to development processes. Hope you find it useful.
Software development processes have been a fascinating aspect of software industry, often leading to a debate between its proponents. My first exposure to these processes was through Rational Unified Process (RUP) – a comprehensive process covering various facets of software development. There was a big RUP cardboard in the center of my workplace with few colleagues of mine swearing by it, and taking pride for their in-depth understanding of the process. At the same time, industry was evolving towards lean approach to software development, working only on those activities that created value for customer. Lean approach coupled with agile manifesto for embracing change, lead to a set of new development processes like Scrum, Kanban and XP among others. Agile processes were an instant hit with developer community, as these were largely created by practitioners and not managers, who believed in empowering individuals cutting layers of management above.
Adopting agile though can be journey in itself. Let’s take Scrum. The Scrum process talks of a lean process with just three roles (Product Owner – a business representative, development team and Scrum master – a facilitator) and two weeks incremental development cycle called sprint which covers planning, demo and retrospect (continuous improvisation). But most organizations got the implementation wrong. For instance, in my team we religiously adopted agile, even changing our working place to reflect it – moving from isolated cubicles to collaborative benches, etc. We ran two weeks sprint (incremental development cycle), occasionally allowing business to re-prioritize work at starting of the sprint. Surprisingly though when we measured business impact of all these, it turned out to be almost zero. Issue was while we were internally having two weeks development cycle, our release to business was still every quarter, as we left out activities like regression testing, production deploy, etc. for the last sprint, water-scrum-fall as most experts call it. And it took quite a bit of churn before we leaped from a two week development cycle to a two week release cycle as desired by business.
Another fumbling issue about agile processes is the management struggle with it. CXOs and senior management find it tough to figure out a way of tying their budgets, forecasts, strategy and portfolios to things like burn down chart, velocity, story points, etc. For my workplace, we tried marrying different tools like Microsoft Team Foundation Server and Microsoft Project Server, with former catering to developers and latter to executives managing portfolios. We informally adopted process like scrum of scrums, where respective scrum masters across board met every two weeks with their progress report. Execs though were still looking for prescriptive guidance to manage large portfolio of agile projects, treating agile as a developer only framework.
This is where methodologies like SAFe come in. SAFe builds on scrum process, providing a framework for agile enterprise. SAFe framework breaks the process into three broad areas – team, program and portfolio. At the team level nothing changes much. SAFe prescribes scrum for the teams to deliver incremental development with two weeks sprint. In addition to sprint meetings, SAFe recommends a joint planning session (described later) involving all members, which happens at end of every program increment (PI).
The value of SAFe Framework primarily starts above the team level with program level. SAFe maps many scrum (team) level aspects to program level aspects. For instance team (product) backlog becomes program backlog, user stories becomes features, sprint becomes program increment (PI), scrum master becomes Release Train Engineer (RTE), product owner becomes product manager and agile teams come together to form a long lived Agile Release Train (ART). ART is at the heart of SAFe. ART is chartered to drive development of program level features with 8-10 weeks cadence called program increment (PI). Each PI thus is an aggregation of team level sprints. PI objectives too are an aggregate of teams’ objectives. ART also has shared roles like System architect, RTE, and UX among others across sprint teams. Unlike agile processes, SAFe explicitly defines architect role to create an architecture runway ensuring teams have the necessary foundation to start building PI features. At the end of each PI, there is retrospect and release planning meeting for the next PI. At this time business owners measure the PI objectives by comparing planned value with actual delivered value. All of these shouldn’t sound too different for individuals and teams practicing scrum or scrum of scrums.
Top level is the portfolio level, intended to cater to the needs of senior leadership. Here the strategic themes of organization (e.g. enhance our digital channels to improve customer experience by 30%) are translated into portfolio epics. Epics are business and technology oriented, with the intent of latter supporting the former. To limit epics and work in progress, SAFe recommends Kanban process. Each epic in turn gets assigned to ART which breaks it down further (program epics, features and user stories) and delivers incremental value with PI iteration. SAFe recommends budgeting to be done around ART and not around projects to ensure there are no impediments to value creation. It’s interesting to see SAFe have guidance around expenditure and capitalization (you know why CFOs prefer OPEX vs. CAPEX).
So, would I recommend SAFe? Or is Ken Schwabber right in stating it as ‘unSAFe at any speed’? From my perspective SAFe has a unique appeal to senior leadership, people who right the cheque. Good (or bad) part is, SAFe really doesn’t offer anything substantially new, and hence I don’t see it creating much friction with existing development teams, who are practicing agile development. And, while most organizations already have a similar process in place, SAFe does provide a good reference framework. I also like the ubiquitous language and acronyms it brings to the table – agile release train, architecture runway, etc. At the same time, like any other framework SAFe isn’t one size fit all, you will find it bloated in specific areas (e.g. roles, planning, etc.) and hence, you will have to customize to ensure it doesn’t impend organization’s agility. But overall it appears that SAFe is here to stay.
If your developer face is still frowning, just remember, it has anyways always been about practices and less of processes. I am embarking on my first release train. Let’s see if the title of this post holds true – ‘it won’t cause harm, it’s SAFe :)’.
Niraj Bhatt - Architect's Blog 