At MojoTech, we constantly evaluate our processes and tools to improve the way we build great products for our clients. We follow the Agile Methodology but employ its various techniques dependent on the needs of an individual project. Opinions regarding these techniques can vary immensely, so I, along with my fellow Product Managers, recently read Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. Our aim was to brush up on our agile best practices and make certain we were avoiding its pitfalls. As a team we agreed with many of Meyer’s points, but we also found that in many cases, "it depends". I’ll take you through a three-part series of blog posts assessing Meyer’s points on "the good," "the hype," "the ugly," (and as a bonus, "the brilliant"), and whether our team agrees, disagrees, or feels it’s contingent upon the situation and context.
First up, the ugly!
1. The outright rejection of any upfront tasks
MojoTech Assessment: We agree, this is ugly.
We spend a fair amount of time getting to know our clients and plan their products before starting any development work. This upfront work is instrumental to running a successful project. We use this time to make important early decisions: the team size and make up and what technologies we’ll use. Spending this time early on ensures we have staffed appropriately, and that we have a solid foundation for what we build moving forward.
2. User Stories as a basis for requirements
MojoTech Assessment: It depends...
Meyer’s point is that User Stories can’t replace domain abstraction. We agree that stories don’t replace domain abstraction. However, we believe that successful software is both user focused and opinionated. User Stories accomplish these goals by focusing on the value provided to users, and by forcing the team to be opinionated about which stories provide the most value. We write our User Stories in terms of the abstractions that already exist or are to be built into the product.
3. Feature-based development and the ignorance of dependencies
MojoTech Assessment: We agree, this is ugly.
When we plan our sprints, spending time discussing how a feature plays with the other parts of the system and whether something has prerequisites, allows us to more accurately estimate how long it will take to build. Failing to have this discussion for a new feature means that we will discover how it connects with the rest of the system while we develop. This slows us down because it takes time to reconcile what’s already been built with how it needs to interact within the existing software.
4. Rejection of dependency tracking tools
MojoTech Assessment: It depends...
As stated above, we track dependencies, but we don’t use separate tools to do so. Instead, we use Pivotal Tracker tags to track this type of dependencies. Tools like Gantt charts may be useful when task estimation and timing can be very precise and accurate, but for us, things change so often and so quickly that the effort to constantly update something like a Gantt chart would not be worth the value gained.
5. Rejection of traditional manager tasks like assigning tasks
MojoTech Assessment: It depends...
For us, it really depends on the project. For teams that have been working together for a long time, our engineers can very easily choose their stories and do the task breakdowns themselves. In other cases, we as Product Managers rely on the project’s Technical Lead to assign stories that we think each engineer can reasonably tackle.
6. Rejection of upfront generalization
MojoTech Assessment: It depends...
This really depends on our client and the type of product we are trying to build. We do our best to build extendability into our software to the extent that the time investment to do so does not significantly change the time it takes to build the desired functionality. We talk a lot about the quality-speed dial and how to tune it appropriately for each project. A young startup with very limited funding runway needs to get out features so they can perform user tests and learn as much as possible as quickly as possible. This means tuning more towards speed while sacrificing quality and extendability. If our client has a more established business and a longer runway for funding, we will slow down to build more extendability into their system, making development of features easier down the road.
7. Embedded customer
MojoTech Assessment: We agree, this is ugly.
While we think that talking with customers is a necessary activity to do as often as possible, we know that having a customer embedded on the product development team is simply impractical.
8. Coach as a separate role
MojoTech Assessment: We disagree
Meyer’s point here is that “Good development requires not just talkers but doers.” We agree with that sentiment, since our entire company is built around having doers. However, instead of having a Scrum Master type role for each project, we have a dedicated Engineering Mentor. Having a full time coach helping those doers become better engineers provides much more value to our company and our clients than having that senior engineer developing full time.
9. Test-driven development
MojoTech Assessment: We agree, this is ugly.
Meyer’s point is that the dogmatic approach of constantly focusing on the latest test loses sight of the broader perspective of the system. While we do spend time making sure our test suites cover the entire product, we also make sure new functionality works well with what’s already been built. While passing tests indicates a certain level of working software, our clients judge us, rightfully so, on whether or not what we’ve built improves their product. They measure this using higher level metrics like active users, new signups, revenue, and the like, not by how many tests pass. We use tests to ensure we don’t break anything while we build software, but they aren’t the end all, be all.
10. Deprecation of documents
MojoTech Assessment: It depends...
In many cases we are building non-mission critical pieces of software for our clients that need minimal, if any, documentation. Our feeling is that unless it’s required for certification or as a specification for an integration, it’s probably unnecessary.
That’s all for now. Let us know if you agree or disagree with our assessments. Stay tuned for Part 2 where I review Meyer’s thoughts on what’s hyped up about Agile.
Skip to: Part 1: The Ugly, Part 2: The Hype, Part 3: The Good and Brilliant