Can we use Scrum or Kanban for smaller tasks or projects? Let's say that I have a small software project comprising of the following:
And then in the end my client said these details are partial. More details will be sent after 5 or 10 days.
My core question is: can we use Scrum and Kanban for this project or not? If not then why not? Please explain.
[I]n the end my client said these details are partial. More details will be sent after 5 or 10 days.
You've just described the core use case for iterative development. You had what you thought was a complete scope or set of requirements, but the requirements and deliverables will now change.
Scope creep can sometimes be laid at the foot of poor scope management or a poorly-defined contracting process, but it happens so often that managing it well is a core agile principle:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
All project management processes incur overhead. The question you should be asking is whether the benefits of a formal project management process outweigh the costs of the framework's overhead. Scrum has more overhead than people think; it's often worth it in terms of project effectiveness, but it's still a cost that must be acknowledged.
If you have a small set of tasks, rather than a project, you're probably better off skipping the overhead of a full-blown project project management framework and just getting the work done. Why incur the overhead if you don't need to do so? However, if you have an actual project, the benefits of a formal framework will often quickly outstrip the cost of the overhead.
In your case, you may have thought you had a small set of tasks, but the iterative nature of your client's expectations suggest that you actually have a project. See if you can define the extent of the project, and then see if a formal project management framework makes sense for your team.
Scrum is a process. Kanban (for software development) is a meta-process; a process from which you derive your actual process.
It's perfectly possible to do them both. You can start with Scrum, then add Kanban. I would do it in a very lightweight way. The following might be useful.
Lightweight Scrum
Scrum starts from an ideal. You set up a visual board with the kind of columns you'd like to have, and "done" at the end. This is a good way to start if you don't know what's going to happen ahead of time.
Show your work regularly to your customer. Set up meetings ahead of time to make sure this happens. Scrum also suggests "signing up" for work iteratively, which basically means managing your customers' expectations about what you're going to show them next.
Now let's add some Kanban.
Visualize your workflow
In Kanban, you visualize what's really happening. If you're waiting for details from your client, you can find a way to show what details you have, and what questions you still need to have answered. You can track what's been shown to the client, and what hasn't. You can even track what's been released, or what's been paid for, what you've invoiced - whatever you consider to be important to your side of the project. Do this for the whole stream - from ideas coming in, to whatever you consider to be "done" - and be honest about whether "done" really does mean "done".
Start light. As the project progresses, different things will become important, and you can add them to the visual board; either as rows, or new columns, or different colour cards, or sticky notes on the cards; whatever works best.
It's especially important to visualize the things that aren't ideal. This acts as a reminder to fix (preferably), or work around, those things.
Limit your Work In Progress (WIP)
Perhaps you find that, because you're waiting for details from the client, you end up with lots of things in progress. You were working on the UI for the registration form, but you realised you didn't know what validation was needed, so you've moved on to the admin form, but you're waiting for them to tell you about the permissions, and the contact form contains some preferences that you don't understand, so you write the database tables instead, then you fix a few end-to-end tests that were failing, then start reading about how to write that particular PL-SQL monstrosity...
By the time you get the information from the client, you've forgotten what you were doing with the registration form. You have to remember, and it takes longer.
This is the equivalent of car parts rusting away in a lot (hence Maxood's comment about an inventory management system; Kanban is traditionally used to manage inventory in factories). But now it's your brain, and your memory, that's rusty.
By limiting the number of things you're working on, and waiting for the information you need, it may actually be possible to save time. In your case, it might make sense to ask the client to send you details as and when they come up with them, rather than sending lots every 5 to 10 days. It might be better for you to refactor your code and make sure that it's easy to change when the details arrive, than to start something new.
Being productive isn't the same thing as being effective.
Continuously improve
At regular intervals, take a step back and look at how things are going. If this is your own project, you can do this at the end of the day, or even the next morning when you're seeing your work with slightly fresher eyes.
What would you like to do better?
Retrospectives are a Scrum practice. Kanban suggests the same thing, but you don't need to wait for a retrospective to improve. If you do make changes, they should be based on some kind of evidence, preferably numeric metrics.
Is there anything you're waiting for? Have you sent screenshots to the customer a week ago and still not heard anything? Are you still waiting for those details? Do you even know how long it takes your customer to respond?
Perhaps you've got tests that take three hours to run. Is that slowing you down?
Whatever is slowing you down the most is your constraint. You'll probably be able to tell what it is if you're trying to limit your WIP, too, because the work will be piling up in front of that point, threatening to break your WIP limits.
And that's it.
You can read more about Kanban on the Wikipedia page, but this is what I apply to my own personal projects. I also run my own Kanban board for my one-man consultancy, and find this useful. For instance, I limit the number of clients I'm handling at any point, and the number of people I'm waiting to respond to me (I bug them if I'm about to hit that limit), and the number of outstanding tasks (if I have too many, I work hard to get rid of some).
I hope this helps you and gives you some ideas.
