The long awaited Innovation Sprint… Almost.

Photo by Ben Shan on Unsplash

To be up front, this article is about how frameworks for agile are not really agile and how they can ruin your day. A little over two years ago my company adopted SAFe. Ever since then I can honestly say that I’ve not really seen any benefit, actually its caused more segmentation, isolation, and mis-communication than I can remember prior to us adopting it.

With that said, my team is considered as a “shared” services team. We primarily focus on developing what I will label as “middleware”. Basically we develop high end scaleable web services for our internal customers. We offer an abstraction layer away from off the shelf backend solutions. More on that in another article. We have many customers, demands, and of course vague requirements.

There isn’t a product owner, nor a business owner for what we do. We have developed well into the hundreds of micro-services. Well some of them are a little larger.

SAFe just doesn’t work for a shared services team. We try to plan out our iteration (there are five two week sprints per iteration) but rarely are we able to actually complete them due to changes in priority. Additionally, there is a lack of pre-planning by other trains/teams that seem to dis-regard that we need time to do the work prior to them actually needing it. Go figure…

So, back to the original reason for this article. In theory the fifth sprint in the iteration is reserved for “innovation” like as in research, training, pet projects etc. If your train/team has meet their IP objectives that fifth sprint is free and clear.

Unfortunately, my team was always on the go, the demand was so high, we never had the opportunity to participate in the “innovation” sprint. The team was always behind. You can blame it on poor planning, etc. Most SAFe advocates would say that we’re not doing it right. They probably would be correct. It works great for a single (or limited) product but not when dealing with a shared services team.

The only reason we got to participate was due to the organization is going through some major changes due to a merger. The organization needed a little time to figure out some priorities. We were supposed to do our PI days, where we plan out our up and coming PI. Instead we got a freebee sprint, thus we made it an “innovation” sprint.

It isn’t an official one, so technically we didn’t participate in the “official” one. Other teams on the train, got 2ish sprints, but hey I will take it.

The team was pretty excited, and we had an in person meeting to discuss what we’d each like to do. Then off we went…

Umm… for like 2ish days…

Out of the blue, there was an announced launch date for one of our projects in a couple of weeks. No notice, no consultation, no nothing. The business picked a date and declared we’re going live. So a couple of us had to make sure all the stars were aligned. I’ll write about that in yet another article.

Photo by NASA on Unsplash

Other members of the team, got pulled into issues as well. So our innovation sprint got side lined in a big way. We did manage to grab a few days and got some things we wanted to figure out started so hopefully we’ll get to continue them and finish them.

Some of the observations that came out of the this experience are:

  1. The promises that SAFe markets are false, at least from what I’ve seen.
  2. Management should ensure that we get the carrot occasionally. I had a good time digging into stuff for the brief period of time I had it.
  3. The SAFe leadership and management should have seen that our team never had an innovation sprint. They should have looked at the why and maybe seen the un-relenting demand the team had to deal with.
  4. SAFe doesn’t seem to provide empowerment to the team. I know that I couldn’t demand we have our innovation sprint. Item 3 was completely ignored.

I do plan on finishing up on my “innovation” project. Its nothing to big, just developing a cli that allows me automate some of the following tasks:

  1. A command to authenticate via AWS SSO when developing CDK and pushing code to code commit.
  2. A command to create and setup a bitbucket repo. Creates the repo, creates the main/develop branches, and sets the default branch to develop. Along with a simple README.md and initial .gitignore
  3. A command to install the CDK bootstrap into our AWS Accounts. We have 3 accounts per product. The command will install the CDK bootstrap into each account with a simple my-cli cdk-bootstrap my-account.
  4. A command to remove a cloud formation stack from an account. It will clear out all items including any persistent storage and other items. Essentially wiping things clean.
  5. A command to bootstrap an AWS Application Stack with all the necessary CI/CD stuff and Code Commit

I’m doing this in python using Boto3, which I’m fairly new to booth. I managed to develop the first three. Just need to figure out how to package it up and setup our internal pypi repo.

So much to learn… Its fun… and this type of stuff helps learn so many things. AWS, Boto3, python, CDK, etc.

Photo by Tim Mossholder on Unsplash

As a developer, I forgot that we need to take time to take these things on. If you’re experiencing similar issues, you need to take a hard look at what your company is doing. Have that discussion and explain that these “innovation” sprints are important. From both a mental, and efficiency stand point.

I’ll be fighting for ours, and start advocating for this.

Thanks

Bill

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store