F secure team-self-assessment-1.6

Protecting the irreplaceable | f-secure.com

F-Secure Team Self-AssessmentAssessment you can use for measuring the maturity of team practices and working environment

Global Methods team

April 12, 20232

Purpose of This Assessment

To be a simple and fun maturity/health assessment for a software development team, that helps:

• Creating self improvement energy in software development teams

• Giving teams clear achievable goals and ideas to improve

• Efficiency and risk factors

• Somewhere at F-Secure there is a place where each one is broken..

• Team members to get to know their team better

• Developing knowledge of team practices and working environment in R&D

© F-Secure / Confidential

This assessment is a work in progress for GM team. Feedback is

welcome.

April 12, 20233

Areas for Evaluation


1. Team Resourcing

2. Iterations and Planning

3. PdO work

4. Programming Work

5. Testing Work

6. Quality

7. Visibility to Work

8. ScM Work

9. Cooperation in the Team

10. Improvement

April 12, 20234

4 pts

Performing this Assessment

• Arrange this with the team upon request

• Show the team the assessment areas one-by-one

• Team discusses and decides which level describes their situation best

• Focus on facts, not blame

• Discuss what the team could do to improve things

• Take note of clear escalation items

• Calculate the score of all areas

• Discuss about the results with the team


10 points

0 points

Gateway question

Gateway question

Gateway question

You get the amount of points indicated by the statement above the first statement that is not true

for your team

1 pts

7 ptsGateway question9 pts

April 12, 20235

Team Resourcing

1. Everyone agrees who are part of the team

2. Team has between 4 and 9 members

3. Team members are at least 75% allocated to team work

4. Team members are not members of any other software development team

5. Team members are not working for any other (conflicting) software projects

6. Team has only shared goals/targets

7. Team members only change at iteration boundaries

8. Team is co-located

9. Team members only change based on consultation with the team

10. Team members stay in the team long enough to work smoothly with the team


April 12, 20236

Iterations and Planning1. The development team works in Sprints of maximum one month fixed length

2. The team plans the Sprint together. Work content is not changed in the middle of a Sprint without agreement of team and PdO together.

3. Team clearly states what Stories it commits to get Done™ in each Sprint

4. Team performs a demo at the end of each Sprint, to show in a useful way what was done for the PdO and stakeholders. The team clearly states what it committed to achieve, what it achieved, and what is not fully Done™

5. The team commits to at least 3 Stories of work per Sprint and none of them exceeds 50% of estimated capacity for the team

6. The team only commits to an amount of work that fits estimated capacity. Capacity estimate is based on actual velocity.

7. Team uses 5% workshops in all Sprints to evaluate future work and provide knowledge for the PdO

8. Team uses definition of Done™ when making effort estimates. Time for bug-fixing is also taken into account in initial Story estimates.

9. Team always sets a Sprint goal statement to align the team and clarify the purpose of the Sprint

10. Maintenance, infrastructure and improvement Stories are included in planning just like Stories for new features


It’s like a box of chocolates, you never know what you’re

going to get

April 12, 20237

Product Owner (PdO) Work

1. Team has a PdO that understands the purpose of PdO work

2. Team has exactly one PdO and exactly one prioritized list of future work

3. PdO does not force the team to attempt more than the team estimates it can do

4. PdO does not express an unhealthy interest in technical details of Stories

5. PdO is able to clarify Stories and Features sufficiently upon request by the team.

6. PdO is able to describe Stories and Features so that they are agreed and understandable by all stakeholders enabling the team to find the best implementation

7. PdO is able to provide priorities for the team, including what is less important

8. PdO does not unnecessarily disturb or interrupt the team

9. PdO provides suitable visibility to the future work of the team

10. PdO is promptly available whenever the team needs


“Yes, it’s less important but they all need to be done.”

April 12, 20238

Programming Work

1. All code created by team is stored in a versioning, backed-up repository.

2. Team can test changes before code is integrated for everyone’s use.

3. Team keeps trunk in good shape and makes releases from the trunk.

4. Team uses branching when needed.

5. Entire system is built several times a day. The team integrates stable changes with the entire system as early and as often as possible.

6. No piece of code is understood by only one member of the team.

7. Unit-testing is a standard practice (line coverage 50+ %)

8. Team employs automatic analysis tools, e.g. static/dynamic analysis or unit test code coverage. Tools are run at least daily for the whole codebase.

9. Refactoring is used as a standard practice.

10.Team employs advanced development methods, e.g. pair-programming, code reviews, or TDD.


April 12, 20239

Testing Work

1. Team has member(s) who have good testing skills

2. Testing within the team provides a fast feedback loop for the programmers

3. Acceptance oriented testing happens as soon as possible, and as much as possible in system context

4. Testing takes into account non-functional aspects, such as interoperability, reliability, usability, supportability, performance..

5. Functionality created by the team is designed and implemented to be testable

6. Team employs testing tools

7. Test automation is kept at a passing state, fixing it is automatically highest priority

8. Testing is done on several abstraction levels for efficiency (eg. unit-, module-, application-, system-level..)

9. Team employs automated testing as a standard practice in all development work

10. All Stories include automated regression tests


April 12, 202310

Quality

1. Bugs discovered are either fixed immediately or reported properly

2. Team has defined a definition of Done™ and team follows it

3. Done™ includes acceptance level testing that verifies Story meets acceptance criteria agreed together with Product Owner

4. Team takes responsibility of quality on system and solution level

5. Done™ includes low-level automated testing (unit- or module-)

6. Software developed by the team is released to users at least monthly

7. When a bug is found, decision fix/no fix/escalate is done and followed immediately

8. Team very rarely integrates anything that causes problems for other teams or users

9. Any work that the team performs on a codebase leaves it in a better shape than it was before

10. The team understands the business quality target for different quality areas of the software


April 12, 202311

Visibility to Work

1. Any information provided by the team is completely honest

2. It is clear in the team which Stories they committed to in the current iteration

3. It is clearly visible to everyone interested which Stories the team is working on this iteration

4. Relative priority of Stories is clearly indicated

5. Contents, estimated sizes, and priorities of upcoming Stories are clearly shown in the Product (Solution) Backlog

6. Team provides a way that shows how work is progressing in the iteration

7. Team tracks it’s velocity for each iteration

8. Team makes velocity and iteration progress visible and understandable to any stakeholder

9. Release burn-up indicates scope changes, progress rate, and probable release date

10. Status of quality is visible to everyone interested


April 12, 202312

Scrum Master (ScM) Work[The team decides if ScM is allowed to stay in the room]

1. Team has a Scrum Master (ScM)

2. ScM does not apply command and control (servant, not manager)

3. ScM role is the primary one that is prioritized over other work the person may have

4. ScM has good understanding of the F-Lex process and agile methods

5. ScM facilitates and organizes team activities smoothly, promoting collaboration.

6. ScM protects the team from disturbances - no one except the PdO tells the team what to do

7. ScM makes sure backlogs, realized velocity, and burndown charts are updated and clear

8. ScM brings people together across teams enabling direct communication

9. ScM challenges the team so the team comes up with new solutions and innovations

10. ScM helps to improve the team’s processes and performance


Dear ScM: You can go and grab a cup of coffee.

April 12, 202313

Co-operation in the Team

1. Team members share a common goal

2. Team members share all relevant knowledge with each other

3. Team members communicate smoothly with each other

4. Team members co-operate to get Stories Done™

5. Team self-organizes during the iteration whenever needed to achieve the common goals as well as possible

6. Daily team meeting is meaningful to all team members

7. Team members actively offer each other advice and support so everyone can succeed in their work

8. Team members are willing to work in new roles and in new ways to achieve goals

9. Team functions efficiently even if any one member is missing

10.Team members work together to improve how the team works


April 12, 202314

Improvement

1. All members take responsibility to improve their own work continuously

2. Team members understand the function of retrospective and participate in it after each iteration

3. Team is willing to try new things and look at old things in new ways

4. Team routinely takes action on issues identified in retrospectives

5. Team includes improvement work in their Iteration Backlog and significant items are included in Solution Backlog

6. Try items from retrospectives get high priority

7. Team actively and constructively takes to other teams or management those problems that the team can not solve on its own

8. Team is able to continuously improve its own work practices and internal processes without help from ScM or people outside the team

9. Team members actively participate in bodies that aim to improve the work of entities larger than the team

10. Team helps other teams to improve their processes and practices


“Somebody Else” does not work for F-Secure.

Protecting the irreplaceable | f-secure.com

That’s all!What will you do next?

What can you say about the team in this picture?

April 12, 202316

Backup slides follow


April 12, 202317

Programming Work – old (2011-01-28)

1. All code created by team is stored in a versioning, backed-up repository. Team integrates all changes at least daily within the team

2. Team can create local builds for testing when needed

3. Team uses branching when needed

4. Entire system is built several times a day. The team integrates with the entire system as early and as often as possible

5. Unit-testing is a standard practice for all new development

6. Software developed by the team is released to users at least monthly

7. Team keeps trunk in good shape and makes releases from the trunk

8. Programmers employ static analysis tools

9. No piece of code is understood by only one member of the team

10.Team employs advanced methods, like pair-programming, reviews, or TDD. Refactoring is used as a standard practice


April 12, 202318

Quality – old (2011-01-28)

1. Bugs discovered are fixed immediately or documented properly

2. Team has defined a definition of Done™ and team follows it

3. Done™ includes acceptance level testing

4. All Stories meet acceptance criteria agreed together with Product Owner

5. Team takes responsibility of quality on system and solution level

6. Done™ includes low-level automated testing

7. Done™ includes documentation needed by stakeholders (true for maintenance and improvement Stories as well)

8. When a bug is found, decision fix/no fix/escalate is done and followed immediately

9. Team very rarely integrates anything that causes problems for other teams or users

10. Any work that the team performs on a codebase leaves it in a better shape than it was before


F secure team-self-assessment-1.6

Documents

Transcript of F secure team-self-assessment-1.6