Years ago, I wrote a book on ATDD. Only years later I notice the value that this practice can bring to an environment with multiple teams working together on the same platform. The connection to scaling agile in the larger enterprise wasn’t that obvious than it became when I started to dive deeper into how to scale agile. Though, most larger enterprise struggle with getting one team running, scaling has become the latest fuzz in the agile community. Let’s see why ATDD is relevant for this sort of environment, and how you can challenge your team colleagues about it.
I have to admit: I am German. Us Germans are well-known in the world to deliver good results. That said, we are very dedicated to deliver efficient results. There is one thing that troubles me about that. Having our main business in Germany, I often face questions with regards to efficiency while introducing agile methodologies. You can efficiently drive your car right into a wall. That would be very efficient, but unless you try to kill yourself, not very effective. The English saying ‘don’t try to run before you walk’ expresses this gallantly from my point of view. Let’s explore that thought.
Before I joined it-agile in 2010, I was exercising up to six times per week. When I joined it-agile, I knew I would be traveling more. It took me a bit more than four months until I noticed that I lacked some exercise. So, in January 2011 I started to go running, as this seems to be the only exercise compatible with a travel-rich job. Last year, I completed a 31,1 km run close to my hometown. While learning to to run, I noticed lots of parallels to Exploratory Testing. Here are the things that stuck.
Over the years, I became more and more suspicious about the concept of a project. I have worked in several companies, at times working with products, at times working with projects. I have seen more waterfall projects, I have seen waterfall products, and I have seen both agile projects and products. What strikes me most is the amount of ignorance most companies have with regards to the effect that projects have in the longer run. Let’s see some stories.
Over the course of the past week, I realized the importance of external help – and some of my cultural biases for admitting that I might need it. Here is my story, hoping that it might help others seeking out for help.
So far, I think I have undervalued the importance of some practices when it comes to working in a large-scale development shop with lots of teams. One of the major problems with software development in the large is that we as an industry of software developers are terrible. We have bad development practices in place, and it’s strikingly easy to hide your bad software development skills in larger corporations. I also think that the Craftsmanship movement could come up just because we have badly educated software developers since decades.
When it comes to consulting, I notice three kinds of solutions out in the field: the blueprinters, and the emergenters, and the ones that float between these two worlds). Dealing with blueprint solutions is a fallacy in my point of view. Let’s take a closer look on each of these three patterns I saw, and see what’s going on.
I am guilty. Over time I have served in several online communities. I have tried to provide some of my limited knowledge to help people overcome some of the struggles they were facing. I have a confession to make: I am addicted. I am addicted at offering help. I am addicted to help others. I am addicted to keep them in a symbiotic relationship. Over the years, here is what I learned by trying to be more helpful.
Stick long enough in context-driven testing, and you will hear the term “shallow agreement” one time or another. A shallow agreement happens when we forget to confirm our understanding regarding a user story before starting to work on it, and find out during the Sprint Review – or worse: later – that the functionality did not meet the expectations of our ProductOwner or end-user. Shallow agreement happens when we find out too late that we seemed to agree on something, but really weren’t. We didn’t check our assumptions, and usually both parties end up being disappointed by each other.
Last year, I realized there is also something like shallow disagreements – and I am not sure whether these are worse than shallow agreements.
Scaling Agile appears to be a theme. At times, I am wondering how many organizations there actually are that would adopt large scale Agile to start with. Currently, I have the impression there are as many scaling frameworks out there as participants that joined a casting show. But I am exaggerating at bit here. With all these frameworks out there, how do you pick the right one for you? Or should it be a mixture of all of the frameworks available? While diving deeper into scaling frameworks, I found some considerations at picking the right one fruitful. Here they are.