Welcome back to my 3-part review of Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. As a quick refresher, last time, in part 2, I took a look at what Meyer considers “hyped” about agile methods. In part 1, I took a look at Meyer’s take on what’s ugly about agile. This week I’ll take a look at what Meyer considers both good and brilliant about agile. Meyer considers these agile practices the cream of the crop and thinks they’ve done a lot for software development. I don’t see much difference in utility between what Meyer considers ‘Good’ and ‘Brilliant’, but I’ll review them as he’s categorized these practices.
Let’s take a look at the good stuff first.
1. Refactoring
MojoTech Assessment: We agree, this is good!
We refactor as part of our regular process. We use refactoring to consolidate duplicated code, to introduce simplifying abstractions, or to remove unnecessary abstractions. This process helps make the code easier to understand and more maintainable.
2. Short daily meetings
MojoTech Assessment: We agree, this is good!
We have daily standups with our teams. See my previous post on standups for why we think this is an important practice.
3. Importance of team communication
MojoTech Assessment: We agree, this is good!
We recognize that without good team communication, running a successful project is pretty much impossible. To facilitate this communication, we use Slack for the MojoTech team, Basecamp for larger discussions with our clients, and Pivotal Tracker for questions about specific development items.
4. Practice of identifying and removing impediments
MojoTech Assessment: We agree, this is good!
As part of the daily standups, we make sure to identify any impediments that are slowing down team members. If possible, we decide on a strategy for removing the blocker on the call. Otherwise, we take the discussion offline for further discussion. No matter what happens, we make sure we address the difficulty so that we can continue development as smoothly as possible.
5. Identification of sources of waste
MojoTech Assessment: We agree, this is good!
Similar to how we identify impediments on a daily basis, we try to identify sources of waste on a regular basis in our retrospective and planning meetings. We may decide to make a change to try and be more efficient. Making this decision in planning allows us to implement the change in a fresh sprint. We’ll then revisit the change in the subsequent retrospective to see if it made a noticeable difference.
Now let’s take a look at the brilliant to finish off the blog series.
1. Short iterations
MojoTech Assessment: We agree, this is brilliant!!
We’ve standardized all of our projects to use two-week sprints. We found that one-week sprints were too short to develop a meaningful velocity. One-month sprints turned out to be too long to have a good idea of what can be done in that period of time. This has the added benefit that our engineers and designers can easily jump into the two-week cadence on a new project without too much disruption of routine.
2. Continuous Integration/Regression test suite
MojoTech Assessment: We agree, this is brilliant!!
We swear by our tests, and we use Circle Continuous Integration on all of our projects. Circle ensures that updated branches pass tests on a remote environment before we even merge or deploy changes. This helps us make sure we don’t break features that previously worked and plays into #6 (delivering working software) below.
3. Closed-window rule
MojoTech Assessment: We agree, this is brilliant!!
This rule says that nobody, regardless of status, can add functionality during an iteration. We strive to define sprints during planning and leave them unchanged throughout. However, we recognize that important bugs or business driven changes may arise when we work on live software. As such, we allow for the possible addition of urgent fixes during the course of a sprint. When we do allow for this addition, we need to have a very good reason for doing so. For example, a bad bug may be pulled into a sprint because it affects the majority of customers and there is no workaround.
4. Time-boxing iterations
MojoTech Assessment: We agree, this is brilliant!! This principle states that the sprint ends on a given day, no matter whether everything has been finished. We follow this principle, and Pivotal Tracker even enforces this idea of iterations for us.
5. A clearly defined product owner
MojoTech Assessment: We agree, this is brilliant!!
For every project, in addition to the MojoTech Product Manager, we have a dedicated client representative (AKA Product Author) who can answer business questions and make decisions regarding priority of the different possible development items. When an engineer has a product or requirements question, they’ll ask the Product Manager. In the event that the Product Manager doesn’t know, they’ll go to the client representative for confirmation.
6. Delivering working software
MojoTech Assessment: We agree, this is brilliant!!
We base our entire business off this principle. Almost any software is more valuable than no software, so we work hard to deliver working software as early and frequently as possible, as I mentioned back in Part 2.
7. Notion of velocity and associated task board
MojoTech Assessment: We agree, this is brilliant!!
We use Pivotal Tracker for both of these items. Pivotal allows for estimation of features using points, and then it calculates an average velocity using the last three iterations. I would argue that the task board is actually more important than the velocity. We use it to not only reflect the state of what’s being developed, what’s being tested, etc. but also to prioritize a backlog of future items to be developed.
8. A test for every piece of functionality
MojoTech Assessment: We agree, this is brilliant!!
As mentioned above in the Continuous Integration section, we think testing is essential for any successful piece of software. We typically don’t add any new feature without adding associated tests. Sometimes we may decide to release the feature before the tests are written. In that case, we will write the tests (and potentially refactor) after releasing to make sure future additions don’t break what’s already there and working.
That’s a wrap! Don’t forget to check out Part 1 and Part 2 if you haven’t already! Let us know if you agree or disagree with our assessments.