Monday, September 21, 2020

When Agile is not the right choice? - Part 2

 

(Image Credit: https://hygger.io/blog/agile-and-waterfall-teams/)

In the previous post, we discussed unknowns in the project. Based on that, we decide the Project management technique should be Agile or Traditional. 

In this post, we will discuss the criticality of the project for the organization. If the failure of the project can be a big impact on the organization, then adopting a new method is not prudent. Inspiration can be taken for some areas, but a complete revamp is not advisable. With the adaptation of Agile, the project should benefit instead of getting exposed to the risk of failure. If the project teams are comfortable in following a prescriptive plan, and the project is critical. In this case, adopting an Agile methodology is a risk not worth taking.

When the requirements will change and be more elaborated on as we progress with development, agile may be the best choice. However, if the project is of the type where requirements should not change, agile is not recommended. An example of such projects could be the one related to security and safety. One can not change the requirements, which may impact the safety of individuals. Like the foundation of a building is laid based upon the number of floors to be built. Customers cannot add a requirement of a few more floors in the building. Similarly, developing an off-roader on the chassis of a city car is a threat.

Agile is to be used only when it is a value add, otherwise it is better to stick to the traditional approach.

Sunday, September 13, 2020

When Agile is not the right choice? - Part 1


 Today, when everyone is talking about Agile as a must-have for a fast-paced world. There are cases or incidents when we do not need Agile project management.


Agile can shorten the software delivery cycle, improve quality, and result in better customer satisfaction. However, agile is not suitable for all projects.

What we are going to build? Who all will be involved in development? What is the culture of the workplace where this development is going to happen? Organization's ideology and beliefs? Industry to which organization belongs? Is the customer willing to collaborate or participate in the development process?
Answers to such questions help us to decide on Agile or No-Agile.
Let us look at each aspect in detail and decide on A or NOA.

In this post, we will discuss the type of project we are going to develop, and the approach would be A or NOA. Uncertainty in the project is one deciding factor. It can be internal or can be external. Let us take a hypothetical scenario. The organization wants to launch a trading application. The development team that is going to work has considerable expertise in developing trading applications in the past. The client organization, however, is not sure of the kind of trading application they want to launch. They have ideas, but nothing is final. They also want to explore the market and accordingly expand the area. Project management wants to promote an application based on acceptance in the market. As the development team is an expert and project management novice, the core expectation of the development team is to be creative.
What do you suggest? Agile seems the best way to go.

Let us now revert the situation here. The organization is very clear about the application to develop. They know when to deliver a particular feature to the market. They know the in-scope and out-scope of application. The development team is technically very sound. However, they have never developed such kind of application. What do you suggest? In this case, a traditional approach to project management may be more suitable. The reason is, there are not many unknowns. There is an answer to questions such as what to deliver and what not deliver. The development team needs to follow a straightforward plan here. 

We just covered one aspect of the project to be considered for A or NOA. In the next post, we will develop upon this. We will add more complex ingredients of risk, criticality, safety, and security to the type of project and analyze it further.



Thursday, August 27, 2020

Kanban and Scrum - alike and apart


Hello friends, nice to catch up again on some Agile concepts. I have observed some of my peers and colleagues get confused over Kanban and Scrum. I have also heard them saying 'Ek hi toh baat hai, sab agile hai', which means 'it is the same thing, everything is agile'. Yes, both are agile frameworks, but there is a considerable difference. They can be used optimally when the difference is understood. There has been confusion around the scrum board and kanban board. It is at times though as the same thing. In this post, we will be discussing more the differences between these two and their beauty individually.


Kanban focusses on : 

  • Visual board
  • WIP
  • completion of each item that has been started
  • Quality of deliverable
  • limit on WIP
  • Introducing slack in the system for improvements
  • cycle time, throughput

In Kanban, there is nothing like 

  • Timebox in Kanban as compared to scrum. 
  • Roles like that of Scrum Master and Product owner
  • Sprints
  • Daily Stand-up, review, planning
  • velocity

Scrum and Kanban are similar as they both have

  • Transparency
  • Iterative work system
  • rely on process flows
  • aim to reduce waster

Scrum has below

  • Scrum events
    • Sprint
      • Sprint Planning
      • Daily Scrum
      • Sprint Review
      • Sprint Retrospective
  • Scrum Roles
    • Product Owner
    • Scrum Master
    • Development team
  • Scrum Artifacts
    • Product backlog
    • Sprint backlog
    • Product Increment

Every event in scrum is timeboxed, which means have to be finished in a specific timeframe and cant be extended beyond that. Scrum is based on empiricism. It is supported by three pillars of Transparency, inspect and adapt. Every ceremony in scrum ensures that.

So, when to use Kanban and when to use scrum?

Kanban works well along with Scrum or any other agile method. Kanban helps in visualizing the flow of work irrespective of implied methodology or framework. It provides good transparency to the flow, and helps in getting work delivered faster and more often.s


 

Comments system