This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Search

How to be an Agile Customer?

In this dynamic and ever-changing scenario today, a lot of customers want to make their vendors follow Agile Project Methods. Be it in an IT or Non-IT environment, continuous integration is the most practical way to achieve continuous and visible results.Hence, a lot of companies who look for vendors/partners for accomplishing some goals are keenly interested in finding partners/vendors who can work in Agile methods of delivery.Working on continuous integration is as much as the task of a vendor as it is applicable for a client as well. Now, a lot of clients are unaware of these Agile methods in the first place and find it difficult to follow it sometimes. And also will understand the Use of Agile to Deliver Customer Success.Characteristics of Agile Customer:Joins the initial estimation of the Product BacklogSupports Agile contractingCreates the product vision & backlog togetherAttends the Sprint ReviewRespects team stabilityBeing a part of the rigorously delivery-oriented software world, I can summarize my experience with a lot of clients who wish to run their projects in Agile, but often have very limited to minimal knowledge of a working Agile environment. With this constraint, the vendors/partners are required to work in absolute sync to run the Agile Machinery in a well-oiled and productive manner.As a Scrum Master who has had the opportunity to run multiple projects in a client/vendor/partner model of products with teams scattered to multiple locations across the globe, I can say that educating and collaborating with the clients and their partners is not as easy and seamless as it sounds in a theoretical manner.We must understand the core values of Agile thoroughly to handle such situations and scenarios and also to improve customer experience with Agile. Many teammates, managers, and leadership have very limited knowledge of Agile Practices and what they are about, and often try to put restrictions on the processes which are not part of Agile Values and Principles.Core Values of Agile that one must understand The Agile Manifesto has Four Values, each Agile methodology applies the values in different ways. These Four Values are people-centric and results driven. That is why there is value in the items on the right, we value the items on the left.As an example, I will quote a situation that I faced during a project execution. Our client in this scenario was completely unaware of the Agile practices and Values. The client was mostly dependent on us as a vendor to teach them and follow the Agile Values and Methodology. Our leadership roped in an Agile Enablement team internally, so that the client could be educated and workshops were held with our team and client-side personnel to make sure that everybody learned to be Agile together.At this point, we had knowledge that a 3rd partner will create some precedents to start our project. Our team would never have to collaborate with the 3rd partner once the preceding requisites are handed over to us and we would work without any dependencies. Our team started preparing to begin the development in full force and was fully prepared to take over the Agile challenges.What challenges does Agile team come across?Days before development, our leaders got notified that the whole project schedule got bumped because the partner company had not prepared the prerequisites for us to start the development. After multiple discussions and workshops, we came down to the below solution:Now, in a situation like this, the whole Agile school of thought comes under the scanner. In this scenario, not only us, but all the three entities must be in sync to follow Agile methods and to get any real work done.Being a client/partner in an Agile ecosystem means contributing the same amount of Agility, thought and work in the process. If the client wants the vendor to be Agile, the client also should be Agile educated and willing to follow the right process to get their work done in time and with the expected quality. Usually, in these situations, the client is the required to be the oil to the whole Agile machinery between vendors and partners.A client who wants a continuous delivery should keep the following points in mind:Clear Vision – For a client to work with an Agile team it is important that they have their vision for their product/software and the way they want to build it to serve their purpose bestProduct Owner – The client party should appoint a product owner who is concurrent with their visionAgile Ceremonies – The clients should understand the importance of all Agile Ceremonies and should be willing to attend and participate the ones required for themA partner in an Agile enforcement should also be willing to enhance the Agile practices by delivering their owned work on time to avoid the cost to the client and time to the vendor.Collaboration: The key to success!In a corporate structure where collaboration is the key to success, it is very important to understand and follow common processes as important it is to understand their requirements to succeed and create meaningful and successful product/software.                                          “Talent wins games, but teamwork and intelligence win a championship”                                                                                                                                        - Michael Jordan
Rated 4.0/5 based on 1 customer reviews

How to be an Agile Customer?

4K
How to be an Agile Customer?

In this dynamic and ever-changing scenario today, a lot of customers want to make their vendors follow Agile Project Methods. Be it in an IT or Non-IT environment, continuous integration is the most practical way to achieve continuous and visible results.

Hence, a lot of companies who look for vendors/partners for accomplishing some goals are keenly interested in finding partners/vendors who can work in Agile methods of delivery.

Working on continuous integration is as much as the task of a vendor as it is applicable for a client as well. Now, a lot of clients are unaware of these Agile methods in the first place and find it difficult to follow it sometimes. And also will understand the Use of Agile to Deliver Customer Success.

Characteristics of Agile Customer:
Characteristics of Agile Customer:

  • Joins the initial estimation of the Product Backlog
  • Supports Agile contracting
  • Creates the product vision & backlog together
  • Attends the Sprint Review
  • Respects team stability

Being a part of the rigorously delivery-oriented software world, I can summarize my experience with a lot of clients who wish to run their projects in Agile, but often have very limited to minimal knowledge of a working Agile environment. With this constraint, the vendors/partners are required to work in absolute sync to run the Agile Machinery in a well-oiled and productive manner.

As a Scrum Master who has had the opportunity to run multiple projects in a client/vendor/partner model of products with teams scattered to multiple locations across the globe, I can say that educating and collaborating with the clients and their partners is not as easy and seamless as it sounds in a theoretical manner.
We must understand the core values of Agile thoroughly to handle such situations and scenarios and also to improve customer experience with Agile. Many teammates, managers, and leadership have very limited knowledge of Agile Practices and what they are about, and often try to put restrictions on the processes which are not part of Agile Values and Principles.

Core Values of Agile that one must understand
 
The Agile Manifesto has Four Values, each Agile methodology applies the values in different ways. These Four Values are people-centric and results driven. That is why there is value in the items on the right, we value the items on the left.
Core Values of Agile that one must understand
As an example, I will quote a situation that I faced during a project execution. Our client in this scenario was completely unaware of the Agile practices and Values. The client was mostly dependent on us as a vendor to teach them and follow the Agile Values and Methodology. Our leadership roped in an Agile Enablement team internally, so that the client could be educated and workshops were held with our team and client-side personnel to make sure that everybody learned to be Agile together.

At this point, we had knowledge that a 3rd partner will create some precedents to start our project. Our team would never have to collaborate with the 3rd partner once the preceding requisites are handed over to us and we would work without any dependencies. Our team started preparing to begin the development in full force and was fully prepared to take over the Agile challenges.

What challenges does Agile team come across?

Agile Testing Challenges
Days before development, our leaders got notified that the whole project schedule got bumped because the partner company had not prepared the prerequisites for us to start the development. After multiple discussions and workshops, we came down to the below solution:

Now, in a situation like this, the whole Agile school of thought comes under the scanner. In this scenario, not only us, but all the three entities must be in sync to follow Agile methods and to get any real work done.

Being a client/partner in an Agile ecosystem means contributing the same amount of Agility, thought and work in the process. If the client wants the vendor to be Agile, the client also should be Agile educated and willing to follow the right process to get their work done in time and with the expected quality. Usually, in these situations, the client is the required to be the oil to the whole Agile machinery between vendors and partners.


A client who wants a continuous delivery should keep the following points in mind:

  • Clear Vision – For a client to work with an Agile team it is important that they have their vision for their product/software and the way they want to build it to serve their purpose best
  • Product Owner – The client party should appoint a product owner who is concurrent with their vision
  • Agile Ceremonies – The clients should understand the importance of all Agile Ceremonies and should be willing to attend and participate the ones required for themThe Agile train

A partner in an Agile enforcement should also be willing to enhance the Agile practices by delivering their owned work on time to avoid the cost to the client and time to the vendor.

Collaboration: The key to success!

In a corporate structure where collaboration is the key to success, it is very important to understand and follow common processes as important it is to understand their requirements to succeed and create meaningful and successful product/software.

 Collaboration
                                          “Talent wins games, but teamwork and intelligence win a championship”

                                                                                                                                        - Michael Jordan

Shreeti

Shreeti Bhattacharya

Blog Author

Shreeti is an Agile enthusiast with 7+ years of experience in IT  industry and is currently working as a Scrum Master.She believes once you become Agile, you can always achieve it in time.

Join the Discussion

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

1 comments

venkey 13 Nov 2018

The article is very intresting and very infromative.

Suggested Blogs

Benefits of Implementing Agile Practices for Infrastructure Operations Support Teams

Agile methodologies have become mainstream and more than 90% of the organizations had indicated that they are practising Agile in some form or the other (Version One, State of Agile Survey, 2016). In this post, I will highlight how a specific Agile methodology is used in the infrastructure space to manage routine operations work.  In the infrastructure domain, there are not many organizations which are using Agile as it is not easy to implement the scaled Agile framework (Scrum) as the nature of work is more from the operational perspective as compared to the product development space where the focus is on knowledge work. However, in large enterprise organizations (> 5000 members), if an organization has to become agile, all the divisions will sooner or later need to focus on Agile. The organization does not derive much benefit if only one division in the organization is focused on Agile and all the other divisions are not being agile. Hence, initially as part of the Agile transformation, the product development division adopts Agile and subsequently, other support divisions also focus on exploring Agile and how to implement Agile for their activities.  With this background context, I would like to explain how the Infrastructure teams which are engaged in operational activities focus on implementing Agile in their projects/activities. Taking the specific example of a Unix Server Support team which is offering support for L1, L2 and L3 activities (L1, L2 and L3 – different and increasingly varying and higher levels of support where the team focuses on providing support to the customer, e.g. – L1 – call center support, L2 – Basic configuration and minor changes, L3 – Deep Dive and resolution of problems). Generally, the Infrastructure teams follow the ITIL Best Practices to ensure that their services are providing optimal support to the customer (24*7 support – also enabling follow the sun approach). In this case, when we are implementing Agile practices for these teams, I have observed that Kanban practices and a good Kanban framework help the team integrate ITIL with Agile practices.  These teams are focused on operations work which is routine and is undertaken daily through the implementation of a help desk support system (Service Now, Impulse, Jump, Remedy and other tools) utilizing tickets that are raised by people and non – humans (computer programs).  The tickets are raised automatically by computer programs (incidents), raised by humans (mostly requests), problems (raised by humans), change requests/ctasks (change tasks) by humans. Hence, ITIL implementation provides a good focus on the key areas – Incident Management, Problem Management, Change Management, Help Desk and related areas. In such a scenario, the implementation of Kanban helps to integrate ITIL and Agile and the team does not feel the extra burden of the Agile implementation. Kanban easily dovetails with the existing ITIL framework and the team is able to implement both Kanban and ITIL at the same time. This ensures that the team is meeting the organizational requirements and at the same time, the team is also able to implement Agile as per the requirements.  The routine operational work of these teams is considered as one big project focused on delivering operational support and meeting the service level agreements for the customer. Kanban is basically a framework for managing the process flow and change in a visual manner. It starts with the as-is state and slowly builds on incremental improvements to improve the process over a period of time. Hence, it becomes easier to start with the already existing ITIL processes which the teams are already following in their day to day work. The Kanban system focuses on visualizing the process flow and identifying the bottlenecks in the process and how they could be eliminated so that the process becomes faster from concept to cash. In this case, it derives the basic inspiration from Lean principles which are also focused on identifying and maximizing value, while minimizing waste at the same time.  The focus on implementing Kanban frameworks for the Operations team in the Infrastructure domain leads to the following benefits–  The team can manage its process flow with the already existing systems in place (e.g. lean, ITIL and other process models/frameworks).  Workload Management, Capacity Adaptation, and Capability/Competency Improvement in the teams. It is easier for the team to implement Agile practices as Kanban focuses on starting with the existing processes instead of making any drastic changes in the basic process.  The team is able to visualize the basic work through the technique of value stream mapping (VSM) and it is able to eliminate bottlenecks using the Theory of Constraints (ToC).  The team is able to identify the core values and focus on how to enhance customer delight.  Implementing Agile practices leads to improved team motivation and team morale.  Focus on working at a sustainable pace instead of working in death march projects which leads to quicker burnout and increased attrition.  It helps the team to visualize the workflows which enables the team to focus on out-of-the-box thinking and innovative techniques to improve lead times of their processes.  Simple metrics like – lead time, cumulative flow diagrams and Yamazumi charts help the team to focus on their processes and check how they could fine tune their processes further.  Lessons learnt as part of the Kanban meetings and workshops enable the team to focus on continuous improvement.  The focus on Kanban practices enables the team to set up a robust ecosystem in the organization that engenders continuous learning and enables the organization to build the skill level of its employees.  Assimilation of new processes by the team through design thinking and other techniques for providing operational support helps the team to improve customer satisfaction. Thus, we can observe that the choice of selecting Kanban as an Agile implementation methodology for the Operations Support Teams in the Infrastructure domain is a prudent option as it helps the team to continue following its existing processes and at the same time also implement Agile practices in their projects with minimal conflicts. In future posts, I will highlight how we could go about implementing Kanban and Agile practices in the Infrastructure Operations Support teams, providing support to the product development teams in the organization.   
Rated 4.0/5 based on 20 customer reviews
1460
Benefits of Implementing Agile Practices for Infra...

Agile methodologies have become mainstream and mor... Read More

CSM or CSPO: Which Certification Fits Your Requirement?

Agile methodology has been gaining a lot of clout in the IT Industry recently. With so much attention and talks around it all companies big and small are making themselves agile ready to deliver better sooner. Some common Certificate courses on Scrum methodology have also gained popularity because Scrum is the least restrictive of all agile approaches. CSM and CSPO are two such known Certifications that are often thought of as next steps in career progression introspection analysis. While both grant the benefit of knowledge, it is important to analyse what Certification makes more sense and can help better in future growth.     CSM Certification: It is for professionals seeking the Certified Scrum Master Certification. Its course work is educative to learn about how Scrum methodology works. Moreover, all the principles and practices around scrum are discussed in detail to lay a sound foundation of its conceptual framework. This certification is beneficial to gain an understanding of Scrum for all present and future scrum projects. Gaining a CSM Certification would benefit individuals who would rather want a Certification that validates their scrum knowledge. Hiring decisions based on Certifications are usually a motivator for professionals pursuing the Certification. This could also lead to challenging opportunities in a space that may interest professionals. Also, professionals seeking to change their present roles can also benefit from this certification to project their interest in this field. Other benefits of CSM could be acceptance in scrum based teams based on scrum knowledge. Also since a lot of organisations tend to portray to their respective client base they own the skills and knowledge to deliver, they also rely on certified professionals to join them so that they may use this as their asset over competitors. Another reason to pursue CSM could also be to expand ones’ knowledge of scrum methodology to be at par with peers. Since existing technical courses do not teach these new methodologies in courseware, pursuing a course about Scrum can help deliver work better if you have recently joined a scrum team or if you plan to join one. So, it is beneficial not only for professionals seeking knowledge as fresher but also for experienced professionals who seek work in scrum space.   CSPO Training: CSPO is a common IT Certification acronym for Certified Scrum Product Owner. CSPO Certification is beneficial for professionals who are closer to business.  This course is also useful to give an end to end view of the feature that traverses from conceptualisation to deployment or ideation to a minimum viable product. Also, aspects related to understanding stakeholder interests in each functionality are reiterated in this course. Also, because a Product Owner’s role is critical for any organisation they tend to seek candidates who can genuinely guide the team well. While Certification is a way to project, that relevant knowledge is present and make way for a baseline to set that a candidate has genuine interest in the area and that they are focused on continuous growth. A Certified Scrum Product Owner training is also a good to have training to be able to handle the work as a Product Owner better. While a lot of professionals learn on the job, this certification is from the very Scrum Alliance dedicated to set guidelines that can help smoothen the learning curve. A Certification decision is hence usually based on career goals, present career role, and future possible roadmap. Having knowledge is always good and to keep refreshing basics helps revisiting decisions and making teams and individuals in scrum space more effective.
Rated 4.0/5 based on 20 customer reviews
1367
CSM or CSPO: Which Certification Fits Your Require...

Agile methodology has been gaining a lot of clout ... Read More

The Importance of the Transparency Value in Agile

1. Introduction In this article I’ll be writing about Agile and the importance of transparency in Agile Software Development.  This article is focused mostly around Scrum teams, but many points would apply to Lean and Kanban environments as well. Transparency is one of the core values of Agile.  Transparency is critical to the success of organizations and groups adopting Agile.  In Scrum we use burndown and/or burnup charts to report the progress of the team throughout the Sprint.  In Scrum we also have “ceremonies” or meetings that help with transparency, which include the Daily Standup, Sprint Planning, Sprint Review, and Retrospective meetings.  These all give the team and product owner a chance to raise issues and be honest about things like the team’s progress.  The meetings also give the team a chance to adapt and improve. 2. Why is transparency important to Agile Transparency in Agile Software Development cannot be overstated.  In some organizations it is not easy to be transparent and open.  There are lots of pressures to say what the business wants to hear.  But I believe in the long-run a lack of transparency hurts an Agile team, the project, the organization, and ultimately the company.  I've seen firsthand organizations that claim they want “openness” but then, I can say that true transparency is not easy.  Transparency is critical to the success of Software Development using Agile Methodology  and it is well worth the effort.  Without full transparency there are lots of bad things that happen, including: Lack of trust with the Product Owner Team has to get caught-up in politics instead of focusing on what needs to be delivered Team morale can suffer Measuring future work is more difficult The team’s true velocity is not known 3. How teams can be more transparent with a Product Owner There are several steps a team can take to prevent the issues raised in the previous section.  In this section, we will cover some of those steps.  Use burndown charts to be honest about how the team is performing in a given Sprint. A burndown chart tells the true story of how the team is performing. Some teams also use a burnup chart for this purpose. If you cliff-dive at the end of the Sprint, that's not the greatest, but at least you are being honest to the Product Owner in terms of what happened.  If you are not going to make the Sprint commitment, at least that will be more obvious during the Sprint (i.e. the burndown will show that the team is not closing enough points each day and is at risk of either cliff-diving or not meeting the commitment). The point is that the team is being completely transparent.  The velocity is what it is.  The product owner knows what the team is capable of delivering. Using the raw data and not hiding anything from the business frees an Agile team. I believe it is Kent Beck that has an excellent quote in one of his presentations about what he calls “schedule chicken.” He tells a story about people around the table during a typical project meeting and the project manager is going around asking each team how things are going. Everyone wants to put on a good face and says “umm, yeah we are on schedule” even when they are not. Now they have to sit there and know that they might be caught in a lie later. Better to just be honest and say “Well, we are about 2 Sprints behind.” Done.  Now there is nothing to hide and you can move on and deal with the reality of the situation you are faced with. There are a couple things that happen when the team is honest with the Product Owner.  The first, as mentioned previously, is the relationship between the Product Owner’s trust in a team and the team’s transparency.  Figure 1 below shows this relationship.   But there is another benefit we get from being transparent: the team’s velocity becomes more accurate.  This can be seen in Figure 2 below.   4. What Product Owners Should Ask If you are a Product Owner what are some of the signs that a Scrum team is not being 100% transparent?   This section will focus on some of the red flags or “smells” that may indicate a team is not being truthful and transparent.  If a team does not want to share their burndown and/or burnup charts, that is an obvious red flag and is simply not acceptable. If the velocity of a team is very static, that may also indicate issues.  This may indicate that the team has a fixed amount of points they will always commit to for a Sprint, regardless of their actual capacity.  More on this in the section below on case studies.  Another possible red flag is when most User Stories have the same point value.  It could indicate that the team is using a “one size fits all” for their estimates.  The Product Owner should not be afraid to press the team if they feel the team is not accurately estimating User Stories.  But you need to ask in a way that is not accusatory. 5. Case studies In one Scrum team I saw a real lack of transparency and it really was not a good experience. Soon after joining this Scrum team, I attended my first Sprint Planning meeting on this team. In the meeting I noticed something odd. Their true velocity was let's say, 40 points, but they would only commit to around 30 points. They would then find a few more stories and put them in the next Sprint. These additional stories were what they would call “a stretch goal”. But they knew their velocity was much higher than what they were committing to. This seemed very wrong to me. It was a total lack of transparency and honesty. Not surprisingly, the team would typically finish the stories in the current Sprint and then work on a few more stories from the next Sprint that they had put aside. For the most part, this was a management decision because they did not trust the team to meet their velocity in a consistent fashion. This led to a lack of transparency with the business, and normal tools like burndown charts could not be trusted. Also, it did not make the team feel very good because they knew they were not being honest with the business. Instead of using this "stretch goal" approach, use the velocity of the team to measure how much work can be done in a given Sprint. Then, based on capacity, commit to what you know your team can complete that Sprint. Be honest about the team’s velocity and don't give into political games about trying “to look good” on some presentation slide. This type of misrepresentation does not benefit anyone in the long run. 6. Conclusion The bottom line is to let the quality of the team’s work speak for itself. Have a consistent velocity, deliver software without defects, deliver business value, and adapt to what the business needs.  This will lead to more trust with the Product Owner and will make the team feel better since they are being 100% honest not having to play any games.  This lets the team focus on what truly matters:  delivering quality software that adds value.  
Rated 4.0/5 based on 20 customer reviews
The Importance of the Transparency Value in Agile

1. Introduction In this article I’ll be writing... Read More