Please login or join to subscribe to this thread
Use what works. Understand why you want to go Agile and then look at what will accomplish that. Remember the Agile principles and values are guidelines, not rules. When considering the methodology or framework again consider what you want to achieve and do not be guided by the latest buzz. Scrum or SAfe might not work for everybody.
One thing I would avoid like the plague is trying to be a purist. I've seen so many posts about how people are doing Agile 'wrong'. REALLY! The only time anything is 'wrong' is if you do not achieve your objective, which I would assume is some positive outcome.
So let me conclude - Understand what problem/s you are trying to solve with Agile and then USE WHAT WORKS.
In reality, in my projects there is a kind of resistance to change and the excess of documentation often delays daily activities.
Personally I would start by looking at exactly what excess documentation means and why there is an excess. I'm not saying you should not adopt Agile but I am saying that you need to consider the cost and benefits in your situation. Maybe the reason for excess documentation is a guy named Peter sitting in some corner and just speaking to Peter and resolve the issue. I know it is oversimplified but I think you get the point.
Interesting your question
Thanks for sharing
There are several people in this forum who write about AGILE and AGILE Transformation
There are some webinars on the topic.
I recommend watching a series of webinars
There is also the option of content search
I wish you a good walk in search of AGILE
If you are looking to transform your organization to being more agile, this will take a combination of top-down (strong leadership commitment) and bottom-up (team-level buy-in and interest) participation.
While there can be many benefits of becoming more agile, like all organization transformations, it will take a lot of effort to get there.
I'd encourage you to look at the Disciplined Agile framework as it does provide a good basis for guided continuous improvement rather than the 'revolution' which many agile methods require.
No, no recipe. But certainly, based on what you conveyed about your organization, slow and steady. Hopefully, this change is supported by leadership, otherwise, the road may be a bit bumpier. Don't overburden your stakeholders with jargon or force the adoption. Provide sensible changes that make sense and are further supported by the rationale of why - as in what's in it for them.
I had done something similar. I conveyed the rationale as being more inclusive with smaller buckets of work and an increased feedback loop to further empower them and better ensure the final product more accurately solved the intent of the work.
And like Kiron, suggests, DA looks at it more general, as in Ways of Working, which is essentially what we're talking about here. And it can be conveyed that way - changing ways of working by adopting an Agile mindset.
There is not a receipt. There are lot of studies and literature based on practical cases. And sorry to said that but it includes my own studies and published cases. But, forget about it. Go to the "Master". There is one and only one source that will help you: Tom Gilb´s work mainly EVO Model. Go for it and forget any other thing (sorry for being cathegoric). And remember: Agile is not about to use a method or using a process of not about software. About this topic you can search for the deliverables of the plance were agile was born in 1990 some of them compiled by Rick Dove.
There is no recipe for this because Agile is a mindset, not a methodology. There isn’t much to add to what my colleagues mentioned above but Kiron mentioned the magic key: It is a two way approach - Top-Down + Bottom Up
One of the most important things to keep in mind is that an agile transformation is first, and foremost, a transformation, and needs to be handled as such. You're dealing with scaling agile across an organization, not just setting up an agile team and telling them to go deliver value quickly. There are processes to change, expectations to manage, and possibly harsh realities to face.
I attended a panel, yesterday, with thought leaders from both the Organizational Change Management (OCM) and Agile Coaching spaces (two separate groups of people). The Agile Coaches recognized that they would benefit from better OCM on their transformations. One of the speakers also made a significant point - that you can expect an agile transformation to take 1-3 years AFTER your leadership is on board and actively supporting and using agile processes (not just signing a check and saying 'Go!').
Agile does require structure and controls. It is not do what you like and keep it only in your head.
Please login or join to reply