The Human Element of Agile Development

It's been 10 years. Wow. 

10 years ago, my development organization (at the time) embarked on its first journey into Agile Development. I doubt we were the first organization in the company to transition, but we certainly weren't the last. The transition itself was probably more exciting for some than others, but it wasn't a stretch to detach myself from the Waterfall Development pattern and other approaches we had employed up until that point. 

So here we were with a 'shiny' new approach to developing software (or anything really). So what?

Focus on the End-User

Unsurprisingly, guessing what end-users were willing to pay for didn't always lead to success. The same applied for when we only engaged target audiences early in the process. Call it ignorance or arrogance, but we had to change. When time really is money, we can't afford to repeat what we need to get right in the first place. 

Simply put: We were missing the mark.  

But how were we going to fix this? Was transitioning to Agile the solution? Honestly, only using Agile practices and principles would never be a silver bullet, but it did bring something markedly different. It wasn't just organizing the work better. It wasn't just the notion of time-boxed Sprints/Iterations. It was the human element in all of it. Specifically, Agile focused us on developing features with our target end-users. Stop. Read that again.

 "...developing features with our target end-users"

No more hypothesizing. No more limited engagement with our target users. Complete end-to-end engagement with our users from design to delivery. Try the following:

• Engage end-users and listen to their direct (and indirect) feature requests. Pay close attention to their pain points. Make a conscious effort to share these details with the Product Owner.
• Leverage playbacks to show off design ideas and get feedback early.
• Establish a well-organized Alpha and Beta program. Avoid getting too deep into a release without making deliverable available for feedback.
• Demo via social media. Leverage relevant channels on YouTube and share via Facebook, Twitter, LinkedIn, etc.

Focus on the Team

So after many years of Agile, it started to iterate over itself. Lean Software Development grew in popularity and Project Managers were starting to integrate many of those practices with their now well-experienced Agile Development organizations. After all, Agile's core tenants are to learn and improve constantly. As a result, these approaches largely merged their best practices together and we now have what I call Agile 2.0. 

In short, this new form of Agile brings a much more value-centric and waste-adverse mentality. The renewed focus on the human element remains, but in an expanded form. The original approach of engaging our end-users throughout the life-cycle hasn't changed. It's just as important than ever; however, the focus on the Development Team becomes much more of a priority.

Let's be clear: It's no longer sufficient to cobble together teams with talented individuals with good leadership (including management) and send them on their way.

Self-directed teams: Good, but also not enough.

So what is a team supposed to do and how are they supposed to act? 

The team has to evolve from being a band of hard-working, bright individuals working on their own deliverables to a team functioning as a single entity with a common purpose. Consider Past, Present, and Future responsibilities:

Technical Debt (Past) - Everyone is responsible for technical debt. Identify it. Prioritize it. Plan it. Eliminate it.

Deliverables (Present) - Everyone is responsible for committed deliverables. Everyone must be invested in high-quality, on-time deliverables regardless of who gets treated as the 'assigned owner(s)'.

Vision (Future) - Everyone should actively participate in defining where the product/service is going, how we might get there, and why.

Agile 2.0 highlights the need for shared understanding, paying attention to the collective mood, communicating quickly, and more. At the end of the day, you need a team "hyper-collaborating" and arguably 'bonded'. Let's be honest - this might make some people uncomfortable, but the goal is to establish a team that wants to work with each other because they trust their peers (and leadership) deeply, enjoy the inviting environment, and feel empowered - all while having fun along the way. Imagine that.

The following Agile practices are just a few examples how teams can work towards this level of engagement:

• Establishing a social contract
• Stand-ups (combined with team-wide drive to resolve issues and generate collective progress)
• Using Mood Marbles to identify low morale. This requires action by relevant parties to address situations.

Note: In a separate blog, we'll dive deeper into the role of leadership (managers and non-managers) here. I guarantee the information will surprise you. ;)

Caution: If the team isn't working closely, everyone should be asking 'Why'. Recognize it's a tough problem to solve because you may be asking individuals to function in a manner they're not 100% comfortable with. That's OK - accommodate. Find common ground. Do not push them in a manner that will be interpreted negatively. This runs the risk of losing the many other gains made with the team. 

More Than Business...

It's enjoyable watching companies and others grow with Agile Development. For me, it's been 10 years and who knows where we'll be in another 10. While we must be a successful business, we can't lose sight of the people involved in the development process. Agile, intentionally or not, delivers on this need. 

I'm going enjoy some virtual cake to celebrate (at least) 10 years of personal Agile Development. Don't worry - I like to share. ;)

-Jason

About The Author

Updated 3/13/2021: Jason Bouknight is a veteran IBM development leader with deep technical and management experience. He has proudly served other IBMers for 20+ years and is always willing to help transform teams to make them more productive. Currently, he's a Development Manager for the IBM Enterprise & Technology Security organization. He works in RTP, NC and can be contacted via LinkedIn and email ([email protected]).

Disclaimer: The thoughts and opinions here are solely those of Jason Bouknight. No representation, either directly or indirectly, by IBM or other employers is implied.

Image Credits

• “The Journey” by evan courtney is licensed under CC BY 2.0
• “Darts” by John is licensed under CC BY 2.0
• “People team meeting Holiday Extras” by Holidayextras is licensed under CC BY 2.0
• “chocolate cake” by Salvatore Dalia is licensed under CC BY 2.0