If a Scrum team working within the SAFe (www.scaledagileframework.com) framework were a fish, then SAFe would be (to that fish) the thing that would make sure your water is cleaned, the filter is running and you get fed on a regular schedule.
You’re still a fish.
As a software engineer, I spent a year on a “SAFe systems team” at a large provider of extremely high-resolution satellite imagery. During that time an imaging satellite was launched. It was cool. Very cool. The launch was incredible and to see the first images breathtaking. I was really glad to have been a part of it.
This systems team operated as part of a SAFe ART. It was a supporting ScrumBan team that provided CI infrastructure support for about the 10 Scrum teams we worked with. For example, we developed a strategy for test driven database development and automated migrations using LiquiBase, and taught everyone else how to do it. We supported our shared Jenkins, Artifactory, etc. to keep the teams in flow. We created deployments and test systems in Docker and EC2, etc. We did these things for the teams and as part of an overall management of prioritization of a “program backlog” all of us pulled from.
I can contribute the view of what it is like as a software systems engineer on a Scrum or Kanban team on a SAFe ART. The most important thing to say about it, I think, is that it was just like many other agile team I’ve been a part of over many projects over many years. Those differences were mostly good (see the fish analogy) but were *very good* in the larger enterprise-wide ecosystem.
For one, we always had a very good backlog of the best parts of what the user wanted and we had a clear path up to the business strategy that created them. We had a great way to prioritize between teams and manage dependencies as we were aligned with our cadence but also a regular synchronization point (as well as constant interactions with the other teams in our value stream). In fact, that regular synchronization via “program increment planning” was about the only difference to a plain old scrum team. It took place over 2 days about every 10 sprints where the ARTs “inspected and adapted” and planned together for the next program increment, a la Scrum. That helped all of our schedules, for sure.
Those planning sessions were flat out productive and fun. Everyone in the value stream was there and we talked as a group and then, the ARTs broke out and did a program increment planning, built the new one and inspected and adapted through excellent retrospectives. Moreover, the “social fabric” of a very effective larger team in the ART context and in the value stream context was built. On top of that it, as I mentioned: it was fun, invigorating and, pretty much what we wanted it to be.
Another difference is that we had built in slack for innovation between program increments. We could work on our hackathon projects for about a week every quarter. Then we’d have an awesome, awesome demo and, again, we had a lot of fun as DevOps engineers. The best projects got mandatory time in the next program increment and were implemented.
One of the core values of SAFe is “respect for people and cultures”. I can attest to that. The ART I worked on bore it out anyway. We did self-organize and we did self-select on our teams. What we also had was a clear expectation of what decisions were ours to make, what needed to be made for all the teams in the value stream. This little piece, an awareness of clear decentralized control all the way through leadership in the ART, was very, very useful.
Some things, like having the teams on a regular cadence, are decided at the program layer, because they affect everyone. Other things, like if the team is using Kanban or Scrum, or what practices of XP they want to use (pairing, test first, etc.) are still in the purview of the team. On the systems team (which is right in the middle of the SAFe picture) worked with the business and the engineering teams and we saw great visibility to the overall work in process and solid metrics and approaches to control it. I know managing WIP locally helps manage WIP globally, so I imagine what I saw was extraordinarily valuable to the “business fish”.
Really, though, as a fish what I saw was was clean water and little multi-colored flecks of food on a very regular schedule. Sometimes I could even control the colors of those flecks.
--
In the spirit of full disclosure, I am an extreme fan of SAFe and have been using it a long time. I was a rails engineer on a scrum team that was used as one model of SAFe initially as the company referenced in “Agile Software Requirements”, Leffingwell, though I didn’t know it at the time. The job on the system team I referenced above was something I took a pay cut to pursue specifically to experience SAFe in context, which I continue.
--
Yours in the aquarium. Tim
You’re still a fish.
As a software engineer, I spent a year on a “SAFe systems team” at a large provider of extremely high-resolution satellite imagery. During that time an imaging satellite was launched. It was cool. Very cool. The launch was incredible and to see the first images breathtaking. I was really glad to have been a part of it.
This systems team operated as part of a SAFe ART. It was a supporting ScrumBan team that provided CI infrastructure support for about the 10 Scrum teams we worked with. For example, we developed a strategy for test driven database development and automated migrations using LiquiBase, and taught everyone else how to do it. We supported our shared Jenkins, Artifactory, etc. to keep the teams in flow. We created deployments and test systems in Docker and EC2, etc. We did these things for the teams and as part of an overall management of prioritization of a “program backlog” all of us pulled from.
I can contribute the view of what it is like as a software systems engineer on a Scrum or Kanban team on a SAFe ART. The most important thing to say about it, I think, is that it was just like many other agile team I’ve been a part of over many projects over many years. Those differences were mostly good (see the fish analogy) but were *very good* in the larger enterprise-wide ecosystem.
For one, we always had a very good backlog of the best parts of what the user wanted and we had a clear path up to the business strategy that created them. We had a great way to prioritize between teams and manage dependencies as we were aligned with our cadence but also a regular synchronization point (as well as constant interactions with the other teams in our value stream). In fact, that regular synchronization via “program increment planning” was about the only difference to a plain old scrum team. It took place over 2 days about every 10 sprints where the ARTs “inspected and adapted” and planned together for the next program increment, a la Scrum. That helped all of our schedules, for sure.
Those planning sessions were flat out productive and fun. Everyone in the value stream was there and we talked as a group and then, the ARTs broke out and did a program increment planning, built the new one and inspected and adapted through excellent retrospectives. Moreover, the “social fabric” of a very effective larger team in the ART context and in the value stream context was built. On top of that it, as I mentioned: it was fun, invigorating and, pretty much what we wanted it to be.
Another difference is that we had built in slack for innovation between program increments. We could work on our hackathon projects for about a week every quarter. Then we’d have an awesome, awesome demo and, again, we had a lot of fun as DevOps engineers. The best projects got mandatory time in the next program increment and were implemented.
One of the core values of SAFe is “respect for people and cultures”. I can attest to that. The ART I worked on bore it out anyway. We did self-organize and we did self-select on our teams. What we also had was a clear expectation of what decisions were ours to make, what needed to be made for all the teams in the value stream. This little piece, an awareness of clear decentralized control all the way through leadership in the ART, was very, very useful.
Some things, like having the teams on a regular cadence, are decided at the program layer, because they affect everyone. Other things, like if the team is using Kanban or Scrum, or what practices of XP they want to use (pairing, test first, etc.) are still in the purview of the team. On the systems team (which is right in the middle of the SAFe picture) worked with the business and the engineering teams and we saw great visibility to the overall work in process and solid metrics and approaches to control it. I know managing WIP locally helps manage WIP globally, so I imagine what I saw was extraordinarily valuable to the “business fish”.
Really, though, as a fish what I saw was was clean water and little multi-colored flecks of food on a very regular schedule. Sometimes I could even control the colors of those flecks.
--
In the spirit of full disclosure, I am an extreme fan of SAFe and have been using it a long time. I was a rails engineer on a scrum team that was used as one model of SAFe initially as the company referenced in “Agile Software Requirements”, Leffingwell, though I didn’t know it at the time. The job on the system team I referenced above was something I took a pay cut to pursue specifically to experience SAFe in context, which I continue.
--
Yours in the aquarium. Tim