These days I rarely run into anyone who has not heard about Agile software development methodology. It has become almost universally accepted brave new way of taking on the world. Let’s admit it, it’s hard to stay unaffected, and most of us embark on this bandwagon. The benefits and advantages are all too convincing, sweeping the minds of young engineers and seasoned executives alike.
With so much said and written about what makes Agile good, I’d like to contribute to the knowledge pool about some challenges you might face in adopting Agile, so here come my 10 picks, in no particular order:
1. The turnaround on customer feedback may be too slow. You read me right, taken too literally Agile can be used as an excuse for being slower than you need to be. Let me demonstrate this with an example. We work on large scale enterprise software destined for open market, so we don’t show end of sprint demo directly to 1,000s of potential customers. Instead Product Managers find a way to schedule customer demo to validate results of each sprint’s worth of work. In the ideal case, we can arrange such demo on Friday afternoon, at the end of the sprint. In reality the feedback does not rich the team till well into the next sprint. By the time this feedback is converted into a user story with clear acceptance criteria, the earliest the team can take this on is in the following sprint, i.e. nothing to show for 2 sprints. In our case this translates to 6 weeks for something that could have taken an engineer a couple of hours to correct. This inability to react fast is becoming more impeding as the project nears completion.
2. You may end up developing the wrong product faster than you would otherwise. Okay, overall Agile can help speed things up, but here is another catch. If you don’t have enough seasoned Product Managers able and willing to take on the Product Owner role, be prepared for someone else to step into these shoes. Whoever turns up in the Product Owner’s role is responsible for day to day guidance for their scrum team, dictating essentially what gets done and what does not (the pitfalls of engineering driven organizational cultures has been a well-studied topic).
3. Technical stories. I find developers like the idea of measuring team’s velocity by describing work that needs to be done in form of a user story added to the team’s backlog. From my point of view however, this is not a real user story, but a technical story. Why is this distinction important? Because in my experience, the Product Manager in the role of Product Owner, and by extension majority of real world customers, would not understand the essence, let alone the value of this type of story. This begs the question, how can a Product Owner rank such story on the backlog? If there are too many of these stories on the backlog, can the Product Owner still claim the ownership of the backlog, or is this now a development team who decides what to work on next?
4. Underperforming super stars. Don’t be surprised to find your former top performers struggling in the new Agile culture. These seasoned developers have long basked in the glory of their superiority, and may find it less motivating to learn new roles, and to listen to the arguments of junior team members. In short, someone used to be star on the team will not fit in naturally in supporting role, or don’t expect Many Ramirez to thrive at pinch hitting.
5. Generalists vs. Specialists. On a related note, Agile encourages erasing functional demarcation lines, asking everyone on the team to be able to work on any part of code, to be able to test, and contribute to the user documentation. The reality is, not all of us are equally good at everything. Taken to extreme this normalization of expected contribution leads to mediocre results. Just imagine the User Interface developed by color-blind database architect and IEEE network engineer who have neither talent nor desire to be good at GUI design (and let’s not go to Manny Ramirez pitching skills).
More to follow...
