Fighting OK
One of the worst things to have happen at work is for everything to be OK. Last week I read a post over at Managed Agile Development. It got me thinking about the push towards Agile that we are making. We have met with resistance, and some of it is most definitely because things here are OK.
Our development process doesn’t have a huge pain point. Sure, we have some irritation here and there, but nothing really hurts. With nothing causing a large amount friction there’s resistance to change.
In our journey we aren’t pushing change to justify our jobs, make life hard for anybody, or just for fun. We have primary roles that do not rely on moving to a more Agile environment. One of the primary tenants of Agile is “Individuals and Interactions over Processes and Tools.” We truly believe in this and would fight to preserve the people of the team above any process. This includes putting the team needs above our Agile desires. Finally, pushing process change where none is wanted is not fun. Nothing more should be needed here.
We do want to make the work environment the best possible one we can for the entire team. This means not over committing developer time to get features out if at all possible. It includes controlling workflow through the team so QA isn’t unexpectedly asked to do a full regression test in a week. It also means the customer should have an idea of what they are getting and when it is coming in.
There is a strong desire to make sure our customer gets the most value possible from the work we do. Left to our own devices we could make amazing software. It would look and work beautifully. The flow would be so seamless using it would require less than no thought. It would also fall apart as soon as some non-development team people tried to use it. On top of that, it would be missing some of the functionality they expect regardless of how refined what we saw as important was.
That leaves us where we are. The project we just finished was Agile-Like. We had Agile elements sprinkled in our classic phase structure. The project was not delivered perfectly. It was delivered well though, It was good enough that the idea of doing the next one a whole different way raises warning bells in upper management. This is what we fight as we try to move to a more Agile process.
Next week we will look at what time is the best to move to Agile. In the interim if you haven’t yet read the post which inspired this pair of posts, go do so now.
