Age of Product Author Meghana Bendre

TL;DR. I am an engineer and have been practicing Agile for several years now. And I do not despise Agile. My company has been successful in sustaining a multi-tiered Enterprise Agile environment. Why I Don’t Despise Agile I had posted some comments on the article Why Engineers despise Agile following which Stefan invited me to expand on it and make it its own post. Thank you for the stage, Stefan. Here goes: I. Line managers are simply that. They do not influence the delivery teams. In our multi-tiered Enterprise Agile model, Delivery teams follow Scrum. These teams are fed work by a Core Product team (think: Product Owner team) which is comprised of Solution Architects, Product Owners, Product Managers, SMEs and Program Managers. The Product team receives work from Portfolio team which includes Enterprise Architects, Product and Program Leadership. The Portfolio team identifies Initiatives which are tied to one or more Epics that the Product teams break down into one or more Features and high-level stories and the Delivery teams refine these stories and deliver them in 2-week sprints. Developers and testers on Delivery teams report to managers who may or may not be on the Product teams. The manager's job is to keep track of team availability and assist Scrum Masters of Delivery teams with capacity planning in addition to other managerial duties. Rarely, if at all, do these managers provide any direction to the teams in terms of what they can or cannot do within a sprint. That is determined solely by the work lined up by the Product team and accepted by the delivery teams within the sprint. II. Team boundaries are the people. Work is moved to people, teams are not re-organized to fit the work. We have several different products and traditionally one Delivery team has been aligned with one product. We are trying to change it so that one Product team now aligns with a family of Products and works with several Delivery teams. It may happen that in a given Sprint, there is more work for Product A than what one Delivery team can do in one Sprint. Some of that work is then shared across Delivery teams (under the guidance of the same Product team). This way Delivery teams are Product-agnostic, rather they are cross-trained across products and the Product team is not limited in their ability to prioritize work within a sprint. III. Predictability comes from stable teams. Story points and velocity have no meaning if teams change over time. Cross-training Delivery teams across products is hard and time-consuming and we aren't quite there yet. Every time a team takes on one or more stories outside their comfort zone, the velocity for that team within that sprint dips a little. We recognize that and attribute it to the learning curve knowing that as teams get familiar with the various products, it will be easier to achieve predictability. IV. Shared understanding leads to ownership not the loss of it. In crunch time, we have made the mistake of "just-in-time" story grooming (and are still guilty of it sometimes). This is when the Product team grooms stories with the Delivery teams during Sprint Planning. That is the worst possible time to groom stories. We have started making concerted efforts towards grooming stories beforehand as part of several grooming sessions throughout the Sprint. Not everyone from the Delivery teams attends these but the teams are well represented. This ensures the teams have a fair understanding of the stories lined up for the Sprint prior to Sprint Planning rather than being introduced to the stories then. We ultimately want to get to a point where Sprint Planning is simply an exercise in prioritization and, perhaps, negotiation based on capacity. V. Retrospectives are much more than a ritual. If there is only one Scrum ceremony that I can use, I’d choose the retrospective. When done right, this brings out the good and also the dysfunction in the team. Some of the changes we made, namely, the need to identify stories beforehand or recognizing that taking on work from a product that the Delivery team has not worked on before will result in a slower sprint, were the outcome of retrospectives. Line managers are not allowed to attend retrospectives lest they influence the team's observations and resulting action items. All this is not to say I work with perfect teams in an ideal environment. Far from it. We are a distributed team that works across time zones and are heavily reliant on tools for communication. We get very little face-time (although that may change since we are asking the offshore teams to set up cameras in their conference rooms). As Scrum Master, I have to make sure that stand-ups don't turn into boring updates directed solely at the Scrum Master; that people actively contribute to feedback in a retrospective instead of hiding behind multi-tasking. And that’s not easy given the distributed nature of the teams. As a Personal Kanban practitioner, I recognize the importance of limiting WIP and know when to reach out for help. The bad thing is that changes are still happening and the process is still in flux. It is not easy to change the ways of a mammoth. In-flight projects cannot simply stop the delivery cycle and take the time to re-align with a new process. But the good thing is that changes are still happening. Conclusion: With the help of a team of Agile coaches, our Enterprise Agile model is taking shape and I am happy to see the transformation being adopted across several business groups. Related Posts. Agile Failure Patterns In Organizations Why Engineers Despise Agile How to Kick-off Your Agile Transition (Part 1)

Follow us

Social Counter

Our most recent

Age of Product

Our posts by Meghana Bendre

I Am an Engineer and This Is Why I Don’t Despise Agile

TL;DR