Exploring Success and Failure in Agile

Are you an Agilist or an Agile Realist?

geralt / Pixabay (Measurable spelled wrong in the graphic, I know)

I have been asked this question often in my interviews of late, and my answer has always been honest and forthcoming. I am an Agile Realist. Too many times it was not quite the answer my interviewers were looking for which I feel is unfortunate for me and for the organizations that they serve. Also of note from my recent observations, is that the organizations that want to employ True Agilists with a gung ho attitude, who want to religiously stick to Agile methods, seem to have the most available surplus work and appear to me to be more successful. My conjecture is that true Agilists are also sensational in their approach and because of this, cause more waves within the organizations that they go into. This might be the reverse butterfly effect. Many of the companies looking to implement Agile, especially those employing consultants to bring in Agile via one or more pilot teams, want to profess to the rest of the company (and in some cases to external analysts and stock watchers) that they are bringing about the much-needed change to business processes and trying to improve as promised. The pilot teams are examples of their strong commitment to change and they, as leaders, are doing the right thing for the company. Sensationalists are a good fit for these roles and their passionate fervor towards Agile and the constant push to shape the transformation to meet exacting Agile standards, is perceived as a good change that will result in quick Agile Success for the company. Short term wins do follow hard pushes towards the Agility of development environments. I believe that this is the prevailing insight.

Terms that I often hear bandied around in interviews are DevOps, CI/CD, TDD, ATDD, Automated Testing, Virtualization etc. I am sure that I am missing some phrases as I write this and I will add them once I hear of a new one. I also am asked whether I would use one web based Agile tool or another for a transformation, whether one should allow teams to work remotely in Agile and what I thought of closed environments and segregated development teams during an Agile transformation. While these questions are discussed ad nauseam, I rarely am asked whether I have ever worked with a very mature Agile team or what I would do to improve the productivity of such a mature team. I am a big proponent of all that is DevOps and would love to see every team run an automated TDD environment that is continuously delivering to production without needing UAT at all. I would also like World Peace to come soon and every person in the world have clean drinking water and enough to eat every day. In spite of my love for automation and a completely integrated system of development, I think that the ones I mentioned previously are all advanced tools. They are meant to be solutions for problems that exist within certain of these systems (I use system loosely as a container of processes within a complete development factory) that are alleviated by making specific changes to processes within the factory.

I am a big proponent of all that is DevOps and would love to see every team run an automated TDD environment that is continuously delivering to production without intervention. I would love to see virtual servers spun up and destroyed with every release and the deployment of needed servers, the configuration of these servers, creation and partitioning of databases, population of seed or test data and creation of firewall partitions or opening up of firewalls, be a part of the code deployment process that also tests the code automatically for TDD, performs a qualitative analysis and identifies the most common bugs and memory leaks without the system ever needing human intervention. I am familiar with many of the tools that could be used to accomplish these goals, have personally configured many of them and have used many of these tools in some combination over the years in a pursuit of hastening the process of deployment and reduce human touchpoints. I also like World Peace and would love for every person in the world to have clean drinking water and enough to eat every day.

I really like the following quote that I recently saw on LinkedIn.

Any improvements made *anywhere besides the bottleneck* are an illusion. —Eliyahu Goldratt (Theory of constraints)

Applying pop tech to a development process does not necessarily make it better. None of the above is, in my opinion, an all encompassing solution that will actually bring about improvement to any aspect of the actual output. Instead of a one size fits all solution, I would really like to look closely at processes first. Then I would like to think and analyze every stage, see if I can find problems, document the problems and then see if I can think of a solution to that problem. If I cannot, I put it aside for discussion with a larger group and move to the next stage. Now granted, I am nowhere as thorough with my thinking or documentation as I should be and tend to look at groups of stages instead of just one to find low hanging fruit. I still need to look very closely at the input to try and predict output. I try to help increase the quantity and/or quality of the output or decrease the amount of time/labor required to produce such output. I personally have some knowledge of tools and tricks to improve certain types of problems. I also rely heavily upon brainstorming with the teams to find other solutions and Google is my close friend. I then rely on the team to actually implement the change and stick to it in the long run while I provide support or encouragement as needed. It is then up to me, as a coach or a leader, to observe and measure the initial state, measure the departure from the initial state after applying the agreed upon change, and then follow the difference for some time to be sure that it is improving over the long run. I also stick to a lot of Lean principles and like to reduce waste in the value chain. I find that waste is easy to identify if I stop focusing too closely and look at the process as a whole and in some cases, the entire factory as a whole. I also believe that waste should only be identified after the process or the factory has been rid of bottlenecks in productivity. If waste identification is performed while or before bottlenecks and pitfalls are being removed, then bottlenecks and pitfalls might appear to be a waste and vice versa. I believe that reduction of waste and decrease of handover time could be accomplished by technology and processes such as DevOps, CI/CD, Automated testing etc. while bottlenecks can be reduced via processes such as ATDD or TDD, code reviews, qualitative analysis, merge meetings, daily standups etc. I also feel that Agile coaches need to have a variety of experiences such as Project Management, resource management, development and testing in their background to really understand the needs of individual processes and systems better and pick out the bottlenecks and then identify the waste in these systems. Agile coaches also need to be good at sharing and seeking out the help of the team to find solutions that work for that particular team and can be sustained in the long run with the resources that team can afford.

I have nothing against strong Agilists. I know a few who have become good friends of mine and I have had glorious debates with them. I strongly feel that Success in Agile is dependant upon finding the right Agile realists for your Software Factory, pairing them with an Agilist or two and then letting them loose on a project that is ripe for improvement.

So who is hiring?

2 thoughts on “Are you an Agilist or an Agile Realist?

Leave a Reply