Search

Value Proposition of Agile Development

Value Proposition of Agile Development The benefits of Agile development have been extolled extensively across the web and almost every one of us is well aware of those benefits. Some of the inquisitive members have taken the efforts to research and study the Agile development framework to understand why those benefits are the products of this framework under discussion. I have no intention of going in that direction since it requires a detailed discussion that is possible in a classroom setting [reach out to your KnowledgeHut support to ask for one].   Through this article, I want to discuss the value propositions of Agile development with you i.e. in essence means, how the benefits of Agile play out for you on the ground during the execution time. What are those actual in-hand benefits that you and your team will reap because of the good thing in Agile development called Value proposition? That is what I want to share with you.   Visibility: The first value proposition that we are going to discuss is “Visibility”. The visibility to the product owner, project sponsors, managers, and engineering team about the current state of the project or product development and whether  we are headed in the right direction or not. Unlike waterfall model, where visibility is highest during requirement gathering phase then suddenly everything goes black and behind curtains with no idea about building the right thing, then suddenly we ship the product with the highest visibility. Alas, that is too late to correct anything if things have gone in the wrong direction. The value brought by Agile in this matter is that visibility remains high at all times; it slightly dips for a week or two during actual development, but it again picks up; so on an average, it remains consistent and at a higher level than waterfall model. This can be easily understood through the means of this graph where the dotted line shows how visibility into the project direction suddenly dips during the execution phase, but it remains constant for Agile.   Adaptability: The word adaptability refers to the ability to accept changes or changing business scenarios and move forward in the new direction with the same vigor and enthusiasm. In any project, adaptability is highest since the project is being kicked off, requirements are being collected so any direction, request or change can be easily accommodated. But things start to change in a traditional waterfall model soon enough and adaptability goes down considerably from the design stage and becomes lowest during shipping. Because once those things are finalized then there is no way to change them without starting all over again. Whereas in the Agile mode, though adaptability remains highest during the initial phase, it continues to hover around the same range through the project duration since every sprint is a chance to pick up something new or change direction as per business need. As you will see in the below diagram, adaptability looks  like this:   Business Value: How your project or product is delivered at the end or at regular intervals, and how it will help the business or your project owner is considered as business value. Because business does not get any value from your project until you deliver something that can be used by end consumers. Needless to say, business value is always available to be consumed at the end of project cycle or rather we should at the time of shipping. The shipping can be at regular intervals [as in the case of Agile] or in the end [as in case of traditional development methods]. In this sense, both Agile and Waterfall sound similar to us but in reality, they are not. Because they vary in the way of delivering business value. Since waterfall believes in shipping in the end or when the product is completely ready, so business value shoots up from 0 to highest suddenly towards the end. That part is obvious. Let us see how it evolves for Agile methodology. Here in Agile, we start delivering incremental versions of the product from the first sprint; so Business value starts getting generated from Sprint 1 and continues to go up until the last sprint or the time when product owner asks us to stop. This is clearly reflected in the graph shown below. Risk This is a remarkably interesting aspect of value proposition for any development model. We all want to avoid risks somehow; sometimes we succeed and sometimes we fail miserably, and our worst nightmares come true at those times. It is not my intention or objective here to dive into many ways to cut risks, but instead, analyze the concept of risk and how it varies according to the development model being followed by the team. It is a common sense that risk is highest in the initial phase of the project since we are dealing with the utmost unknown at that time. Any wrong action or decision by us will lead to failure and a complete wastage of resources. As we progress and start building something, the risk continues to go down and becomes 0 when we ship it. Because either we have succeeded by then or we have failed utterly. Agile allows us to cut down risks faster than the traditional methods because the visibility is maintained at a high level throughout, so if something is going wrong then it is addressed immediately, owing to high adaptability. If we pause and analyze for a while, we understand that high visibility, high adaptability and ability to deliver from early in the game allows us to have minimal risk score through the project rather than working hard for 1 year then finding out that you built something that was not required in first place. That is how Agile development helps us manage risks effectively as long as we execute Agile properly. Conclusion So, as we saw here, any development methodology, related to software field or manufacturing or service-based industry can be analyzed over 4 value proposition parameters, namely: Visibility, Adaptability, Business Value and Risk. In the above post, through means of graphical analysis, we compared Agile development methodology Versus Traditional waterfall and found that Agile development is much better to be followed in recent times with a condition that it has to be executed correctly. You can read my other blog post about “10 deadly myths of Agile and Scrum” whereby I have explained how wrong implementation of Agile and Scrum harms us more than benefit us. With this thought in mind, I take your leave and I hope that next time when you explain to your stakeholders about the need to use Agile, you have a better and stronger story to tell. All the best!
Value Proposition of Agile Development
Abhinav Gupta
Rated 4.0/5 based on 20 customer reviews
Value Proposition of Agile Development 325
Value Proposition of Agile Development

Value Proposition of Agile Development


The benefits of Agile development have been extolled extensively across the web and almost every one of us is well aware of those benefits.

Some of the inquisitive members have taken the efforts to research and study the Agile development framework to understand why those benefits are the products of this framework under discussion.

I have no intention of going in that direction since it requires a detailed discussion that is possible in a classroom setting [reach out to your KnowledgeHut support to ask for one].


 

Through this article, I want to discuss the value propositions of Agile development with you i.e. in essence means, how the benefits of Agile play out for you on the ground during the execution time.

What are those actual in-hand benefits that you and your team will reap because of the good thing in Agile development called Value proposition? That is what I want to share with you.




 

Visibility:

The first value proposition that we are going to discuss is “Visibility”. The visibility to the product owner, project sponsors, managers, and engineering team about the current state of the project or product development and whether  we are headed in the right direction or not.

Unlike waterfall model, where visibility is highest during requirement gathering phase then suddenly everything goes black and behind curtains with no idea about building the right thing, then suddenly we ship the product with the highest visibility.

Alas, that is too late to correct anything if things have gone in the wrong direction.

The value brought by Agile in this matter is that visibility remains high at all times; it slightly dips for a week or two during actual development, but it again picks up; so on an average, it remains consistent and at a higher level than waterfall model.

This can be easily understood through the means of this graph where the dotted line shows how visibility into the project direction suddenly dips during the execution phase, but it remains constant for Agile.


 

Adaptability:

The word adaptability refers to the ability to accept changes or changing business scenarios and move forward in the new direction with the same vigor and enthusiasm. In any project, adaptability is highest since the project is being kicked off, requirements are being collected so any direction, request or change can be easily accommodated.

But things start to change in a traditional waterfall model soon enough and adaptability goes down considerably from the design stage and becomes lowest during shipping. Because once those things are finalized then there is no way to change them without starting all over again.

Whereas in the Agile mode, though adaptability remains highest during the initial phase, it continues to hover around the same range through the project duration since every sprint is a chance to pick up something new or change direction as per business need.

As you will see in the below diagram, adaptability looks  like this:


 


Business Value:

How your project or product is delivered at the end or at regular intervals, and how it will help the business or your project owner is considered as business value. Because business does not get any value from your project until you deliver something that can be used by end consumers.

Needless to say, business value is always available to be consumed at the end of project cycle or rather we should at the time of shipping. The shipping can be at regular intervals [as in the case of Agile] or in the end [as in case of traditional development methods].

In this sense, both Agile and Waterfall sound similar to us but in reality, they are not. Because they vary in the way of delivering business value.

Since waterfall believes in shipping in the end or when the product is completely ready, so business value shoots up from 0 to highest suddenly towards the end. That part is obvious. Let us see how it evolves for Agile methodology.

Here in Agile, we start delivering incremental versions of the product from the first sprint; so Business value starts getting generated from Sprint 1 and continues to go up until the last sprint or the time when product owner asks us to stop.

This is clearly reflected in the graph shown below.



Risk

This is a remarkably interesting aspect of value proposition for any development model. We all want to avoid risks somehow; sometimes we succeed and sometimes we fail miserably, and our worst nightmares come true at those times.

It is not my intention or objective here to dive into many ways to cut risks, but instead, analyze the concept of risk and how it varies according to the development model being followed by the team.

It is a common sense that risk is highest in the initial phase of the project since we are dealing with the utmost unknown at that time. Any wrong action or decision by us will lead to failure and a complete wastage of resources.

As we progress and start building something, the risk continues to go down and becomes 0 when we ship it. Because either we have succeeded by then or we have failed utterly.

Agile allows us to cut down risks faster than the traditional methods because the visibility is maintained at a high level throughout, so if something is going wrong then it is addressed immediately, owing to high adaptability.

If we pause and analyze for a while, we understand that high visibility, high adaptability and ability to deliver from early in the game allows us to have minimal risk score through the project rather than working hard for 1 year then finding out that you built something that was not required in first place.

That is how Agile development helps us manage risks effectively as long as we execute Agile properly.



Conclusion

So, as we saw here, any development methodology, related to software field or manufacturing or service-based industry can be analyzed over 4 value proposition parameters, namely: Visibility, Adaptability, Business Value and Risk.

In the above post, through means of graphical analysis, we compared Agile development methodology Versus Traditional waterfall and found that Agile development is much better to be followed in recent times with a condition that it has to be executed correctly.

You can read my other blog post about “10 deadly myths of Agile and Scrum” whereby I have explained how wrong implementation of Agile and Scrum harms us more than benefit us.

With this thought in mind, I take your leave and I hope that next time when you explain to your stakeholders about the need to use Agile, you have a better and stronger story to tell.

All the best!

Abhinav

Abhinav Gupta

Blog Author

PMP, has 12+ years of experience working in Information technology sector and has worked with companies like Infosys and Microsoft in various capacities. He started his career as a manual tester for a world renowned software product and grew on to become automation champion in both functional as well as UI. He has worked with Healthcare units providing various software solutions to companies in North America and has worked with search engine based groups to enhance their experience and provide more bang for buck to their customers.

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

Built Instability Fosters Innovation New Product Development

As funny as the Calvin and Hobbes comic is, it conveys an important message about how creativity and chaos almost always go together. In 1981, when Honda was developing Honda City – the innovative first-of-its-kind compact car – an executive in charge of its development remarked, “It’s like putting the team members on the second floor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” Haven’t most of us experienced this at some point in our lives? The idea of “built-in instability” was first published in a 1986 Harvard Business Review paper, which kicked off the Agile movement. The paper names built-in instability as a top quality of new product development at leading companies such as Honda, Fuji and Canon. Well, what does built-in instability mean? Why is it important? How does it help teams succeed? Let’s address these questions one by one. What built-in instability means When a company’s top leadership does the following: establishes a broad but extremely challenging goal, does not provide a product definition or a work breakdown structure, AND offers the project team ample room for experimentation and failure … this is called built-in instability. The leaders have basically created an environment of constructive chaos to serve as a catalyst for creative output. Why built-in instability matters Honda’s leaders instructed the Honda City project team to develop “the kind of car that the youth segment would like to drive.” Do we see a goal here? Yes. But is the goal well-defined? No. Do we see what kind of product is expected? Uh, maybe. But do we see the steps to get there? No. With a goal like that, the only way leaders can expect the team to succeed is by letting them fail – to fail early, fail often, and fail forward. When a team has the freedom to fail and knows there isn’t a firing squad waiting down the road, it begins to break traditional boundaries. And companies that thrive beyond decades or centuries with avant-garde products do not get there with traditional thinking. This is why built-in instability matters. How built-in instability fosters success Look at the Honda City team’s goal again: to develop “the kind of car that the youth segment would like to drive.” A broad goal like this naturally demands cross-disciplinary work across a broad spectrum of organizational functions – market research, finance, planning design, production, testing, sales and service. When the team wants to succeed while having the luxury to fail, the built-in instability fosters collaboration among individuals from various functions. In the words of a member of the Honda City team: “You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand. If everyone understands the other person’s position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.” In sum, what we today use as Agile/Scrum or other modern methodologies essentially relies on built-in instability. By giving teams the freedom to fail, the process encourages a DNA of experimentation, learning, innovation and continuous growth.
Built Instability Fosters Innovation New Product Development
Author Image
Rated 4.0/5 based on 20 customer reviews
Built Instability Fosters Innovation New Product D...

As funny as the Calvin and Hobbes comic is, it conveys an important me... Read More

Empowering Teams with the Art of Positive Assumptions

What are assumptions?               In simple words, assumptions can be termed as “Personal Beliefs” or “Expectations” without any concrete evidence. These assumptions can be about a person, place, thing, the outcome of certain activity etc. Every one of us assumes at various points in our lifetime. Sometimes we even assume about our own capability. These beliefs can be either positive or negative. They may or may not turn into reality. In any case, all our behaviors and actions are closely related to our assumptions. Hence we should be cautious while making assumptions as they can make or break things.  Impact of Positive Assumptions        Building affirmative assumptions keeps us in peace and eases our life a lot. Because “Positivity” is like a boomerang! Let us see how we could use this boomerang to empower our teams: The strength of every scrum team is based on how well its team members collaborate with each other. The primary responsibility of a Scrum Master / Coach is to build a strong bonding among his / her team members. When there is a strong bonding, they trust one another, lend helping hands, collaborate well and deliver high values; above all, they will be more excited to work together. The major challenge in building a close-knit team is overcoming the conflicts that arise among its members. Conflicts are inevitable when people of different personalities work together.  Why do conflicts occur?         One of the basic reasons for workplace disputes is that the intent of the opponent’s action is assumed to be negative. We generally judge that the intention of all the souls close to our heart is good; on the other hand, in every occasion cynical about the act of the persons with whom we don’t get along well. The moment our thoughts are non-affirmative, our behaviors change and we go to any extent to distress them. Assuming Good Intention        What if we think the objective of others is good?  Just close your eyes and think for a few minutes about your childhood. Every one of us would have had fights with our siblings or friends when we were young. Did we carry it on for a long time?  Did we detest them forever? In fact, we had a lot more merry times with them after those fights right? This is because as kids we were not making any judgment of others considering their past actions; we were able to forgive and forget others mistakes. Let us bring back the same into practice now.It gives us a different perspective to look at the actual issues behind the conflicts. Therefore, being non-judgmental and assuming positive intent of every action is the key to improving intimacy among the team members. How do we get the team to assume on positive intention? We should coach the members on the following:-   Avoiding preconceived notions within and outside:                           Encourage the team to have open communications and make them focus on the facts, rather than on their beliefs. Help them use "open ended questions" for generating more insights about a person or a situation.  For instance, if a relatively junior resource joins the team , others may assume that he/she would not be proficient in domain knowledge and do not give him critical tasks. In reality, the new joiner might have strong technical skills and quick learning capability, still hesitating to open up to the seniors thinking that they may not help. Here, as a Scrum Master/ Coach, we can foster an environment, wherein both the parties discuss frankly and come forward into a mentoring relationship. Having direct communication whenever possible:          Enable the team to have more face-to-face communications than mail conversations. This is because in mails the messages are open to interpretation. Elucidating the right tone of a mail or text message would be difficult when we can’t hear the sender's voice inflection or view their body language. The accurate interpretation of any message depends on the mood of the person who crafted it as well as the one who reads it. Thus it is always better to have direct communications.    Analyzing the situational context for any actions:         For any workplace conflicts, there might be certain triggering points. Assist the team to identify those points by assessing the background and situation of the contentions. Once the origin is understood, help them discern the solution in an amicable way.           I would like to share an incident here. In one of my teams, a team member started coming late to office frequently and because of this his deliverables were getting delayed. Others in the team began to blame him, thinking that he was negligent towards his tasks. I got into this issue, had a discussion with that particular team member and understood that he had an ailing dependent at home whom he ought to take care for few months. When others were aware of this, they came forward and charted out a plan, to work in such a way that the deliverables were not impacted, at the same time his personal need was also fulfilled.     Restricting generalization:     Generalization is usually a form of exaggeration. For example, a statement like "Onshore team members always don’t understand the challenges of the offshore team" is a generalized one. It is obvious that every onshore team in an organization does not go by this statement. Hence make the team clearly comprehend all the factors before proceeding with any generalization. This will make sure that they have a clear state of mind which in turn leads to good rapport with their colleagues. Separating the persons from the problems:       Nobody wants to be a problem creator mindfully. As a Scrum Master/coach we should articulate the issues clearly, separating them from the people who appear to be the core of those issues. This helps the team to distinguish the problems from the persons, stop hating those persons for their actions and allowing them to course correct their behaviors. Improvising the Emotional Quotient:         Emotional Intelligence is the capability to recognize, manage and utilize the emotions of ourselves and others in a positive way. It gives us the ability to control and override our impulses. Moreover, it promotes empathizing, reduces stress levels and anxiety, defuses conflicts, aids better communication and improves relationships. Recognizing the opportunities and growth factors in every feedback:            Giving and receiving feedback is an effective way to raise the awareness of a person's strengths and improvement areas. In a workplace, feedback may come from any co-worker, either in a formal or informal manner, constructive or destructive in nature. In general , constructive feedbacks motivate an employee a lot, whereas the destructive feedback works in a negative way. But it is always wise to analyze every feedback, appreciate the underlying values and utilize them as an opportunity for personal and professional betterment. Changing the perceptions:            Persuade the team to change their viewpoints into the positive directions.        Once I received an opportunity to harmonize a Scrum team, which was dysfunctional due to various reasons. I observed them for few weeks. Got to understand each of the members personally. Spotted that the false opinions and lack of trust are the base for the team's dysfunction. I wanted to get rid of their false opinions at first place. Having all the team members in a room, conducted an activity as below: Team members were made to be seated around a table (ensured that friends are not seated nearby ) Had set the stage that it is an opportunity to know more about their team mates. Provided a white sheet and a pen to everyone. In 3 minutes, they have to list down the positive traits whichever they had observed from their neighbors over the period. If there were no direct observations, whatever they felt or believed as their neighbor’s strengths, good characters can be written.  When everyone completed their writing, asked them to share what they wrote to the entire team. Facilitated to elaborate the situations in which they observed those positivity of their teammates; on the other hand if someone had assumed about others good characteristics, encouraged them to share what made them to think so.   The above activity was not an instant solution to the problem which the team was facing; however, it gave a good start to know each other better and come closer. People started looking others in a different perspective, through the lens of positivity, which removed the mental blocks at first which eventually resolved other issues.       Following the above practices will ensure that the team members always assume for positive intentions and remain tightly knit. Hope you also would be trying these with your teams and sharing the valuable experiences.  Happy Coaching :-) !  
Empowering Teams with the Art of Positive Assumptions
Author Image
Rated 4.0/5 based on 20 customer reviews
Empowering Teams with the Art of Positive Assumpti...

What are assumptions?               In simple words, assumpti... Read More

Career Benefits of Scrum Master Certification

If your company is planning to adopt Scrum, the expectations will be higher in terms of increasing productivity, appreciating employee morale and getting financial rewards. One important aspect should be kept in mind in this context. Certain specific goals which you hope to achieve by virtue of Scrum, may not have absolute clarity in some cases, until the Scrum is fully implemented. In general, people do not have any idea about the benefits of Scrum, which is evident at the early stage of the transition period. Mostly you will find people who have knowledge of Agile management principle and processes. The best way to enhance your comprehension of the Scrum and its principles, along with its overall implementation, is to have an authentic certification. There are various certifications such as ITIL, Prince2, SAFe etc, which are implemented in organizations to achieve the project goals. Scrum training or Scrum certifications can be identified as one of the many courses, where employees are trained to become self-motivated and can be propelled to perform huge responsibilities. “If you are fine with yourself, you will definitely be fine with others”, goes one of the popular sayings. It tells you the importance of self-confidence which will be steer you toward achieving life goals in a self-organized manner. Benefits of Scrum certification:  Scrum certification concentrates on the importance of ‘self-organization’, which can result in the following- You can easily participate in the team activities and also, members can feel a sense of self-ownership. Employees can be self-motivated, which can help escalate team performance This training can let you create a work environment which is useful for company’s growth. The knowledge and skills garnered can make the team immune to internal and external distractions. Job Description for CSM:  CSM entirely falls under the category of Engineering. Certified Scrum Master can act as a project lead and facilitates the Agile methodology for the teams. CSM is also responsible for arranging the Scrum meetings and Sprint planning sessions CSM develops and maintains the Agile training, guide to entry-level engineers, and also ensures that the processes are lined-up with the goals. Certified scrum master works with a number of associates, including engineers, production employees, project managers, supply chain personnel, and logistics employees. CSM generally reports to the Engineering department head. According to the need of the CSM’s employer, Scrum master have to work full time or overtime if required.  Salary in different cities in US:  Popular Cities Salary New York, New York $70,685 – $1,37,957 Seattle, Washington $71,907 – $1,31,710 San Francisco, California $81,894 – $1,46,277 Washington, District of Columbia $68,885 – $1,36,149 Atlanta, Georgia $57,929 – $1,22,558  Comparing Salaries among different companies:  Popular Companies Salary Amazon.com Inc $96,958 – $1,38,725 Capital One Financial Corp $73,830 – $1,20,355 Booz, Allen, Hamilton $67,117 – $119,230 Cognizant Technology Solution Corp $69,531 – $1,04,559 General Electric Co (GE) $83,763 – $1,26,111  Entry Level Salary for Scrum Master:  Job Profile Salary Software Engineer $70,398 Software Developer $59,701 Mechanical Engineer $60,001 Electrical Engineer $62,209 Financial Analyst $50,950  Senior Level Salary for Scrum Master:  Job Profile Salary Operation Manager $75,310 Office Manager $49,941 Executive Assistant $58,975 Director of Operations $106,933 General/ Operation Manager $75,639 Administrative Assistant $42,095 Chief Financial Officer $146,171  This is all about the Certification details for the Scrum Master course. This certification adds some amount of credibility to your profile, elevating your status in the project team as well as in the organization.
Career Benefits of Scrum Master Certification
Author Image
Rated 4.0/5 based on 20 customer reviews
Career Benefits of Scrum Master Certification

If your company is planning to adopt Scrum, the expectations will be h... Read More