Bridging Between CAD & GIS: 6 Ways to Automate Your Data Integration
Handouts
1. Challenging your comfort zone
AgileSparks
W W W . A G I L E S P A R K S . C O M
info@agilesparks.com
2. We are very happy to have you with us at AgileIsrael
2013, our sixth Agile conference. AgileIsrael is the
major Agile event of the year in Israel, and we are
happy to host it.
This year we are focusing on "hands-on”, which
means that every session is practical and immediately
usable after the conference.
We filled the conference with many interesting
sessions and case studies, and have brought 5
international speakers to give you a unique
experience.
In the spirit of hands-on, some of our speakers have
joined us in producing this booklet which includes
handouts containing tips on various topics of Agile
from meeting facilitation to discovering pains.
We hope this booklet is useful to you and helps you
leverage the ideas you got today in the near future.
Please feel free to share it with your fellow workers.
We will be happy to hear your feedback and assist
your Agile journey, please write us at:
info@agilesparks.com.
Thank you for being part of this conference and see
you all at AgileIsrael2014!
Inbar Oren, conference Chair
AgileSparks
3.
4. Feature Teams – 10 guidelines and tips to make it happen right
For those who have already been convinced about the need for their organization to migrate to
feature teams. Here are some practical considerations and tips to help make the transition
effective and successful.
1. Define the domain – Define the orientation of the team: specific line of business, specific
product, specific strategic goals to achieve, or a squad team that can achieve anything.
2. Maximize autonomy - Align the team structure, processes, tools and environments with
the teams’ goals so as to enable them achieve maximum results autonomously.
3. With empowerment comes ownership – Team should be responsible for end to end
success or failure and have continuous improvement cycles to make the team perform
better.
4. Invest in the technical landscape – Assign tech owners to each component, subsystem
or knowledge domain. 5%-20% of their time will be allocated to the well being of the
component (scale, stability, architecture, coding standards etc), enabling efficient and
scalable development (test and deployment automation, etc) and knowledge transfer.
5. Remember the matrix – Although we push for autonomy of the team, we need a matrix of
collaboration that crosses teams’ boundaries: PMs, Team leaders, Experts, QA etc.
Establish forums and platforms for knowledge sharing AND relevant decision making.
6. Think architecture – Architects should be involved in major development efforts. Make
sure they have free communication channels to PMs. Architects should enable, educate,
review and promote system well being.
7. Delivery automation included – Each team needs to deliver. Delivery automation
should be part of the team skills, supported if needed by external specific team (e.g. QA
automation, deployment automation)
8. System support and stability - Based on the system maturity and size choose one of the
two models for handling system support cases: All support cases to be handled in one
specific team, or through rotation between teams. The more mature and larger the system
– rotate it.
9. Dev-Ops collaboration culture – Feature teams boost the power of each team to make
decisions. These might affect system stability. Be aware of this. Establish open
communication and improvements cycles between dev and ops. Educate for collaboration.
10. Transition to feature teams - Execute as a step function. Make all the right preparations,
execute, and be prepared for a few months stabilization period with lower efficiency.
Mind: Treat transitioning to feature teams on one hand with great determination but keep
reflecting and adapting to your own needs.
6. tips for ATDD implementation–QA Transition to Agile testing
Tips for QA team transition to ATDD:
Promote the new tester role.
o From bug hunter to “Represent the PO within the team”
o QA and developers understand Agile approach for testing (whole team
approach, ATDD, automation pyramid)
Train early the entire team (also development) on ATDD and how to write good BDD
o Understanding the framework (Text<->code) is a must!
It is not so difficult to learn to write code automation
o One week Java training is enough to start
o But, Automation champion to support the QA team and ensure
test infrastructure is a must !
o Need more focus on software engineering and refactoring (for the automation
code)
o Ensure Scrum team support shared ownership concept accepted by the team
Read the Cucumber book ! be part of the community !
Tips for choosing ATDD tool
Expressing expectations in a language and format that allow collaboration among the
whole team (PO/Dev/QA)
Required minimum of test code (allow re-use, auto-completion)
Test code written in the team “native” language (so developers can also develop and
support the QA)
Play nicely with source control systems and continuous integration
Pluggable to support a variety of interfaces (e.g. UI automation)
Can become a product spec. (documentation tool)
Active community
Tips for BDD development process
Describe ALL expected business behavior with BDD , decide later what will be tested in
which level (UI, Manual, AT)
Write Acceptance test (feature file) for MMF, Write user stories DoD as scenarios within
the MMF feature file
Ensure BDD is readable, written in business language (not implementation) , as possible
use tables for the data description
Integrate ATDD into the release process
o PO writes User Story description in the backlog management tool (it is rare to
find PO that willing to describe it in BDD format )
o QA translate it to BDD (after team sniffing, before iteration planning)
o PO review the BDD with QA (and if possible with development representative
from the team)
o BDD is a condition for “Ready Story”, might be a step in the release Kanban flow
Team commit to the BDD!!! Not to the user story description.
When team start working on the story:
o Developer and QA review together the BDD and agree: What to test, by whom
and how to automate it (unit/acceptance)
o Developer develop first the “API contract” (so automation can run and fail),
QA develops the automation (code review with developer)
7. 5 Tips on how to implement electronic project
management tool
Begin with physical task board
Encourage: team work, commitment and trust through transparency,
visualization and activeness
Make the board the team’s tool in the daily routine – use it to facilitate
discussions and meetings such as dailies, planning and retrospectives
Only when the team shows active use….
Start using the electronic tool in the team
Use big screens for visualizing the task board
Facilitate the daily meetings
Team member ownership on items on the board – they createupdate the
items
Continue using sticky notes to facilitate discussionsdecision making
In order to be fully present in the meeting and focus on having an effective
meeting input the results of the meeting after the meeting to the tool (not
the manager)
Visualize project progress
Use Agile reports to visualize project progress, preferably Burn-up chart
and cumulative flow diagram
Management feels thing are under control and allows the team to work
Connects the team to the big picture and creates common language with
management
Visualize Improvement
Choose 2 key KPI’s and use them on the board
Fuel motivation by visualizing and acknowledging improvement in the
selected KPI’s
UpdateChange the KPI’s according to needs periodically
12. W W W . A G I L E S P A R K S . C O M
info@agilesparks.com
The 10 commandments for the facilitator
1. Do you have strong opinions on the meeting subject / agenda / conflict / interest?
Maybe you should ask someone else to help you by participating in the meeting to
representing this opinion so that you can remain neutral…
2. Prepare… who is attending? Who really needs to be? Who shouldn’t be?
3. Is the team willing to accept a new way of work? Are they prepared to take it from you?
Today?
4. Are the meeting participants, boundaries, constraints clear? Make sure time limits,
space, time-of-day, etc…
5. Oh – are all the participants coming? Are they ready? Did they prepare last meeting's
action items?
6. Meeting goals and agenda, are they
clear to everybody? Including you?
State them to agree and start the
meeting. Is anybody taking notes?
7. Is there enough time? Do less, but
close issues…
8. Is everybody with you during the
discussion? Are you helping people
understand each other? Are all the
voices heard? Is anyone too
dominant?
9. Accumulate action items. State them clearly when they show up, and make sure they
are visible. Action item – what, who, by when…
10.Decisions? Is the team committing, or is just the manager making decisions? Who will
really carry out the action items?
For consulting about the transition to efficient meetings, visit
www.agilesparks.com
