Any advice for an org trying to shift to an agile software delivery process? What’s the best way to make a smooth transition to more iterative software delivery?
Sort By:
Oldest
Strategic Banking IT advisor in Banking4 months ago
I believe you must first identify clearly if it will serve you and in which circumstances. For example, developing a mission critical system in Agile where regulatory compliance, risk management and reliability are keys might not be a good candidate.On the other hand, adding functions to your mobile app is perfectly well suited.
We've been working in Hybrid (Agile and Waterfall) for 8 years now. With more than 200 projects running at the same time and 1,500 IT workers.
Sucess factors are:
A) Product Owners that understand their role
B) A Scrum Master and/or Agile Coach to implement the right mindset
C) Having a steady budget to keep squads working together and not being dismantled
Some risks:
A) Lack of proper system architecting ahead of start (it might becomes a patchwork)
B) Lack of system documentation. JIRA and Confluence are great but not for permanent documentation
But again, I truly believe that you cannot go 100% Agile. It depends of the nature of the project and the systems. And it's ok.
I hope it helps.
Steve
IT Managing Director4 months ago
First everyone – officers on both the business side and IT side need to agree to going in this direction. It’s not an easy pivot. You may need something like an incubation dojo – an area that the product squad – product owner from the business as well as the devs all hunker down and learn to create smaller iterations/sprints and really understand how to work in an agile fashion. This helped us to deliver faster and get feedback on our releases faster.Director of IT in Energy and Utilities4 months ago
100% Agile is a way / one way to accomplish things. It is not the only way. Agile like anything else has good things and not so good things that come with it. It is very much worthwhile to think about the outcome that is being pursued and agree on that. It is only then that Agile fit for purpose can be determined.
Director of Engineering4 months ago
Agile is a different way of working, guided by a set of principles that help teams adapt to their specific needs. When considering a successful transition to Agile, assuming you have already answered the 'why Agile' question, there are a few key points to consider:1. Start small, ideally with one team.
2. Avoid blindly copying other organisations, as it might not work in your specific context. However, it can be beneficial to gain inspiration and identify potential blind spots from others organisation experiences esepcially the one that failed to implement it.
3. Embrace Agile as a continuous improvement process; do not rush through it. Adopt the journey mindset and adjust your approach accordingly as you progress.
4. Do not become overly fixated on Agile frameworks and try to force your organisation to fit one of these frameworks. Instead, focus on adhering to the guiding Agile principles and evolving your organisation through a 'try, learn, and adapt' approach.
5. Perhaps most importantly, invest in upskilling your entire team. External training and relevant literature can be invaluable resources in creating change agents, Agile ambassadors, and coaches within your organisation.
Associate Director of Engineering in Finance (non-banking)4 months ago
Most important thing is to have strong sponsorship support from senior management or executives. It makes it easier for the change management and execution.
1. Leadership needs to be trained and part of the Agile transformation. If the teams begin working on Agile and are not supported by the upper management layers, it will most probably fail quickly.
2. Patience, patience, patience. Things will not work quickly. It will take time for teams to understand the value. There has to be an evangelist inside the organization that pushed the momentum.
3. Large organizations need to adopt some kind of a hybrid mode. Typically, organizations are governed by some kind of stage gate. It is OK in the beginning to hide the Agile development behind the stage gates. Eventually and as the organization matures, the stage gate can be relaxed, and a new proposal can then be used to reduce the stage gates in favor of the Agile discipline.
4. Learn how to estimate and use stable story point estimates. The typical story points are extremely complex for any organization to quickly adopt. I have used normalized story points which many Agile practitioners don't like but the Fibonacci sequence adds the necessary variability to make the normalize story points work (a normalized story point is 1 story point is a person delivering over day - 6 hours- taking 2 hours away for typical admin activities like meetings, training etc).
5. Take time to establish the discipline. Doing daily standups and planning is not natural and it is all about the value of Agile. If the discipline is there everything else can be done successfully.
6. Tools are not important until the discipline is established. I have been using Rally heavily and when I switched to Azure Devops I did not like it as much. Through time I adopted, and I am using the new tool successfully. Don't get stuck on the tool. It is just an enabler.
7. Estimate the team velocity and efficiency and measure it constantly and continuously. You want to see an upwards trend and get directionally to a higher or constant velocity. Fluctuations are OK but should be limited.
8. Invest in a good scrum master and more importantly a good product owner. Typical issues I have seen are caused by lack of product owner (marketing is typically not a great team to offer one - Product managers are busy with pricing, tradeshows etc - they don't have time to write stories). A good product owner sits between the product manager and the team and translates the requirements from the product manager to the functional and non functional requirements.
9. SAFe is a great system to use to scale across teams and regions. Don't take SAFe as bible. Use what works for the team. SAFe has several lean methods adopted to cover a lot of scenarios of interest for your team.
10. Empower the team to get better and always improve. Don't penalize them if they have a bad iteration. Rather ask them how can we get better in the next one.
11. Use Epics and break into Features that you estimate in t-shirt sizes (S, M L, XL, XXL), then use stories and estimate in story points (Fibonacci: 1, 2, 3, 5, 8, 13, 21, etc), then during iteration planning use tasks in hours. When the iteration begins, ask all members to put the estimate hours, todo and completed so that you can build your burndown chart.
12. Ensure your burndown chart has small WIPs (Work in progress) by ensuring the team is working on 1 item at a time to completion. Ensure the product owner accepts stories as they are delivered.
I could go on but I don't want to write a book. I hope this helps someone.