Develop Your Post-Agile Process Mashup with the Software Development Game

Post-Agile themes like “process fusion” or “mashup” or “doing what works for you” can be difficult to quantify and execute. Without a structure, how do teams determine what to do in an optimal fashion? If people just do whatever they feel like, or have a chaotic process that doesn’t support consistent software development, the team is going to run into problems. Some teams are good at doing this naturally – they have the right mix of skill, communication and buy-in to move forward with implicit structure. However, not all teams share this trait. Enter the Software Development Game (SDG). David McFadzean and Jonathan Kohl have gamified decision making, rule and policy creation and the process to determine an optimal mashup of processes, tools and technology at any given time. Check out the article here: The Software Development Game.

The SDG is a reflective process for developing private policy. Using concepts from gamification, it enables an organization to develop a near-optimal process for developing software that fits the organization’s unique requirements. Since the SDG is inherently adaptive, the organization can experiment with policies taken from existing methodologies, keeping what works best, and discarding ones that are more trouble than they’re worth.

Jonathan Kohl Interview on Agilism, Post-Agilism

Jonathan Kohl was interviewed by uTest recently. One of the questions was about the Agile movement and post-Agilism. Here is an excerpt from that interview with his response:

uTest: You were an early adopter of Agile and later started talking about “post-Agilism.” What are your thoughts on the Agile movement over the years? (Since you could probably write an entire book on this topic give us the dust jacket version.)

Jonathan Kohl: “I started looking into Agile methods when I was working on a team in 1999 that was trying a combination of Rapid Application Development (RAD), Open Source, and iterative/incremental models like Spiral. The lead developer sent us this article called “Chrysler Goes to Extremes” which described the very basics of Extreme Programming. We liked that it was open and free (we didn’t have to purchase some tool chain and coaching we couldn’t afford) and we started trying some of the ideas out. We then bought the book “Extreme Programming Explained” by Kent Beck, and started implementing XP as best we could. A year later I was introduced to Scrum, and we had good success with it. After a while, I started noticing failures on Agile projects, and people moving on and doing other things. That was fascinating to me. Sadly, instead of learning why there were failures, there was an overwhelming urge to suppress them, or worse, dehumanize people by blaming them for doing it wrong.

As for Agile methods in general, I am ambivalent. I am glad that lightweight methodologies are much more common place than they were in the ’90s, and we have benefited from creating a common language around practices, and our tools are so much better now than they were ten years ago. I enjoy working on many Agile projects, since they fit my process and personality, and how I like to work.

However, there is a lot of snake oil out there, with proponents claiming that merely adopting Agile methods will lead to a successful business (What about having a great product, great customer service, skilled people and strong financials? Don’t those sort of matter too?) That really turns me off. Furthermore, for years, any Agile failure would inevitably involve blaming the victim: you did it wrong, you don’t get Agile, if you were really Agile it would have been a success, which often sounds like another variation on the “no true Scotsman” argument fallacy. Sure, sometimes people fail because they made some mistakes, or didn’t commit, but every Agile project that fails can’t be blamed on the people.

We should elevate people above processes, practices and tools, not make them subservient to them. The people come first, not the process. Also some of the Agile gatherings feel very religious to me, with conversion stories, wild eyed claims that aren’t questioned and lots of zealotry. Those sorts of meetings make me feel very uncomfortable.

There is also a lot of rigid thinking about implementing Agile methods themselves – do it by the book, or the way the coach describes, and once you have reached a level of mastery, only then may you adapt. That smacks of a priesthood, and that bothers me. I believe teams know what is best for themselves, and should be self-determining in a mix of tools and processes that helps them create valuable software for their customers, value for the shareholders and owners of the company, and value for their teammates and themselves. No one should have the right to dictate how you do that. It’s a personal decision, and in an industry with so many organizations, people, fields and different contexts, there is no such thing as a “one size fits all” solution. By all means gather expertise and learn from people with more experience and different ideas, and really try out concepts instead of just prefixing “Agile” in front of whatever you are doing, but don’t stop there. The world is not a static place. What worked last release may not work the next one, and you have to adapt in this business or fall behind.

Post-Agilism was something I observed that reminded me of post-modernism in architecture and art. Modernism is more rigid in rules of how things should form, while post-modernism rebels against that restriction, and people use combinations or mashups of styles to solve a problem. The problem is solved in the end, just by different means. We see this in music, where much of popular music is a fusion of what has come before, and in much of the food we eat, which is a fusion of many cultures and tastes. I saw this group of people who were grasping their own freedom to create value, not just follow a process. They were not being dictated to by consultants, coaches and books, and were taking information and ideas from many sources creating mashups of processes, tools and technology to create great software. They often had high morale and a good deal of creativity and retained staff, so they were also creating value for themselves, something that gets overlooked if you just think of value as “business value.”

That was interesting to observe, especially at a time when “being Agile” was held up to be the most important thing, and people were losing sight of why Agile was supposed to help us. I felt so strongly about this, in 2009 I presented a keynote at the Better Software conference: “What’s More Important: Being Agile or Creating Value?” I’m happy to see “value” as an overarching concept now on Agile projects, but we still have a ways to go. (There is more to value than just “business value” for example.)

Post-Agilism, as I observe it, is about freedom, about giving you and your team permission to experiment and figure out your current mix of processes, practices and tools to help create value. There is nothing wrong with Agile methods out of the box if they work for you. But if they don’t, or they stop working for you, don’t be afraid to experiment and find your own way, no matter what the Agile experts say. If what you do works, but your Agile coach doesn’t like it, seize your freedom anyway. Post-Agilism is about using what works for that release, and jettisoning what doesn’t.

That way of thinking is heresy to some of my Agile friends. They are great people, but they prefer if you do things the Agile way. I like to see a mix of old practices, new practices, and things in the middle on a team that is doing well. If whatever weird and wild combination of what they are doing works, that’s great. If it works and I haven’t seen it before, that’s even more fascinating. I don’t need to call it Agile or something else. It’s your process, name it what you want. Many of my Agile colleagues are more purist, like the modernist architects. It seems like they are saying: “We want you to create valuable software, but we think it is better if you do it according to the commonly accepted practices of this community, using these approved tools, techniques and practices.” While they might be right in many cases, I want to let people know they have the freedom to choose what they want as well, even if it isn’t something I or my colleagues personally like.

One of my colleagues told me about a team that had implemented Scrum, but were having some quality issues, so they implemented software inspections as well, a very old school tool. They had great success with this mashup or fusion of old and new. My Agile friends are rarely very supportive of this sort of thing, (it isn’t Agile) but I think it’s great. I love to see creative solutions that teams use to create great software, and value for themselves as well as the business. There is so much we can learn from others who do things differently. Furthermore, new technology changes the dynamics, and Agile methods were created in the 1990s, so some new technology projects find they need to adapt processes as well because they may not have the easy fit with Agile process or tool support they had when developing with older technology.

Another area of contention in the Agile movement for me is testing. Many Agilists think manual testing is a bad thing, that all tests should be automated. I prefer a blend, especially when humans are the customers of the software we develop, we need some human involvement, since they use the software. Especially with pervasive computing, like mobile technology, movement and human reactions to the technology are very important to capture, along with tech solutions like test automation. The technology augments, it can’t replace. I have also worked on systems that bridged different computing systems, and most of the testing was automated – our customers for our software were other computers. We still had some humans doing work though.

If labels matter to you, Post-Agilism has a home for you if the Agilists don’t like your weird mashup. If the Agile world works for you, then more power to you and your team. If you are doing something that defies categorization, then that is even better! Take pride in your individuality and uniqueness, don’t feel like you have to follow the crowd. The software we create should be valuable for all the stakeholders – that’s the most important thing, and all processes should help serve that, not the other way around. Be different. Be you. Do some amazing things, and then tell the rest of us about it.”

Originally published by uTest, 05/21/2013. Accessed 06/07/2013.

Read the entire interview here: Testing the Limits With Jonathan Kohl.