welcome to the project time box overview session in this session we'll introduce
the time box principle and view it from a number of different perspectives to
try to understand it better to start no agile practice is a one-size-fits-all
approach we need to understand the business and IT reality and the culture
behind it and attempt to adapt to that this means that the core agile
methodology should be followed but the method can be customized or optimized so
that the business and IT that are adopting it and implementing it can do
it successfully the OutSystems agile methodology has several guiding
principles the timebox principle which means that the overall development will
occur in a well-defined time frame collaboration and a collaborative
approach between the delivery team and the stakeholders so that the groups
begin to act as one team we also know that development will occur in
iterations which gives us room for feedback and changes without budget
impacts we know that user feedback is golde to making sure that we can improve
the overall solution we want transparency throughout project and
project management so that people understand where things are and we want
full visibility on the progress and the execution of the project all of this
will allow for more overall flexibility in how the solution is built so given
those guiding principles let's see how the overall time box timeline occurs now
there are four main phases initiation iteration development solution release
and post-production an initiation will begin preparing for the project to start
and this will include doing a workshop with the whole team where we begin
identifying the project vision goals and personas the business context as well as
the business processes and we'll gather all of this and place
it into a vision document which is kept alive during the project and is key to
guiding the project throughout the lifecycle this document is key because
it provides the high-level plan and the goals that should be followed now during
the initiation phase will be the first time that the team gets to meet
including the project team the stakeholders the business users and
everyone else now we need to use that time effectively so that the team gets
to know each other and we need to understand the business users and their
needs and motivations because their journey is what we're attempting to
build the solution for we also need to make sure that the delivery team itself
understands the delivery practice that's going to be used and how everyone will
be working together in the iteration development phase we'll be delivering
different iterations based on what is needed inside of the user stories
they'll also be a shaping phase though that will be focused on the next
iteration by prioritizing the backlog and analyzing and choosing the user
stories that will be implemented in the next iteration there's also some work
being done from the previous iteration which includes business tests and the
validation of delivered user stories of all of the work that was done in the
previous iteration and that takes us to the solution release phase this phased
has user acceptance testing and make sure that the user stories can be
accepted it will close out all of the preparation for the rollout and at the
end of the phase we'll actually go live and the final phase which is
post-production and we'll want to reserve some time in post-production for
monitoring the live app doing some performance tuning and making
improvements this may include quick wins from
different parts of user feedback or addressing minor change requests that
the business has given us
so here's the same framework again except this case we're zooming in on a
single iteration this single iteration will last between two and three weeks
and here we can already see a glimpse of the three different tracks that we
mentioned that take place in it development and testing of the scope for
the current iteration analysis which is the business analysis and creation of
the backlog from the set of user stories which are ready and agreeing on the
planning and scope for the next iteration and finally there's
stabilization where even before the final iteration demo to the business is
done there are some tests and the validation and tests are being done by
the business analyst and the tester of course when we look at that main area
there are some other key agile mechanisms that are there we can see
that there are daily stand-up or scrums so that we can get daily progress status
on the project and make sure the team is still aligned and at the end there's an
iteration retrospective so the team can be aligned and more focused on the team
itself and the delivery process that they're using finally we have what we
call a reference allocation so let's take a look at the roles involved in the
process most roles are involved in the initiation workshop that will produce
the product vision project vision this is also so that the project starts out
with all the information it needs and the business and development teams are
aligned this timeframe may be reduced if a business vision workshop was done
because it provides a lot of information that can be leveraged for the project in
the iteration development phase many of the roles are only needed part-time the
core development team seen in yellow and blue below will be almost completely
dedicated to the project the product owner may or may not be
completely dedicated to the project depending on it whether or not it's a
first release or a late release but the tech lead and the
developers are almost always 100% committed the blue and yellow colors
indicate suggestions of when teamwork should be done together on-site or could
be done remotely the third phase during solution release the core team
allocation levels should be maintained and the business involvement will
increase because of the acceptance testing and to make sure that everything
is ready to go live and in post-production it's really the tech
lead that is doing a majority of the work and that's because they'll be
looking at the monitoring and performance tuning with the product
owner and the devs on a part-time basis the experts are only allocated at
certain times in the project when their specific skills are needed so that's a
quick summary of the overall project delivery the roles that are involved and
their allocation at different times so that's it for the project time box
overview session thanks for watching and have a great day