A rapid overview about Agile and SCRUM for better development experience in teams.

1. WORKING WITH AGILE
TECHNOLOGIES AND SCRUM
SCRUM + Visual Studio, Kanban, Team Foundation
Server, Source Control, Git
Andrea
Tino
#allrightsreserved #2015 #creativecommons #cc4.0 #attribution #noncommercial #sharealike #international

2. Who is this
presentation for?
Everyone with a
minimal background
on programming
What topics does it
cover?
See previous slide :)
Oh yeah... But how
detailed?
I will follow an
horizontal approach
without many details

3. WHAT’S SCRUM?
Introducing the most popular software development
model in industry as a replacement to old Waterfall.
1.1
Murphy’s Law
“Anything that can go
wrong, will do!”
Requirements
Design
Implement
Verification
Maintenance
Once upon a time... Waterfall
Software Industry has radically changed from a heavvy,
hierarchical, vertical, document-based, long-term centered
model to a lightweight, flattened, horizontal,
zero-document, short-term centered process.
Why? Basically the reason is simple: Waterfall took time,
was very resource demanding and lacked flexibility.
Waterfall (Royce) is, briefly,
unable to respond to
unexpected problems that may
arise at every possible stage.
Once a stage is secured and
closed, it is not possible to go
back.
In real life, Waterfall was almost
99.9% violated.
Agile The stiffness of such
models was a proper fuel for the
community to start putting effort
in finding an alternative. We call
this Agile Development and it is
much more flexible + makes a
better use of resources.
Up: The Waterfall model.
Each stage cannot be
executed until the previous
one has been completed.
Specification forbids going
back to a previous phase
but some modified versions
allow this (only one step
though).

4. SCRUM = AGILE DEVELOPMENT
The most foundamental concepts revolving around
SCRUM methodologies.
1.2
SCRUM is...
A methodology to SW
development with different
variants and flavors
SCRUM is NOT...
A collection of rules or
protocols to coordinate
developers and teams
Roles Events
Artifacts Tooling
Take it easy
Instead of providing a set of rigid rules, SCRUM defines a collection of
concepts that should be observed and adapted in the best way on the context
in exam.
That’s why there is not one single way of implementing SCRUM in a company.
An organization decides to adopt SCRUM at its own pace and considering its
own needs and possibilities.
Key features Those few concepts are actually the core features of SCRUM.
They are grouped into 3+1 categories:

5. ROLES
Do not focus too much on hierarchy, rather define few
figures and rely on those.
1.3
Product Owner
The representative for the customer. SCRUM
is a methodology that places stakeholders in
the development process. The customer
needs to have its voice heard.
Development Team(s)
The group of developers responsible for
delivering the product. Note that SCRUM
does not provide restrictions here, teams
can be arranged in whatever way.
SCRUM Master
A person among developers responsible for facilitating the SCRUM process and remove all possible
obstacles threatening the agile process. He doesn’t need to be a Lead, nor a Manager.
SCRUM defines 3 core roles (pigs). There is also a set
of ancillary roles (chickens) which are not really
needed in real life scenarios.
Hierarchy free Note how these roles do not touch
an organization’s structure. SCRUM prefers dealing
with horizontal orgs, but it is not a requirement.

6. EVENTS & TIME FRAMES
SCRUM defines a very short horizon: one day. The Team
might need to change approach or focus the next day
so it is useless planning on a long-term basis.
1.4
Sprint
Basic iteration unit of timeboxed focused
effort for developers.
Typically lasts 1,2 or 3 weeks. But no more.
S1 S2 S3 S4 S5 S6 ...
Morning SCRUM
Very important. Occurs before starting the
day. The WHOLE Team gets together in one
room and each developer reports on:
1. What he did the previous day.
2. What he is going to do in current day.
3. Problems, difficulties, help if needed.
Meetings To achieve a common goal one thing is
necessary: communication. SCRUM Teams talk a lot
and have many meetings.
SCRUM is iterative
Given its flexible nature, SCRUM encourages developers to
put their focus od few problems at a time. A unit of
development time is defined and it iterates until software is
finally released.
Typycally who arrives late at morning SCRUM has to
do penance: buy cake or run naked in every office :)The whole year is divided into sprints and developers will reason in
terms of sprints only. It is actually a good way to set time.

7. MEETINGS MEETINGS MEETINGS
Meetings are important in Agile metodologies.
Developers meet regurarly in order to share ideas and
keep product development on track.
1.4.1
Sprint Planning
The Team assembles together at the
beginning of the Sprint and decides what to
focus on during that Sprint. This meeting
defines activities ans strategies.
Sprint Review
Managers (and the product owner in some
cases), review the product iteration at the
end of the Sprint. Developers demo new
features and receive feedback.
In Agile Development, managers and developers interact in
some important events that define key changes in the final
product.
Demo & get feedback
After each Sprint, somebody external from the
Team should review how the work is proceeding.
Sprint Reviews are a powerful tool to keep the
Team focused and have its members show what
features were pushed into the product.
According to the size of the organization, at
these meetings must attend developers,
managers, product owners, designers and
almost all people involved in the product.
Good demos are essential to show new cool
functionalities and get positive feedback.
Sprint Review
Planning and
Sprint Review
Retrospection
meetings are also
important chances
to plan and
analyze feedback
on demos.

8. ARTIFACTS AND WORK ITEMS
In order to get work assigned, managed and done,
SCRUM defines a few concepts which enable work
structuring and distribution across team members.
1.5
Deliverable
A unit of work representing
a (new) feature to
implement in the product
Bug
A problem in the current
released product that
needs to be fixed
Product BL Sprint BL
Backlogs Deliverables are defined by managers and
managers also decide which one of them should be
implemented by the Team. Backlogs are used as
buffers to groom activities and focus on them.
SCRUM is incremental
The other side of SCRUM is the fact that it proceeds on an
incremental flavor. Thus, the development process scans
different iterations of the product until goals are reached.
In order to organize work across team members, SCRUM
considers 2 different types of Work Items.
A deliverable can also be a
feature to push in the product as
part of an extension to an
existing functionality.
A bug is a problem that is generally filed by
customers. Escalation process ensures that the
Team receives bug notifications. The Team must fix
the bug and ship a patch for the current version.
Grooming The operation of selecting which
deliverable the Team should focus on is called
Grooming. Managers might organize Grooming
Meetings at the beginning of every sprint.
Bugs Bugs can be organized using backlogs as well,
however no more than 1 is typically used.

9. ORGANIZING WORK ITEMS
There is laways a lot to do, Agile methodology
offer a way to keep all work items in track.
1.5.2
EPIC
SLICE
Deliverable
MOVE TO CLOUD
MIGRATE CLIENT COMPONENTS
Enable AJAX controls
MIGRATE SERVER COMPONENTS
More lightweight Metadata
Update tests
Migrate REST components
Migrate database
Update tests
Epics and slices
An Epic is a work item which maps a goal to be reached at
the end of the overall release process. Epics are made of
Slices, a Slice is a subunit of work focusing a specific
feature to be implemented.
Slices are broken down into Deliverables to map each single
work unit assignable to a team member.
A realistic example of
epic/slice/deliverable work
breakdown in the context of a
company developing an
application that needs to be
moved into the Cloud.

10. APPROACHING RELEASE TIME
When approaching release time, the Team undergoes
certain stages that ensure the product to be correctly
released with the least number of bugs.
1.6
Tell Mode
Teams are allowed to change the
code, but they must notify
managers or supervisors
Ask Mode
Teams MUST ask managers for
changing the code. Detailed
description is required.
Shiproom The Team has a daily meeting called
Shiproom where the current status of the product is
evaluated. All bugs on new features are considered
and members decide whether it is worth fixing them
basing on a risk/cost analysis.
When all bugs have been handled, Shiproom calls for
a Release Candidate (RC). RC is fully tested and if no
bugs are found that becomes the Release Build.
Otherwise the process starts over until a new RC is
identified.
Endgame
When it is time to release, the development process
changes. Pushing new features is not allowed anymore and
more meetings occur. This process is called: Endgame.
Bug Bar Bugs are normally classified using a Severity
Index (higher index = higher severity). As Shiproom goes
on, bugs allowed for fixing must comply the Bug Bar
which increases as RC are iteratively defined.
Endgame typically starts during the final 2-3 Sprints of the
whole lifecycle.

11. TOOLS FOR AGILE AND SCRUM
Tools and instruments for implementing SCRUM and
Agile process in teams and facilitate the development
model
2

12. SCRUM KANBAN (看板)
SCRUM has a few variants (dialects), one of this is
called Kanban.
2.1
Work Item
Work item
description with
details on bug
and status.
Work Item
Work item
description with
details on bug
and status.
BACKLOG
Work Item
Work item
description with
details on bug
and status.
APPROVED
Work Item
Work item
description with
details on bug
and status.
Work Item
Work item
description with
details on bug
and status.
VERIFIED/CLOSED
Work Item
Work item
description with
details on bug
and status.
IN PROGRESS
Work Item
Work item
description with
details on bug
and status.
RESOLVED
Work Item
Work item
description with
details on bug
and status.
Good at morning SCRUM Usually Kanban is used at
morning SCRUM. The board will show work items’
statuses and the team can understand how good is
general progress.
Tracking team’s work
Kanban is an approach for visually tracking what team is
focusing on and what work item each member is currently
working on. It also allows managers to keep tracking on
each work item’s status.
How a Kanban board
typically looks in a
bug configuration.
Each work item has a
team member
assigned to it and a
status represented by
the lane it is placed in.

13. KANBAN IS NOT JUST FOR BUGS
Kanban board can be personalized in order to keep
track of whatever work item type, even deliverables.
2.1.2
Work Item
Work item
description with
details on bug
and status.
BACKLOG
Work Item
Work item
description with
details on bug
and status.
Work Item
Work item
description with
details on bug
and status.
COMPLETED
Work Item
Work item
description with
details on bug
and status.
IN PROGRESS
Work Item
Work item
description with
details on bug
and status.
BLOCKED
Work Item
Work item
description with
details on bug
and status.
Tracking deliverables
Kanban can be used for deliverables as well. The Kanban board configuration changes as deliverables can be
in different states than bugs. Most common tools out there offer customization features.
For deliverables, Kanban boards
can be typically configured as
shown here. A very important state
is “blocked”, where a work item is
waiting for another one to be
completed first in order to proceed.

14. KANBAN TOOLS
There are many OSS offering Kanban, some more
integrated solutions offer a whole environment. Visual
Studio has Kanban as well in TFS.
2.1.3
Microsoft ALM
https://msdn.microsoft.com/en-us/library/f
da2bad5.aspx
Visual Studio Kanban
https://msdn.microsoft.com/en-us/library/jj
838789.aspx
JIRA
https://jira.atlassian.com
Kanbanize
https://kanbanize.com
TRELLO
https://trello.com
Visual Studio and TFS
Microsoft and Team Foundation Server offer Kanban as part of Application Lifecycle Management (ALM).
Other solutions for Kanban
Other applications offer Kanban as part of their release management environments, check them out.

15. CODE REVIEW
Basically it is Agile’s own “One for All, All for One”.
2.2
Review policy
If a reviewer asks for a change, the author
must provide at least a comment.
Programmers are human
Thus they make mistakes. How is it possible to prevent bugs
and code defects? Pair programming bas identified as a
possible solution but it uses two team members for one
work item: it is a waste of resources. Code Reviewing is
today’s most common solution for preventing mistakes and
producing better code.
How does it work? When a programmer completes his
development activity for a bug fix or a deliverable, it sends
out a review which contains only his changes to the code.
The developers selectes few other team members which will
look at the code and provide feedback.
Author
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type':
'text/xml'});
res.end('<id>14394955</id>');
}).listen(1337, '127.0.0.1');
Reviewer 1
“We use port 1337! Use another one!”
...
res.end('<id>14394955</id>');
}).listen(1337, '127.0.0.1');
Author
“We don’t use 1337 anymore! Will keep it :)”
...
res.end('<id>14394955</id>');
}).listen(1337, '127.0.0.1');

16. TOOLS FOR CODE REVIEW
There are several applications on the Internet for
handling code reviews. Some projects are also OS and
available in Git.
2.2.2
WinMerge
http://winmerge.org
Microsoft WinDiff
http://support.microsoft.com/
en-us/kb/159214
Wiki:Comparison of diff tools
http://en.wikipedia.org/wiki/Comparison_of_file_compa
rison_tools
meld
http://meldm
erge.org/
Notepad++ compare
http://sourceforge.net/projects/npp-
compare/
Focus on differences only
A review typically does not show involved files
only, it is also able to highlights those parts of
the code which underwent changes by the
author, so that reviewers can understand where
to look at.
Diff To have this, diff tools are necessary. A diff
program simply compares two text files and
highlights differences focusing on what was
removed, what added and (only advanced tools)
what moved.
Code reviewing applications use diffing tools, but
those can be used also to compare two generic
files. Windows used to have WinDiff.exe as
default diff tool. Today we can find many
solutions among OSS.

17. CHANGESETS
A team is free to edit the codebase freely. However to
keep track of changes, changesets can be a very
good tool to organize your code modifications.
2.3
CODEBASE
Contains all the code for the application
under development, together with
branches if any.
Change
set
Change
set
Change
set
One pack at a time
Users share the same codebase which is stored and
kept safe on one or (hopefully) multiple servers.
When a developer wants to change something, he
prepares a pack or changeset and submits it to the
codebase.
Keeping things in order Such a system helps
developers track changes. Also, every change is
assigned to the team member who introduced it, so
it is easy to understand who changed what!
commit syncrevert info
The role of tests
For every new feature pished into the codebase and
every component, the Team should ensure to have
unit tests and tests covering those! But when should
these tests be executed? Exactly when a changeset
is being merged in the codebase.

18. MICROSOFT UNIT TEST FRAMEWORK
Microsoft Visual Studio offers an integrated solution for
running tests and getting results.
2.4
ATTRIBUTE BASED
EXTENDABLE
TEST RESULTS
XML SUPPORT
VS Unit Test Fwk
https://msdn.microsoft.com/en-us/li
brary/ms243147%28VS.80%29.aspx
MSTest reference
https://msdn.microsoft.com/en-us/li
brary/ms182489.aspx
Writing tests in .NET
Part of the Visual Studio Development Kit,
the Unit Test Framework lets .NET
developers write unit tests and tests in
every .NET compatible language.
MSTest.exe
/testcontainer: “<path-to-dll>”
/test: “test-name”
/resultsfile: “path-to-trx-dst”
Command line The executable will run all or
specified tests that can be found in the provided dll.

19. AGILE DEVELOPMENT ENVIRONMENTS
Solutions to develop applications with Agile
methodologies and for a better development
experience
3

20. TEAM FOUNDATION SERVER
Microsoft’s technology for developing application in
collaboration contexts. It supports SCRUM and Agile.
3.1
CLOUD READY
KANBAN
SOURCE CNTRL
AGILE SUPPORTSCRUM SUPPORT
TEST MGMT
REPORTING
ISSUE TRACKING
CUSTOMIZATION
All in Visual Studio
Visual Studio has everything needed when
relying on Microsoft for developing
solutions.
Deployment TFS requires deployment
on a server which acts as the central
datastore for all data. The architecture is
pretty flexible and, once the server is
ready, it can host the code, its branches
and also handle work items.
Customization Work items can be
configured with custom fields and rules in
order to better handle automatic
operations and save time.

21. GIT
Today’s most famous code repository, version control
and collaboration tool on the web.
3.2
CLOUD READY SOURCE CNTRL
AGILE SUPPORT
SCRUM SUPPORT REPORTING
ISSUE TRACKING
FREE (PUBLIC)
Git it!
Git is a source control system which
started becoming very popular in the last
5 years. Its hosting service, GitHub, today
includes the greatest majority of OSS.
Althought one of the first VC was Google
Code, Google is now cutting in favor of
GitHub.
Git offers many services for free, however
private repositories require a “premium
account” which is not free.

22. THANK YOU
Twitter: @_atino
E-Mail: andry.tino@hotmail.com
The end
This work is distributed under the Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International license.