The continued success we’ve had at Apprenda is the result of the recruitment of top developers, and our prospective hires love hearing about Apprenda’s unique development and testing structure. If you are looking to join a smart team, we’re hiring! Otherwise, our process is something worth taking a look at for staying agile, innovative and on-task.
Apprenda started our Agile journey by following Scrum practices and, after 18 month or so, we transitioned into a mix of Scrum and Kanban that fit well with our team size and maturity level. In essence, we are an Agile team, although I feel it is important to note that we don’t follow ALL Agile practices; instead, we follow only those that get us the most bang for our buck.
At the core of it, we have a continuous integration process and focus a lot of effort on test automation. Additionally, we don’t follow XP or TDD; not because we don’t believe in them, but because we are happy with the results we are getting in our current approach and have found a harmonious balance between quality, velocity, sustainability and our Agile maturity that, at this point in time, we are comfortable with.
Let’s talk details: Our R&D team is divided into two main areas: Development and Test & Release. Every morning we do standup meetings to review progress, status updates, unblock dependencies, evaluate our Kanban Boards and discuss any potential regression that might have been introduced the previous day. This meeting should never last more than ten minutes and it is one of the reasons why its actually conducted standing up.
At Apprenda’s onset we were a very traditional Scrum team. Our Sprints were 2 weeks long; a planning meeting on the first Monday marked the beginning of the Sprint, and a retrospective meeting on the second Friday marked the Sprint’s end. We worked diligently to process the Backlog and plan the iteration, breaking up the work so that we delivered continuous improvements, and potentially shippable code, at the end of every time-box. Our velocity was around 58 percent and things seemed to be progressing nicely. Our deadlines were being met and the quality of our product improved, as well.
Behind the scenes, however, there were several dysfunctional issues at work, which led us to stop doing fixed time Sprint iterations and adopt Kanban, instead. The particulars of the referenced issues are fodder for a later post.
Kanban, with a side of Scrum
We didn’t move entirely away from Scrum, as we still do employ several Scrum practices, but we amended our process to work well with Kanban, similarly to how many other teams perform. We still employ fixed time iterations for retrospectives (a retrospective is held every 2 weeks) and for releases (a shippable release every 2 weeks) however we no longer commence Sprints. While this may not seem like a noticeable difference, the main variance is that we don’t artificially plan functions that have to be accomplished within the scope of a Sprint. Instead, work on Stories occurs continuously in an easy, sustainable manner, making its way into releases when finalized so, in essence, a release will include whichever functionality was completed after the prior release.
This means no more time spent on Sprint planning meetings, no more breaking up functionality artificially to deliver continuous improvements on a Sprint timeline that often is unnatural to the Stories, improved quality as a result of no longer rushing tests to complete by a Sprints conclusion and, consequently, a much more sustainable, happy development environment for everyone involved in the process.
It’s all about Balance…
Our system works due to several factors. We’ve identified a number of work item types (stories, tasks, enhancements, bugs, etc) and we usher them through slightly different workflows in our Kanban boards, which are largely based on ideas that have come out of past experience.
We’ve also implemented a Costing & Priority system which gives us an idea of effort and expected deliverable dates, in addition to assisting us in striking a good balance between working on interesting new functionalities while maintaining the platform stable. Not unlike what is possible in Scrum, we “T-shirticize” stories from x-small to x-large (xs, s, m, l and xl), thereby prioritizing work from lowest to highest.
The breakdown of our work items looks like this: a Story is the typical Scrum Story expressed in a form resembling: “as x, I would like to do y, to address z.” These represent business scenarios that are defined and prioritized by our product team and include acceptance criteria to consider a Story complete.
A typical Story will include some background information to explain the scenario and a set of acceptance criteria and notes, as well as wireframes, to help visualize the concept. Once a story is accepted by a development team, they plan the implementation and task out all the particulars necessary to meet the acceptance criteria. Tasks originate with the developers and are only relevant to developers.
T-Shirt sizes represent a high level estimate on the cost of story implementation. We understand that as an approximation there is variability on what it will actually take to implement the work, but we are comfortable with that fluctuation. The goal is not to have an exact date when something will get finished, but to generate a rough idea of the effort required to complete it once it is begun. The following defines the meaning of the sizes:
XS: The story can be completed within 1 to 2 days
S: The story can be completed in less than 1 week
M: The story can be completed in 1 to 3 weeks
L and XL: The story is too large to estimate and we need to break it down
We employ priorities determining when to work on items and as a result we came up with the following meanings for our priorities:
Highest: Any issue that causes total loss of service to the platform or the inability to complete a major workflow or is a security hole
High: Any issue that causes an inability to complete a minor workflow or that materially affects the expected results of a major workflow
Normal: Any issue that materially affects the expected results of a minor workflow
Low: Any issue that causes minor unexpected results to a workflow
Lowest: Any issue that is cosmetic in nature
Developers work on Stories through task execution. At the same time, Bugs and Enhancements are being reported and prioritized accordingly. The way developers know what to work on next can be summarized in the following ways: Highest priority: Signals the development team to “drop whatever you are doing right now and attend this ticket immediately”; High priority: Signals to the development team to attend this ticket as soon as they complete the task that they are working on. Notice that it doesn’t say the story, but merely the task (which is a small subset of a story); Normal priority: Signals to the development team to attend this ticket as soon as the story is completed.
Most business logic bugs would fit into this priority as well as enhancements that can’t wait until a later hardening date; lastly we have Low/Lowest priorities which essentially mean don’t work on them until they become higher priority.
If any of the above information excites you, and you are passionate about building quality software, we’d love to hear about you! Send me your resume to asultan at apprenda dot com.
Cheers and I hope to meet you soon!