1. Nuances of Building a Product Organization
within a Services Company
Process, Mindset, System Transformation for tomorrow's world
PRAMILA THOMAS
DELIVERY DIRECTOR
HITACHI CONSULTING COMPANY
2. What are we
going to learn?
(and why it’s important
to learn now).
IT IS NOT EASY, MANY CAVEATS AND
NO UNIVERSAL SOLUTIONS:
1. PROJECT TYPES: FIXED BID
ENGAGEMENTS ON SCRUM
2. DISTRIBUTED TEAM: THEIR
WORKING AND COLLABORATION
3. QUANTITATIVE MANAGEMENT:
PERSISTENT CONFUSION AS TO
WHAT TO COMMIT IN TERMS OF
MEASUREMENT
4. PERFORMANCE APPRAISAL : ONE
SIZE FITS ALL APPRAISAL
5. TOOLS: IS EXCEL NOT ENOUGH?
6. OUR CALL TO ACTION
3. Sailing in the same boat….
Water Scrum Fall ?
Hockey Stick Delivery
Is Agile Cool
A Selling Strategy ?
A few enthusiasts and many waterfall believers
!!
Agile is for lazy people !!
Agile and Devops are bad words
What does being agile mean to teams?
Practices that work & those that don’t &
what to do about them
Shun the fear: Packaging things
differently
Advantages of making mistakes
Tearing masks people wear to work
4. Takeaways
Process, Mindset, System Transformation
Adorning the right mindset
Differentiate between Agile and Agility
Facing the Future
Moving from Services to Value Engineering
Inspire the next ! Make things better !
6. Water – Scrum - Fall
Requirements
Understanding
Sign-
off
Design
& Planning
Analysis
Dev
Testing
Demo
0..n
S.I.T Release
• No Shared vision
• Componentized teams
• Deadline driven than Quality
• Hockey Stick delivery
• Long Testing Cycles
• Challenging Deployments
• Agile/Scrum a selling strategy
8. Managing Fixed Bid Engagements
Structure requirements into multiple phases & tie payment milestones to the phase
High order business value & impact mapping must drive requirements; eliminate low
value items to last phase
Design workshops/Paper modeling/prototypes to understand requirements with
business users
Be connected & engaged with client, don’t rejoice over CRs
Customers are changing – deliver business value within budget
Don’t be limited by your client counterparts business knowledge, reach beyond or invest
in a domain expert
Stand on Quality; demand premium – institute mature technical quality practices
• Domain
• Architecture
9. Holistic Approach is the key
Before After
Two Big Phases in Scope Phases broken down to work-packages
No difference between high value & low value items – within scope
or not only mattered
Prioritized high order value items
Componentized Teams Feature based teams
UI driven development Business Feature/User Story driven
Integration testing post development Integration testing within sprint
Demos to Client just before SIT Sprint Demos
Huge list of bugs in SIT 22% Reduced defects in UAT < 7%
Missing SMEs SME lead Client collaboration
Weak Technical Quality practices CI/CD
11. Challenges in distributed teams
Less Scrumming
Lack of belief in Scrum
Attrition
“Working hard, but not smart”
Inefficiencies hidden
Many lessons learnt, little improvement
Going through the motion
15. Assess ground reality
Less trust on team
“There is some confidence gap between Client and team
which is leading to some unease in accepting new things”
• Delivery of code is more complicated than development of code
• No Breaks between releases
• Not acting what is discussed in the Sprint Retrospection
• Not many ready user story, consumption of time in Sprint Planning
day
• Sensitivity towards setting up the local working environment.
• Calling everything as a priority
• Very less recognitions to testers.
• Delivery friction between scrum teams due to dependency
• Delivering all sprint stories to QA just 2 days before end of the sprint.
• Changing stances by architects during deployment review
• Waiting time to get clarifications of the requirements
• Environment maintenance
• Deployment process
• Developer should be given a comfortable time to work on a piece of
work rather pushing him to meet the dead lines, so that he will be
able to deliver a quality code. Note: ….responsible people will try
new/Innovative things at work which would add value to the project.
• No Agenda, deviations in every meeting I attend.
• Weekend work “
Continued
21. Continuous Assessments, Training & Certification
Sharpening the Saw
Skill Assessment (Domain/Tech)
Technical Audit
Role change
Team rotation
Pair Quality Development
Experiments on Innovative Features
- Code Kata
Retention & Career Development
24. Why Measure?
Enables Early warning system => early course corrections
Trend and predictive analysis => well informed decision making
Treats cause than the symptom => stops recurrence of issues
Advisory to right investments => increase in stakeholder satisfaction (internal and
external)
Demonstrate Continuous improvement => Faster time to market
Manage by Quantitative Objectives
Know thyself before thy customer tell thee who you are
25. What to Measure?
Not all metrics are useful
Plethora of metrics are available but an assessment of the PDLC may be
required to recommend a right set of metrics
Metrics must align to business targets
26. When to Measure?
Intensity of the business problems may
require measurements as early and often as
possible
Periodicity- time bound basis (daily, weekly or
iteration wise)
Milestone/Phase - on completion of a specific
milestone
Review on a quarterly basis and retire metrics not
yielding business value
30. Performance Appraisal
KPIs at both Team and Individual level
Team – Moving team from Performing to
High-performing teams
Achieving Sprint Commitment
Be wary of team fighting for Story points with
PO, negotiating hard on sprint scope
Achieving Quality Targets (usually tied to
definition of done)
Define Quality in objective numbers and not
quality
Depend on tools
Retrospection improvements
Individual - Frequent feedback
Innovation (this could also be at the team level
in case of SAFE)
Improvements in assessments (discussed
earlier)
Agility Behaviours & values
38. New Methodology – Make others better !
We believe that
[building this feature]
[for these people]
will achieve
[this outcome]
We will know we are
Successful when we see
[this signal from the
business users]
39. Mindset - Collaboration
“Best architectures,
requirements,
designs emerge
from self-
organizing teams” –
Manifesto for Agile
Software
Development
