Leda WuSr. Manager of Enterprise PMO| Empyrean Benefit SolutionsLeague City, Tx, United States
Hello all, I am curious about the success rate of Agile framework. Our company's development team has adopted Agile process for 8 years, yet the team is still struggling to complete the items in each sprint. The completion rate is less than 50%. Hence the rate of hit the target development completion date is very low. Can someone in this community share some information at your company? What is the success rate? How do you conduct the Agile process? Appreciate any advice/input.
On the other hand, we have project team who is doing Waterfall and delivered the project successfully (on time, meeting the requirement, get a very good ROI). Saving Changes...
1. Agile approaches are not a silver bullet to cure all delivery problems, especially those related to cultural or senior leadership dysfunction.
2. Any time you introduce a change to how teams work, there will be a corresponding reduction in productivity for a (hopefully) short period of time.
There are companies in many different industries that are succeeding with agile approaches, but you need to remember that agility is a journey and not a destination and sometimes there are potholes along the road.
Kiron
...
1 reply by Leda Wu
Mar 01, 2021 10:19 AM
Leda Wu
...
Thank you Kiron for your reply! We do have leadership's full support. Agile approach has been implemented for 8 years and the journey has been quite long.
There is no "Agile framework" but there is a Scrum framework and since you mention sprints I think that your question is about Scrum.
If the team is completing on average less than 50% of the work in a sprint then they are not doing sprint retrospectives and sprint planning properly. Are the team measuring their performance and adapting accordingly? If so, why do they keep planning twice as much work in a sprint when they know from past performance that they don't complete it?
It's possible that the problem may be: the team aren't truly in control of what gets assigned to a sprint; sprints are too long to allow for realistic planning; the team is too large. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I am bringing the bread to my table from 1995 up to date helping to implement and use Agile in organizations around the world with different size and markets. Beyond that, I published articles and papers on the matter of my own research including it PMI´s official publications. So, sorry for talking about me but my intention is to emphasize that "it works". BUT here comes the key points. First of all, what does mean "it works". For example, taking your comment "as-is", please do not be angry with me, you stated "Agile framework". That´s one of the problems and reasons to fail. Agile is not a framework neither a method and Agile is not defined in the Manifesto (the Manifesto is for software solutions). So, while I can write a lot, the problem is do not understand: 1-what Agile really is. 2-Agile is a matter of enteprise architecture. 3-Agile, Lean or any other approach to use has to be implemented taking into account the architecture of implementation which is (from botton to top) approach/life cycle process/method/tool. AND the most important: when you use an approach, a "new wave of living" the organization, that´s must be because it is a solution to a business problem not a silver bullet like @Kiron stated. Saving Changes...
Product Operations Program ManagerBarcelona, Cataluña, Spain
Great discussion with fantastic inputs from Kiron and Sergio.
You mentioned that the development team has shifted towards Agile. Is the company fully on board with this (partial) transformation? In the case of Microsoft, the agile transformation was bottom up, with a tipping point when top management decided to embrace it and back it up. Is your company fully on board with the Agile transformation? And this goes beyond project management, but also at operational level.
In short, if not endorsed by the decision makers/big guys, the likelihood of a successful transformatio significantly decreases.
...
1 reply by Leda Wu
Mar 01, 2021 10:15 AM
Leda Wu
...
Yes, the company is fully onboard. Yes, top management embrace it and back it up.
Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
"Our company's development team has adopted Agile process for 8 years, yet the team is still struggling to complete the items in each sprint."
Have them commit to less work each iteration. Empirical data proves that they're taking on more work than they can complete. This is not "Agile vs Waterfall," this is simple lessons learned. Saving Changes...
Leda WuSr. Manager of Enterprise PMO| Empyrean Benefit SolutionsLeague City, Tx, United States
Feb 27, 2021 12:30 PM
Replying to Eduard Hernandez
...
Great discussion with fantastic inputs from Kiron and Sergio.
You mentioned that the development team has shifted towards Agile. Is the company fully on board with this (partial) transformation? In the case of Microsoft, the agile transformation was bottom up, with a tipping point when top management decided to embrace it and back it up. Is your company fully on board with the Agile transformation? And this goes beyond project management, but also at operational level.
In short, if not endorsed by the decision makers/big guys, the likelihood of a successful transformatio significantly decreases.
Yes, the company is fully onboard. Yes, top management embrace it and back it up. Saving Changes...
Leda WuSr. Manager of Enterprise PMO| Empyrean Benefit SolutionsLeague City, Tx, United States
Feb 26, 2021 5:03 PM
Replying to Kiron Bondale
...
Leda -
A couple of comments:
1. Agile approaches are not a silver bullet to cure all delivery problems, especially those related to cultural or senior leadership dysfunction.
2. Any time you introduce a change to how teams work, there will be a corresponding reduction in productivity for a (hopefully) short period of time.
There are companies in many different industries that are succeeding with agile approaches, but you need to remember that agility is a journey and not a destination and sometimes there are potholes along the road.
Kiron
Thank you Kiron for your reply! We do have leadership's full support. Agile approach has been implemented for 8 years and the journey has been quite long. Saving Changes...
You can do Agile in a lot of different ways, seems that you are doing scrum and doesn't work, are your teams tech teams? ERP, UX, WEB...? depending also the type of work, maybe scrum as "scrum" is not a good fit, there are other ways to be agile, and for a big developments or ERP's maybe LeSS or Scrum at scale will work. Saving Changes...
I would suggest looking at the root cause of the shortcomings in the "agile" teams so that you can work out the bugs. I have found that there are many different opinions regarding what it means to implement agile approaches. Some work very well, and some resemble sanctioned chaos.
In some cases, people adopt a specific brand of agile workflow learned from someone else in a marginally related field, and treat it like dogma that cannot be altered. I call that "rigid agile". Any approach must be tailored to the specifics of the situation. Like the PMBOK, "agile" is not a cookbook approach.
In other cases, some people use agile as an excuse to avoid all accountability. Schedules, process, and PM oversight are all considered the enemy of efficiency. In these cases, work can go on indefinitely without converging on a solution.
In my current job where we develop integrated electronics in a large developmental program, we use agile approaches daily without ever mentioning agile. Implementing functionality early and then building upon it has been far more successful than purely predictive programs where we got to the end before we found all the problems which took many months to resolve.
My own work is primarily focused on how we manage the equivalent of sprints. At each iteration, I analyze what worked, what didn't, and why. Then we self-form teams of relevant stakeholders and further develop the process, just like others are developing the product.
When we go late implementing sprints due to late discoveries, so I focus on ensuring we have time at the end to account for those issues. If groups adopt an attitude that late doesn't matter because problems will just slide into the next sprint, I focus on schedule discipline. Rather than watching the recurring problems repeat themselves, we continuously work to build on the current process functionality to meet our customers' needs. Saving Changes...
Leda stated: "Our company's development team has adopted Agile process for 8 years, yet the team is still struggling to complete the items in each sprint. The completion rate is less than 50%."
I have some questions and thoughts/experiences for your consideration. 1) Who is deciding what work to put into the sprints? 2) Who is sizing the work? 3) Who is committing to complete the work? 4) Is the answer to the first three questions the same person or group of people? 5) Are regular retrospectives held?
The answer to question #4 will help determine the type of problem you have, with relation to the work performed during sprints.
If the answer to question #4 is yes, the same person or group of people are responsible for sizing the work, defining what can be done during the sprint, and then completing the work, this team either does not understand or is ignoring their actual velocity. One way to approach this problem is to work with the team to size work that has been completed and then calculate the value of each sprint to determine average velocity. Then, going forward, use the previously established sizing to size new work and use the new velocity to determine what can be accomplished in the upcoming sprints. Another thing to look at is whether there is enough information in the stories for accurate sizing at the time the sizing is performed. Lack of information can be a schedule killer.
If the answer to question #4 is no, what needs to change for the answer to become yes? If the people performing the work aren't sizing the work, the sizing will be wrong. If the people performing the work are being told what needs to be finished and actual velocity is being ignored, there is a strong chance that not all of the identified work will be finished. Are there other influences (like launch dates or management) pushing the team to make unrealistic commitments?
Regarding question #5, assuming the answer is yes, does the team discuss why they are struggling to complete the items in each sprint during retrospectives? Are they working together to come up with solutions? Are the solutions tracked and discussed in following retrospectives? Think of retrospectives as your own internal change management process. If the answer to question #5 is no, you might consider changing that.
Several years ago, I took over a scrum team in what was, on the surface, a similar situation to yours. At least half of the work in each sprint was carried over to the next sprint. There were some external factors that required more than just improved sizing to improve the situation. I used retrospectives to identify the challenges, come up with solutions, monitor progress, and change our approach when a solution became less effective. We changed our approach from Scrum to Kanban - management didn't care about our approach as long as we delivered. Managing WIP and WIP limits was a little bit of a challenge, but as we resolved the external problems and improved the teams ability to size their work, we were able to switch back to Scrum and start delivering on a more consistent cadence.
I'm not suggesting you switch to Kanban; changing your approach could create more problems if the approach is not a contributing factor. It's more important to identify the contributing factors to the delays and then, with the team, develop strategies to overcome them. Saving Changes...
Community Champion
