The document discusses team maturity and how to measure it. It presents a simplified maturity model with three stages: chaotic, mid-life, and mature. The chaotic stage needs a dictator, the mid-life stage is managed by a teacher, and the mature stage needs a coach. It then provides examples of metrics to measure different aspects of team maturity, including engineering ability, communication, client relationships, team engagement, and leadership.

1. 1
TEAM MATURITY SCALE:
HOW OLD IS YOUR
TEAM?
May 2017
Project Manager
Tetiana Ivanova

2. 2
INTRODUCTION
Many so called ‘Agile’ teams fail so miserably to deliver for the
obvious fact that the teams simply are not mature enough to be a
part of an agile process that requires self managing and high sense
of ownership..
Many organizations are doing agile, and very few
organizations are being agile. In order to improve
agile maturity, the measuring needs to go beyond
agile as "agility." It is a philosophy of managing
complexity and unpredictability through empiricism.
How do you measure a philosophy?​

3. 3
ABOUT AUTHOR
● Project Manager with more
than 10 years experience
● Product Manager experience
● Reaching count of 50 projects
● Certified Scrum Master
● Internal Scrum and Agile
Coach
Tetiana Ivanova
Project Manager
Email: tivanova@waverleysoftware.com
Twitter: @taty_iva
Skype: tatyana_iva

4. 4
WHAT ISSUES YOU CAN
USUALLY FACE
• Sprints fail or barely succeed
• Underestimate of the tasks
• Growing Tech debt and number of
bugs
• Growing complexity of bugs
• Ad-hoc release and deployment
• Heroism and bravery over analysis
and risk management
Burn outs
Low product quality
Lack of predictability
Uncertainty
Decrease of Transparency

5. 5
Capability Maturity Model (CMM)

6. 6
Simplified Maturity Model
The trick most team leaders need to do is to recognize which stage a team is
in, and to advance their team to the next stage.
Chaotic Stage Mid-Life stage Mature Stage

7. 7
CHAOTIC TEAM
NEEDS
A ‘DICTATOR’
Either in technical lack of knowledge, lack of motives, or
lack of ambition.
You can’t take a team that doesn’t even do source
control, and say “you’re self managing from now on,
GO.” - no one will know what to do, or have any
inclination to do it.

8. 8
MID-LIFE TEAM IS MANAGED
BY ‘TEACHER’
At adding some process and thinking
before doing, team reaches some
“safe shore”– the stage where a
team will learn the skills needed to
become self managing, all within a
very concrete series of constraints
that will slowly open up as the team
progresses.

9. 9
THE MATURE STAGE
NEEDS A ‘COACH’

10. 10

11. 11
MEASURE AND SCALE MATURITY
Engineering Ability
Communication
Client Relationship
Team engagement
Leadership

12. 12
ENGINEERING ABILITY

13. 13
CONTINUOUS DEPLOYMENT MATURITY SCALE

14. 14
COMMUNICATION
● Regular on time meeting attendance
● No surprises
● Does engineering let QA know when user stories are ready to test?
● Do team or members request assistance when needed?
● Does each team member knows who plays what role on the team
● Does every team member know when people are/will be out of office
● How often status is on Basecamp/Pivotal or other vehicle on time
● How often pieces of the application developed separately integrate together cleanly on the first try
● How up to date Pivotal is

15. 15
LEADERSHIP
● Did team introduced improvements and/or new processes during last month?
● PM/supervisor promotes participation by the team in key decisions.
● PM/supervisor shares responsibilities with team members.
● Team/PM promotes individual problem solving and intelligent risk taking.
● Are the team proactive in distributing knowledge?
● Each in a team shares ideas/suggestions whether or not PM/Tech Lead agrees with their input.
● Can you give an example of what information have you provided recently to other teams?
● Do you mentor someone?
● Did you have any blog post, technical publication, paper submit within last 3 month?
● Situational leadership is used in 70% of times on the team

16. 16
TEAM ENGAGEMENT
● Team Profile
● Positive/Negative questions
● Does everyone know how many people are on their team and what is the role of everyone?
● Does everyone know and follow the definition of done [tasks, sprint, release, etc]?
● Does everyone know (can check) the scope planned for this sprint/iteration?
● Does everyone know (can check) how is the burndown rate (progress of done vs. planned) looking on the
current sprint/iteration?
● Does everyone know when is the next release deployment (to field/external customers)?
● Is the team willing and able to handle any task on the project no matter if it fits the specialty or not
● (How often do people work on parts of the project outside od their roles?)

17. 17
TEAM PROFILE
TEAM COHESION
● New team
● Existing team
● Partialy worked together previously
TEAM SIZE
● 1-2 developers, rest is part-time
● 3-9 people, QA full time
● > 9 team members full time
● Several teams working together?
PROJECT PLAYERS
● Dedicated Project Manager ? (Y/N)
● QA on our side? (Y/N)
● Our Technical Lead/Architect? (Y/N)
● Some of the team members are contractors
● Part time members are more then 1 and/or more
then 30% of capacity
● Distributed team or not
● Seniority Level of team members

18. 18
● Practice is a habit.
● Practice is a routine.
● Practice does not need to
remember.
● Practice comes by practicing.
Practice needs dedication and
● Commitment.
... Shooting, Driving, Writing
When we talk about
"Practice", what
does it mean?

19. 19
PRACTICES ADVISED TO FOLLOW
Collaborative Practices
Defining Practices
Planning Practices
Tracking Practices
Developing Practices
Testing Practices
Releasing Practices.

20. 20
AGILE DEVELOPMENT MATURITY MODEL
● Inconsistency in delivery of
quality software code
● Lack of unit tests coverage
● Lack of management
support for unit tests owing
to delivery time
● Lack of automated build 8t
deployment process
● Lack of team awareness &
knowledge regarding agile
coding techniques
● Lack of monitoring &
measurement on code
quality
● Setup a software quality
governance team
● Regular training on software
quality, unit testing & agile
coding techniques
● Define Software quality goals
forteams
● Encourage unit testing with
management support;
● Setup code review guidelines &
best practices
● Setup automated build &
deployment process with tools
● Setup framework for
monitoring & measurement
software quality
● Setup tool for static
(automated) 8: manual code
reviews
● Enforce design & code
reviews tasks while
planning & estimation
● Enforce unit testing tasks
while planning & estimation
● Monitor & measure software
quality characteristics
(Testability, Reusability,
Reliability etc)
● Enforce usage of code
review tools for static and
manual reviews
● Optimize learning from
design 8r code reviews with
regular workshops

21. 21
t

22. 22
THANK YOU!
Tetiana Ivanova
Project Manager
Email:
tivanova@waverleysoftware.com
Mobile: +38 (050) 155 93 15
Skype: tatyana_iva
Twitter: @taty_iva
Linkedin: tanya-ivanova-2312b749