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


 

Wednesday, May 6, 2020

Physics of Agile - All about Velocity


In High school, I always confused velocity with speed. I always used to wonder, how is it possible that speed has a numerical value and velocity at the same time zero. Relative velocity is another confusing concept and students struggle to understand it in the first attempt. 

In the present day, I am working in the Agile world, and velocity is still glued with me. I have been thinking whether to consider it as a vector or a scalar. If a person has traveled 5 miles forward and 3 miles backward in 1 hour towards the starting point, it will have different values for velocity and speed as per physics. He has a speed of 8 miles/hour but a velocity of only 2 miles/hour. This is the beauty of direction. 

Now, in an attempt to introduce velocity in agile development, I am moving ahead with this analogy and comparing it to the present day Agile development environment. I have developed something in a sprint having a story point estimation of 5. I had an early feedback meeting with the Product owner and had to revert some changes, which involved 3 story points of work. So what is my velocity, 8 story points, or 3 story points? Many of you will say that it is 8 story points of work. So, velocity here is a scalar quantity and not a vector. In agile, we do not believe in going back, instead, small increments of working software are implemented. So velocity is something which has magnitude as well as direction, and that too in the right direction! That is the reason we take small incremental steps and move ahead. Exactly the same way we climb an unknown uphill. 
Imagine a hypothetical scenario, where you are participating in a mountain climbing competition. On reaching the summit, you are completely exhausted as well as thrilled, as results can be announced anytime, you are very sure of your win. You get a message from the base camp that you have climbed the wrong summit. Probably you misunderstood the map. Now what? You have time in hand, you rush down quickly to reach the correct base, from where you have to start once again. But now, you realize that the only thing available to you is the zeal to reach the top. You are out of food, water, and no energy in your body. You have a positive attitude, but that is not just enough to be there.
This scenario is no different from a particular day in a software development organization. Consider the scenario now, when you would have taken small steps and ensure after every few steps you are in the right direction. This could have been done in many ways, by looking for the correct milestones, checking messages from the basecamp, looking around, and many more ways. You may feel that you are going too slow, but you have just realized the result of going too fast in the previous example. 

We have discussed how we progress in Agile and we have something as velocity which is related to our progress. In further sections we will try to understand velocity in more detail.

Exploring Velocity in some more detail

Velocity is defined as the measure of work finished in a particular sprint. It can also be defined as the sum of the story points of “Done” work. Your team must have estimated some story points for each user story they committed to finish in a particular sprint. At the end of the sprint, story points of all stories which are in conformance with the definition of done are added and what we get is the velocity of the sprint. 

This is just the pure definition I have discussed so far. There is more to it. Good, bad, or maybe ugly.

What is bad about velocity?

We, humans, have a deep-rooted psyche to compare numbers. We even, without realization, start doing that. I can give you a live example. My height is around 7 feet.
Didn't you just compare my height to something or someone? Maybe you just looked up at your ceiling and had a thought where I would be reaching, or something similar. It is normal, it is how we are. The moment velocity becomes bad is, when it is used for any comparison or being looked up as a performance parameter. The problem is, we do not even realize when we start doing it. Be it anyone, developers, Product Owner, or even scrum master. I have seen examples where teams are compared based on the velocity. Velocity is the sum of story points delivered and nothing more than that. Story points do not have a definitive measure, they are just relative measures. So, don't you think comparing velocity is like the most absurd thing? Even teams themselves fall prey to this. They, at times, start looking at it that their velocity has decreased this sprint or have increased this sprint. Why even a team looking at it is bad? Team grows and learns every sprint.

Now, I will explain why even a team shouldn't look at their velocity. In a particular sprint, the team has estimated a complex work as 5 story points and delivered it. So the velocity comes out to be 5. In the next sprint, now as they have developed ability from the previous sprint they estimate the similar work to be of 3 story points and commit for some additional work as well which is of 1 story point. At the end of the sprint when velocity is calculated it comes out to be 4, which is less than last time. This is the crime scene. The velocity from the previous sprint is less which means less work is delivered, while in reality they delivered more from the previous sprint. They anticipated that the skill they have developed in the previous sprint, they will be able to deliver work of similar complex nature quickly and can pick some additional work and they did it.

Is it such a bad number? If my team gets to know about it will they be demotivated? It depends upon the organization's culture and how velocity is being looked at. If one doesn't even calculate velocity, it is not something you are missing in life. It is a good metric to show off, but of no value. The moment this metric is showcased, the devil of comparison makes the dance move. In organizations where velocity is used as a performance metric, those organizations suffer from the challenge of inflated estimates. Teams unknowingly inflate the estimate numbers, so that they can look good.

What is good about velocity?

One school of thought is that velocity is a great metric to measure the progress of the team. It is but when looked at rationally. Velocity oscillates every sprint. If all other factors were kept constant, team velocity increases every sprint by 8-10 percent. However, this is not the thumb rule. As I demonstrated in the example above, the velocity of the team dipped from 5 to 4, which is a dip of 20 percent. Velocity is a good number when it is kept secretive. It should be used by Scrum masters just to have one perspective to look and understand things. If the team has done the same nature of work, how are they progressing? But numbers may speak lie, so have to carefully analyze these numbers and shouldn't be trapped in them. 
As velocity fluctuates each sprint, so the best way to look at it is always an average of velocities resulting from all previous sprints, keeping all other factors constant. This number can be looked up as a help to forecast. For example, if the team is excited and tries to over-commit on something, then velocity can be looked up by Scrum Master to coach the team and help them look at the real picture. An athlete who performs 3 sets of exercises each day, can just be outstanding one day and can perform 4 sets, which is realistic. However, if the performance commitment is raised to 6 sets, then we are expecting too much heroism. It will be a miracle and it doesn't happen when expected, except movies…  :). Miracles happen when they are least expected and that is their beauty. In such scenarios, Scrum Master can coach the team by sharing with them their velocity numbers and help them forecast realistic goals.

In summary, velocity is NOT a performance metric. It is NOT a tool of comparison. It is just an average number to forecast the completion of work. 

Tuesday, March 10, 2020

Practice questions for Scrum certifications





Hello Friends, I have prepared the below set of questions while studying about Agile and Scrum.
The questions are prepared on the basis of thorough study of the subject. While preparing for the PSPO assessment, I referred to a lot of study material, websites, books, Scrum.org open assessments and I even don’t remember the name of each study material that I went through. One thing that I noticed was missing everywhere is uniqueness. There were a lot of questions that I went through in open assessment in scrum.org were repeated in mock tests available on websites. So, I always felt why this question is here when one already has access to this in open assessment. So, while preparing for this questionnaire below the underlying idea and intent was “Unique”. The questions are not copied from anywhere. They are formed based on thorough study of the subject and practical experience while working in Agile. I assure you that you won’t find them anywhere else, other than the case if they have been copied from here…. :).  Also, the purpose of having a unique set of questions was to challenge your mind and think for the right answer. While going through the same set of questions every time, I started feeling that I had even stopped reading through the questions and just looking at the structure I knew the answer to the question. This is a very bad practice from an exam point of view. With this practice, chances of me marking a wrong answer are high while going through a similar question I have attempted during mock tests. I am sharing just the questions in this post. Please share your answers in the comments and lets take it as an open forum for discussion. Your feedback is highly appreciated, I will keep sharing accordingly 






Questions: 
  1. What are the pre-conditions to start a Sprint?
a)    There are no preconditions
b)    Completely refined product backlog
c)    Both of these
d)    None of these

  1. What is the minimum required to start a sprint?
a)    Availability of scrum team
b)    List of business ideas
c)    Project Manager who can inspect the progress from start
d)    None of these

  1. From where the team gets its requirements?

a)    Product backlog 
b)    CEO of the organization
c)    Product owner announces it on mail
d)    Scrum master in collaboration with product owner

4.    Select all that is required as inputs for Sprint planning.
 .               
a)    Product backlog
b)    the latest product increment if any
c)    projected capacity of the development team
d)    past performance of the development team
e)    None of these

  1. Development team along with the Product Owner is in the meeting room for sprint planning with Product backlog, latest product increment, past performance of the development team. Scrum master Ramesh checks into the room with few minutes delay and observes that the team is not doing effective planning. Why do you think Ramesh has this observation?
 .               
a)    Team has not enough stationery available in meeting room, and may move out in middle to collect some which will be interruption in the process
b)    They are not taking into account projected capacity of the development team
c)    Ramesh is too critical of the things and interfering with the teams functioning
d)    None of these

  1. Sushil, a very dynamic and proficient Product owner, has asked her scrum master Rashmi to attend the Sprint planning event on his behalf and represent him as he is busy with some other business critical meetings. He has informed Rashmi that he has refined the backlog thoroughly and she won't face any challenge. Despite this Rashmi has declined his request. What do you think is the reason for the decline?
 .               
a)    Product owner cannot delegate his participation in the scrum events
b)    Scrum master is not justified in the decline of request as Sushil is busy with some business critical meetings and business always takes priority.
c)    Rashmi should coach the Product owner for this behavior.
d)    None of these

7.    The product owner is empowered to do the below
 .               
a)    Delegation of participation in scrum events
b)    Delegation of activities of Product backlog management
c)    None of these
d)    Both of these

  1. What is incorrect about Scrum?
a)    Lightweight
b)    Simple to master
c)    Difficult to understand
d)    B and C
e)    None of these

  1. Though scrum is a framework, however if a scrum has to be defined as a process
 .               
a)    Scrum is an a agile process to manage and control development work
b)    Scrum cannot be defined as a process as it is a framework
c)    Both statements are incorrect

  1. Why scrum is referred as a framework and not a process, technique or a definitive method.
 .               
a)    Within Scrum you can employ various processes and techniques.
b)    Scrum doesn't believe in defined processes as it against agility
c)    Process, techniques and definitive method hampers creativity and scrum fosters creativity.
d)    A framework is an approach to solving a problem that provides a rough outline of the process that will achieve a specific goal, but that does not provide the level of specificity found in a process.

  1. Scrum helps to improve the following:
a)    Product
b)    The team
c)    Work culture and environment
d)    All of the above

  1. Manohar is an agilist and has wide experience in implementing Scrum. He has been designated to implement scrum in the organisation. Team is not very convinced with the new way of working and has escalated it to the CEO. The CEO knows Manohar is doing the right things the right way and at the same time doesn't want to make the developers unhappy. He suggests few tweaks in the scrum components and their implementation.
 .               
a)    Scrum is a framework within which we can employ various processes and techniques, so suggestions by the CEO should be implemented.
b)    Each component of the scrum framework serves a specific purpose and is essential for effective usage and success.
c)    Scrum helps in improving work environment, so the happiness of developers should be taken care of and tweaks are justified.
d)    Scrum is about inspection and adaptation, so adapting to suggestions by developer and CEO should be done on priority.

  1. What is the importance of rules in Scrum?
 .               
a)    Rules of scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them.
b)    Scrum doesn't have rules as it hampers agility.
c)    Rules of scrum are described in Scrum guide.
d)    Both A and B

  1. Ravi hates sprint events every sprint and feels that it is a waste of developer’s time. Scrum master Aniruddha has been trying to coach Ravi for quite some time now on the importance of these events.  What all is applicable to each scrum event.
 .               
a)    Each event is time boxed except sprint planning which can continue till end of sprint, till the development team does not break down complete sprint backlog
b)    Each scrum event enables progress through adaptation and transparency except Sprint planning
c)    Daily scrum is one of the scrum events which is time boxed but is optional to have it as per development team decides as they are the ones who must attend it.
d)    None of these is applicable.

  1. Scrum events helps in the below:
 .               
a.            Enable progress through adaptation and transparency
b.            Opportunity for socialization among team members.
c.            Keep scrum master in job
d.            None of these

  1. What are professional scrum competencies
 .               
a)    Understanding and applying the scrum framework
b)    Developing people and teams
c)    Managing products with agility.
d)    Developing and delivering products professionally
e)    Evolving Agile organization

  1. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Living by this belief the senior most member Lakshay of the development team takes decision independently considering the juniors are not capable to handle challenges as of now and will learn with time and let them focus on other work. What is being compromised here?
 .               
a)    Transparency
b)    Respect
c)    Openness
d)    Nothing, Lakshay is living by the value of commitment and is protecting the junior team members from losing focus on the work of the sprint and goals of the scrum team.

  1. The development team in agreement with the product owner commits for a sprint goal. The team always meets its sprint goal, is focussed and is transparent in the deliverables. Product owner is also happy with the quality of deliverables. They are turning the product backlog into potentially releasable work every increment. However, the scrum master feels the development team’s work is not very challenging when looked at the deliverables of other development teams in the organization. Scrum master feels that the team is not living by the value of courage and they lack courage to work on tough problems. What should be done?
 .               
a)    Scrum master should coach the development team
b)    Development team is doing the right thing, letting them work as they are already doing a good job.
c)    Scrum master is too critical and doing comparison between teams which is not appropriate
d)    Scrum master may need to do more investigation and clear his doubts and then take the right approach to solve the problem if it exists.

  1. Today, at daily scrum Kapil has committed to finish a task which is a dependency for the rest of the team to merge their work in the master code base. He leaves by 5 and when he was about to merge his code and leave for the day, the environment has gone down and has been informed it may be up only after an hour. He has nothing pressing back at home and can spare a few hours to finish the work and then leave for the day. What should he do?
 .               
a)    He should leave for the day after sending a mail to the team that why he couldn't complete his work and also inform Scrum master that it is an impediment should be removed.
b)    Should stay back and complete the work as he has personally committed to achieving the goals of the scrum team and the goal can be endangered.
c)    Kapil can stay back late and complete the work, but he doesn't want to set up a wrong work culture at the workplace for junior team members.
d)    He should immediately check with the Environment maintenance team and understand the gravity of the situation and may take his decision based upon his analysis.
  1. Ashiana is the junior most member of the development team, and she performs testing of the software developed. Raj, senior member always ensures that what is being tested by Ashiana is re-tested so that there may not be any slippage. Also while doing estimations the team the dual testing effort is estimated, as they Ashiana is not senior enough to independently handle testing tasks, though there has been no slippage of bugs in quite some time. What scrum value is being compromised in this case?
 .               
a)    Courage
b)    Focus
c)    Commitment
d)    Respect
e)    Openness

  1. Raghav, a junior member in the team always believes in what is being told to him to do. Team is very happy with his behavior and performance and likewise Raghav as well. Navneet, the scrum master, sees that the scrum values are being compromised. What scrum values Navneet needs to coach the team about?
a)    Courage and Openness
b)    Commitment and Respect
c)    Respect and Openness
d)    Focus and Commitment

Comments system