F secure team-self-assessment-1.6

Editor's Notes

• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #12: 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.
• #18: 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.