Mix-in Constraints

I just got done introducing another group to the the idea of agile mix-ins. The conversation was a lot of fun. There were a few takeaways for me that I think made the conversation particularly interesting: When it comes to applying mix-ins, you control how much or how little you do, and you also work within the context of the organization.

Let me back that up a little bit. First, before you try and apply mix-ins, I think it’s important to have established a baseline of working practices. This means that if you have just rolled out SAFe, for example, you should probably give yourself a PI or two to really establish a baseline of performance before trying to muck with the system. Otherwise, you just run the risk of creating a never-ending storm of change. That won’t serve you well. So allow yourself to establish a baseline before introducing a lot of new changes.

Second, Scale the change to the level of of organizational permission or tolerance that you believe exists. In other words, if the management team isn’t really on board with the change, then you probably won’t be able to introduce it much farther than the team itself. On the other hand, if the management team does buy in, then you can apply more global change at the program or portfolio levels. It’s a judgement call. Scale your efforts accordingly.