I was eating dinner with my son the other day and he asked me for the meaning of “conundrum.” As I explained to him the definition as sort of an impossible problem to solve due to ironic or conflicting situations. He countered with a response like “It’s like having only enough money to buy the things you need versus what you want”. I told him that could be a practical conundrum to have. He then pressed for further conundrums and I realized we sometimes face moral conundrums on a daily basis like when your spouse or significant other asks you if they look tired. Do you morally lie to them so you don’t hurt their feelings or do you just tell them the truth knowing the repercussions? That’s when it dawned on me how much software development faces conundrums every day.
The need for speed and business agility has pushed us to implement short-term solutions for long-term problems. Will these new Agile trends like Scrum; DevOps; and SDET become the answer? Is this the right direction? I will be providing a series of posts that will hopefully put a new perspective on these trends as a possible step forward in solving for software development conundrums.
Let’s begin with the Agile movement and the defacto standard today: Agile Scrum. We know it all started with The Manifesto for Agile software development in 2001. It was a bold transformational announcement by the development community to come up with their four values and 12 principles. What would eventually happen was the typical capitalization of good ideas that become codified for the benefit of making money. The creation of Agile Scrum and its proliferation of certification workshops for implementing these values and principles have now become a cottage industry. I think we all know that mastery comes from years of experience; a two-day class won’t improve a person’s personality. I’ve seen first-hand so many Scrum Masters get kicked off projects because their personalities conflicted with the team. They become so enamored with the thought that following the practice of Scrum is more important than understanding the Agile values & principles. The concept of “doing” does not automatically transform to “being”. People can easily follow practices, especially if they are mandated by management. However, to truly adopt the “agile mindset” will eventually take time. There lies another conundrum: do we wait to change our existing people or hire new people with that mindset? Blending different mindsets makes reasonable sense but it will ultimately be dictated by how receptive the existing culture and its norms are willing to accept the new employee’s persuasions. Unfortunately, Agile Scrum and all its guidelines does not address how you deal with existing organizational structure and cultures.
When traditional software development teams have a Project Manager, Business Analyst, Developer, QA and sometimes even UAT roles take Scrum classes, they come back confused with unexplained mappings to new roles. So, who falls into the Scrum Master, Dev Team, and Product Owner roles? The developer & QA before this trend had a sort of symbiosis relationship like the old adage “you scratch my back and I’ll scratch yours.” And now you’re telling us we all test? The business analyst who had problems with clearly articulating software requirements in a document now has the convenient excuse of less documentation via user stories. The project manager who was a command and control freak to begin with now has codified practices to force the team to comply. What? You don’t want to stand up on these daily stand ups? I’ll have to escalate this because you’re not following Scrum practices!
The new employee is struggling to learn our business domain and existing complex systems and can’t prioritize but was a product manager at her previous job so it makes her qualified as our new Product Owner/Manager. You can easily see how a movement of naysayers might jump on the bandwagon that Agile Scrum is not working. Still, this is what we have today in terms of any codified process for Agile.
Changing the corporate culture takes a lot of patience and time. What we can do is take the defined roles of Scrum Master, Product Owner, and Dev Team and apply them to how they fit into our existing culture and champion these agile values and principles. The Scrum Master can master an understanding of the team’s personalities, what motivates them, and what will build trust among each other. They become self-servant coaches and scrum practices are just guard rails to follow so that the team can eventually “be agile” by routinely practicing these good habits. The Product Owner is an important role in bringing the traditional software teams closer to the “user experience” and a focused approach to outcomes that bring value to the client versus just meeting another project deadline. The Dev Team is no longer bifurcated by a developer and a QA role since the more integrated and collaborative we become, the more incremental value we can produce through the so-called sprints – and quality is now shouldered on the whole team. Let’s just say Agile Scrum is now allowing us to “crawl” and the next mature step is to take what we have learned so far and learn to walk and eventually learn to run as we build up confidence with an agile mindset. The Agile movement is taking us in the right direction and it may have stumbled out of the blocks, but we will have to adapt and improve on the positives as we continuously move forward. With that I will close on this:
“When trying to introduce change in software engineering practices (or any practices, for that matter), it’s often better to work by addition, rather than subtraction. Instead of continually emphasizing what people are doing wrong, emphasize what they are doing right so that they will do more of it.” ~ Jerry Weinberg
