What are the differences/similarities between Kanban and Scrum?

Scrum and Kanban are not necessarily that much different, provided that Kanban usually builds on the top of an existing framework, which is generally Scrum. If, however,  we really want to compare the two methodologies, the final conclusion is: Kanban is less prescriptive, Scrum is more prescriptive.

Kanban, according to the inventor, David Andersson (http://www.djaa.com/principles-kanban-method-0), defines five principles:

  1. Visualize workflow: usually, a Kanban board is a physical one, with index cards attached on it, where a card represents a task to do. This has to be visible to everyone so nobody will forget about updating the board, and it is generally easy to see the snapshot of the progress.
  2. Limit WIP: every single column has to be limited, so the burden is less. Limited WIP will makes sure the team is focused on a small number of tasks. It also makes sure the tasks will be pulled through the board as soon as possible, otherwise leftover cards can block the whole system.
  3. Manage flow: index cards travel one direction only: from left to right. Tasks are never moved backward, as that would be considered wasted work, which is a thing to be eliminated in Kanban.
  4. Make rules explicit: All the team rules have to be attached somewhere on the board, so nobody breaks them, and it is clear to everyone.
  5. Improve collaboratively: come together and improve the process as a team.

Scrum is more prescriptive than this: it prescribes roles, meetings, and artifacts. As can be seen from the list above, Kanban does not have any roles or meetings defined. It does not prohibit roles, meetings or artifacts, it allows everything that makes productivity greater. Kanban focuses on small numbers of tasks pulled through the board as soon as possible, without any kind of ceremony (in a very pure Kanban system).

Scum dictates the presence of a burn down chart in order to measure velocity. Kanban does not prescribe any such means of measurement, but it usually measures lead time (medium time for tasks to travel through the system) and cumulative flow diagrams (one diagram that captures the sequence of system snapshots until the current day).

Scrum prescribes meetings such daily scrum, retrospective meeting, demos, sprint plannings, etc. In Kanban, there are no compulsory meetings, but since Kanban usually is built atop Scrum, it may borrow most or all of these meetings.

Scrum believes in the presence of sprints, which is considered the unit of time. Kanban can be seen as holding mini-sprints of one day. Because of that, Kanban is more flexible and can adapt better, as such teams can focus on the most important items all the time. Scrum teams have to wait two weeks to change direction, which, at times can be too long – for example in the case of fixing critical bugs.

Scrum boards usually are erased and reset at the end of each iteration, while Kanban board is a continuous entity, which rarely needs erasures.

How does Scrum fit with the concept of Agile ?

In order to see how Scrum fits the Agile model, let’s take a look at the Agile Manifesto and Scrum’s view on those values:
Individuals and interactions over processes and tools: Scrum does not believe in over-engineering the process. Although it has some prescriptions when it comes to roles (Scrum Master, Product Owner, team), meetings (daily scrum, retrospectives, demos, etc.) and artifacts (e.g. burndown charts), there is no detailed documentation, no project plans, no incredibly detailed processes to follow, no extensive description of project roles. Scrum does not need detailed descriptions like RUP or Prince2, it is kept extremely simple. Scrum is a rather minimalistic approach, the absolute basics are given, anything still needed can be added later.

Working software over comprehensive documentation: Scrum targets this principle with the combination of sprints and demonstrations. Sprints are small size iterations, which are still long enough to deliver features, customer value. These features are then later demonstrated during a meeting at the end of the sprint. The audience of this session always contains the product owner, and possibly end users too. The reason behind these sessions is that the product owner to accept the delivery, or suggest changes to be incorporated. Every two weeks (the usual length of a sprint) some working software is delivered, so customers can start using the product right away. Documentation is usually ad-hoc in real life Scrum implementations, and entails a number of wiki pages most of the time.

Customer collaboration over contract negotiation: As mentioned earlier, in an ideal Scrum setup, the customer attends the demos so they can see for themselves what the next release of the software contains. Also, the product backlog represents a list of customer requirements. Such a way, Scrum delivers value based on customer requirements with the approval of the client at the end of the sprint.

Responding to change over following a plan: Scrum leaves room for team improvement with the retrospectives. Retrospectives are meant for teams to come together, revise their process and experiment with new things. Scrum is flexible: sprint lengths are not set in stone, project roles can be added if the situation requires it, meetings can be organized for better performance. With the retrospective, the team is able to adapt to the current situation and respond to changes in customer requirements, competitors’ movements, product success, etc.

Based on the four values of the Agile Manifesto, Scrum is fully qualified as an Agile process. All the principles in the manifesto are addressed, the primary goal is to deliver customer value and not to stick to a plan created upfront.

Is Prince2 an Agile or Traditional PM framework?

I think that Prince2 is definitely a traditional, sequential project management framework. It believes in lots of documentation, very rigid boundaries between project phases, really formal procedures in handing over work, managing the developers closely and monitoring and controlling.

I really see no flexibility or adaptability in the process once the project starts. Before any work is done, there is a way to tailor the Prince2 ways of working to suit the project’s need, but in my opinion, that’s a too early stage to know what is going to work for a particular project.

Although Prince2 has a notion of iterative development through the concepts of “Next Stage,” this is not flexible enough to be considered agile. At the boundary of a stage, project plans are updated, end stage report and next stage plans have to be created, which entails a lot of documentation. This is very far away from Agile’s “barely enough” view on creating documents and plans.

Instead of adaptation, the Prince2 way believes in monitoring and controlling. The execution of the plan has to be carefully monitored, and once deviations are experienced, they have to be addressed using corrective measures. In an Agile view, in such situations adaptation is needed, flexibility in the process and not blindly trying to stick to a plan created up front.

Again, like in traditional project management methods, customers, end users are not addressed. The goal is to stick to the plan, deliver what was expected within time and budget. Values, as such are not mentioned, and it is outside of the scope of this method to measure how useful the product is.

If we contrast Prince2 to the Agile Manifesto, we can see that most of the Agile values are not addressed in Prince2:

  • Individuals and interactions over processes and tools: Prince2 is a comprehensive process, where interactions usually happen in a very ceremonial way, e.g. request to initiate or deliver a project.
  • Working software over comprehensive documentation: lots of documentation at every phase of the project lifecycle
  • Customer collaboration over contract negotiation: not exactly addressed
  • Responding to change over following a plan: stick to the plan, monitor progress and apply corrective measures if necessary

Because of these features, I really think Prince2 does not qualify as an Agile project management process.

How to transform Waterfall into a modern development model

I think it is very hard (nearly impossible) to transform Waterfall, so it meets nowadays’ software development requirements. However, as a quick thing, the excessive documentations should be removed. As Royce mentioned in describing the Waterfall model, he’d expect 1500 pages of documentation for a 5 million dollar project. WhatsApp was a 20 billion dollars project, so I’m pretty sure nobody would have read the 6 million pages long documentation. So step 1, limit the documentation to a reasonable level.

Coding and testing should never be separated in two different steps. That would partially imply that developers are not writing any unit tests, and all the bugs ranging from trivial to blocker are discovered once the full coding part is done. This implies going back to coding and then testing again, which can be a waste of time. Coding and testing shall be kept together, so as the project progresses, parts getting done are validated in one go.

Today’s market is so volatile that the full project just cannot be designed up front. Smaller units, like features, maybe could be designed very well before starting the coding phase, so the process could be broken down into delivering features (we are getting closer and closer to what we call Agile software development). At most one feature would be analyzed , designed and built at a time, and the whole project would entail several mini waterfall cycles, packed back to back.

These new features, however, would still not make the waterfall process capable of handling all kinds of software development efforts. I am pretty sure that for Facebook or Amazon these continuous waterfall cycles would not be flexible enough to roll out new features to an extreme number of customers. This new, improved waterfall would still only be suited for short to medium timescale projects. Due to breaking the software down into distinct features, more projects could benefit from the waterfall model, but larger projects still don’t qualify.

Problems with APM

Although I think Agile methodologies yield better results than serial ones, there are some aspects which are not explicitly addressed. This is my subjective list of these issues:

Mixture of feature development and maintenance

Many companies have large, legacy systems that need both new features and maintenance to address bugs. Most agile textbooks and papers only talk about greenfield software development or new features only. Many companies (in some regions) do not even start new projects and have to integrate agile into the combo of new features and maintenance. For maintenance, I feel agile does not really offer a reasonable alternative in some cases.

Of course, one can use sprints for tackling bugs. However, fixing bugs in a large, complex codebase can be very time consuming. Due to this, two weeks sprints may not be delivering as much value as they should be. Also, when bug fixes are extremely important to ship, two week sprints may be too long. The delivery of emergency patches, in a matter of days, is pretty hard to integrate into the well-known agile universe. Bugs are also hard to plan, they can come at any time, so a sprint planning meeting can not cope with such uncertainty.

One partial solution could be assigning some teams to solve bugs while the rest delivering new features, provided that the bugs are not extremely urgent. This, however, can be problematic, as bug solving teams can be locked up in maintenance work, which can cause early team members’ burnout.

Hire the best talent

The textbook suggests that an agile organization should aim for smaller, but more talented teams. In theory, this idea makes perfect sense, but in real life situations, this may not be possible. Only very well known companies with high reputation can afford to be “picky” enough for this. In my current company (a firm that believes in agile values) we have been trying to fill two positions for more than three months now, without success. However, our case is somewhat fortunate, we can cope with the workload and don’t have to hire someone just for the sake of hiring them.

Finding the best talent is also really vague. Who do we consider talented? Someone with the capability to acquire new skills? Someone knowledgeable in several programming languages, frameworks, and libraries? Everybody understands “talent” in a different way, as it is a relative term.

Customer value. All the time

From time to time, it is not easy to deliver customer value. Let’s take Twitter as an example. Twitter used to be written in Ruby, but after the application became really popular in 2012, massive scalability issues have arisen. As an answer, Twitter’s engineers switched from Ruby to Java to solve scalability and performance issues. As a result, the system managed to cope with the US election in 2012. Changing libraries and languages does not lead to direct customer value. Had Twitter stuck with Ruby, the user experience would have degraded considerably; however, at the time of the switch, there were no issues yet. Hence no direct customer value was provided.

The textbook mentions scalability and performance issues, but only at the beginning of a new, greenfield project. In these days, it is hard to plan for the volume an application has to cope with. Nowadays, every day a few startups take off: some of them may become famous, others fail. However, the most important metric is time to market; there’s no time to plan with millions of transactions per second, those problems have to be sorted out as time goes by. User value may not always be possible to ship.

Agile in large, traditional companies

As mentioned before, agile books usually revolve around greenfield projects. A major problem is how to port agile values into large, traditional organizations so much of these values are preserved. Let’s take a telecom company as an example, like Ericsson. Software development units can be agile, however, from the point of view of network operators it is not desirable to roll out new software every two weeks.

To implement full agile, Ericsson would have to convince all the network providers to be agile enough to roll out every time new features are ready. However, in such organizations network downtime may affect thousands of users, and software upgrade comes with downtime. Also, a fault slip-through may have even more severe consequences.

Release management

This might be only my personal experience, but I’ve never seen a transparent, agile project, where not only sprint but a product backlog is kept and updated. In my experience product managers give in very quickly to all the requirements, pushing the work on development teams.

When clients demand new features, many product owners treat those as a top priority, making the product backlog a huge mess. Not to mention that these backlogs are not transparent across the organization: development teams usually know the current sprint backlog only, or one or two sprints ahead, but nothing more.

However, I think this is not an issue in the model, it is a problem in the implementations. The textbook offers several ways of overcoming this problem, but many companies never get any further than implementing two weeks iterations; I personally have never seen an organization where upper levels followed the agile practices too. But again, this is a personal experience and not a fact.

What extra challenges and possibilities does adaptability post for a leader?

Adaptability is a two-edged sword, as it can create both new possibilities and disruptions in an agile project.

Adaptability and flexibility mean that a project is able to keep up with changing requirements and user needs. End users do keep changing their minds from time to time, and this can have an adverse impact on the project: too many changes make the project a mess, with no clear priorities, frustration, and awful technical solutions. This, in turn, implies slower progress, messy spaghetti code, and high fluctuation. In such situations, the activity of value creation may be put in danger, and the product owner has to step in in order to establish a constructive way of change inflow.

On the other hand, however, adaptability also represents a chance to deliver exactly what is most valuable to the users. Many time customers do not know what they want until they see some first release. By expressing their opinion, the agile team is able to create new, valuable features and make sure the software contains exactly what end users want to have included in the software. In this context, adaptability is a means of delivering customer value, which is the primary end goal of agile project management.

Of course, as a developer, being flexible and adapting all the time may not be easy. Ever-changing requirements may produce a feeling of frustration which can result in conflicts. That is a serious problem, and that’s why it is crucial for the project lead to find the right team members: right from the point of view of technical and personal traits. Failing to staff the project with the right team members can result in a failed product.

Agile and Traditional team management

As in the previous topics, agile and traditional project management take a radically different view on team management.

Traditional project management has its focus on very strong processes that allow the least deviation for product teams. The idea behind traditional project management is that the project manager is responsible for delivery, and in the delivery process, a team is a tool. As such, the most time is spent on assigning tasks to team members, following up on them, monitoring and controlling their progress. Traditional methodologies try to reduce uncertainty using detailed project plans, as they believe that the more plans are in place to stick to, the less uncertain can happen, so negative surprises can be avoided.

In contrast with these techniques, agile project management places a high emphasis on shared responsibility: delivery (creating customer value) is everybody’s responsibility. The team has to manage their workload, which means that they commit to a set of features to be delivered until a date, and they can be held accountable for their commitment. In agile, the project manager should thrive to create self-organizing, empowered teams. This means that teams are able to work with little guidance. Thus the micromanagement of traditional ways of working can be taken out of the picture. Also, empowered teams have the possibility to decide among themselves in important questions, like architecture, deployment or design. This does not mean that at times the project lead should not step in and say no (4 different architectural styles with 4 teams would be chaos, rather than empowerment), but the idea is that the leader assumes a facilitator role, rather than a micromanager one. To build self-organizing teams, the right people have to be selected. Unlike in traditional PM where it may have less impact due to the rigid processes, in APM the personal traits of the team members are crucial besides the technical ones. People who can not accept shared responsibility, commitment or are not accountable should not be allowed on the team.

Values in Traditional and Agile PM

Agile project management takes an entirely different view on values than traditional project management. The latter believes in delivering value in one, big chunk, and does not make customer value part of the project lifecycle. Although traditional project management defines effect goals, it does not talk about how valuable the final delivery would be to end users. To measure the product’s usefulness, a new, follow-up project has to be started in order the evaluation to be done.

Agile project management, on the other hand, is radically different and makes value delivery a number one priority. This methodology believes in a continuous flow of values on both sides. On the incoming side, feature ideas are coming in and are placed on the product backlog, on the outgoing side, complete, working, valuable features are delivered.

It is also important to take a look at how the two methodologies think about work itself. Traditional management considers the unit of management a task: tasks are created, assigned, followed up on, in one word: managed. A task can be highly technical (building the object model necessary for Hibernate), which the end user does not have to care about and has no interest whatsoever in. In agile, the unit of management is a feature: a functionality of the software that creates value to the end user. Such a way, traditional PM cares more about the project, agile about the product.

As a result of the previous differences, the delivery methods are entirely different. Traditional project management believes in delivering one final product, designed and analyzed at the beginning of the project. Changes are hard enough to carry through. Agile, on the other hand, delivers working software every 14 – 30 days. This means end users can enjoy a limited set of features after an extremely short time. Changes are welcome anytime which makes the process adaptive and flexible.

Agile project management also employs lean thinking: everything that does not add customer value is waste, and therefore has to be eliminated. Reports, bureaucracy, useless meetings are all considered waste, as they add no value. It is important to remember that activities like code refactoring, even though create no immediate customer value, are considered value added tasks, as they have a positive impact on the future product.

What is agile project management?

If I had to use one word to characterize agile project management, it would be VALUE (in capitals). The whole project management process is centered around creating value to the customer in the form of a great, fully functional product; working software delivered as fast as possible.

In real life situations, the value creation process is not easy: priorities, users, trends, and technologies change extremely rapidly; due to that it is not possible to plan very far ahead in the future. As a response to that, agile project management values the principles of adaptability and flexibility. Very short release cycles employed in agile project management make it much easier to respond to users’ needs, adapt to changing requirements and as such, deliver working products.

Compared to traditional project management the agile way does not try to apply the smarts up front. Very fast time to market accompanied by frequent, small releases are valued much more than trying to figure out and solve problems at the beginning. Also, agile project management values early and regular customer involvement. Practitioners understand that the clients, end users can and do change their minds frequently and may not even be aware of what they want differently until they see an example. Hence agile employs product and sprint backlogs for capturing user requirements, and demo meetings for early and highly valued feedback.

The agile ways of working also believe that no process is ever perfect. Rather than trying to craft a sound process from day one, agile believes in empowering the teams. They are free to tailor their ways of working in a continuous manner, in a constructive and inclusive way. Agile gives a guide to newly formed teams but also gives them liberty and room to experiment and find the ways that are best suited for them. The agile mindset does not believe in the ‘one size fits all’ principle, but acknowledges that each team and situation is different, with unique needs.

To conclude, agile project management is about:

  • Delivering value
  • Embracing change in all phases of development
  • Being flexible, trusting and empowering teams
  • A continuous improvement cycle based on feedback (be it internal – retros – or external -demos)

Agile values, SU-DSV courses

The Agile manifesto addresses four central values: individuals and interactions, working software, responding to change and customer collaboration.

Individuals and interactions over processes and tools: In my opinion, this is everything the communication course was all about. Involving everyone in the decision process, empowering teams, non-violent communication, small groups as complex systems: these are all about interaction and placing people in front of everything else. Agile takes communication and involvement to a whole new level: sharing knowledge, collaboratively improving the process further, keeping all the participants updated all the time.

Working software over comprehensive documentation, responding to change over following a plan: these principles seemingly contradict courses like Practical Project Management or Business Strategies. These courses were talking about the role of the project manager, project plans composed of different chapters, like risk assessment, communications plan, activity plan, etc. Agile does not address the project manager role and places documentation and plans on the right, making them a non-top priority. However, in real life conditions, I think, it is on the contrary: Agile has actual value, but for most projects, it cannot be implemented ‘by the book.’ Letting the team build the product in isolation is not possible unless the product is a relatively new one (not yet introduced to the market). For more mature projects some sort of coordination and planning is required: that’s where the project manager comes to the picture. Project managers take off a huge load from the back of the team, by dealing with coordination, empowerment, planning, staffing, etc.

These two courses also pointed out the importance of responding to unforeseen circumstances: monitoring and controlling, keeping the project plan up to date, taking action when something goes off-track.

Customer collaboration over contract negotiation: I think this is the principle which has not yet been explicitly covered in the courses. Communication, PPM and BS have all addressed smaller parts of it: effective communication (collaboration), some bits of negotiation techniques, productive meetings. However, collaborating with customers as such was not yet part of the curricula.