I have spent many years in software development and when I was formally introduced to Agile, I really enjoyed it much more than being in a Waterfall system. I was able to be much more productive and focus more on writing code than focusing on requirements gathering and other paperwork. Instead of having to worry about my release being successful after 3-6 months of going through the Waterfall process, I saw results of my work within 2-4 weeks in production in an Agile implementation with continuous delivery. I was able to get feedback on a portion of my work much quicker.
Agile Implementation Differences
Most every Agile implementation at each company I have worked at who mentioned they follow Agile processes, have some differences (or very different). Some have more specialized roles than others, some incorporate pair programming and some unfortunately have their old Waterfall-based processes they hold onto within their Agile implementation.
Common Agile Systems
These are the four major types of Agile where companies draw concepts from for their implementation.
Scrum – structured sprints, defined roles, ceremonies
Kanban – continuous flow, visualizing work in progress
Lean – eliminating waste, maximizing customer value
Extreme Programming (XP) – engineering practices like pair programming, TDD, continuous integration
Common Agile Roles
Agile teams may be more specialized with most of these roles listed below, where generalized teams will only have a few. The titles may vary.
- Tech Leads / Architects – ensure technical quality and scalability.
- Product Owner / Manager – grooms and prioritizes the product backlog, bridges business needs with the technical.
- Scrum master – removes blockers, helps to keep the team aligned with core Agile principles and facilitates Agile ceremonies.
- Software Engineers – code the features, collaborating with BAs and QAs.
- Quality Assurance Engineers – tests the features to ensure requirements are met and maintaining quality.
- Business Analysts – refine epics into user stories with the Product Owner, Tech Lead and Solutions Architect.
A specialized Agile team has most of these roles. A generalized team have only a few, more combined roles like a Team Lead also acting as a Business Analyst, Scrum Master and Architect.
Balancing the Agile Team
Through my experience, I’ve seen Agile team imbalances and the harm on productivity, communication and growth. In highly generalized team, certain combined roles can create a bottleneck for the whole team. The Team Lead role was typically combined with the Scrum Master, Architect and Business Analyst roles, causing what could be done in one sprint into two or more due to the unbalanced workload for a key role.
However, highly specialized teams could be siloed enough to limit collaboration and learning. The healthiest teams are more balanced to prevent overload and allow for more feature delivery.
Lessons Learned
Don’t overload key roles. A Team Lead with multiple roles can become a bottleneck. Spread around the team functions more equally.
Follow Agile principles. Resist keeping old Waterfall processes as it runs counter to what Agile product development is used for.
Pseudo-Agile. Just a stand-up meeting alone doesn’t make a team following Agile. It’s about delivering features quickly in an iterative format based on feedback.
Conclusion
In my career, the most successful Agile teams were balanced with the workloads while implementing certain functions of Agile to improve iterative software delivery. It helps to create less waste and delivery quality value sooner.
Leave a Reply