I'm in a situation where my stakeholders are asking for short-cycle iterative releases on a new application we're introducing to manage subscription based projects. In essence we're being asked to do work in sprints, but we have only one full time developer working on the whole project. Two questions:
Is it reasonable to take an agile approach with only one developer?
Whether or not agile is the best approach here, what recommendations do you have for meeting the needs of the stakeholders while allowing our *one* developer to work in a way that doesn't put him on the hook to deliver features every ten days? Saving Changes...
To take or not to take an agile approach is not a matter of number of people available to work. First of all, take into account agile is not a method, is not software related only. But you are asking about software and you are related your question to an agile software development method (at least I understood that). You will not get short-cycle releases because you are using agile. Unfortunatelly, all of that are big missunderstanding in the actual world because of that most of the people said "agile does not work". Well, returning to the point, you have to take into account some critical success factor to apply agile, like this: 1-product life cycle. Somedoby will maintain the product in the future?. 2-level of knowing about the market. Are you creating the product to deliver it and when people work with it then you will get lot of requirements thanks to know better the market and users?. 3-your organizational architecture. Which and how are your organizational process, structure, type of decision taking model, business unit distribution, culture?. Saving Changes...
Some clarification might help here. We're not developing a new software product, but working with a vendor to implement their product. In that sense it's like installing a new game on your computer. You have certain minimum system requirements that have be met before the game will run, and installing it in iterations doesn't make a ton of sense.
To that end the requirements and scope on this project are generally known, it's unlikely that we'll see a lot of changes, and it's a fairly substantial and cross-functional project.
The approach I'm considering is to fully decompose the project deliverables so we understand what the work breakdown structure looks like, then attack it feature by feature, or deliverable by deliverable. I think in that way it structures the project in a way that works within our resource constraints, and allows us to demonstrate progress in an iterative fashion. Thoughts? Saving Changes...
It's better task based, a breakdown in deliverable and work like that. If you have not done agile before and you have one developer, I would not recommend it, unless both you and the developer understand the dynamic of the agile project process. You can go the opposite way and in fact have delays rather then faster delivery. Saving Changes...
Sharing my experience, hoping that this might help.
We had done this 2 years ago, for an IOS application development with one developer.
We had a Product owner, a scrum master and myself a developer. We had all scrum ceremonies like grooming, sprint planning, daily stand ups, sprint, retrospective, review. It was a 2 weeks sprint, ran upto 3 months. End of each sprint we had a release candidate ready for stakeholders review.
PO used to collect the requirements and create an epic out of it. Epics are then broken down into user stories and added into product backlog ready to groom. Based on DOR (definition of ready) user stories were added into sprint backlog and considered for development. Based on DOD (definition of done) PO used to review work done for each story and mark it as accepted or rejected. Rejected stories were moved to next sprint.
Any change requests were created as a user story added into product backlog. Based on the priority, and sprint readiness it’s been moved to sprint backlog during sprint planning and taken for development in next sprint.
- Sometimes unplanned leaves / sick leaves caused reduced sprint velocity due to which burndown chart looked odd.
- Story points matters a lot. Decision of the complexity of the story needs thorough understanding of the story and the development skills related to that.
The answer is YES. So long as you adhere to the original Agile principles. I only had 5 developers for 8 software projects and a product owner and scrum master (me). Agile or SCUM talks about 7 plus and minus 2 being the optimal number of resources per Agile/SCRUM software development. Note the word 'optimal' - you can define this as 1 resource. Saving Changes...
I agree with Raymond. Agile is more of mindset - where you focus on delivering the Business Value. Many times, we think Agile = Scrum. But it is about to come up an approach where you can practice Agile Manifesto (4 Values and 12 principles). Scrum is one of the framework to practice Agile Manifesto:
Agile never says about how many members needs to be on the team. Yes, Scrum Guide mentioned it.
Isaac, if you feel that installing in iterations does not make sense, then you can use the Kanban approach, where you create a ticket for each work. As soon as you finish it, you can show it to the customer. The important thing is that your client wants continuous involvement and transparency. Understand the customer and the nature of your work, then think how you can deliver business value to the client - Agile is all about Business Value Generation.
"We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one anymore."