Is Being Agile a Good Thing?

1
Is Being
“Agile” a
Good Thing? Backlog
Product Sprint Sprint
Daily
1-6 weeks
Done
Scrum Cycle

October 2015Copyright © 2015 Hood Software Solutions LLC
2
Alan Hood
Hood Software Solutions
Alan.Hood@comcast.net
Is Being “Agile” a Good Thing?
UNITE 2015
GE4052
October 13, 2015

3
• About Agile development
• Brief history
• High level summary of the most popular schools
• Comparison with traditional methods (Waterfall)
• Case Studies
• Summary and conclusions

4
What do you think of when you hear the word “Agile”?

5
• You use Agile Business Suite, BIS, or ePortal
• You run on a ClearPath Forward Fabric
• You do all of your development with Visual Studio or Eclipse IDEs
• You have a daily meeting with all of your developers to discuss status
and plan the next day’s work
• You use Scrum, XP, RAD, Lean, or some similar methodology
You just might be agile if…
… but none of this is a guarantee
Agility is more about process than technology and tools

6
• Customer satisfaction through early and continuous delivery of valuable software
• Welcome changing requirements, even late in development
• Deliver working software frequently (weeks rather than months)
• Business people and developers work together throughout the project (daily)
• Build projects around motivated individuals, who should be trusted
• Face-to-face conversation is the most efficient form of communication (co-location)
• Working software is the primary measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done—is essential
• Self-organizing teams
• The team regularly reflects on how to become more efficient, and adjusts
accordingly
The Agile Manifesto
Paraphrased from:
http://www.agilemanifesto.org/principles.html

7
• Iterative, incremental, evolutionary
▫ Frequently deliver small, but complete, working samples
▫ Also known as Evolutionary Prototyping
• Efficient, face-to-face communication
▫ Best if team members are all in the same place
• Very short feedback and adaptation cycle
▫ Typical duration is 2-4 weeks per increment or sprint, feedback within the
next sprint
▫ Quality focus
 Always try to improve
Key concepts

8
• Adaptive Software Development
(ASD)
• Agile modeling
• Agile Unified Process (AUP) – a
simplified RUP
• Business analyst designer method
(BADM)
• Crystal Clear Methods
• Disciplined agile delivery
Popular Agile methods
• Dynamic systems development
method (DSDM)
• Extreme Programming (XP)
• Feature-driven development
(FDD)
• Kanban
• Lean software development
• Scrum
• Scrumban

9
Scrum
• Popular Agile development method
• Characterized by small (mostly) co-located, self-
managed teams, and multiple, brief iterations
• Requirements and tasks defined as “stories”
• Sprint Backlog defines the work items for a given
Sprint
• Various “ceremonies” with each Sprint
▫ Sprint Planning
▫ Stakeholder Demonstrations
▫ Retrospective
Backlog
Product Sprint Sprint
Daily
1-6 weeks
Done
Scrum Cycle

10
• Scrum Master – leads the scrum (not a manager)
• Product Owner – speaks for stakeholders in the scrum, makes product
related decisions
• Team members – developers, testers, SMEs as needed
▫ Usually 3-6 members
• Business Owner and Stakeholders
▫ Not part of the core team
▫ Author stories
▫ Receive product after each Sprint
Organization of Scrum Team
Scrum
Master
Product
Owner
Business
Owner
Stakeholders
Typical Scrum Team

11
• Who needs it?
• What do they need?
• Why do they need it?
• How will we know it is done?
What makes a good Story?
• As a …
• I want …
• So that I can …
• I’ll know it’s done when…
“As a mobile phone user, I want secure iPhone access to my ClearPath banking
transactions, so that I can make deposits, transfers, and check account balances.
I’ll know it’s done when I can do all of my online banking from my iPhone.”
“As an iPhone user, I want secure Web access to the account
deposit transactions, so that I can make deposits into my
checking account. I’ll know it’s done when the same
functionality on the DEPST transaction is available on iPhone.”
Oops. That’s too big.
It is called an Epic.
This is more like a
Story that can be
completed in one
Sprint.
Content Format

12
• Waterfall Approach
▫ A Methodology for Development
▫ “Traditional” Application Lifecycle Management
• Iterative approach
▫ Allows frequent, rapid feedback
▫ Ideal when requirements may change
▫ An “agile” approach
Comparisons

13
Waterfall approach
▫ Traditional Application Development
 Different Tools
 Different Skills
 Can not easily back-track without losing information
Requirements
Design
Code
Integrate
Test
Deploy
Maintain

14
Waterfall Approach
Requirements vs. Capabilities Delivered
user requirements as originally specified
Requirements gap

15
Iterative approach
Iterative Prototyping (Evolutionary Development)
Develop, Maintain, Modernize, Re-engineer
Investigate
Design
Develop
Deploy/Demo
Analyze Business Needs
Design Object Model
Build System
Refine and Repeat for each Sprint

16
Iterative approach
Requirements vs. Capabilities Delivered
user requirements as originally specified
Requirements
gap

17
Case Study - Presented at UNITE, 2011

• Modernization goals
• Process
▫ Workshops with end users
▫ Prototyping
▫ Agile development process
• Results and timeline
Outline
18

CE
GateCE
Gate
CE
Gate
Application Integration
19
Application Modernization – Phase 1
Mainframe
channel
ASP .NET
GUI
Web Delivery channel
WOF Online
Cool ICE
VIN Direct
Cool ICE
Web Delivery channel
MotoChek
(ASP .NET)
eGovt Transact
(ASP .NET)
Common Data Interface (CDI)
Driver Check
(ASP .NET)
TORO
(ASP .NET)
Programmatic
Interface
channel
Component Enabler
BP Card
Upload
EAE applicationsRich Client channel
WinDLR
(ASP .NET)
Image Capture
Application
(VB 6)
Image
Management
System
(non-EAE)
Solaris
FTP/Flat File
Application
Programmatic
Interface
Electronic
Data
Interchange
Interface
NOF to
Component
Enabler
gateway
CE
Gate
XML/Web Service
FTP
I/Fs used by these
clients must not
change
Access Control
(ACC)
Motor Vehicle
Register
(Landata)
Driver License
Register
(DLR)
Scope of Changes
Phase 1
Replace older
client
technology
with
Component
Enabler
based clients

20
• Step 1 – Proof of Concept
• Step 2 – Prototyping
• Step 3 – Development and deployment
The Process

21
• We defined several proof points to demonstrate feasibility
▫ Show “green screen” (Landata) functionality in a Web browser
▫ Show PowerClient (WinDLR) functionality in a Web Browser
▫ Design (“paper proof”) of revised user access
▫ Demonstrate image capture and custom printing interfaces
Step 1 – Proof of Concept
(December 2010)

22
Vehicle Change Attributes
VCATS – “Green Screen” starting point

23
VCATS – After simple GUI update

24
• Workshops held in Palmerston North with user representatives to
determine requirements and define interface standards
• Development team produced a prototype with some key business
processes and 15-20 “screens” to show resulting interface
• Duration: approx. 2 weeks
Step 2 – Prototyping
(February 2011)

25
GUI Standards – first pass October 2015Copyright © 2015 Hood Software Solutions LLC

26
• Team adopted elements of agile development during the prototype
phase
▫ Small team
▫ Daily scrum meeting
▫ Rapid prototyping, frequent releases (sprints)
▫ Continuous testing
▫ Continuous user feedback
• Requirements were refined as the project progressed
• Positive response from both the development team and the end users
Agile development process

27
• Made “global” changes to EAE model, according to style guidelines
• Defined process for Ispec changes
▫ Produced reports for listbox data
• Refine style guide
▫ Document exceptions
• End user exposure
▫ Feedback rapidly incorporated
Development process during prototype phase
Prototype Phase Development
Team (some part time):
• 1 Project manager
• 2 Architects
• 2 EAE developers
• 2 .NET developers
• Various from operations,
support, test, as needed

28
• Prototype phase flowed naturally into development
▫ Added development and test personnel
▫ Global changes made during prototyping were kept
• Project test team verified functionality
▫ Minor changes to DLR GUI
 Due to differences between PowerClient/Visual Basic and Web Browsers)
▫ Internet Explorer selected as default browser
 Firefox and others were tested
 Any differences or exceptions noted
• User representatives confirmed usability factors
Step 3 – Develop and Deploy
(Begin March 2011)

29
VCATS – Using Final Style

30
• The project was named ‘ICT Project of the Year’ at New Zealand’s 2012 ITEX
Computerworld Awards. The NZTA CIO stated that “Unisys developed and
implemented an innovative modernisation program that provides more flexibility in
the way we incorporate changes and engage with our customers without needing to
replace our systems. It is definitely an approach that other organisations seeking to
modernise their IT infrastructure should consider.”
Result

31

32
• Develop a new product for ClearPath portfolio
• Involved development on ClearPath and Windows .NET
• Key attributes:
▫ Maintain security
▫ Improve Performance
▫ Improve Ease of Use
Project Description

33
• Team adopted elements of agile development
throughout
▫ Small team
▫ Frequent scrum meetings
▫ Rapid prototyping, frequent releases (sprints)
▫ Continuous testing
▫ Planning and Demonstration with each sprint
• Requirements were refined as the project progressed
• Positive response from both the development team
and the end users
▫ Some early “teething pains” from some developers, but
very successful in the end
Agile development process
The Team (some part time):
• 1 Architect
• 2 ClearPath developers
• 2 .NET developers
• SMEs from Security,
Performance
• Technical writer
• Testers both local and remote

34
• Project completed on time, within budget
• Senior management amazed at how much was done so quickly
• Performance better than expected
• User responses very positive
• From the team: “Good process, right people, at the right time”
Results

35
• You use Agile Business Suite, BIS, or ePortal
▫ These tools do allow rapid development, prototyping, and a high degree of automation
▫ Good candidates for use in an agile project
• You run on a ClearPath Forward Fabric
▫ Can provide greater flexibility for testing and deploying in different environments
• You do all of your development with Visual Studio or Eclipse IDEs
▫ Good tools, but not really a factor in the use cases presented
▫ Use the technology that makes your developers most productive
• You have a daily meeting with all of your developers to discuss status and plan the
next day’s work
▫ The timing and frequency of the meetings is far less important than the content and how you
conduct the meeting
• You use Scrum, XP, RAD, Lean, or some similar methodology
You just might be agile if…
Agility is more about process than technology and tools

36
Question Response
What if you have a large team? Consider splitting it up into to two or more smaller teams
Some have a “Scrum of Scrums” to coordinate their activities
What if the team is spread out
geographically or by shifts?
Scrum/Agile prefers co-located teams, but it can be made to work with
telephone/video conferencing and social media tools*
What if the end-users and stakeholders
don’t agree with agile methods?
It is really better if you have buy-in from all parties
Lacking this, it can still be effective, but will place a greater burden in the
Business Owner and Product Owner to coordinate with Stakeholders’
expectations
What if my programmers only use
COBOL?
The specific language is much less critical than the process and the way
to structure your project
Will it work with offshore development
teams?
*See above – it can work, but will require more work to coordinate team
efforts
Some have adopted “Uberscrums” or Scrum of Scrums approaches
Additional considerations

37
• Agile methods tend to be lighter on up-front design and documentation,
but this is not an excuse for “no plan”
▫ User documentation, test plans, design docs are still produced, they are
just less formal, and are refined over time
• As with any process, radical changes to requirements may result in
changes to schedules or deliverable content
• Agile is a process of continuous improvement
▫ If you try it and it doesn’t work for you the first time, don’t necessarily
blame agile – there may be other factors
Final thoughts

38
Content and format of this presentation is Copyright © 2015 Hood Software Solutions LLC.
Trademarks and third party products referenced are the property of their respective owners.
For more information, or to schedule consulting, training or a POC, please contact Alan at
Alan.Hood@comcast.net
Visit our web site: www.HoodSoftwareSolutions.com

Is Being Agile a Good Thing?

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Is Being Agile a Good Thing?

Similar a Is Being Agile a Good Thing? (20)

Último

Último (20)

Is Being Agile a Good Thing?