Posted on

Differences and similarities between Kanban and Scrum

Both Scrum and Kanban are well-known Agile software development methodologies. They are both flexible processes that promote small, iterative changes and promise enhanced productivity and a better quality of the final product. Of course, they both have their advantages and success stories when adopted in software projects therefore, the decision of which framework to embrace usually belongs to the development team. In the followings I will go through some of the similarities and differences between the two frameworks as they were presented by Henrik Kniberg in his book “Kanban and Scrum, making the most of both”.

So, as I already stated, both processes follow the Lean and Agile principles, are empirical development methods and approach large work packages in the same manner: by dividing the total amount of work into small, manageable work items and delivering them as early and as often as possible. Both methodologies use pull scheduling and set limits on the WIP (work in progress) but, while Scrum indirectly limits the WIP by means of time units, or iterations, Kanban limits the WIP directly, per workflow state. Nevertheless, transparency is ensured by both methodologies with the purpose of improving and optimizing the process.

In terms of differences, Scrum is more prescriptive compared to Kanban. For example, a striking difference is that while Scrum requires specific roles (Product Owner, Scrum Master and team), Kanban prescribes none. Also, in terms of teams, Scrum prescribes cross-functional teams but Kanban sets this as optional and allows as well specialists teams. Unlike Scrum, that uses and advises for time boxed iterations, Kanban can be very much event driven and have separate cadences for planning, release or improvement. Moreover, both estimation and commitment are optional in Kanban while in Scrum the teams must always break down the items, estimate them and commit to a specific amount of work during each iteration. Another difference lies in the boards: while the Scrum board belongs to one team only and resets at the beginning of each sprint, Kanban boards are persistent and can be owned by several teams.

Posted on

How does Scrum fit with the concept of Agile?

Agile encompasses several methods for developing software. Out of these, Scrum is the most famous and used one. A good starting point that helps us assess how Scrum fits with the concept of Agile is the Agile Manifesto together with the twelve principles behind it.

‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’

‘Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter time scale’

The core of Scrum is the sprint, that lasts up to one month and that has as purpose the delivery of a working, usable and releasable product increment. The limited time duration enables predictability and ensures inspection and adaptation of progress towards the goal. Meanwhile, Agile itself advocates for the incremental development of the systems and for the prioritization of the functionality that gives the highest customer value. Unlike the traditional ways of building software, Agile methodologies encourage as well early feedback with the purpose of learning and improvement.

‘Business people and developers must work together daily throughout the project’

In the case of traditional project methodologies, a project’s success was evaluated based on its delivery within the agreed scope, time plan and costs. However, a successful project should also generate customer satisfaction and not only fulfill a series of formal requirements. Moreover, it should be ready to be launched on the market at the right time instance and the customer should be involved in the development process from early stages. So, while the developers have the “know-how” for building a system, the business people and customers have the knowledge related to market, timing and needs. Scrum supports entirely these aspects and promotes collaboration not only within the team but also between persons with different backgrounds and knowledge.

‘The most efficient and effective method of conveying information to an within a development team is face-to-face conversation’

Scrum focuses strongly on communication. The proof is given also by the various Scrum events (daily Scrum meeting, sprint review, retrospective, backlog refinement, sprint demo) that are meant to encourage collaboration and effective communication, to promote transparency and to offer the opportunity to inspect and adapt. Hence, it is highly likely that in an organization practicing Scrum the extensive documentation will be replaced with brainstorming sessions or meetings next to a whiteboard!

‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly’

Scrum is a framework that sustains continuous improvement. As such, two major events are held every sprint with the purpose to inspect and adapt the product backlog (Sprint review) and to analyse how the sprint went with respect to people, relationships, processes, tools (Sprint retrospective).

Posted on

Is Prince2 an Agile model or a traditional project management model?

Prince2 is, by far, a traditional project management model. According to its description, Prince2 has a very formal structure, with a clearly defined project organization and specific stages, roles, activities and deliverables. Its formality and strict structure can be noticed already in the pre-project phase, when the project manager not only has to put together a significant amount of information for creating the Project Brief but also has to plan in detail the Initialization stage.

Moreover, it is a model focused entirely on the managerial process/activities: the “collaboration” between the management and the board has a protocol-like structure, with request-authorization patterns at every stage and the value is created by delivering the project within the agreed scope, time plan and costs. As expected, there is no flexibility regarding the plan: this is more or less “set in stone” from the early beginning, the output of every stage is evaluated against it and, in case deviations occur, efforts are usually made to restore the project on the “meant to be” trajectory.

Also, it is a model heavily relying on documentation at all stages. As an example, during the Initiation stage only, the project manager has to prepare, besides the project plans and business case, four extra documents related to strategy; same goes on at team level where the team manager has to deliver checkpoint reports after team’s regular meetings).

So, as summarized above, the differences between Prince2 and Agile project models are obvious.  In Prince2 there is no rush to make it quickly on the market and no place for the customer in the picture: the focus falls entirely on the established requirements irrespective of the value that these create for the customer. Moreover, Prince2 is a very closed, business centric model, with a strong focus on the managerial activities performed (planning and controlling) but not on learning from mistakes, on being adaptable or innovative. Besides, the tasks and the end product have a central role while the development teams’ role is rather limited and marginal.

Posted on

What can be changed at Waterfall to make it work better in today’s IT industry?

One way to approach this would be to consider the areas in which the Waterfall model always falls short, namely: the long and detailed requirement specification phase, the extensive documentation written throughout the entire development cycle and the lack of customer involvement.

In the Waterfall model, the requirement analysis and definition is an extensive phase in which all the functions and constraints of the system are collected and analysed meticulously. The deliverable of this phase is a requirement specification document that will serve as guideline for the next phases.

To decrease the time spent in this phase and to optimize the requirements gathering, an idea would be to develop in parallel a prototype. This prototype is meant to be constantly subjected to customer’s feedback and modified accordingly until a “good enough” version is obtained.

Of course, when it comes to prototypes, one may choose from employing the so-called “throwaway prototypes” or “evolutionary prototyping”. “Throwaway prototypes” are more suitable for validating the requirements or clarifying those that have been poorly understood. Moreover, they may give hints about critical points or possible flaws and offer the opportunity to select a different design/solution that will overcome the issues. As its name implies, the prototype will be discarded and it will not be part of the final system. Therefore, once the client validates it, the workflow is expected to resume and continue with the design, implementation and testing phases.

Unlike the former one, evolutionary prototyping does not imply doing the same job twice and discarding the prototyped system after its validation, but rather using it and refining it (based on customer’s feedback) in the subsequent development phases. While a final refinement and testing are still required, it can be noted that this approach is similar to the iterative, incremental development methods.

One may argue of course that evolutionary prototyping is nothing else but a first step towards Agile and that “throwaway prototyping”, even though it has some advantages, is not suitable (due to its time and resource requirements) for today’s fast paced IT market. Therefore, I see no other ways and no possible “fixes” for the Waterfall model to succeed other than turning Agile.

Posted on

Agile vs. Waterfall: strengths, weaknesses, opportunities and threats

In the past years, software development practices have seen a dramatic shift from the traditional model to the agile, collaborative way of working. Even though they were initially regarded with caution, even distrust, the Agile approaches for managing projects projects are, according to one of the latest statistics from Project Management Institute, one of the main factors contributing to the increase in the project rates success (see  PMI). In the followings, I will briefly go through the strengths, weaknesses, opportunities and threats of the two models.

Waterfall is a structured, segmented and easy to understand model, with clearly defined phases and fixed deliveries. The entire work is well documented and usually, the projects have development costs that are easy to estimate. These strengths trigger also a set of opportunities. For example, the existence of a formal and solid documentation will ease the knowledge transfer to the newcomers, giving them a good start and a way to fill in their knowledge gaps.

However, the weaknesses of the Waterfall model outweighs its advantages. Here, one can always name the time spent in each stage of the process and the effort dedicated for trying to overcome the future bugs and errors. Nevertheless, in a Waterfall model, the teams are quite separated, focusing each on a specific part of the system and not collaborating too much with each other. Same goes for customer interaction: this one is less likely to be involved in the design and will have no opportunities to influence the development process. In terms of design, if proven wrong or, simply, not working, this will be difficult  and very expensive to be changed towards the end of the project. Also,  Waterfall methods are ineffectively using the resources (for example, the testers will be held on idle until the actual testing phase begins) and is prone to long feedback loops and error correction procedures.

On the other hand, Agile methodologies have a longer list of strengths and opportunities but, unfortunately, do not lack weaknesses and are still subjected to threats. Starting with the strengths, the Agile projects are centered more around functionality than around “nice to have” features. Besides, their high flexibility allows the developers to add small, incremental changes and constantly tailor the project to the customer’s needs. The small development patches and short cycles require early and continuous testing, which leads in the end to fewer bugs and implicitly, to a better product.

When it comes to communication, an Agile way of working triggers constant interaction among the teams and among the stakeholders. The critics of Agile (if any left!) will eagerly turn this into a weakness (as meetings require time), but overall, the information spreading is faster and more effective as everyone is “on the same page”.

In terms of documentation – Agile projects will not deliver extensive documentation. I have not met too many developers who like documenting their work and I also believe that a well written and working code is self explanatory. Also I think it is an advantage – both time and energy wise – that effort is spent in a different direction rather than on writing documents that very few (or none!) will read.

Regarding the weaknesses of Agile – I would say that it does take time until people move from simply understanding Agile to actually practicing it. Apart from this, I found many statements regarding the drawbacks Agile has when it comes to geographically distributed teams. From a personal perspective and as being part of a project in which the teams were not always co-located, this was rarely a problem. There were indeed issues with the synchronization (sometimes not all the resources were available or it was difficult to have all the teams working at the same pace), and maybe extra work was required to coordinate all the teams, but in general, everyone perceived it as a joint venture and made efforts to overcome the distance.

Unfortunately, an Agile setup will not run smoothly from the very beginning and, for the organizations that have just started to adopt Agile, that is when the most threats show up: as an example, for the persons who have been working in the organization for a longer timer, the redefinition of roles together with the new ways of working might lead to confusion, misunderstandings and, inevitably, to a resilience towards change: comments and beliefs such as “it was better before”, “we talk about how to work but no-one is actually working or getting things done any longer” are quite common in the early stages of such shifts. Besides this, I would add that the planning and estimation is difficult at the beginning.

When it comes to opportunities the biggest I’ve seen (and experienced) was that, team members have the chance to work with different areas and to stretch their competence and abilities. Of course, this may lead to fewer experts/specialists but I personally see no better way of fostering learning among employees or encouraging them to thrive on challenge.