Introduction to Agile
If youre in IT, youve probably lived through this: clients demand last minute changes on a tight budget, you dont know what the other developers are doing, your work keeps overlapping, and you wonder how they come up with those unrealistic estimates.
And youve probably heard of a solution called Kanban, maybe even moved a few tasks in columns. That might have seemed too simple and didnt work that great - or you came across a 500-page book which made it sound really complicated.
This a quick read. By the time finish, youll have a basic understanding of Kanban - and more importantly, how to start using it. We focus on the practical part, write from our own experience, and show you how to avoid some common pitfalls.
Everything you read here, you can apply right now in Active Collab and start managing your projects more efficiently.
Going Agile
When starting a new project, the traditional way was: gather a team, book a conference room, and plan the whole project upfront. If something changes, youre in trouble - and in software development, that something changes all the time.
This called for a new project management philosophy, one that embraces the shifting nature of project requirements - and so Agile was born. Instead of coming up with a BIG plan and hoping nothing unexpected happens, Agile allows you to change a projects direction on the go.
The Agile approach consists of many overlapping methodologies and Kanban is one of them.
Lets compare the two approaches on a website redesign project:
The Traditional (Waterfall) Approach
You first plan everything every color, button, expected user behaviour and then start working. You work step by step and deliver when youre done. The client sees progress only when you hit a milestone. You stick to the plan because youve already agreed on all the details. If the client doesnt like the layout at the end, you have to do a lot of backtracking, without being able to charge your client for the extra work.
The Traditional Approach
The Agile Approach
You get feedback early in the development. You see how the client responds and make adjustments on the go. Again, and again each adjustment gets you closer to the finish. If the client doesnt like the layout, you can change it early on without losing time and money on dead ends.
The Agile Approach
Kanban Basics
Kanban is a Japanese word which roughly translates to a card you can see. Basically, you organize tasks as cards on a board (or in a software). You then track progress by moving them across different columns.
Kanban Basics
Lets say youre developing a mobile app. You create several columns in the project: TO-DO, IN PROGRESS, REVIEW, DONE. Then you create and put all the tasks in the TO-DO column (eg. create a wireframe, design icon packs, write API calls, choose fonts and colors, fix loading bug).
When you start working on the wireframe, you move the card to the IN PROGRESS column. When its finished, it goes to REVIEW. The client can see whats in REVIEW and give feedback. If its good, you move it to DONE if not, the card goes back to IN PROGRESS.
A common way to organize projects is by task types (like DESIGN, DEVELOPMENT), but thats not appropriate in Kanban because a task cant travel from one column to another. For example, a task like Export hi-res logo in DESIGN task list cant travel to DEVELOPMENT task list. But a feature request like Put number of active users on admin dashboard can travel from BACKLOG to DEVELOP to REVIEW.
As you can see, Kanban is very simple to use. Its applied in logistics, software development, and even as a productivity method to organize personal tasks.
Push vs. Pull
Most project management uses the push principle - a project manager creates a master plan and tells everyone on the team what to do. This can be inefficient because the manager cant know whos the best for a task (no matter how well they know the team).
But Kanban operates on the pull principle - team members get to choose the tasks themselves. The best person for the job will pluck it personally from the backlog. This way, theyre empowered, own the work, and are more motivated to finish it. And when they finish, they wont sit idly but jump on the next task they feel comfortable with.
Push vs. Pull
Kanban Benefits
Flexible planning
You put everything that needs to be done in one column, and then decide what to work on. You dont have to lose time categorizing the tasks, just put them all in the backlog. If a task becomes urgent, you can always schedule it as the next one in the pipeline - this is different from Scrum where you only work on tasks that are scheduled for the current sprint.
Flexible planning
Clear focus
When you multitask, your productivity drops down by 40% and you do shoddy work. With Kanban, you limit the number of things you work on so you dont get swamped. Then you can focus on getting the task done and not subconsciously worry about other tasks.
Clear focus
Work satisfaction
You dont force developers to work on things that get arbitrarily assigned (as far as they know), but let them choose the tasks and be more motivated to work. Plus, people get credit for what they do, can set the pace themselves, make better estimates, and accomplish more.
Work satisfaction
Transparency
Tracking progress is easy and your meetings are more efficient. You can decide how many tasks can simultaneously be at any stage, and divert more resources to bottlenecks if needed. Also, youll always know whats next for the release.
Transparency
Getting Started With Kanban
All you need is a big board that everyone on your team can see and pin cards to. But in this book, we are relying on Active Collab because it makes the process more efficient with features like @mentions , notifications, labels, assignees, due dates, filters, and more.