Common Mistakes in Agile Implementations
Agile — if implemented correctly can deliver tremendous value in terms of speed and agility to organisations of all sizes. A number of organisations are moving to an agile environment, the change is cultural and requires a mind-shift change for larger enterprises.
The most common implementation of Agile is the Scrum process framework typically used for software development and scaled agile framework (SAFE) which scales Agile to a larger program and portfolio level with multiple scrum teams. Read Scaled Agile in Enterprises. A cross functional team (or teams) working closely with the business to deliver value in the form of working software in an incremental and iterative fashion can satisfy the expectations of the digital customer in modern times.
We are going to explore some common mistakes (or challenges) in the “Scrum” implementation of agile in the context of software development with some suggested areas of improvement and readers are encouraged to leave their own thoughts and experiences in the comments below.
Cultural shift — It is relatively easy to come up with an Agile transformation roadmap and way more challenging to create a corporate culture which adheres to an agile mindset. Years of corporate culture, hierarchal organisational structures, bureaucracy, budgeting commitments, and politics stay in way of becoming truly agile.
This is a journey that leaders at the top have to drive in the organisation for easing in Agile. Easier said than done — Creating an “agile friendly” culture requires a firm vision, senior business and IT executive support, strong governance and a clear roadmap.
“Culture eats Strategy for Lunch”
Mixing agile and non-agile teams — Since the entire organisation cannot be made agile overnight — awareness and collaboration processes to ensure the agile and non-agile teams can work together in the transition period without “writing off” each other is critical for IT leadership to align and enforce through their directors and/or managers.
Infrastructure, HR, Legal and legacy departments should be made aware of what agile really is and plan for additional capacity in their teams.
Scaling too fast with multiple teams on a single project — Scaling too fast can happen when there is ample funding commitment and teams can become large (or silo’d) and multiple teams, scrum masters and even product owners can lead to confusion in terms of shifting priorities, un-coordinated delivery and the cultural remains of working in the past.
A shared purpose, common product owner, single backlog and co-ordinated planning and release process can align teams to deliver together on a value increment usable by the end-customer.
Practices without the Principles — While doing stand-ups and other ceremonies are vital for the process to deliver value, the values are sometimes easily forgotten. Focus, Commitment, Courage, Respect, and Openness are the scrum values which need to be embodied by every member of the team in every day practice.
Having an agile coach with your team or teams is definitely a good investment since not only does it ensure there is a dedicated focus on making sure the fundamental agile principals are followed but there is someone responsible for constantly reminding the team(s) of the right values and steering them in the right direction when they stray away from it.
Project Manager becomes the Scrum Master — Scrum masters run the project in the name of scrum without being champions of the process and coaching teams instead resorting to command and control role which does not go a long way in creating self-organising teams.
Ensuring there is training and unlearning between the roles. That scrum Masters truly understand the “servant leadership” paradigm for this critical role is vital for the performance of agile teams
Technical Scrum master — A scrum master dictating technical solutions to the team may lead to employees who will stop thinking by themselves and will tend to rely on the scrum master to provide technical solutions.
The scrum master should remove impediments, facilitate and enable the team to function and think on their own. Ideally, the team should be coming up with solutions they would have to implement on their own.
Outsourced and overpriced scrum teams — if the entire scrum team is vendor based and expensive with a internal manager acting as an “enabler” — the cost vs value of the software may take more time to be realised and one may see management appetite for investing in the product gradually diminish until the scrum team is dismantled. A lot of software and process internals may get lost in the process once the vendor teams are gone due to budget or “traction” constraints.
Management needs to make a clear and aligned call on business priorities and investment they are willing to commit — establish clear KPIs both to success and failure. A good resource mix [ internal and external ] for strategic projects is the key to ensure quality and monitoring gets baked into the software development process.
Product Owner Who is Not Available Or Involved: A product owner who is not trained, who does not understand scrum or is not interested in following it may often jeopardise the program or project with their own style which is typically hands-off. The issue escalates when software does not get “delivered” as agreed in the beginning and stakeholders need to be reported on feature delivery.
Training and commitment from Product owners and their availability to adhere to agile practices are critical for the process to function.
Product owner becomes delivery manager: Rookie management can often get their own “delivery person” with IT background to be Product Owner (PO) also owning the delivery of the project end to end. This will eventually result in the PO paying more attention to the team, delivery and project timelines than bringing in business value through stakeholder communication, product success, marketing and customer support. This often results in chaos and one person having an unbalanced say in both the product and its implementation.
Delivery is the responsibility of the team. Period. Clear focus of the PO in prioritising business value working through stakeholders, working with the BA/ team to clarify key requirements, getting business people involved, ensuring internal and external marketing strategies in place and the business support required for make the product successful are planned and executed correctly should remain the full time focus of the PO (than delivery and team mechanics)
Business Analyst (BA) reports into Product owner: BAs are usually part of the scrum team and play an important role in large organisations to breakdown the requirements and systems dependancies. Since a product owner is in the driving seat for prioritising and shaping the product, a BA may tend to follow the PO, sometimes without thinking independently. It is up to the BA to work with the stakeholders and the development team to break down the real requirements behind the user stories so that the team gets a fair chance to understand the implementation complexity. Underestimating the effort for a user story is often requirements not clarified.
BA should work closely with PO and project stakeholders with a independent mind and inquisitive approach. The goal of this practice is to reduce the feedback loop, clarify requirements (both business and technical) and thereby improve overall communication and estimation for the team.
Not Raising Obstacles Early Enough: The team is new and succumbs to not speaking up and raising obvious issues — either they are a vendor team or not able to speak up in the initial stage, pile up technical debt and are rushed into delivering sub-optimal quality since scrum is meant to “speed-up “ software delivery. They suffer burnout silently, impact software quality and cause turbulence as people start moving roles and jobs.
Management and Scrum master should make the Team feel empowered, the Scrum master should facilitate protecting the team and its interests and push back on unreasonable demands from the stakeholders that could potentially impact the team’s performance.
Not Conducting Retrospective Meetings After Every Sprint: After a few rounds the same points for improvement keep coming up and the team thinks it’s not worth spending the time.
Keep retrospectives interesting. There are many different ways in which the Scrum Master can facilitate feedback from the team and determine the next action steps for improvement. Continuous learning, feedback and improvement are vital for the team to perform at the highest levels. The agile coach can also help running the retros and so can a team member alternate between facilitating this exercise with interesting variations.
Lack of coordination: Multiple scrum teams working on the same product can get big with no clear boundaries of which team is responsible for the “integration” work.
Constant communication and Planning sessions are the channels to clarify the approach and align the teams. Commitment, Communication and collaboration with a shared purpose are principles which need to be practiced to ensure people work together and are not acting in silos.
Slippery definition of “done”: Definition of done agreed by the teams working towards completing the backlog: sometimes these are vaguely defined, compromised or taken lightly in the name of completing the sprint.
A typical list could be code complete, Unit-tested, bug-free, reviewed, checked-in with automated tests. These must-have items must be true for every user story before it’s accepted by the Product Owner as completed. It becomes even more critical when there are multiple scrum teams to ensure code is consistent in terms of its quality.
Low daily value scrums: The team gets bored answering the 3 questions daily and think its just a way for everyone to report to the scrum master. They seem disinterested in what other team members are doing at times.
The team should use this as a way to collaborate, align and let each other know how they are progressing towards the current sprint goal and speak up about the impediments or risks which may derail the current sprint.
Team burnout: The team commits to an unrealistic sprint commitment (often a result of overzealous sprint planning) and then slogs day and night to meet the goals. While this may happen infrequently at times — having this as a regular cycle will mean an inevitable burnout, low productivity and shortcuts which will compromise code quality.
Sprint planning task breakdowns are exclusively for the team members to estimate with confidence without undue pressure from senior stakeholders. Senior architects and technical leads can help share their experience of implementing a technical feature and the Scrum master facilitates this breakdown in a manner which keeps the team commitment to something they can realistically deliver without burning the midnight lamp. An occasional stretch should not be the norm and after every 6–8 sprints 1 sprint can be dedicated to cleanup and other housekeeping activities.
Team begins to overestimate too much: My favorite for the last! Team becomes smarter and starts creating cushions or buffers so that sprint completion is guaranteed but they take way too long to deliver features and value increments to justify agile to senior management, who simply don’t see the point anymore. Worst case: the management does not have anyone benchmarking the performance of the team. So a team which always delivers in sprint may be taking more than required time to create the product increment because of intentional safety buffers to keep up to their “delivery commitment” instead of finding their optimal zone for delivering.
Checks on team velocity, undue and long planning process with too much technical documentation upfront, more demand for resources, irrational estimates compared to ones in the past are all signs that instead of being agile teams are falling back to “water-fallish” ways of doing things. An internal technical person working closely with a agile coach can measure, monitor and bring these to the attention of management before things go from bad to worse.
While not all of these are mistakes — they are realistic challenges in larger enterprises where culture, finger-pointing, “cover my back”, contractors and job titles may be responsible for creating hiccups — the organisation can be assisted with agile coaches and objective facilitators who can ensure teams are fully engaged and perform assessments of teams working together.
Ensure you hire great people with skills and commitment to delivering on agile. Always make sure your collaboration process works by clarifying what it means when teams reach agreement. At the end of the day it’s all about people. Hence, getting each member aligned with the shared purpose, vision, agile values and principles with a commitment is required to make it all work.
What mistakes or challenges do you see in your agile organisation? Share your views and feedback in comments below.
Altaf Rehmani is a Technology Innovator, helped various businesses with Digital transformation projects, Agile Evangelist and a champion of applying technology to enable business growth. He lives in Hong Kong and can be reached via email or twitter. Please leave your feedback and a clap if you have liked this article.
Learn all about Generativ e AI in my book: on Generative AI
Join the free Generative AI community.
Check out my free eBook “TECHSCAPE” discussing a variety of topics helping you navigate the exciting Technology space.
Other articles which may be of interest:
Future of work going into 2023.
Managing High Performing teams
Continuous team improvements using Agile Retrospectives
Common Mistakes in Agile Implementations
