This article was previously published in 2009 and was republished in 2024. Time has changed, the HAN’s organization changed but the core of this article is still valid. Happy reading!
Introduction
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 software engineering 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 programs 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 his own process and use it wisely?
- Product: is the student capable of delivering the required product (mostly software, but can also be a report or a visual prototype)?
- Presentation: is the student capable of presenting his product and process and answering questions about his own choices?
- Report: is the student capable of writing a structured report that contains the most important information about the project?
- Reflection: does the student know his own strengths and weaknesses and is he able to use his strengths and minimize his weaknesses?
Before graduating, ICA students followed a unique program with three semesters of their own choice. Each semester focuses 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 in 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 software development processes are used during 8-week Software Engineering projects:
- Scrum combined with XP best practices
- 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 will 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.
Scrum
Short introduction
Scrum was formalized as a software development process 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, as described in Figure 1.
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]
- Team members: “… 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 rugby ball in your hands, however with a pragmatic approach Scrum can be applied to a one-person project. Some principles also yield for “ordinary Scrum teams”:
| Do | Don’t |
| 1. Assign/find a Product Owner. Let the customer disharmony be his or her problem, not yours. |
1. Be your own Product Owner. |
| 2. As a team member 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 of 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 an architectural slice during a sprint, each slice should be able to operate independently of another slice. |
5. Build your application completely layer by layer. |
| 6. Write a manageable definition of done (DoD) [GUP08]. Focus on code complete with just enough design to keep your product maintainable with the 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 unit tests. Although time-saving, you need (automated) test cases every time there’s a nasty bug in your software. Because your team lacks reviewers, your test cases might be your safety belt. Never cut down quality. |
| 7. Perform Sprint Reviews. Show demos 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, or lengthen your upcoming sprints. |
| 8. Use a fully integrated IDE (build tools, version control, formatting, etc.). |
8. Dress up a continuous integration environment. With a professional IDE, you have sufficient tooling in most cases. |
| 9. Concentrate 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. |
UP
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, in 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 version control, requirements management, document templating, 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 the 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:
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:
|
Do |
Don’t |
|
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 feasible and use Elaboration to build an executable architecture that proves your high-level design. |
|
2. Use templates specifically 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. To obtain traceability, a small spreadsheet will do. |
3a. Build software that does not relate in any way to the requirements. Do 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, preferably on a whiteboard:
|
4a. Stick to the UML meta-model. Instead, create diagrams that illustrate the tricky parts of your software, if you need use case elements in a sequence diagram, 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? |
XP
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, but 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:
Do’s and don’ts for a one-person project
| Do | Don’t |
| 1. Write user stories including acceptance criteria. Perform acceptance tests 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 than 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 them 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 test case first. |
7. Write test cases afterward. In a project team that sometimes is an option, but only when the developer of the test case is not the same developer as the code under test. |
| 8. Use an integration computer (Docker will also do fine). |
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 on what to do and what not to do. These processes have some characteristics in common that make 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, issue tracking, backlogs, acceptance criteria, or –tests.