6. Is the rest of your organization ready for Agile? Developing a great product is half the story. Depending on your organization setup and practices, you will need to go beyond your development team to conduct beta program, develop sales collateral, train account teams, solution architects and technical support to sell and service the new product, develop customer education content, set up back-office systems to accept and process purchase orders, etc. If your development team has only recently embarked on Agile path, chances are the rest of the organization will need some help to understand how they can best help successful product launch in this setting.
7. Arbitrary deadlines. I hear a lot about time, as opposed to feature, driven nature of Agile development. At the beginning of our project we had to put a stake in the ground, decide on the product launch date. We picked a date that happened to coincide with a major trade show so that we could announce a new release there. The thought was Agile forces us to work of the ranked backlog and produce a working product at the end of each sprint, so in theory any date is as good as any other. The problem I see with this arbitrary approach however, you are not necessarily giving your team adequate time to develop and introduce to the market a winning product.
8. Size is not everything, or is it? Not all aspects of new software product development can be broken down into chunks of work that fit in one sprint and still make sense. Consider a user interface design. What could fit in one sprint may resemble raw database tables exposed to the end user. On the other hand a wireframe that has gone through multiple revisions and validations by customers may seem to be too big to fit into one sprint.
9. The “wisdom” of not thinking too far ahead. I often hear: “it’s just software”, “let’s fail quickly and often”, “we always refactor later”. Not so fast. Later, we don’t have time because we are working on something else, so we end up with poorly designed product, missing on important objectives. Alternatively we create mountains of technical debt or technical stories. A good example, manually creating tens if not hundreds of similar views vs. investing some time upfront to have the same views automatically created by the product using data driven approach.
10. Multiple scrum teams. We have seven scrum teams and despite our efforts to follow best practices, we all the time deal with stories spanning multiple scrum teams. This leads to all kinds of drawbacks: developers from one team struggling to find time to help another team, Product Owners not always ranking/prioritizing their backlogs with respect to these dependencies, creating bottlenecks and delays for other teams. At the end of the day, the end to end stories and workflows are more likely to be left unattended without anyone fully taking care of them.
I am not trying to paint Agile in dark colors here. However, I have to admit adopting Agile approach like any other organizational transformation is a challenge in itself. In my future posts I'll look to share with you how I dealt with some of these issues and what happened.
In the meantime, if any of the points I described in this blog resonate with your own experience please share with me and other readers.
Thank you for reading, and may the force be with you!
