September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Based on my understanding of your description, I do feel you are heading in the right direction. Remember, Agile is a mindset (see the Agile Manifesto), that can be supported by incorporating frameworks (like Scrum). It does not mean you can't have an Agile mindset in a different framework, or instill a hybrid approach. Like you mention, providing ample runway in digestible bite-size pieces can be helpful.
I would recommend reading through the Agile Practice Guide. It will provide a good connection b/t a more traditional to more adaptive way of working. Which is key here, right? That we steer the ship toward a new paradise by positively challenging others to think about their work differently in a new WoW (way of working).
Others will chime in with a variety of perspectives. Take what recommendations and experience are provided here as snippets of information to support your cause.
start by confirming that the project and the context in which the project is being run will be a good "fit" for an adaptive lifecycle. Regardless of whether you pick Scrum or some other agile method certain conditions will or will not support an agile delivery approach.
1. Will there be a single empowered, knowledgeable, sufficiently available person to play the role of a product owner?
2. Can you form a "whole" team possessing the cross-functional skills needed to deliver the scope and is this team dedicated to the project?
3. Will dedicated development, test & production environments be made available for use by the team or are these shared?
4. Is there strong leadership support and team-level buy-in for an adaptive approach?
Interesting your question
Thanks for sharing
Yesterday at PMI® Business Analysis Virtual Conference 2019
we had the opportunity to watch a presentation:
"What Should I Be Doing as a BA in an Agile / Waterfall Hybrid World?"
I think I can help you answer your question
in the Agile Practice Guide there a simple assessment tool, how good your project is suited for agile. Do it with your sponsor, should not take more than an hour but helps aligning both of you.
Instead of reading and understanding the full Agile Guide, you might just attend a 2 day class and get the scrum master certificate. Think scrum is simple enough and well laid out, it will help you create buy in from your sponsor if he agreed to be the product owner.
Yes, the agile mindset is what helps you in any case, Independent if you use scrum or WBS.
Agree with Kiron
I will write this with tha aim to help you. First of all: Agile you are mixing an approach (Agile) with the process model/life cycle (adaptative/iterative) with the method. All this is totally independent. For example, you can use Agile approach with waterfall life cycle. Second, Scrum is a framework, not a method. It does mean that you must fill it up with tools and techniques that best fit for your current situation. There is no line in Scrum that said you have to use user stories, storie points, etc. Scrum is defined inside the scrum guide. All the others are implementations of Scrum. Third, do not forget the systemic thinking. Is the basement do not fail. If you are thinking that using Agile approach is encapsulated to one busines unit only (software development for example) you are lost. MOST IMPORTANT: why you will use Agile? do you made the work to understand if your organization is ready? do you made the work to meassure the impacts? Each thing you introduce is because you need to solve a problem, is a solution. If you do not answer those questions in adavance then you are buying a problem, a nightmare.
The first question you should ask yourself is: what is the benefit of adopting this approach? Are you going to deliver faster? Better results? Better quality? Less resources needed?
The second question would be: is there any value in delivering small chunks of functionality? In many software projects all or most of the functionality has to be delivered in one go otherwise it is useless for the users. The theory in Scrum says that each sprint should deliver workable software but in many cases the software is never fully workable until all or a big chunk of functionality is delivered.
Scrum from my experience is a heavy-weight bureaucratic framework that involves a lot of overhead and useless meetings. I would avoid Scrum if I were you. Also it has a huge potential of micromanaging.
The advantage of an iterative approach is that you may get the users involved during the actual work so that they can identify potential issues early in the process. Even if you can't deliver workable software in two weeks you can at least present to the users the functionality that have been developed so far.
The iterative approach and user involvement has also its risks. For instance the users may continuously ask for changes and your project would never finish. I have seen that. The users get over-excited and ask for more and more until the budget is finished and the development has to stop after it has delivered nothing.
Please login or join to reply