Having worked in a product development team developing and delivering ICT based products for about 4 years now, I have accumulated quite a few insights on project management. The very first question in project management is which methodology to use.

The two most popular methodologies especially in software development are

Waterfall:  which is famous as “traditional” approach more like a linear model with series of steps to be followed. It is best suited for known methods of developing a product. It heavily relies on initial requirement and follows a sequential pattern of eight stages (conception, initiation, analysis, design, construction, testing, implementation, and maintenance). Change is not its style.

Agile: While agile is newer than Waterfall which is often implemented using Scrum or Kanban. Agile starts with a simplistic project design and planning. Changes are allowed after initial planning. The timely review of projects are done and depending on the client’s feedback and market needs adjustments are done if necessary.

On the better one

Agile is highly adaptive which is important while developing a product with great complexity and uniqueness. The reason why agile is famous in software development is because of the same reason – developing a software is notoriously complex with lots of dependencies and urgency- “the deadlines.” Agile is also the best approach while developing a new product because while developing a new product, there is no way you know the right method of doing it unless you do it. The only way you can know is by doing it while leaving a whole lot of space for flexibility. This itself is agile method of working.

But if we are developing a same kind of product doing same kind of thing everyday, we do not need an agile approach. Waterfall models maybe suited best for such kind of development. If for such cases agile is used, it might be a sheer waste of time.

Elaborating with experience and example for the same  

While developing a ride sharing application called Tootle, we followed agile methodology. In terms of business model, the product was not new. There were pioneers like Uber, Lyft, Ola, Go jek etc. as global leaders in ride sharing economy. But in terms of contextualizing the product in the local market here in Nepal, it was a complete fresh project. Plus, the technology itself was a research from its very scratch, being a small team of four initially.

When the beta version of the app was released first at November 2016, we had it available only in android. The process of developing the android version of the app can be called completely agile. It is because the process was very iterative with lots of feedbacks and requirement adjustments from the market. Even up until the final release of the product in January 2017, the product had transformed completely than what we had envisioned initially. There was no way we could follow a waterfall model in the development of the app.

But later now, when we want to release the same app in ios version, the process of development is following a waterfall model. Since the logic has been identified, the process is pretty clear now but the language is different. The ios development is definitely following important steps of product development with testing being its core. However, the process need not be agile.

I have learnt the perks of both the methodologies by the “doing way”. However, there is no one best method, both work best where they are suited well. Like it is said, it is like asking whether a spoon is better or fork? Depends on what kind of food you are having.

My understanding of Scrum and Kanban theories. (Could be boring just to read but great to refer, includes summaries from multiple blogs on the same.)

 Scrum is a process of agile methodology. The framework breaks long process of work into different chunks of deliverables. The different chunks are then prioritized and divided into different sprints. In scrum, a set of self organizing team play different role. The chunks of work are called stories.

Scrum roles include product owner, Scrum master and Scrum development team.

Product owner is a team member which co-ordinates between the development team and its customers. The product owner is responsible for communicating requirements and ensuring the development of a complete product.

Scrum master is responsible for ensuring that Scrum best practices are carried out and the project is able to move forward.

Scrum development team is a group that works together for creating, testing and finally delivering a potentially shippable product.

The Scrum process encourages team members to perform and continuously evaluate what is working and what is not. Communication is a vital part of scrum and is carried out through meetings called Events.

Scrum Events include:

Daily Scrum is a short standup meeting that happens at the same time each day. The team reviews the work done the day before and plans what work will be done within next 24 hrs. Team members any kind of issue that they think is vital to the project.

In Sprint Planning Meeting all the team member participate and decide an incremental release of a piece of software within a sprint. A sprint refers to the time frame in which work must be completed. In most cases it is 1-4 weeks.

Sprint Review is done to know the status of the planned deliverable during a particular sprint.

Sprint Retrospective is a meeting that is held after a Sprint ends. During this meeting, everyone reflects on the Sprint process. A team-building exercise may also be offered. An important goal of a Sprint Retrospective is continuous improvement.

While a Kanban system consists of a big board on the wall with cards or sticky notes placed in columns. Each card represents work items as they flow through the development process represented by the columns.

In a nutshell, it follows these principles:

Visualize the workflow- Split the work and write each of those on the cards and place in columns according to the workflow.

 Limit WIP (work in progress) – Assign limits to how many items may be in progress at each workflow state. Normally, the numbers at the top of each column are limits on the number of cards allowed in each column.

 Measure the lead time – (average time to complete one item, sometimes called “cycle time”) Optimize the process to make lead time as small and predictable as possible.

On the difference

Scrum and Kanban is similar because both are tools used in agile methodology. However, the major difference between these lie on few things like:

Scrum processes place heavy emphasis on schedule like they call sprints. While the Kanban method is iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is continually completed.

In scrum processes there are at least three roles like discussed above and each role have specific responsibilities. In Kanban for a large complex project there might be a project manager but there are no such roles defined. A Kanban team is not required to be cross-functional since the Kanban work flow is intended to be used by any and all teams involved in the project.

The Scrum Board and Kanban Board are also significantly different. On a Scrum board, all the stories added to the board at the beginning of each sprint should be found in the final column at the end of that sprint or the sprint was unsuccessful.

On a Kanban board, the columns are labeled to show work flow states, but with one vital difference: they also publish the maximum number of stories allowed in each column at any one time. This enforces the team-determined limitations. Since each column has a limited number of allowed stories therefore there is no required time boxes (such as sprint) also no reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories being added as the need arises, and completed stories being re-evaluated should it be necessary.

And finally the sprint retrospective, in scrum after the completion of a sprint, the board is cleared and prepared for the next sprint. In Kanban there is absolutely nothing as retrospective. There are no compulsory review meetings and retrospective.

Summarizing, we can say that Scrum is a little more prescriptive than Kanban. That is there are a little more rules to follow while maybe in Kanban there are lesser rules. However, we still can’t say which one is the best. It again becomes a spoon or fork question.

On Tootle Project Management

While developing a ride sharing application I talked about earlier, we mixed and matched these tools and executed an agile environment. We used trello boards and managed free flowing tasks through various cards in lists. The lists followed a sequence of Backlogs, Upnext, Doing, Testing/Review, Done and Ready to Archive.

Retrospective part of scrum was adapted in our style of project management where we had atleast two retrospective sessions in a week. However, the process wasn’t as prescriptive as Scrum for example we did not have sprints. We had due dates though. Like Kanaban, the cards continued to flow for as long as the project continued, with new ones being added as the need arises, and completed. The card status and team members were evaluated based on the due dates, retrospectives, discipline and accountability of being a part of the project.

The challenge of implementing a project management in Tootle mostly came from the discipline perspective. We started the project from four and the working style was very random. All the requirement was mostly in the heads of people, in A4 paper, glass boards or at the best in google sheets. The members however were still reluctant on switching to the formal style of project management. So, conducting a thorough study of worldwide management of software development landed me to Scrum and Kanban. This mix-match style was however an ice breaker to a startup life of tracking the project.

Image credits: Ayush Subedi