How to (not) manage a one-person software development project


As a consultant and as a lecturer I am constantly working on quality both on the softwareproduct and the softwareprocess. On the one hand I try to (let my colleages) deliver software using a small software factory, on the other hand I try to convince students to deliver sofware using the right process. This article will give some background on choosing the right process for a very small project-team (to be specific, a size of one) for a softwareengineering-project. This article is written mainly from the point of view of a lecturer, but I can’t help drawing parallels between education and “real” life.

Academy of Communication and Information Technology (ICA)

“HAN University of Applied Sciences’ Academy of Communication and Information Technology (ICA) offers state-of-the-art study programmes in the fields of Computer Science, Information Technology, Business Information, Media and Communication Systems.” [HAN10]

Although ICA uses a graduation-assessment based on levels of standardized competencies, there are five key aspects to consider:

  • Process: is the student capable to choose it’s own process and use it wisely?
  • Product: is the student capable to deliver the required product (mostly software, but can also be a report or a visual prototype)?
  • Presentation: is the student capable to present his product and process and answer questions about his own choices?
  • Report: is the student capable to write a structured report that contains the most important information about the project?
  • Reflection: does the student knows his own strengths and weaknesses and is he able to use his strengths and to minimize his weaknesses?

Before graduating, ICA students have followed a unique program with three semesters of their own choice. Each semester focusses on a specific professional task within the field of Computer Science, Information Technology, Business Information or Media and Communication Systems. Some tasks are better performed using Scrum, other tasks have a better match with Evo, Unified Process, UCD or Prince2. Most of the tasks are performed in a team consisting of five, so students don’t have that much experience in choosing a process for a one-person project like the graduation assignment which is performed by the individual student.

Because Process is one of the five aspects to determine whether the student succeeds graduating, they need more help in choosing the right process. Scrum is one of the most popular processes among students, however Scrum is also the process that is understood and applied badly by students and other junior professionals. The same applies more or less for Unified Process and other agile methods like Evo and XP: very popular, often misunderstood.

What process to pick?

At ICA several softwaredevelopmentprocesses are used during 8-week Software Engineering projects:

  • Scrum combined with XP best practices (semester Develop a Distributed OO Application, DDOA);
  • Evo (semester Make a High Performance Network Application, MPNA);
  • Unified Process (semester Develop an Information System, DIS).

Most students tend to stick to what they (think they) know, and I think that’s good when you’re a junior professional. That means that most of the students wil pick one of (or a combination of) the above mentioned processes. In the next paragraph Scrum, UP en XP will be discussed using a short introduction and some principles that can be used to determine what (not) to do.


Short introduction

Scrum was formalized as a softwaredevelopmentprocess in 1995 by Jeff Sutherland and Ken Schwaber. In Scrum, a team delivers a “potentially shippable product” every increment (“sprint”) of 2-3 weeks, using several recurring ceremonies, like the daily stand-up, sprint planning, sprint review and sprint retrospective, like described in Figure 1.

Recurring events in Scrum

Figure 1: Recurring activities during a sprint

The team consists of a:

  • ScrumMaster: “… primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences.” [SCR10]
  • ProductOwner: “… represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The ProductOwner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.” [SCR10]
  • Teammembers: “… has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.).” [SCR10]

Do’s and don’ts for a one-person project

It might look strange to run around in the field alone with a rugbyball in your hands, however with a pragmatic approach Scrum can be applied to a one-person project. Some principles also yield for “ordindary Scrum teams”:



1. Assign/find a ProductOwner. Let the customer-disharmony be his or her problem, not yours.

1. Be your own ProductOwner.

2. As a teammember be your own ScrumMaster:

a. Estimate work.

b. Manage impediments.

c. Log and re-estimate work and manage your velocity.

d. Use lightweight tooling like a spreadsheet or (a little less lightweight) dashboard.

2. Hold your own private daily stand-up, instead you could still pick a regular moment every day to manage impediments and (re)gain focus on your work.

3. Choose a fixed length for your sprints. You are the one and only developer so two weeks can be problematic.

3. Keep the sprint-length fixed, even when you’re not capable of delivering value through product increments. Also see 5.

4. Create a high level design on a whiteboard during the first sprint. Take pictures. Detail the design every upcoming sprint in case you build something difficult or risky.

4a. Create a big design up front (BDUF). Although you are the one and only developer and you need some structure, BDUFs don’t increase the business value of your project.

4b. Be a cowboy-coding idiot.

5. Focus on a architectural slice during a sprint, each slice should be able to operate independently of another slice.

5. Build your application completely layer for layer.

6. Write a manageable definition of done (DoD) [GUP08]. Focus on code complete with just enough design to keep your product maintainable with help of other parties.

6a. Freeze your DoD during the project. Tune the DoD during the sprints, after two of three sprints it should be solid.

6b. Cut down unittests. Although time saving, you need (automated) testcases every time there’s a nasty bug in your software. Because your team lacks reviewers, your testcases might be your safetybelt. Never cut down quality.

7. Perform Sprint Reviews. Show demo’s of your potentially shippable product and let a key user get some feeling of the product.

7. Use Sprint Reviews to “just show what you’ve got”. Remember, Scrum is about commitment, if you can’t commit, lower your amount of user stories, rethink your DoD of lengthen your upcoming sprints.

8. Use a fully integrated IDE (buildtools, versioncontrol, formatting, etc.).

8. Dress up a continuous integration environment. With a professional IDE you have sufficient tooling in most cases.

9. Concrentrate on two Scrum values: Commitment and Focus.

9. Be disrespectful to your customer representatives and hide all your problems.

10. Perform Sprint Retrospectives. Find out what you’ve done well (and what not) and how to improve. Adapt.

10. Think there is no need to change and that the world around you will change in favor of you.



Short introduction

Unified Process (UP) is a use-case- and risk-driven, architecture-centric, iterative and incremental software development process framework. There are several implementations or refinements of UP available, among which:

  • Rational Unified Process (RUP): developed by Ivar Jacobson, Grady Booch and James Rumbaugh when working for the Rational company, currently part of IBM. RUP is fact the first known refinement of UP, you could say that UP was retracted from RUP. Simply put: UP = RUP minus Rational tools, artifacts and templates that support the process (like versioncontrol, requirements management, documenttemplating, processcomposing, etc.).
  • Agile Unified Process (AUP): Simplified version of RUP, developed by Scott Ambler [AMB09]. AUP has less disciplines and conforms to the principles of the Agile Alliance.
  • Enterprise Unified Process (EUP): Instead of simplifications like AUP, EUP is an extension for UP, developed by Scott Ambler [AMB09-1]. EUP solves the problem of the lack of system support and eventual retirement of a software system, so new phases and new disciplines were added.
  • Open Unified Process (OpenUP): “OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.” [OPENUP09]

All refinements can be visualized in the same way, however the disciplines on the left may differ:


Figure 2: Iterative development in UP using phases and disciplines [UP10]

Being part of one of the first RUP-projects in the Netherlands in 2001, I found out that UP tends to be heavy-weight when you apply all the disciplines, roles and artifacts so the first thing we learned was how to make a good Development Case and Software Development Plan.

Do’s and don’ts for a one-person project

So, how do you pick your predefined flavor of UP and how do you tailor this flavor? Well, for a one-person project it figures that full EUP and RUP are not an option, OpenUP should be tailored to your needs and AUP could be the closest to what you need but could still need some adjustments. Regardless of the refinement of UP you want to apply, there are some pragmatic principles that apply:



1. Develop iteratively. All phases can be performed more than once, use risk as the driving factor. Create a Risk Plan.

1. Consider Inception as Requirements, Elaboration as Design, Construction as Build and Transition as Test. It’s NOT a traditional waterfall process. Instead, use Inception to determine whether your project is feasable and use Elaboration to build and executable architecture that proves your high-level design.

2. Use templates specificly for requirements management and software architecture.

2a. Re-invent the wheel.

2b. Use the templates in a dogmatic way. Instead, remove what you don’t need and add what you do need.

3. Manage your changing requirements, preferably using use cases. Create cross-references from use-case, through design, implementation and test to delivery. Obtain traceability, a small spreadsheet will do.

3a. Build software that does not relate in any way to the requirements. You want unhappy or even no customers? Please continue.

3b. Consider all your requirements equally important, they’re not. Instead, prioritize [DSDM10] and categorize [EEL05] them.

4. Use UML. Even for a one-person project use the following diagrams, preferable on a whiteboard:

  • Use Case Model (also write brief use cases, optionally create expanded use cases for risky or hard stuff) with stereotypes. Consider using smart use cases [HOO10] for better planning and estimation.
  • Class Diagram (Domain Model), you might skip the conceptual level, but invest in getting to know the business domain and think about assigning responsabilities to the right class.
  • Sequence Diagram, especially on the architectural-level [AMB09-2]. It helps you to identify components.

4a. Stick to the UML meta-model. Instead, create diagrams that illustrate the tricky parts of your software, if you need usecase-elements in a sequencediagram, draw them.

4b. Model all parts of your software, even the obvious ones.

4c. Reverse engineer diagrams from code and call it “design”. It can be useful to have a picture of how your software is structured, but I consider that as code visualization.

5. Track issues, like technical issues and project risks.

5. Pretend that nothing can go wrong. In a way, that can be the case when you’ve done this kind of project over and over and over, however: will you need process then?



Short introduction

Starting in 1996, Extreme Programming (XP) has grown to a broadly used agile sofware development method. XP emphasizes teamwork and states several rules that must be followed. Most of the rules also apply to one-person projects, some do not: pair-programming is going to be hard and your code is always immediately integrated (unless you work on different branches).

XP is an iterative development process, which is illustrated in Figure 3:


Figure 3: Activies during an XP managed project [WEL00]

Do’s and don’ts for a one-person project



1. Write user stories including acceptance criteria. Perform acceptancetests on a regular basis and publish results.

1. Leave out acceptance criteria. Instead, discuss with the customer what criteria the software should meet and use UI mocks whenever possible.

2. Create a release planning with small releases. Divide the project into several iterations and start iteration planning each iteration.

2a. Constrain your activities to coding only. Instead, also focus on communication and feedback (two of the five XP values).

2b. “Try to catch up by working harder or longer, that’s the fastest way to get further behind. Instead call for a planning meeting, accept how far you have come and create a new plan.” [WEL00]

3. Set a sustainable pace and measure velocity.

3. Hold your own private daily stand-up, instead you could still pick a regular moment every day to manage impediments and (re)gain focus on your work. Also when you’re the one and only developer you can’t “move people around”.

4. Use a simple design and a system metaphor. Assign responsibilities to the right classes. Create spike solutions and refactor continuously.

4. Use CRC-cards. Instead, use GRASP [LAR04] patterns. You can do without CRC-cards in a one-person project.

5. Have the customer always available. That’s hard in a one-man project, however you may decide to make the customer’s office your office. Face to face communication is faster and more reliable that anything else.

5. Work iteratively without showing the results to your customer. Why work iteratively?

6. Apply to coding standards. Use available standards and/or modify it to your own needs.

6. Break rule 6. Even in a one-man project, you need coding standards to make your code readable, understandable and debuggable.

7. Code the testcase first.

7. Write testcases afterwards. In a projectteam that sometimes is an option, but only when the developer of the testcase is not the same developer as the code under test.

8. Use an integration computer.

8. Believe that when it works on your computer, it works on another computer as well.

9. All code must have unit tests and all code must pass all unit tests before it can be released. When a bug is found, tests are created.

9. Break rule 9. However, you could negotiate the test coverage. Is it really important to have 100% coverage?


Wrap up

We have seen three processes in more detail, each described using simple principles that can guide you what to do and what not to. These processes have a some characteristics in common that makes every process valuable, even for a one-man project:

  • Adaptive: every process can be tailored, even if it’s not made to be. You might start a holy war by changing the process, but if it works for you and your project it can’t be a crappy process, can it? Some (parts of) processes can even be combined, like XP and Scrum, or Scrum and UP.
  • Agile: every process is iterative, some are incremental. Only when the customer refuses to participate in an agile process or when requirements are well known up-front and fixed during the whole project you could consider a more waterfall-like approach. Most of the graduation assignments are projects with lots of unknown factors, you risk failure when choosing a waterfall-approach.
  • Quality: every process focuses on high-quality software, sometimes explicitly through defining the definition of done or by requiring a simple and/or visual design.
  • Transparency: every process gives several stakeholders insight through velocity, issuetracking, backlogs, acceptancecriteria or –tests.


LAR04 Apply UML and Patterns, Craig Larman, Prentice Hall, 2004.


Geef een reactie