Welcome back to my three-part review of Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. As a quick refresher, last time I took a look at what Meyer considers "ugly" about agile methods. This week I’ll take a look at what Meyer considers "hyped" about agile. Meyer considers these agile practices neither helpful nor hurtful to building impactful products. While many of these practices can be beneficial, they need to be examined on a project-by-project basis to ensure that they are applied appropriately.
And off we go with the hype!
1. Pair programming
MojoTech Assessment: We agree, this is hyped...
Often times this is a great resource for our developers who are stuck or need help learning a particular piece of the code. This practice works particularly well when a feature needs both front-end and back-end work. The two developers can work together to identify questions, flawed logic, and bugs that they wouldn’t necessarily see right away while working alone. However, we recognize the need for developers to put their headphones on and get into the zone. Sometimes a couple of hours of sustained effort is all it takes to bang out a great new feature or a helpful refactor.
2. Open-space working arrangements
MojoTech Assessment: We agree, this is hyped...
Meyer’s point is that “There is no single formula for the layout of a working environment" (Meyer p.152). While we clearly love our open layout (check out this showcase of our new space here), we also have plenty of small quiet spaces separate from the larger rooms with TVs where more lively discussions take place. Different engineers work best in different environments, and while one might excel in an open environment with a lot of stuff going on, another might need a quiet, distraction-free space to write good code. Having all types of office space allows all of our engineers to find a workspace that meets their needs.
3. Self-organizing teams
MojoTech Assessment: We disagree! We think this is a good thing.
On most of our projects, the engineering team has agency to choose stories and make technical decisions within the constraints of our client’s business. As Product Managers, we recognize that our engineers are the experts on the code, the architecture, and the technology. If we can let them make those decisions, our products will be better and our teams will be happier.
4. Working at a sustainable pace
MojoTech Assessment: We disagree! We think this is a good thing.
We work hard with our clients to set and reach development goals. We recognize that clients come with certain time and budgetary constraints, and we work within those to provide the best product we can. We can’t do that if we constantly over-promise, under-deliver, and scramble to catch up. That is, by definition, unsustainable. It also makes the entire team constantly stressed, anxious, and unhappy. Instead, we aim for steady delivery of new functionality at a rate that we can sustain sprint after sprint. There are times when we put in a little extra work to hit a release deadline or to finish off a new feature, but they are few and far between.
5. Producing minimal functionality
MojoTech Assessment: We disagree! We think this is a good thing.
We constantly work with our clients to clearly define the scope of their initial products so that they can release. The discussion with our clients usually revolves around when we should release a product we’ve built. Usually we view it as releasable well before our clients do. We almost always advocate for releasing early and with minimal functionality for a number of reasons. Especially for a new company, the initial product is just a guess at what people want. With a smaller set of functionality, our clients have more flexibility to change paths as they learn more from their audience.
6. Planning game, planning poker
MojoTech Assessment: We agree, this is hyped...
It may work fine for some teams, but estimating is part of being an engineer, and we probably don’t need to ‘gamify’ it to do it professionally. We do, however, make sure all team members participate in planning and estimation.
7. Members and observers
MojoTech Assessment: We agree, this is hyped...
This distinction really provides no value to our clients or us, so we don’t use it at all.
8. Collective code ownership
MojoTech Assessment: We agree, this is hyped...
We take this on a case-by-case basis. On some projects, certain developers may know the most about certain pieces and we would expect them to handle changes to that part. In most cases any engineer can touch any piece of code. Our peer code review process ensures that even if they did make a serious error, it would be caught well before causing any issues.
9. Cross-functional teams
MojoTech Assessment: We agree, this is hyped...
We encourage our developers to have a good amount of general experience across all pieces (and languages) of the apps that we build. However, there is a time and a place for truly deep knowledge. Depending on the area and intricacy of need, one developer at MojoTech might provide more insight and education than another. Given this dependency and the small, self-organizing teams we use, a general policy is unhelpful.
That’s all for Part 2, and don’t forget to check out Part 1 if you haven’t already! Let us know if you agree or disagree with our assessments.
Stay tuned for Part 3 where I review Meyer’s thoughts on what’s good and even brilliant about agile.