If you’ve been following my blog, you know that I have been using an adaptation of Scrum for a one-person team to manage my graduate project. I (and others) call this “Personal Scrum.” The semester-long experience was very positive. The Personal Scrum methodology was an excellent tool to get the work done.
Personal Scrum Definition:
Personal Scrum is an Agile methodology that adapts and applies Scrum practices to one-person projects. It promotes personal productivity through observation, adaptation, progressive elaboration, prioritizing and sizing work, and time-boxing.
Personal Scrum vs. Scrum:
Let’s compare aspects of Scrum as defined by the Scrum Alliance to those of Personal Scrum.
Scrum’s 3 Roles:
A Scrum team has three roles: Product Owner, Scrum Master, and Team Member. The Product Owner is responsible for the business value of the product and decides what is built. The Scrum Master is primarily a facilitator and enforcer of the Scrum rules. The Team is self-organizing and cross-functional. The Team decides how to build what the Product Owner wants and goes about doing it.
Obviously, since Personal Scrum is a methodology for one-person teams, one person must fulfill all three Scrum roles. This is not as difficult as it may sound, because Scrum’s ceremonies typically focus on one role’s responsibilities at a time.
Scrum’s 4 Ceremonies:
The Scrum Alliance lists four ceremonies (think “group activities”) used in Scrum: Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. Mysteriously missing from this list is Release Planning, perhaps because it is typically not a regularly scheduled event. Exactly what these ceremonies entails is beyond the scope of this blog post, but each of these ceremonies are reflected in some way in the Personal Scrum methodology. I used blog postings for sprint planning, sprint reviews, and sprint retrospective. I tracked my daily work and release plans in Excel. It is important to observe and delineate these activities.
Scrum’s 3 Artifacts:
The Scrum Alliance lists three artifacts used in Scrum: Product Backlog, Sprint Backlog, and Burndown Chart. Each of these artifacts are used in exactly the same manner in Personal Scrum.
- Initially, I thought I could accomplish way more in one semester than I was actually able to undertake. The Personal Scrum techniques helped me to focus on the most important work first. Velocity tracking and release planning helped me to identify early on that I was unlikely to finish all that I had started out to do. I was able to revise my goals and plan accordingly.
- I found that estimating work in terms of time is exceptionally hard, especially when you have no team members to help and few of your tasks are similar. I learned to expect my time estimates to be wrong.
- Estimating in story points is easy and effective.
- I tried one-week and two-week sprints. For me, one-week sprints were much more effective. One-week sprints have smaller scope. The shorter-term deadlines made the goals and tasks more salient. I found myself to be more diligent on the one-week sprints. The downside to one-week sprints is that you spend a greater percentage of your available time on planning and reporting; less time is available for actually doing the work.
- Burndown charts have to be done in terms of estimated hours of work accomplished rather than story points. One person is unlikely to finish more than a couple of user stories per one-week sprint. Burn down hours only when a task has been fully finished (“done done”).
- Use story points to track velocity. Use velocity to do release planning. Release planning is a great way to project what you are likely to be able to accomplish by a certain date (the end of a semester for instance).
- Committing to posting your sprint plans, demonstrations, retrospectives, and burndown charts online is a great way to keep motivated and accountable. I found this to be an even greater source of motivation than having a faculty advisor. If you know your work is going to be visible in a very public way, you will be more likely to do your best work.
The entire project has been chronicled in the materials below. To my knowledge, this is the first fully documented instance of a Personal Scrum project, and it is certainly the most open. My code has been released under the MIT License, and the Excel workbooks and blog posts are released under the Creative Commons Attribution-ShareAlike 3.0 Unported License.
- Vision Statement
- Sprint #1
- Sprint #2
- Sprint #3
- Sprint #4
- Sprint #5
- Sprint #6
- Sprint #7
- Sprint #8
- Sprint #9
- Release #2
InformedIt is imperative that the person in the Product Owner role have a firm understanding of the business processes and needs that are being addressed by the software to be built. A newbie to the business would not be a wise choice for the Product Owner role. A subject matter expert would be a better choice. A person that not only has intimate knowledge of the business but can also teach others well is necessary. The Product Owner has to be able to explain the business to the scrum team. Because the Product Owner is responsible for the project’s return on investment, he or she needs to be well enough informed that they can judge the business value of each user story.
EmpoweredLike George Bush, the Product Owner must be the “decider,” empowered to make the call when questions arise. The Product Owner is the one person on a Scrum project that gets to decide what is built (but not how it is built). One cannot hold a Product Owner responsible for a project’s return on investment without also granting that person the authority to make decisions that impact the ROI. Furthermore, having one person designated to make decisions can greatly improve a project’s velocity. If developers have to convene, address, and negotiate with some sort of council or project steering group each time a decision needs to be made, the scrum team will have difficulty removing roadblocks efficiently.
AvailableThe Product Owner role is a full-time job. The person serving in the role should be dedicated to the project. The Product Owner must be available to explain business concepts, processes, and needs to developers when questions come up. When decisions need to be made, the Product Owner must be ready to decide. When features need to be demonstrated and approved, the Product Owner must be available. Whenever a scrum team has to wait on Product Owner, the team’s velocity is negatively affected and money/time is wasted.
PreparedBetween explaining, deciding, and approving, the Product Owner must be busy grooming the product backlog and release plan. Without a properly prepared backlog, a sprint planning meeting is a non-starter. An unprepared Product Owner can be the biggest source of delay to a scrum team. The Product Owner has an obligation to be ready prior to each sprint’s planning meeting so that the team can begin the sprints on the right foot.
A co-author of the “Manifesto for Agile Software Development” and “The Declaration of Interdependence for Modern Management,” Alistair Cockburn is a self-proclaimed “project witchdoctor and IT strategist” who holds a PhD in methodology from the University of Oslo. In the 1990s, Cockburn researched and interviewed software development teams in efforts to define IBM’s methodology. The result is a family of lightweight, agile, project management methodologies he dubbed “Crystal”.
All of the Crystal methodologies can be described by a number of overarching themes. Crystal professes that no single methodology exists that is suitable for all projects. To put it more positively, different projects require different methodologies. Additionally, Crystal recognizes that the primary goal of a project is a successful delivery and that process is of only secondary importance. In light of these revelations, Crystal prescribes that one should use the leanest process necessary for the project to operate effectively. This family of methodologies places emphasis on people and communication, favoring the replacement of documentation with face-to-face interactions. While people are the most important element in any project, they are also the most variable. Consequently, the Crystal methodologies are designed to be flexible and evolutionary.
Crystal categorizes projects according to two primary characteristics. The first characteristic, criticality, refers to the severity of the consequences should the system fail. Criticality is described in four categories ranging from least to most critical: loss of comfort, loss of discretionary money, loss of essential money, and loss of life. The criticality of a system necessitates the level of safety measures required to ensure the system does not fail. The second characteristic, number of people involved, is measured by the size of the development team. The number of people involved in the project determines the amount of coordination needed for effective communication. When criticality is arranged along 4 segments of the y-axis and staff size along 7 segments of the x-axis, a grid (see below) is formed that can be used to select the appropriate methodology. The Crystal family is segmented into seven, color-designated methodologies by columns in the grid. These methodologies include, Clear, Yellow, Orange, Red, Magenta, Blue, etc. The criticality of the project determines the “hardness” of the particular methodology. Therefore, a 4 person project developing a life-critical system would use the Crystal Clear methodology with the highest level of safety measures (L6).
In contrast to most methodologies, Crystal methodologies are described in terms of project properties rather than procedures. More colloquially, Crystal focuses on the ends rather than the means. Targeting properties is a more effective approach as any one set of procedures may not produce the desired properties in every project. Furthermore, there may be multiple, valid procedures which might achieve the properties for a single project. Crystal identifies seven properties of successful projects.
- Frequent Delivery
- Reflective Improvement
- Osmotic Communication
- Personal Safety
- Easy Access to Expert Users
- Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
Of these seven properties, the first three are common across the whole Crystal family of methodologies. “Frequent delivery” refers to the practice of iterative development in which the project is organized into a series of iterations of no more than four months at the end of which running, tested, and usable code is delivered to the users. Frequent deliveries facilitate rapid and regular feedback. The property of “reflective improvement” refers to the process by which the team regularly reflects over what is and is not working and adjusts accordingly by adding and/or subtracting elements from the project methodology. This property mitigates variations in people, technologies, and requirements by evolving the methodology to suit. The third most important property is “osmotic communication” which means that information flows readily and richly with little disruption of individuals’ work. This kind of communication is commonly achieved through the co-location of team-members in the same room.
By providing a framework of flexible methodologies, Crystal is an antidote to the one-size-fits-all approach to software engineering methodologies. Stressing a less-is-more philosophy that emphasizes effective communication over rigid processes and documentation, this family of methodologies puts the focus of projects back on the elements that contribute more directly to success. Allowing the methodology to evolve over time ensures that Crystal methodologies will not be rendered ineffective by changes in a project’s environment. Overall, Cockburn’s Crystal presents a refreshingly human-centric suite of methodologies.