OutSystemsDev Zone

Five Step Agile Roadmap – Put Your Team at Ease

A recent LinkedIn question asked for advice on how to get a company started down a path to Agile and SCRUM. I thought it might be useful to share some advice and see if the OutSystems community had any ideas to add.

At OutSystems, our five step Agile roadmap is strictly a guideline because companies have different methods, cultures, and management approaches. When introducing Agile, here are the steps we generally go through. Concepts and activities that are emphasized will vary based on understanding of the customer culture, organizational structure (formal and informal), as well as their prior knowledge of Agile methodologies.

A literal five step agile roadmap

1. Education – first, level-set those involved in the roll out. We found that there are many different levels of understanding of what Agile is even if people say they “get it”. Part of this process is to make them actually go through the process before the project begins. At OutSystems, we have “Agile-in-a-Day” training sessions that provide participants with a hands-on introduction to help develop real understanding of key concepts and activities. If you have a project already selected, involve the business sponsor, business manager, and key business users.

2. Project Definition / Selection
– Once everyone is clear on the vision and direction, a project can get started. The project may have been identified earlier but how the project is chosen or what criteria was used needs to be understood. Since this is the first Agile project, we need to make sure that risks at this level are addressed to help ensure success for both project and process. The criteria for selecting the project needs to include the solution’s level of complexity, visibility, resources, and integrations.

3. Execute Project – Now we start the project by educating the target users if they were not involved in the initial Agile-in-a-day. Go through the project kickoff; explain the methodology, roles, responsibilities, timeline, deliverables, etc.; fairly standard project stuff and along the way – expunge the word “scope” from all project documents, thoughts, and discussions. Work on the backlog, feature negotiations, the sprints, scrum meetings, demos, etc. Once a sprint is done, do a retrospective and refine the processes for the next sprint and the next project. Once the solution is in production, conduct a tuning sprint. This is a special sprint we do at OutSystems to ensure 100% adoption by implementing features that will boost adoption and conducting both solution performance & platform tuning in the production environment.

4. Perform Project Retrospective
– apply lessons learned to subsequent projects and refine other processes. Note that this process improvement will involve Support organizations and dynamics between project teams. One of the things we often encounter is that Support organizations cannot move as fast as the project sprints and tend to delay Agile projects. Similarly, non-Agile projects have a difficult time addressing the integrations with Agile projects. As you execute your first project, you will find that you may need to bend or even break some rules to keep your project on track as defined by your timebox. Therefore at the end of the project, you will need to work with Support and other internal organizations to establish new protocols or processes specific to Agile projects.

5. Iterate Steps 1-4 – In our experience, we found it necessary to conduct multiple Agile-in-a-Day sessions to get everyone in the company level-set on the organization’s approach to Agile. Agile is a mindset change; expect hurdles and naysayers. Besides, change is always difficult even if the participants are willing, able, and have executive sponsorship.

(Unofficial #6 – Be realistic and good luck)

What do you think of this roadmap? How have you introduced Agile into your companies?


About the author

Robert Neri

Application development has always been Robert’s passion. From project management to customer interaction to hands-on coding and testing, Robert always looks at improving the process while delivering better applications faster with higher usability.


Nice summary — although I notice from your illustration that the process, if followed, will leave me somewhere in New Jersey. 😉
Serious question: Why do you expunge the word “scope” from all project documents in step 3? I know that we shouldn’t go into the project with preconceived notions about its scope. But within each sprint, don’t we need to maintain some control over the scope of the work? Otherwise wouldn’t we fall victim to “scope creep” and our sprint become more like a series of mad dashes?

Larry, scope creep is simply not possible if Scrum is followed.
– The business or customer, via the Product Owner, determines what features or stories are most important. The PO asks the team to work them in the order of importance.
– The team determines how to implement and how long it will take to implement the stories.
Anyone deciding that the team must do more within a specific time frame is violating Scrum and agile. The company must trust that the team is really doing the most they can. The team must return that trust by really producing what they have committed to do each Sprint.
The company can add as many things to the Product Backlog that they want. The team will continue to work in Sprints that contain a fixed quantity of work for that Sprint.
There is no scope creep.

Hi Larry, thank you for commenting on my post. I’ve never been to New Jersey (other than EWR), thought it would be interesting though…
In all seriousness, there are two reasons why the word scope should be avoided: (1) it implies all requirements need to be delivered; and (2) it to negates and undermines the budget.
Yes, I agree that when you start a project there should be an initial scope but that is just it – an initial scope to help define the project timebox and budget. I look at the word “scope” as a carryover from waterfall approach as it keeps users thinking the traditional way… something we want to change. Note that we’re not changing the way they perceive scope but rather the way they value budget so that we can put scope in check. The traditional way is to keep the scope intact while the budget changes which causes project delays, overruns and ultimately unsatisfied customers. Reality is scope will change (and even increase) but budget will not. It is much easier for the users to change their mind about scope but very difficult to increase your budget.
By making the users think in terms of budget, we get them to focus on what requirements are most important to them. We work sprints based on highest-value requirements without compromising the sprint’s timebox. Remaining high-value requirements plus changes based on end-of-sprint demos are reevaluated as part of the next sprint’s backlog. We stress that if there are new requirements, lesser-valued requirements will be shifted outside the budget… still in scope but outside the budget (think next release). Bottom line we don’t discuss about whether a requirement is in scope or not; all requirements go into the project backlog. What matters is if there is budget for it.
I hope this helps.

Pedro Gonçalves

Thank you for raising this issue! I’ve recently learned a big lesson: how scope can be a bad word. Last week I had a meeting with my Engagement Manager (EM) and customer Project Manager (PM). Our objective: resume a project that was delayed for about 2 weeks due to lack of specifications. So far so good, we did avoid some budget burning with that pause but we were still uncomfortable with all the missing dots. We simply had too much open requirements and we were unable to get more info about them. Since it was time to review the plan for tighter sprint dates and a go-live, we clearly had to make a statement about our timebox. In my presentation I included the topic «scope increase». The PM immediately perceived that as a budget threat. Understandably he couldn’t possibly believe how a month-and-a-half contract could have been consumed in just 2 weeks effort. «Poor choice of words…» our EM apologized, we really did mean «Backlog increase» 🙂 Of course we had to explain that the budget itself was not in danger but the go-live date instead which seemed quite near given the amount of features requested and still not fully analyzed. So eventually we would need to add some features after the go-live. That seemed a totally different meaning. Moreover, the fog is now less thick with a recent Q&A session and more clear requirements. This is a day that I now laugh about very relieved…


Make a good investment in step 1 (Education) and you’ll greatly increase your chances of success in all other steps.

Thank you for the simple presentation and good advice. I was surprised that you only recommended a project retrospective though. I find with teams who are just starting Agile that more frequent retrospectives are more helpful. A retrospective after each sprint allows refinements to the process and shared learning at the same time.

Hi Paul, thank you for your input. We do retrospectives after every sprint. See step #3 Execute Project, (“Once a sprint is done, do a retrospective and refine the processes…”). I wholeheartedly agree that sprint retrospectives should be done and yes, it is a means to recall and share lessons learned and “relearned”. It is the relearning part that is always a concern of course as it may be an indication that the process is not working or that the project participants skipped or did not fully understand the process or the impact of not doing something.

Leave Your Comment