A view into how most IT organisations structure their teams to deal with business demands and possible inefficiencies that emerge as a result. An alternate to the traditional project team composition is a way to deliver end to end features to the business, using what is known as feature teams.
2. How can IT organize to deliver
higher value to the business?
2
3. AGENDA
! What does business expect from IT?
! How is IT set up to deliver?
! Introducing feature teams
! Q & A
3
4. 4
All businesses are driven by Return on Investment
RoI can be in monetary form or intangible like a brand
or social recognition
5. 5
The role of business is to maximize
Customer Experience
and Revenue
or to Reduce Costs
Software project aims to achieve at least one of
these
6. 6
Once a business idea emerges, time to market is
critical
Can value be delivered to the business
incrementally?
7. What does business expect from IT?
! Visibility into progress
! Flexibility to change requirements
! Ability to change priorities of requirements
! Expectation that domain knowledge will be retained in
the organization for future development
7
8. So how does IT set themselves up to deliver?
Typical team organization is around competent teams
formed around architecture modules of the system.
8
User
Management
Security
Account
Maintenance
Transaction
Processing
9. Quite often organized by layer of application
9
UI
team
Business
Logic team
Services
team
Database
team
Number of
applications in
the system under
development
UI
team
Business
Logic team
Services
team
Database
team
UI
team
Business
Logic team
Services
team
Database
team
UI
team
Business
Logic team
Services
team
Database
team
11. HANDOFF AND DELAY
Team A Team B Team C
Consider a requirement from the customer that needs
to be developed by 3 component teams
Handoff Handoff
Waste due
to rework
and
handling
partially
finished
work
Waste due
to delays
12. DUPLICATION
Team A Team B Team C
Writes method to
calculate interest so it
can show this in the
UI
class SimpleInterestCalculator
def initialize(principal,
interestRate, numberOfYears)
@principal = principal
@interestRate = interestRate
@numberOfYears =
numberOfYears
end
def compute
(@principal * @interestRate *
@numberOfYears) /100
end
end
Writes method to
calculate interest
so it create a
reusable service
Class InterestCalculator
def
self.compute(loan_amount,
rate_of_interest,
term_in_years)
(loan_amount *
rate_of_interest *
term_in_years) /100
end
end
Writes method to
calculate interest so
totals can be updated in
database
class SimpleInterestCalculator3
def initialize(options = {})
@loan_amount =
options[:loan_amount] ||
@rate_of_interest =
options[:rate_of_interest] ||
@term_in_years =
options[:term_in_years] ||
end
def compute
@loan_amount * @term_in_years *
rate_of_interest_in_fraction
end
private
def rate_of_interest_in_fraction
@rate_of_interest / 100
end
end
13. BAD CODE AND DESIGN
Work with the same code month after month
Acceptance of bad design
No outside eyes look at the codebase
Do not seek to refactor
16. SEQUENTIAL DEVELOPMENT
UI team
Business
logic team
Services
team
Database
team
UI team
Business
logic team
Services
team
Database
team
UI team
Business
logic team
Services
team
Database
team
!!!
Requirements analysis
!!!
Planning
!!!!!
Testing
17. DO THE EASY WORK
Team A
Team B
Team C
A A A A
B B B B
C C C C
This comprises a
customer
requirement
19. ANOTHER RESPONSE FROM IT : FEATURE PROJECTS
Spin up a project to deliver a particular
feature of the larger system
Unfortunately this has its drawbacks too
Feature touches 3 different components
Component A Component B Component C
! ! !! ! !
20. NEW TEAM : LOWER PRODUCTIVITY
Component A Component B Component C
! ! !! ! !
21. RESOURCE ALLOCATION TEAM USES KEY
PEOPLE AS BAND-AIDS
Component A Component B Component C
! ! !! ! !
!
Component C
29. TEAM MEMBERS WORK ON
ANALYSIS, CODING AND TESTING
Requirements analysis TestingCoding
! ! ! !!! ! ! !
30. HOW DOES A FEATURE GET DELIVERED
UI task
Business
logic task
Services
task
Database
task
A A A A
B B B B
C C C C
This comprises a
customer
requirement
A B B B C S S S S S S S
Analysis & Planning Analysis & Planning
S
33. NO HAND OFFS
UI task
Business
logic task
Services task
Database
task
S
34. VALUABLE WORK CAN BE PRIORITIZED
8 7 6 5 4 3 2
Analysis & Planning
UI task
Business
logic task
Services
task
Database
task
1
Business Idea
UI task
Business
logic task
Services
task
Database
task
18 7 6 5 4 3 2
Analysis & Planning
This gets
channeled into two
features and two
feature teams
35. VALUABLE WORK CAN BE PRIORITIZED
8 7 6 5 4 3 2
Analysis & Planning
8 7 6 5 4 3 2
Analysis & Planning
UI task
Business
logic task
Services
task
Database
task
1
UI task
Business
logic task
Services
task
Database
task
1
The business wants a change
and re-prioritizes the backlog
6 5 4 3 B A 2
Analysis & Planning
7 6 5 4 3 2 A
Analysis & Planning
since teams are working on components, there is partially finished work. This naturally leads to waste when this is handed over to the next team. People either over or under develop pieces of functionality since the interface between each team is
either poorly defined or not yet defined since they have not yet got to that stage of the component.
There is waste due to delays as well – a team developing a dependent component
functionality often gets duplicated since the teams are not in close enough communication to realize that the same item
is being developed by another component team. You often find the same logic in several methods in the codebase
people who work with the same code month after month tend to accept its bad design and not bother to refactor. No outside eyes looking at the codebase
trying to get a series of components developed means dependencies across several teams, often meaning that a delay in one cascades across and delays the final deliverable
the hand offs and integration planning means more management needed. The ratio of managers to actual developers or testers in organizations with component teams will be much higher. Extra management means extra cost and unproductive members of the team.
since business features always span component teams, requirement analysis, planning and testing activities for such features typical are done by someone OUTSIDE the component teams. This promotes the analyze-design-code-test sequential cycle leading to handoff waste and delays. Delivering to the business takes several iterations for a single feature instead of potentially doing it in one.
Since a component team will have a pipeline of work that is specific to its area of expertise, it always get fed with requirements that are either easiest or quickest for it to do. No one stops to think if this ties into the overall priority of what the customer wants. This is explained away by most project managers as necessary to ensure that all the component teams are utilized "They may as well work on this rather than sit idle"
by their nature, component teams accumulate people who specialize in that one component. So you get UI developers and Database developers and developers who can write services. Where is the learning?
the team comes together only to deliver to a particular short lived objective, has not jelled, lower productivity
Since people with overall system knowledge are rare, resource managers tend to reuse the same "experts" in each project to solve the critical business issues. You end up with a situation where you have a patient with several wounds but a fewer number of Band-Aids and you keep moving them around.
shortages of skilled people with the right knowledge means that there is partial allocation of people to several projects, which never really works out - leads to wait delays and more knowledge silos.
people hate being thrown into the resource pool and then joining some random new project every so often.
For our discussion it is a vertical slice of functionality - building the UI layer is NOT a feature
Examples of features : adding a new service provider to an ecommerce application, internationalizing an application, giving customers the ability to take loans and service them
Features could be non-functional in nature : for example, making the application scale up to support a certain number of users or having the application to be deployed across a cluster of machines to allow for better performance
Not all generalists - composed of specialists in different areas
Ideally are co-located
Utilize collaborative development tools and practices - source control, continuous integration, test driven development, build pipeline, automated functional tests
Pairing
Learn from the specialists
Rotation
Full cycle responsibility
Control over the team’s work
Satisfaction of seeing what you built work
Eliminate bad code and design