We swear by our tests, and we use Circle Continuous Integration on all of our projects. Continuous Integration/Regression test suite 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. One-month sprints turned out to be too long to have a good idea of what can be done in that period of time. We found that one-week sprints were too short to develop a meaningful velocity. We’ve standardized all of our projects to use two-week sprints. MojoTech Assessment: We agree, this is brilliant!! Now let’s take a look at the brilliant to finish off the blog series. We’ll then revisit the change in the subsequent retrospective to see if it made a noticeable difference. Making this decision in planning allows us to implement the change in a fresh sprint. We may decide to make a change to try and be more efficient. 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. No matter what happens, we make sure we address the difficulty so that we can continue development as smoothly as possible. Otherwise, we take the discussion offline for further discussion. If possible, we decide on a strategy for removing the blocker on the call. Practice of identifying and removing impedimentsĪs part of the daily standups, we make sure to identify any impediments that are slowing down team members. 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. We recognize that without good team communication, running a successful project is pretty much impossible. See my previous post on standups for why we think this is an important practice. This process helps make the code easier to understand and more maintainable. We use refactoring to consolidate duplicated code, to introduce simplifying abstractions, or to remove unnecessary abstractions. We refactor as part of our regular process. MojoTech Assessment: We agree, this is good! Let’s take a look at the good stuff first. 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. Meyer considers these agile practices the cream of the crop and thinks they’ve done a lot for software development. This week I’ll take a look at what Meyer considers both good and brilliant about agile. In part 1, I took a look at Meyer’s take on what’s ugly about agile. As a quick refresher, last time, in part 2, I took a look at what Meyer considers “hyped” about agile methods. Welcome back to my 3-part review of Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. Part 3: A review of “Agile! The Good, the Hype and the Ugly.”
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |