top

Search

Five Common Mistakes in Agile

With the increasing popularity of Agile, the mistakes and misconceptions associated with it are also increasing. So, we have put together a list of the common mistakes made while integrating Agile into routine work processes to provide you with an awareness to avoid them to get the best Agile environment for your projects to be successful.  1) Expecting the Scrum Master to be the Project Manager The most common mistake made in Agile is assuming that a Scrum Master is the same as a project manager or a lead developer. While none of these is correct, a scrum master is a role we haven’t seen before. His role is to coach as well as facilitate his team and not manage the team. He provides guidance and advice to his team as well as the product owner on matters regarding the scrum framework.   2) Daily Scrum doesn’t make you Agile Holding daily scrum meetings just for the sake of it isn’t enough to be Agile. To get the most out of the daily scrums, it is vital to stick to its core principles, however difficult they might seem. The basic purpose of daily scrums is for the team to review their progress as well as plan their steps towards Sprint Goal. These meetings also enable the team to identify the obstacles they find on the way and deal with them. It helps in team communication and planning for the Sprint to progress smoothly. However, Scrum alone doesn’t make you Agile, it just facilitates the process.  3) A huge Scrum Team Another mistake in Agile is thinking that you need a huge team to reach the Sprint Goals. On the contrary, an ideal Scrum team is a small and dedicated unit working closely to achieve the goals while keeping itself organized. So, go for a team that is easily manageable and works closely to reach the Sprint Goals instead of having a huge and unorganized team. 4) Thinking Documentation isn’t needed in Scrum The Agile manifesto makes it clear that it values complete functionality rather than documentation, but it doesn’t mean that you don’t have to document anything at all. Before Agile, you had to document each and everything ranging from requirements, to technical specifications to test plans and what not. While with Agile, you just have to document what is extremely valuable for you, for instance, your architecture and source code. So, while deciding what to document, keep the principle of Agile in mind and choose the ones that are useful for the product in some way and need to be written down. 5) Wrong Product Backlog Getting the product backlog wrong can set the whole development of the product off course. This is a common mistake made in Agile. Pay special attention to the initial requirement gathering phase to develop a strong ground for the following phases. For instance, if you are using the User Stories, get them written by the person who is closest to the customers, which would most likely be the product owner.  Try to avoid these common mistakes while integrating Agile to your daily working practices, in order to achieve the best outcomes for each sprint progress. If you are making one of these mistakes already, rectify it to obtain better results.  
Five Common Mistakes in Agile
Wasim Irshad
Rated 4.0/5 based on 20 customer reviews
Five Common Mistakes in Agile 150
Five Common Mistakes in Agile

With the increasing popularity of Agile, the mistakes and misconceptions associated with it are also increasing. So, we have put together a list of the common mistakes made while integrating Agile into routine work processes to provide you with an awareness to avoid them to get the best Agile environment for your projects to be successful. 

1) Expecting the Scrum Master to be the Project Manager
The most common mistake made in Agile is assuming that a Scrum Master is the same as a project manager or a lead developer. While none of these is correct, a scrum master is a role we haven’t seen before. His role is to coach as well as facilitate his team and not manage the team. He provides guidance and advice to his team as well as the product owner on matters regarding the scrum framework.  

2) Daily Scrum doesn’t make you Agile
Holding daily scrum meetings just for the sake of it isn’t enough to be Agile. To get the most out of the daily scrums, it is vital to stick to its core principles, however difficult they might seem. The basic purpose of daily scrums is for the team to review their progress as well as plan their steps towards Sprint Goal. These meetings also enable the team to identify the obstacles they find on the way and deal with them. It helps in team communication and planning for the Sprint to progress smoothly. However, Scrum alone doesn’t make you Agile, it just facilitates the process. 

3) A huge Scrum Team
Another mistake in Agile is thinking that you need a huge team to reach the Sprint Goals. On the contrary, an ideal Scrum team is a small and dedicated unit working closely to achieve the goals while keeping itself organized. So, go for a team that is easily manageable and works closely to reach the Sprint Goals instead of having a huge and unorganized team.

4) Thinking Documentation isn’t needed in Scrum
The Agile manifesto makes it clear that it values complete functionality rather than documentation, but it doesn’t mean that you don’t have to document anything at all. Before Agile, you had to document each and everything ranging from requirements, to technical specifications to test plans and what not. While with Agile, you just have to document what is extremely valuable for you, for instance, your architecture and source code. So, while deciding what to document, keep the principle of Agile in mind and choose the ones that are useful for the product in some way and need to be written down.

5) Wrong Product Backlog
Getting the product backlog wrong can set the whole development of the product off course. This is a common mistake made in Agile. Pay special attention to the initial requirement gathering phase to develop a strong ground for the following phases. For instance, if you are using the User Stories, get them written by the person who is closest to the customers, which would most likely be the product owner. 

Try to avoid these common mistakes while integrating Agile to your daily working practices, in order to achieve the best outcomes for each sprint progress. If you are making one of these mistakes already, rectify it to obtain better results.
 

Wasim

Wasim Irshad

Blog Author

Professional Engineer with effective management and engineering skills. PMP® certified professional, having Masters degree in Project Management (MPM). With a good Software Engineering background, I have extensive experience in software implementation, trainings, change management and software marketing. Achieved consistent and remarkable results in execution and completion of projects and managing client relationship by prioritizing customer satisfaction.

Leave a Reply

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

Trending blog posts

Suggested Blogs

Scrum vs Kanban: Deciding New Agile Benchmark

Today in the rapidly changing market, software development is changing its list of requirement every now and then. As we all know, Agile is one form of software development methodology which mainly focusses on continuous delivery of project with client satisfaction. Agile always accepts the change and works on complete specifications to turn the project into a deliverable product. In the recent times, Kanban software development methodology is in the limelight for its ability to enable DevOps. Many of the organizations are moving from Scrum to Kanban for better results. So the question arises, which Agile methodology works better? And  Scrum vs Kanban becomes the essential question. The key differences between Kanban and Scrum depend on the Rules of using the methodology and the workflow. GOLDEN RULES Both Scrum and Kanban have a list of mandated and optional rules for their implementation. According to the Agile advice list for implementing Scrum, there are around 23 mandatory and 12 optional rules. Here are few examples: Teams are functioning in a  cross-functional manner During sprints, Interruptions are strictly avoided Work is always time boxed Scrum meetings are held on  daily basis To measure progress a burndown chart is used Firstly, the problem arises when organizations follow “Scrum But”- which is basically ignoring some specific set of rules for internal reasons. The next issue arises with timeboxing, which forms the core of Scrum. It allows the developer to define milestones for the stakeholders to evaluate and guide their project. Now in the case of Kanban, the rules are comparatively less restrictive. The principal rules are- Limiting the  work in progress To Visualize the workflow Kanban is a flexible and an open methodology that can add rules as needed, borrowed from Scrum depending upon the requirement. In Kanban, the focus is mainly on the flow and not on the timebox. This feature makes Kanban a very appealing choice to use with DevOps. WORKFLOW METHODOLOGY For Scrum: If we take the case of Scrum, every feature is decided before and it is ensured that it will be completed by the next sprint. After that, the Sprint is locked and work is finished over a couple of week, that is, usual sprint duration. The locking of the sprint is done to make sure that the team is getting enough time to make last minute changes depending on the requirement. There is a feedback session for reviewing the work accomplished. This helps to ensure that the delivered amount of work is approved by the stakeholders and is enough for directing the project as per business requirement. For Kanban: In the case of Kanban, the priority is to focus on the workflow and not on the time. The limitation is only regarding the size of the queues. Kanban’s main focus is on the productivity and the efficiency of the product. This allows them deliver superior  quality work items. In addition to this, concentrating on the workflow will keep things moving. In Kanban, there is an extended feature known as stakeholder participation. If your team is responsible for enhancing the feature development feedback of the stakeholder, then go for Scrum. But if your team is in charge of maintenance and requires to be more reactive, then you have to consider Kanban. Eventually, the need for every team is different and depending upon the requirements, methodologies need to be decided for the achievement of the goals.
Scrum vs Kanban: Deciding New Agile Benchmark
Author Image
Rated 4.0/5 based on 20 customer reviews
Scrum vs Kanban: Deciding New Agile Benchmark

Today in the rapidly changing market, software development is changing... Read More

Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum implementation in an organization. The entire effort of transforming teams with Agile ways of working is bound to fail if the role of a Product Owner is not understood clearly. Listed below some of the anti-patterns seen while the person is playing the role of a Product Owner in a team- Busy or Missing Product Owner, not being part of the development team Working software demo to the PO during Sprint Review Expressing the backlog in Technical user stories instead of focusing on business-related user stories Writing detailed user stories (no scope for negotiation) Questioning the estimates given by the Dev Team Not having a clear acceptance criteria for every story Too large user stories Not questioning the customers while collecting the requirements Not allowing the Dev Team to work on Technical Debt Not validating the customer’s idea before implementing the idea Not allowing Development Team members to talk with the Stakeholders directly Not empowering the Proxy POs Lack of vision on the product being developed Delivering more features than valuable features Not having well-defined prioritization mechanism in delivering user stories Changing priorities or requirements during the Sprint No single Product Owner, required governance missing in case of multiple POs Missing in Scrum Ceremonies Relying on mail communication for answering queries from Dev Team No emphasis on Quality Treating estimates as deadlines Instructing team on what needs to be done, acting as a Manager Expecting user stories to be created by team, considering SM and PO to be there only to review the stories Pushing team to do extra work for finishing everything forecasted during Sprint Planning Holding the team responsible for any rework post feedback from stakeholders during Sprint Review  Not showing interest in answering team queries for clarifications after Sprint planning Task monitoring Not coachable by Scrum Master Unable to prioritize the work Consistently changes priorities during the Sprint Accepting partially completed PBI’s Allowing dev team to change the Story points of a user story post implementation Not saying “No” to the stakeholders and allowing the product backlog to grow in size   There's nothing more paralysing than a Scrum team with a bad Product Owner! The characteristics stated above lead to nothing but a Product Owner “Fishbowl” where new ideas and innovative thoughts pertaining to Scrum processes find no entry at all.  The Product Owner  is... The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. It’s a one-person role that brings the customer’s perspective of the product to a Scrum Team.  The Product Owner is responsible for:  Developing and maintaining a product vision and market strategy Product management  Ordering and managing the Product Backlog  Involving stakeholders and end-users in Product Backlog refinement and backlog management  Alignment with other Product Owners when needed from an overall product, company or customer perspective.  #MostPopular in 2017: "Product Owner Anti-Patterns — 31 Ways to Improve as a PO" https://t.co/sryCdoxVKu pic.twitter.com/q5Sxj9kF6F — Stefan Wolpers (@StefanW) 22 December 2017 A GREAT PRODUCT OWNER…  Grasps, shares and spreads the product vision: A great Product Owner acts as the client's voice (also called a proxy-client at times) and makes a product vision together with the stakeholders. Each choice is taken on account of the product vision. This guarantees sustainable product improvement, gives clearness to the development team and expands the chances of product success definitely. Understanding the customer’s goals: A great Product Owner truly understands the customer’s goals with the product and is able to outpace its expectations. After all, pleasing the customer is the ultimate goal. Is a good decision maker: A great Product Owner is an authorized person to take product-related decisions. It may take some time to support his/her decisions, but this is an essential condition for an economical pace of the development team. Manages the product backlog: A great Product Owner comprehends that the product backlog should be in sequence. Priority, risk factor, quality, getting to learn and dependencies are all considered and balanced with each other. Prefers one-to-one communication: A good Product Owner believes in one-to-one communication to convey information. User stories are used as a medium of conversation. Knows modeling techniques: A great Product Owner has a knapsack full of worthful modeling techniques. Actually, the PO has an idea about when to apply a specific model. Based on the model application he/she drives the project success.  Shares experiences: A great Product Owner offers experiences with peers. This may be inside the organization, and outside it. Additionally, courses and meetings are the great approaches to share experiences and garner information. Furthermore, recording your lessons can be significant for other Product Owners. Claims user story mapping: A great Product Owner should ace the idea of user story mapping. It is a method that enables you to add a second dimension to your backlog. The visualization empowers you to see the master plan of the product backlog. Keeps an eye on functionality: A successful Product Owner keeps an eye on functional as well as on the non-functional aspects of the product. The motto of the Product Owner is to exceed the quality expectations the customer and enabling functionality that provides value to the product. So, the functionality is the main focus of the Product Owner.  Is knowledgeable: A great Product Owner has a deep product knowledge and comprehends the technicality. Larger products might be difficult to understand and scale. In this case, the PO should know the formula to solve the large queries.   Comprehends the business domain: A great Product Owner knows the ins and outs of his domain. A product should be built with a clear idea of every aspect being dealt with. This not only entails understanding the organization and paying for the development but also being aware of the current market trends. No matter how great your product is, shipping it after the window of opportunity closes is a waste of time and barely of any value.  Acts on different levels. A great Product Owner is capable of acting on different levels. These levels are popularly denoted as- strategic, tactical and operational. At the board level, a PO should know how to demonstrate the product strategy. Thereafter, he should create a strong support at middle management and facilitate the development team to cope with their daily challenges.  Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long-range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team's progress towards realizing the Sprint Goal.  Is available. A great Product Owner is characterised by his availability to the stakeholders, customers, development team and most important, the Scrum Master. This helps important questions to be answered quickly and valuable information to be provided on time. The Product Owner always makes sure that his availability never becomes the bottleneck of the progress of the development team.  Is able to say 'no'. A great Product Owner knows the best time and way to say “no”. This indeed is a difficult trait to master. While it is easy to give any new idea or feature the nod, there is a flip side. Good backlog management necessitates creating a manageable product backlog with items that will mostly get realized. Appending non-productive items to the backlog will only create false expectations.  Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for his product. He has a sharp eye for opportunities, focuses on business value and the Return On Investment and acts promptly on all possible risks and threats. Every growth aspect such as size, quality, market share of the product is taken into consideration.  Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. For example, technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.  Takes Backlog Refinement seriously. A successful Product Owner spends sufficient time refining the Product Backlog. Backlog Refinement is essentially the act of adding detail, estimates and order to items in the Product Backlog. The result should be a Product Backlog that is granular enough and easily understandable. On an average, the Development Team spends no more than 10% of their capacity on the refinement activities. There is no such prescribed approach. The Product Owner can also involve stakeholders and the Development Team in backlog refinement. Each for a valid reason. The stakeholders are given the opportunity to state their expectations. The Development Team can clarify functional and technical implications. This will ensure a holistic understanding and enhance the quality of the Product Backlog considerably. Consequently, the opportunity to build the right product with the desired quality will also increase.  Concluding Thoughts: A Product Owner is indispensable for a functional Scrum team. He not only bridges the gap between the development team and the client but also ensures a streamlined product delivery. Ill-defined Product Owner roles and some of the critical PO anti-patterns are some of the impediments many of the Agile organizations are battling at present. The only long-term solution to such persistent issues is a clarity of PO roles and a proper understanding of the end-to-end Scrum processes. 
Product Owner Anti-Patterns You Should Be Aware Of
Author Image
Rated 4.0/5 based on 7 customer reviews
Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum... Read More

Top 5 Agile Certifications in 2017

In this age, Agile is the new trend setter. Agile is an alternative to all traditional ways of Project Management which are now outdated. The demand for agile professionals has increased tremendously in both IT and engineering sector. So this is directly triggering the necessity for certifications which recruiting organization can bank on. Why choose Agile Certification? Agile is relatable to other domain service management and Project management organizations which look for Agile certified and experienced candidates. Professionals, who are aspiring to achieve a successful career in the agile domain as well as professionals who are planning to switch their jobs go for the certification. The Agile certifications will overall provide:   5 Agile Certifications in 2017  The current market has variable options readily available with regards to professional certification. Occasionally you might get confused when you have a fairly big pool of certification. Here’s the list of top 5 Agile certification trending in the current year. PMI-ACP (Agile Certified Professional)    Prerequisites: A general project experience of 2000 hours working on teams. Working  with agile methodologies or on agile project teams for 1500 hours apart from general project experience Around 21 hours of training in agile practices.        Fees: Member: US$435.00 Non-member: US$495.00  Certificate Renewal: 30 PDUs, every 3 years, $60   Scrum Alliance (Certified Scrum Master/Certified Scrum Product Owner/Certified Scrum Developer)         Prerequisites: CSM/CSPO : 2 days training from cst is a must and for CSD : At Least 5 days of formal training taught by Scrum Alliance Rep      Fees: Not Mentioned. Training institute defines it. Certification Renewal: No SEUs required, $100. Scrum Alliance(Certified Scrum Professional)             Prerequisites 70 Scrum Education Units (SEUs) from the past three year.         Fees $250        Certification Renewal 40 CEUs, Every two years, $250   Scrum.org (Professional Scrum Master/Professional Scrum Product Owner/ Professional Scrum Developer -1)         Prerequisites There is no mandate to it. Only Scrum knowledge is required.  Fees PSM : $150 PSPO/PSD : $200 Certification Renewal In this certification it is not required.   SAFe Scaled Agilists         Prerequisites 5+ years experience in software development, testing, business analysis,product or project management experience in scrum.  Fees Not mentioned, Training institute defines it. Certification Renewal 10 continuing education/ outreach hours, $100. Way to choose a best Agile Certification? After knowing the best Agile Certifications available, the next step would probably be deciding which is the best amongst them. To make it simple, have a look at the three step process which starts from basic knowledge about Agile. Once the basic level is achieved, move on to the advanced one and then finally to scaled agile So in conclusion, a professional has to make a wise call before making any judgement benefiting their career. PMI-ACP & CSM has more market value if you want to go with the popularity. If you want to gain core knowledge, PSM-I is undoubtedly the best option.      
Top 5 Agile Certifications in 2017
Author Image
Rated 4.0/5 based on 20 customer reviews
Top 5 Agile Certifications in 2017

In this age, Agile is the new trend setter. Agile is an alternative to... Read More