Tip:
Highlight text to annotate it
X
In this video, we'll take a deep dive into how the team works together on a day to day
basis. We'll introduce how doing things the "agile way" helps to achieve the goal of releasing
the first version of your product in 8 weeks.
Let's first do a quick recap of the two project phases we described in the "Idea to Reality"
video. It is during the Exploratory Phase that we determine the scope of the project
and decide on which features should go into the first release of the product.
The product comes to life during the construction phase. The programmers work with the rest
of the team - and work through the feature list as detailed in the release plan.
Of course, if only life were that easy! The real magic lies in how the team adapts to
uncertainty and inevitable change during these two phases.
Let's start with the Exploratory Phase. There are two parts in this phase - Elaboration
and Estimation.
The goal during Elaboration is to understand both the Product and the surrounding Business
Model very well.
Key components of the Business Model include figuring out the targeted customer segment,
who's the competition if any and the planned revenue streams for the product - among other
things.
A good amount of time is also invested in breaking down the Product idea into MMF's
or Minimum Marketable Features and their corresponding stories. An MMF is very simply the smallest
unit of functionality which is marketable to the end user. MMF's typically take about
a week to build - so we break them down further into stories. Each story usually takes about
1-2 days to build. This allows us to demonstrate progress and get feedback more frequently.
Wireframes are also created during this time - to help visualize and detail how the end
user will interact with the product.
Toward the end of this stage, the architect usually has enough to work on - and start
recommending the main technological choices for the product.
All of these tasks require close collaboration between the Customer, the BA, the Product
Manager and the Architect.
The second part of the Exploratory Phase is where we get to the estimation and planning
bit. The goal of this phase is to come up with what's called a Release Plan - which
will specify which features will be included for Release 1 and the target Release date.
The process to create the Release Plan is straightforward. It starts with estimating
each of the stories and Features that have already been identified.
One the estimates are ready, each feature is prioritized keeping in mind two things
1. The value it adds to the product relative to other features, and
2. Its estimate
Once the prioritization of all features is completed, the features are "bucketed" into
one or more releases. This is done using a timeboxing technique.
Since we only have 6 weeks of construction to get to release 1 and we already have
a prioritized list of features at this point - we simply absorb as many of the higher priority
features that will fit in the 6 weeks timeframe.
The date of the release is calculated by simply adding 8 weeks to the date on which the exploratory
phase started.
And here's the team that is involved in this whole exercise. That is everyone who was already
there earlier. But this time we also have the programmers. It is only appropriate to
have the programmers estimate the stories, because it is they who will finally be converting
the requirements into code.
At the end of the exploratory phase, you, the customer can take a few days to review
everything again, if you prefer.
Assuming you find everything okay, we'd start the construction phase shortly behind the
exploratory phase. The goal of the construction phase is simple - that is to get the Release
1 of a working product out the door in 6 weeks.
Before diving into the details, let's a take a look at the team for this phase.
All roles that were introduced during the Exploratory Phase continue into Construction
Phase as well. In addition, we also introduce the only missing role at this point - and
that is the Project Manager.
And that pretty much makes up the Whole Team.
There's a bunch of things to setup before the team can start churning out working software.
This setup takes about 3-5 days depending on the complexity of the project.
Broadly, the setup activities are really of 3 types:
- Infrastructure setup for the Programmers (referred to as Development in this slide),
- the Project Management Infrastructure, and - Requirements and UI Design related work.
This third item is not really setup work, but we'll come back to this shortly.
All of these can happen in parallel, because each of them is handled by different roles
- as you can see here.
The Programmers take care of most of what they'd need to, on their own. Sometimes they
also rely on the Architect to help them out.
The Project Manager works alone at this stage - working through a list of pre-defined checklists,
as we'll see shortly.
As expected the BA and the Designer are responsible for the Requirements and UI Design bit.
Let's take a look at some of the tasks that the programmers work on, during Kickoff. Dev
machine configuration refers to installing any additional software that may be required
to for this project. Continuous Deployment setup refers to creating what is called a
Build Pipeline for moving working software from development to staging and then to production.
Please make sure to watch the Continuous Delivery video to learn more about this.
Moving on. Technical kickstart checklists include things like configuring tools and
services that we'd need for development. These include exception notifier systems, code analyser
tools, setting up and configuring the automated test infrastructure etc.
Finally, Architectural Spikes are required to test any risk technological assumptions
that might have been made by the Architect in their recommendations. These could either
be technological components that are new in the world in general - or they could be items
that the team does not have significant experience on, already.
Either way, Spikes, as they're called - allow the team to test these assumptions - by conducting
small experiments. If any surprises are discovered, the Architect modifies their recommendations
to mitigate the risk.
Let's move on to the Project Management kickoff items. There's a host of online project management
tools out there. We've done the research to find the ones which allow us to track project
progress and help us collaborate better, while also staying out of way when we don't need
them. Make sure to watch the Collaboration Tools video to learn more about the tools
that we prefer.
While the programmers focus on their technical checklists, the project manager has her own
set of things to take care of. These include, for example, walking a new customer through
the project management tools and processes that we use and creating what we call a done-done
checklist. This checklist is a customized laundry list of checks to run on every story
that we ship.
While the Programmers and the Project Manager are busy getting ready to kickoff the project,
the BA and the Designer work with the customer on detailing the requirements, setting the
UI theme for the product - and finally creating the UI designs for the first couple of stories.
This allows them to gain some lead time ahead of the programmers - which they maintain throughout
the project in the weeks afterward. This is explained in more detail in the next few slides.
Let's now dive into the heart of how the team actually works together to ship working software
on a frequent basis. Let's say you came to us asking us to build a Swing for you. Or
a software simulation of a Swing if you will.
If we were to follow what's called a waterfall model, we'd do it this way. Each member on
the team would do their bit - and then handoff their work, once they were done with all of
it, to the next person in the sequence. And once the last person in this sequence is done
with their work, there's one release at the end.
While this process makes logical sense, following that route usually end up in a scenario such
as this.
While this image is quite funny, the unfortunate truth is that more than 80% of software projects
tend to end up in similar situations.
Writing specifications with high accuracy - for the whole product - in the beginning
of the project - is quite ineffective. If that specification is used as the sole input
from the customer - what ends up happening is not very different from what you saw in
this image.
There are two main problems with the waterfall approach:
1. The original product idea tends to get lost in translation - because the direction
of information flow is restricted to flowing only downstream - for the most part. This
lack of interaction and feedback between the various roles on the team results in the wrong
product getting built.
and secondly,
2. There's also very little room for adapting to changing scenarios in the marketplace.
Almost any significant change that is requested for, mid-way through the construction process,
results in creating a lot of rework for the team. Thereby increasing cost and disrupting
the schedule of the project.
So how do we solve those problems? The answer is simple - by releasing working software
many times throughout the construction phase.
Working software begs for feedback by its very existence - its much easier to detect
communication gaps, when you can play around with working software. Because what gets built
and shipped, is based on what was perceived by various members on the team, which could
be quite different from what was conveyed to them.
As you can see on the left, the risk of failure by building the wrong product rises as time
passes. With the Agile approach however, this is constantly mitigated over time.
So, that's the theory. But how does it work in practice? Is the solution to avoid any
kind of structure altogether? And just do whatever makes sense at the moment?
Let's look at some specific questions:
How does the team manage to ship software as frequent as every 2 days or less? What
about the time required to test and deploy changes?
There's also the question of how frequently the requirements can be changed in this scenario.
Can we allow for changes everyday?
And then there's the question of how this impacts communication within the team. Achieving
the above two things will obviously require a high level of communication between various
roles on the team - and that could result in a bad signal to noise ratio as well.
You're probably at least a little curious at this point. We'll answer all of those questions
in the next couple of minutes - by taking a much closer look at how we manage everything
on a daily basis.
To start with, the BA is in constant touch with the customer throughout the construction
phase. While the UX designer's interaction is also pretty high with the customer, it
starts tapering off about mid-way through this phase. The expectation is that by around
that time, the designs are ready for most screens required for Release 1.
Together this team creates Wireframes and UI designs for those features and stories
that were finalized during the exploratory phase, for Release 1. And this is done at
a fairly rapid pace - to allow for discovering things that might have previously been overlooked.
As and when new things get discovered, this team created new stories and maybe even new
features as required. Then the team works together with the programmers to estimate
the new items and then together determines the priority of the newly added items. If
they're considered higher priority than the ones on the existing backlog, then the new
items is swapped in to replace another item of similar size but of lower priority.
But that leaves out one item - the user acceptance criteria. These are very low details specified
for each story by the BA. These include alternate scenarios, test cases, validations and business
rules for the corresponding story. Documenting the UAC's is time-consuming work - and is
best done only for those stories which are at the top of the backlog and likely to be
picked up by the programmers within the next week.
This reduces the possibility of wasted effort on the part of the BA. And also allows for
flexibility in terms of making changes to those features and stories further down the
backlog.
As you can probably imagine by now, all of the deliverables from the BA and the designer
flow to the programmer pair on a continuous basis. Usually these requirements are "hot
from the oven" so to speak - and hence are not stale. That in turn reduces the need for
programmers to rework these stories as well, later in the project.
Finally, its also possible that once the programmers start coding a story, that they will uncover
certain things that were overlooked by the BA and the Designer. We leave enough slack
within the plan to absorb these kinds of surprises as well. Of course, keeping the line of communication
multi-directional helps a lot as well.
Every story is intentionally kept small enough to allow programmers to finish coding them
in 2 days or less. Further, the programmer pair works on only one story at a time at
most times, except in exceptional cases such as when we have a bug reported in the system.
All of this allows the programmer to ship stories at least once every two days. As already
mentioned, they also write automated tests for all of the business logic in the code.
And they run these times multiple times a day - to ensure that whatever was already
working, is still working - as they're adding new code or, changing or deleting existing
code.
Once a story has been coded, the code is pushed through our completely automated continuous
deployment pipeline - to finally end up in the staging environment. At this stage, the
story is ready for the customer to try out - either on the web or on their mobile device,
as they case may be. You will notice that we don't have a separate
testing step after the programmers are done. This is quite intentional - and a reflection
of the confidence on the part of the team - about the quality of their work.
As mentioned earlier, the automated tests typically only cover about 80% of the scenarios.
There rest is handled by the exploratory tester - in the staging environment. What that means
is that we have both the customer and the tester looking at the newly shipped story,
at the same time. The two of them look at the story from different perspective, so this
helps the team get much needed feedback from both sources, simultaneously.
We'll now introduce some terminology to make it easier to refer to all of these activities.
What the BA and the UI designer does - to keep ahead of the programmers by a week but
no more, is called Progressive Elaboration.
The programmers leverage automation at the testing and deployment stages to implement
the concept of Continuous Deployment.
And finally, the tester does what is called Exploratory Testing - which is different from
Checking - in that Testing is a not-urgent but important creative activity to uncover
new scenarios while touring a working product. "Checking" on the other hand is mundane exercise
to ensure that what was working is still working - which of course is already taken care of
by the automated test code written by the programmers.
This is a good time for us to zoom out and take a look at the major concepts that we've
now implemented with the practices that were described in this video.
You will remember seeing this picture from the Big Picture video - the first one in this
series.
The exploratory phase, continuous deployment and test driven development are all practices
that help in Deliberate Discovery.
The cohesive team structure along with multi-channel communication, high levels of automation in
testing and deployment, the involvement of the product manager, and progressive elaboration
- are practices that help to implement Interdependence, Lean Thinking, Systems Thinking and Theory
of Constraints respectively.
Thanks for watching. At this point you should have a good idea of how we do things at Multunus.
Watch the rest of this series to learn about the tools that we use and to understand more
about concepts such as technical debt and continuous deployment.