Agile method for a non-technical product owner + one developer

Question

My current client has several internal products which the IT-department supports. All product owners are non-technical and each application is always developed by one developer (and so is all change requests).

The current methodology is a bit like waterfall. All uses cases are defined first by the product owner. Then the application is developed and released into a test-environment. The user tests it and says yes/no. Any changes results in a change request and a new release (including setup-packages). And it continues like that until the user is happy which results in the product going to production.

I want to introduce an agile method instead to capture changes quicker and focus on the most important features from start. Scrum seems to be overkill since there only is one developer per project. Any other suggestions?

Edit

My client isn't going use anything that isn't documented. So I'm looking for an established and documented method (if there are one which suits one developer).

Answer 1

You don't have to follow full Scrum but you can definitely take advantage of its incremental iterative approach which will replace your waterfall.

How will the process change:

• POs will not need to define all use cases upfront.
• POs will define only use cases they are absolutely sure about at the moment and prioritize them.
• Developer will follow commitment process to take multiple most important use cases to next iteration (with fixed length).
• PO will be able to verify those use cases during (or worse after) the iteration.
• Developer will deliver new "release" after each iteration (this can take big advantage of some automation tools).

Pros of the change:

• Better visibility to development process
• Better change management where problems are discovered much earlier in development phase and can be targeted immediately in the next iteration without cumulative effect (adding more functionality based on incorrectly implemented feature)
• Incremental delivery where after each iteration developer should provide working product with new features
• More important features will be delivered more quickly and thus will be more used when developing / testing rest of the product = there can be more feedback about their long term usability

Cons of the change:

• POs will have to accept a new model and communicate with developer continuously. If POs are not willing to participate on development and provide continuous feedback and clarifications + validate use cases as soon as possible you can give up any try for change.
• POs will have to change the way how they define use cases. Use cases will have to be small enough for iteration and they will have to be independent as much as possible. If developer must work on five use cases concurrently to complete them all it will not work.

The main point of the change: If you want to go for agile you must have much often feedback (small iterations with incremental delivery of working product) and you must have much more communication between developer and PO.

Answer 2

In a one developer environment the key things are:

Source control
Continuous build server
Task/bug tracking system
Defined sprints
Unit tests
Code coverage
Independent testing in parallel to development

Doing this will make you agile enough without meeting the strict definition of one of documented methodologies. If the teams grow, then look at the communication aspects of how the team works.

Answer 3

Scrum is overkill, but Agile is more natural for small teams, even one person teams. The point of Agile is laying out a backlog of user stories upfront that accurately describe the client's use cases.

Before the start of each sprint, priority and LOE (Level of Effort or Points) are determined for user stories, and based on what is possible in the 2-3 week sprint timeframe, user stories are added to the sprint.

At the end of the sprint, all the user stories should be developed and tested and the most important aspect of all is that all functionality from previous sprints should be unaffected and the software should not be left at the end of the sprint in a broken state.

Does it make sense to release to the client after every sprint? No, it doesn't and this is a common misconception of Agile that I see all the time. I encounter few clients who want a working release after every sprint. Some may want a release every quarter for instance, and if Agile is being followed, then the last released sprint should always be in a usable state where a release can be prepared for the client on a regular interval. Some clients may also want an environment where they can authorize, demo and evaluate the latest sprint so that they can keep up to date on the real time progress of the project.

What about the challenges of providing software in a usable state within the first few sprints of a fresh new project? The first few sprints of a new project can be a big challenge because the amount of architecture and design work as well as foundation work that needs to occur always peaks at the beginning of a new project and gradually diminishes throughout development.

This can be dealt with in a number of ways, many shops will use the initial backlog of user stories to make and document core architecture decisions before the first sprint even begins. Other times the project is invisioned to be structurally similar to other previous projects and a project template is used that lays out the foundation for the core design and future development. I have also worked on teams where the architecture team starts to kick off the project with a 2-3 week Preamble before the first sprint is officially supposed to begin. The first sprint can start out small, for the developers too, for a typical CRUD application I always like to start off with a login page and authentication. It is easy to start, clearly defined what is finished, and can be clearly tested by QA at the early stages of the project.

EDIT: So how this helps your client is that changes can be made to user stories throughout the process, and this can reflect in modified timelines, estimations, quicker turnaround for the customer, more feedback to the client and more transparency to the client. This benefits you in that you will be more agile in dealing with changes to the original scope in the middle of a project.