F secure team-self-assessment-1.6
•Download as PPTX, PDF•
1 like•530 views
This has been shared with many outsiders, so I guess good to share it here. This is a barometer we have used to have software development teams assess their own functioning within the FSC whole. It is not necessarily accurate for other companies and environments, but certainly should be inspirational. Part of the credit should go to the awesome GM team that helped me hone it.
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (9)
Similar to F secure team-self-assessment-1.6
Similar to F secure team-self-assessment-1.6 (20)
F secure team-self-assessment-1.6
- 1. F-Secure Team Self-Assessment Assessment you can use for measuring the maturity of team practices and working environment Global Methods team Protecting the irreplaceable | f-secure.com
- 2. 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 This assessment is a work in progress for GM team. Feedback is welcome. February 2 © F-Secure / Confidential 11, 2013
- 3. 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 February 3 © F-Secure / Confidential 11, 2013
- 4. 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 0 points • Calculate the score of all areas 1 pts Gateway question • Discuss about the results with the team 4 pts Gateway question 7 pts Gateway question You get the amount of points 9 pts Gateway question indicated by the statement above the first statement that is not true for your team 10 points February 4 © F-Secure / Confidential 11, 2013
- 5. 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 February 5 © F-Secure / Confidential 11, 2013
- 6. It’s like a box of chocolates, you never know Iterations and Planning what you’re going to get 1. 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 February 6 © F-Secure / Confidential 11, 2013
- 7. 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 February they all need to be done.” 7 © F-Secure / Confidential 11, 2013
- 8. 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. February 8 © F-Secure / Confidential 11, 2013
- 9. 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 February 9 © F-Secure / Confidential 11, 2013
- 10. 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 February 10 © F-Secure / Confidential 11, 2013
- 11. 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 February 11 © F-Secure / Confidential 11, 2013
- 12. Dear ScM: You can go and grab a Scrum Master (ScM) Work cup of coffee. [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 February 12 © F-Secure / Confidential 11, 2013
- 13. 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 February 13 © F-Secure / Confidential 11, 2013
- 14. “Somebody Else” does not work for F-Secure. 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 February 14 © F-Secure / Confidential 11, 2013
- 15. What can you say about the team in this picture? That’s all! What will you do next? Protecting the irreplaceable | f-secure.com
- 16. Backup slides follow February 16 © F-Secure / Confidential 11, 2013
- 17. 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 February 17 © F-Secure / Confidential 11, 2013
- 18. 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 February 18 © F-Secure / Confidential 11, 2013
Editor's Notes
- Software development team can’t work properly unless the team composition is clear to team members and stakeholders.A team with more than 9 members becomes quickly inefficient and hard to co-locate. A team of less than 4 members is very susceptible to absences, individual strengths and random events.A high-performance team requires devotion and dedication. It is hard to belong to such a team part-time. Part-timers disrupt team dynamics.Serving many masters creates conflicts and waste. Team needs to know it can count on the members taking care of the teams work.Timesharing (excessive task switching) lowers the performance. Every project is likely to get delayed. Timesharing makes planning and predicting difficult and creates conflicts.The whole team should work together in alignment. Diverse goals lower the synergy and may lead to distractions (even conflicts). The benefits of a cross-functional development team are not realized as team members do not help each other and ensure that goals are met.Changing team composition inside an iteration is a major disturbance and will hurt the teams ability to deliver significantly.Close proximity enables efficient (face-to-face) communication and quick decision-making. Social (even informal) networking is natural. No traveling costs. No communication breakdowns due to email or teleconferencing equipment. Team benefits greatly from accidental communication.Disruptive changes are harmful for the team performance and motivation.It takes time to build a high-performance, "jelled" team.
- A fixed timebox provides a cadence and enables feedback cycles. Reprioritization and review of results happens often enough.The whole team shares the knowledge and understanding created by planning, and is then able to commit and self-organize to reach the goals. The work can be performed without disruptive midcourse changes.Reliable, predictable team delivery makes it possible for the rest of the organization to align its activities with team delivery.High utilization is usually not a reasonable product development target. Some slack should always be reserved for uncertainties. Working software is usually the best progress indicator. Frequent demos allow regular feedback based on dialogue with the customers (stakeholders). The demo must be performed in a way that is useful for the stakeholders (not only for the team members to show off). Clear statement of commitment and what was actually achieved serves to demonstrate the team’s ability to plan and execute. Stating what is not fully Done serves to show what is the state of the unfinished items and which parts of Done they do not yet fulfill.If there are too few items (too large items) taken into the iteration this is an indication that the items are not understood well enough. This also easily leads to the situation where many items leak since all are under work at the same time or all team time is taken up by one item leaving no room to react to surprises.It is a clear sign of trouble if the team keeps committing to delivering more than they can. The team is not able to plan properly, perhaps basing capacity estimate on some arbitrary theoretical numbers rather than basing it on experience. Beautiful plans and promising unrealistic commitments typically leads to failed expectations, low morale, poor quality, poor long-term planning ability, and technical debt.The PdO needs to gain technical understanding of backlog items, including estimates on the required effort. He also needs time to research any tricky questions the team may present. The team needs to prepare ahead for their future work in many ways.All work must be taken into account for the total effort estimates. Definition of Done works as the team’s own checklist of what to take into account. Engineers typically underestimate items if they don’t use thinking aids.A clear, common goal sets the direction and boundaries of the team effort. The decision-making is guided.All work must be known and visible to everyone. All work should be prioritized together to mitigate conflicts. Teams should continually improve their working methods and infrastructure.
- The PdO is the key actor between the team and the rest of the organization. A PdO that does not understand their role well can ruin the work results of the team.There should be no confusion caused by conflicting multiple sources of work and priorities.High utilization is usually not a reasonable product development target. Some slack should always be reserved for uncertainties. Pressing the team to promise more than they can deliver leads to undue stress, low morale, disregarding improvement and infrastructure work, poor quality, and technical debt, among other things. If the team for some reason is ready before the end of iteration nothing prevents them from taking more work from the backlog. You can agree this explicitly with your PdO if necessary.The PdO role should focus on the customer (business) perspective. It is much more important for the PdO to set the goal and context for the work than to provide a possible way to solve the problem. The team should come up with the best alternative for the technical solution.It is paramount that the PdO understand the problem domain very well so that he can guide the team.It is difficult to write backlog items well. Extra care must be taken to write them so that they are generally understandable and describe well the desired end-state, rather than some technical way of achieve the end-state. The description needs to guide the team well in their work to find the best way to implement the needs.Typically the team will not proceed as fast as the PdO would like. In those cases he must be able to state what is the most important work and what is less important work that can be undertaken later. Prioritization should always be driven by comparing organizational value vs. estimated effort.Uninterrupted work flows quicker.Reasonable anticipation ensures predictable delivery and helps maintaining a steady flow. Any significant unclarities can be clarified before it is too late.Unnecessary waiting times for information significantly hurt the performance of the team.
- Basic professional source code management is a prerequisite for effective agile software development.When making significant changes the team can perform quality control before integrating with the work of other teams.Team is able to branch in a controlled manner when it is needed for releases or special versions of the codebase.Largest single problem with large software projects is late integration and the technical and organizational challenges is causes. The only way to know in which state your product is, is to integrate frequently and test continually.Unit testing reveals defects early, quickly, and cheaply. It is the best way to know that you did not break any existing functionality, thus enabling quick and brave changes.The ultimate Done measure is the release to users and their feedback. Ability to release to users often requires that your software is of constant good quality and that your release process works well. These are fundamentals of agile software development.All "debt" is risky. Keeping your main codeline in good condition is the most efficient development method. It enables rapid development and rapid releasing.Static analysis can provide low-cost error feedback very quickly.The ability of the team to work must not depend on a single individual, who may fall ill or leave the company. Code must be written with supportability in mind to make sure others can develop it further later on.Technical excellence enables steady, efficient flows. When you don’t leave technical debt unpaid you do not have to pay the interest on it later. Advanced engineering methods enable rapid development with good quality of the software and the codebase.
- Specialized skills are required to test software well and to plan testing. Professional software testing is usually the best way to know the state of your software.A programmer can’t usually take into account all the requirements for a piece of software while he is concentrating on finding a good technical solution. The support of testers in his team while he is iterating over the code greatly speeds up development and enhances quality.The actual customer / user performance is the hard criteria for a piece of software. This performance should be checked as quickly and as realistically as possible to immediately fix things that will cost more to fix later and may hamper future work for other teams. Most critical faults are often found in the integrated, realistic systems.Functional testing is just one part of high quality. Sometimes non-functional attributes are even more critical. They are also often not explicitly stated in the requirements and thus require the more attention.Testability of the software has a huge impact on the productivity of the testers, and therefore also the programmers. It is not sensible to develop software that is difficult to develop. The programmers should always consult with the testers before implementing new functionality.Efficient testing is hardly possible without professional tools.A steady, quick development cycle requires stable testing facilities in the loop. Debt in the test system is even worse for development efforts than quality debt in the actual software under development. Failure to react to failing test automation causes more and more commits to be made to the software, making it extremely costly to fix the original problems.Different abstraction levels find different bugs at different rates. They also have very different implementation costs (effort). The most cost efficient solution is to do testing to a sensible degree on multiple levels.Test automation enables continuous testing with fast development feedback cycles. Quality is fairly well known at all times.Changes, releases, and refactoring can be done with confidence.
- Bugs must not disappear in the chaos, they might be dealbreakers.It is important for the PdO and everyone in the team to understand what it means if the teams says that a Story is ‘Done’.If you do not verify that the system works in the intended way from end-user point-of-view, you are likely to leave integration errors and the like in the system.It is not beneficial work to improve your component if it does not make the overall system better.Cheap and quick removal of those bugs that can be found by low-level test automation is very effective in improving system quality and development speed.You need to keep the system constantly in a shape that you dare to release, do not let is deteriorate. Also, you may get extremely valuable feedback that steers your work.Bugs are much cheaper to fix early when the analysis is fresh, the SWE has the environment, and the team is busy at work with the component. The team often has much better understanding on whether something should be fixed than others. Calendar time makes bugs expensive with high interest rate.It is important that your team does not disrupt the work of many other people.Professionals do not create technical debt, but pay it as they proceed through code. If it is somebody else’s mess, you should still clean it up for the people who are coming after you. Quality is a difficult thing to understand and communicate. Do not take a one-eyed view on quality. You need to understand the business needs for quality and the trade-offs that you can do in different areas (like UX, security, supportability..) and succeed in our business.
- If the information from the team is not honest, visibility does not matter.The team must have absolute clarity of the mission for the sprintStakeholders are interested in what is going on. Make it easy for them to see what you are doing. This will benefit you, as they will understand you better.It is critical to understand which Story is the one that can not be compromised and which is the one you should leak if you run into trouble. You should not need to wonder where to put your effort.A well maintained view to the future is a valuable tool for you and your stakeholders for many reasons.Stakeholders want to know how you are doing. You should also know how you are doing, in case you need to take measures to meet the most important parts of your Sprint commitment.With velocity metric you can estimate your commitments well and you see if you are improving in your work.The information is valuable to the stakeholders and you should be proud enough of your results to show them to the world.It is crucial to have a visibility on progress, changes of scope, and probability of making a controlled release.
- Basic professional source code management is a prerequisite for effective agile software development.When making significant changes the team can perform quality control before integrating with the work of other teams.Team is able to branch in a controlled manner when it is needed for releases or special versions of the codebase.Largest single problem with large software projects is late integration and the technical and organizational challenges is causes. The only way to know in which state your product is, is to integrate frequently and test continually.Unit testing reveals defects early, quickly, and cheaply. It is the best way to know that you did not break any existing functionality, thus enabling quick and brave changes.The ultimate Done measure is the release to users and their feedback. Ability to release to users often requires that your software is of constant good quality and that your release process works well. These are fundamentals of agile software development.All "debt" is risky. Keeping your main codeline in good condition is the most efficient development method. It enables rapid development and rapid releasing.Static analysis can provide low-cost error feedback very quickly.The ability of the team to work must not depend on a single individual, who may fall ill or leave the company. Code must be written with supportability in mind to make sure others can develop it further later on.Technical excellence enables steady, efficient flows. When you don’t leave technical debt unpaid you do not have to pay the interest on it later. Advanced engineering methods enable rapid development with good quality of the software and the codebase.