Hello Habitants! Any company wants to achieve greater efficiency in software development, because this directly affects profits. Much of the Agile literature focuses on large, high-growth companies, but what if your company is not at the forefront of IT? The good news is that every organization can improve performance, and this book will help you find specific paths and solutions to get the most out of Agile. “I'm not an Agile evangelist. I am a supporter of what works and an opponent of what promises a lot but does not bring results. In this book, the Agile methodology is presented not as a movement that requires heightened consciousness, but as a set of special managerial and technical methods, the effect and interaction of which are understandable for any businessman or IT specialist.Agile enthusiasts may criticize this book for not promoting Agile best practices. But that's the point - an emphasis on practical methods that have proven effective. The history of Agile is full of ideas that have been successfully implemented by a couple of enthusiasts in some organizations, but which cannot be used by everyone else, ”says Steve McConnell. The new book by Steve McConnell, author of the legendary books Code Complete and Software Estimation, brings together the real-life experience of hundreds of companies. Use a simple and straightforward guide to the modern and most effective Agile practices.which have been successfully implemented by a couple of enthusiasts in some organizations, but which are not used by everyone else, ”says Steve McConnell. The new book by Steve McConnell, author of the legendary books Code Complete and Software Estimation, brings together the real-life experience of hundreds of companies. Use a simple, straightforward guide to the modern and most effective Agile practices.which have been successfully implemented by a couple of enthusiasts in some organizations, but which are not used by everyone else, ”says Steve McConnell. The new book by Steve McConnell, author of the legendary books Code Complete and Software Estimation, brings together the real-life experience of hundreds of companies. Use a simple, straightforward guide to the modern and most effective Agile practices.
Even more efficient project execution
In the previous chapter, we looked at how to organize and support developers when working in Agile. This chapter discusses how to properly organize and maintain the development process when working in Agile.
Most software development is organized into projects. Organizations use a wide variety of terms to describe concepts related to a project, including product, program, release, release cycle, function, value stream, workflow, and more. ...
Terminology varies considerably. Some companies believe that release is synonymous with project. Others think release refers to progressive development, so they stopped using it. Still others define the concept of "function" as the amount of work designed for 3–9 people and 1–2 years. In this chapter, by the word "project" I will mean any of the listed types of work, that is, the work of a certain number of employees for a long time.
Key principle: small project sizes
Over the past 20 years, the most famous cases of successful application of Agile in small projects. For the first 10 years of its existence, Agile paid great attention to keeping projects small, that is, 5–10 people in a team (for example, 3–9 developers, a product owner, and a scrum master). The emphasis on small project size is very important because small projects are easier to handle successfully than large ones, as shown in Fig. 9.1.
Capers Jones has postulated for 20 years that small projects are more successful than large ones [Jones, 1991; 2012]. I have summarized most of the research on project success versus size in my Code Perfect books [McConnell, 2004; SPb .: Peter, 2007] and Software Estimation: Demystifying the Black Art [McConnell, 2006].
Smaller projects are safer for several reasons. Large projects require the involvement of more specialists, and the number of relationships between people in teams and between the teams themselves increases in a non-linear progression. And the more complex the relationship becomes, the more mistakes are made in the interaction. Interoperability errors lead to errors in requirements, design, coding - in general, other errors.
Consequently, the larger the project becomes, the more mistakes are made (Figure 9.2). This means not only that the total number of errors is growing, but that there are immeasurably more errors in large projects!
The higher the error rate, the lower the effectiveness of the flaw detection strategies. This means that the number of defects in the finished product increases disproportionately.
It also takes more effort to eliminate errors. Therefore, as shown in Fig. 9.3, smaller projects have higher productivity per person, but the larger the project size, the more productivity drops. This phenomenon is known as cost of scale.
This inverse relationship between size and performance has been extensively researched and tested for over 40 years. Fred Brooks discussed the cost of scale in software development in the first edition of his book The Mythical Man-Month [Brooks, 1975; SPb .: Peter, 2021]. Larry Putnam's work on estimating software development costs confirmed Brooks' observations [Putnam, 1992]. The study of the development cost model (Cocomo) empirically confirmed the existence of costs of scale twice - in a study from the late 1970s and in an updated study from the late 1990s [Boehm, 1981; 2000].
The takeaway is that to maximize the likelihood of a successful Agile project, try to keep the project (and team) small.
Of course, it is impossible to make every project small. Chapter 10, “Executing Large Projects Even More Effectively,” outlines approaches for large projects, including suggestions on how to scale them down.
Key Principle: Short Sprints
The natural conclusion that small project sizes are preferable is that sprints should not last long. You might think that a small project is already a recipe for success. But short sprints of 1-3 weeks contribute to all-round successful project management. This is described in the next few sections.
Shorter sprints reduce the number of intermediate requirements and improve responsiveness to new requirements
In Scrum, new requirements can be added between sprints. But once the sprint has started, you cannot add requirements until the next sprint. This makes sense if the sprint is 1–3 weeks long.
If development cycles take longer, then stakeholders are more and more insistently asking to add requirements along the way, so requests to postpone adding requirements are no longer so justified. If the cycle with a sequential development model lasts six months, then asking the stakeholder to postpone the implementation of the new requirement until the next cycle means that work on the requirement will begin only in the next cycle - that is, at the beginning of the cycle, this requirement will only be added, and then you need to wait for the product delivery at the end of this cycle. On average, it takes 1.5 cycles, that is, 9 months.
In contrast, normal Scrum sprints last two weeks. This means that a stakeholder who wishes to add a new requirement will have to wait an average of three weeks.
Asking a stakeholder to wait 9 months for a requirement to be implemented is often inappropriate. And three weeks is almost always appropriate. This means that the Scrum team is working calmly, without fear of new requirements in the middle of the sprint.
Short sprints provide greater responsiveness when working with clients and stakeholders
Each sprint presents a new opportunity to showcase working software, validate requirements, and generate feedback from stakeholders. With standard two-week sprints, teams give themselves the opportunity to be faster 26 times a year! With a three-month development cycle, this opportunity is presented only four times a year. Fifteen years ago, a three-month project was considered short. Today, such a schedule means that you will not be able to respond quickly to feedback from stakeholders, customers and the market.
Short sprints build stakeholder confidence
As teams deliver results more often, progress becomes more transparent, so progress is visible for stakeholders, which builds trust between them and the team.
Short sprints help speed development through learn-and-adapt cycles.
The higher the iteration rate, the more opportunities for the team to reflect on the lessons learned, draw conclusions, and apply the results to practical methods of work. The rationale for this area is the same as for customer responsiveness: is it better to let your teams learn and adapt 26 times a year, or just four? Short sprints help your team improve faster.
Short sprints help reduce experimentation time
In the context of Cynefin's Tangled Issues, the issues must first be investigated before the full scope of the work can be understood. Such research should be characterized as follows: "To get an answer to this or that question, do the least amount of work required." Unfortunately, Parkinson's Law says that work takes up all available time. And until the team develops iron discipline, the solution of the issue, if a month is allocated for it, will take exactly a month. But if there are only two weeks, then most often the solution of the issue takes two weeks.
Short sprints allow timely detection of costs and risks
Short sprints allow you to track progress more frequently. After just a few sprints, when working on a new task, the team's "speed" or the pace of progress will be determined. The ability to monitor the progress of work makes it easier to predict the timing of the release of the product. If the work is taking longer than originally planned, this will become crystal clear in just a few weeks. Short sprints are a powerful tool for staying informed. Chapter 20, "Even Better Predictability," goes into more detail about this.
Short Sprints Promote Team Accountability
If a team is responsible for delivering work functionality every two weeks, they don't have the opportunity to work in the dark for long. She shows the results of her work at sprint review meetings and reports to stakeholders every two weeks.
The product owner sees the fruits of labor even more often.
The product owner accepts or rejects the work, the progress of the work is clearly visible. Thus, teams are better accountable for their work.
Short Sprints Promote Accountability
For generations, development teams suffered from "stars" locked in a dark room for months, and it was completely unclear if work was progressing. In the case of Scrum, this problem no longer exists. Everyone works in support of the team's goals in the sprint, in addition, there is a need to come to stand-ups every day and talk about what work was done yesterday - you will not be able to lock yourself up anymore. Either the developer begins to cooperate, which solves the problem in one way, or cannot stand the conditions and leaves the team, which still solves the problem, albeit in a different way. From my own experience, I can say that any of the outcomes is more favorable than in the case when someone works without any reports for weeks or months, and in the end it turns out that nothing really has been done.
Short Sprints Promote Automation
Because teams often perform reconciliation, short sprints can automate tasks that would otherwise be repetitive and time-consuming. Automation is widespread in assembly, integration, testing and static code analysis.
Shorter sprints are more likely to deliver a sense of satisfaction A
team that delivers working software every two weeks is more likely to be satisfied with their work and also more likely to have the opportunity to celebrate their accomplishments. This contributes to a sense of professionalism that fosters motivation.
Short sprints. Summary
In general, the benefits of short sprints can be summarized as follows: "Delivery speed in all respects helps to cope with the volume of work." Delivery of functionality in small batches and short cadences brings a huge number of advantages over the delivery of functionality in large batches and long cadences.
Plan based on the speed of tasks
Story difficulty units are a measure of the size and complexity of a task. Speed ​​is a measure of progress based on how often tasks are completed and measured in units of story difficulty. Speed-based scheduling is planning and tracking work based on history difficulty units and work speed.
Speed ​​scheduling and tracking are not part of the Scrum tutorial, but in my experience I think it would be a good idea to include them. Next, I'll talk about how Story Difficulty Units and Speed ​​Estimates are applied.
Estimating Product Backlog Size
Difficulty scoring is used to determine the size of the product backlog. The sizes of issues in the product backlog are usually estimated in terms of the difficulty units of the stories, and then the complexity units of the stories are added to calculate the total size of the product backlog. This should be done at the beginning of the release cycle and as work is added or removed from the backlog. This is done to the extent the team needs to be predictable. More about it in Chapter 20, "Even Better Predictability."
Speed ​​calculation
The amount of work completed by the team in each sprint is calculated in units of story difficulty. The number of Story Difficulty Units achieved in each Sprint represents the team's speed. The speed is calculated based on the results of each sprint by calculating the average.
Sprint Planning
The team plans the scope of work per sprint, also measured in units of story difficulty, based on observations of the team's speed.
If the team completed 20 Story Difficulty Units per sprint on average, and in the next sprint set itself the goal of completing 40 Story Units, then they need to cut their plans. If a team member is going on vacation or multiple team members are attending training events, the team should plan fewer Story Difficulties per sprint than they did on average. If the team managed to achieve 20 difficulty units of the stories thanks to sleepless nights and work on weekends, the bar should also be lowered. If your team consistently and effortlessly achieves sprint goals, try scheduling more Story Difficulties than the average. In any case, the team is planning based on their actual speed.
Release tracking
Based on average speed, you can calculate or predict the amount of time it will take to complete tasks in the Product Backlog. If the product backlog has 200 story difficulty units, and the average team speed is 20 story difficulty units per sprint, then the team will need 10 sprints to complete all tasks from the backlog. I'll explain more about how this works in Chapter 20, "Even Better Predictability."
Accounting for the impact of changes in process, team composition, and other changes
Based on speed, you can track the impact of changes in process, team composition, and other changes. The specifics of this are discussed in Chapter 19, Improving Process Even Better.
Key principle: product delivery in vertical slices
For sprints to be effective, the team needs to develop the ability to deliver small batches of functional functionality frequently. The design approach that facilitates this is called "using vertical slices", which means making changes to each architectural layer to obtain increment or value.
The vertical slice represents the complete functionality of the stack, such as adding a field to a bank statement or making a user's transaction confirmation one second faster. Each of these examples usually requires the entire technology stack to run, as shown in Figure 1. 9.4.
Vertical slices tend to help non-technical stakeholders better understand, observe, and measure business value. They give the team the ability to release releases faster and realize the real value of the product for the business, and get real feedback from users.
Teams using horizontal slices run the risk of plunging into the jungle for several sprints in a row, working on stories that reflect some progress, but do not bring visible business value.
Teams are sometimes reluctant to use vertical slices, usually because of lower efficiency. They will argue, for example, that it is more efficient to do more work in the business logic layer, and then move on to the interface layer. This approach is called using horizontal slices.
In some cases, from a technical point of view, it may be more efficient to work on horizontal layers, but such technical efficiency, as a rule, leads to optimization of individual parts of the product, which is not as important as obtaining valuable functionality. Contrary to claims that using horizontal slices leads to increased efficiency, our company has found that when using horizontal slices, many teams are faced with the need to make significant corrections.
Vertical slices provide tighter feedback
Vertical slices allow you to quickly deliver functionality to business users, which helps you get quick feedback on how the functionality is working correctly.
Because vertical slices require end-to-end development, team members are forced to work together on design and implementation, which provides useful technical feedback to the entire team.
The use of vertical slices also facilitates end-to-end testing, which helps to ensure tight feedback.
Vertical slices provide more business value
Vertical slices are better understood by stakeholders who don't know the technical details, and this leads to better quality decisions that the business makes about the priority and order of implementation of new and revised functionality.
Since vertical slices provide a full functional increment, they often provide an opportunity to present work functionality to users, which increases business value.
The use of horizontal slices leads to the fact that developers begin to perceive architecture as a product. And this can lead to rewarding activities that are completely unnecessary for the delivery of functionality, and to other methods that lead to a decrease in value.
What a team needs to use vertical slices
Delivering functionality with vertical slices can be difficult. It depends on the composition of the team, their business, development and testing abilities, which include skills across the entire technology stack.
Teams may also need to change their design and implementation thinking to work with vertical slices, which will be different from working by components or horizontal layers. Some teams lack design skills to do this and will need to develop (and sustain development) skills to cope with it.
Finally, teams need to get their work done in vertical slices. The product owner and development team must find an approach to refine the backlog so that the result is vertical slices.
Key Principle: Manage Tech Debt
"Tech debt" refers to the accumulation of poor quality work in the past that slows down the pace of work in the present. The classic example is a fragile codebase where every attempt to fix a bug generates one or more new ones. Even fixing a simple error is time consuming and fixing additional errors.
Technical debt can include low-quality code, low-quality design, a weak test suite, a difficult design approach, a cumbersome build environment, slow manual processes, and other ways a team sacrifices long-term performance in favor of short-term gains.
Consequences of technical debt
Debt usually accumulates as a result of the pressure to prioritize short-term releases at the expense of quality. A holistic view of the resources invested and the returns obtained includes accounting for the impact of technical debt over time.
Technical and business teams can have compelling reasons to accumulate this debt. Some releases are time-sensitive enough to warrant additional work later on because of the desire to get the work done faster in the present.
However, a model that allows technical debt to accumulate over time without a plan to work through that debt will ultimately reduce team speed. The team needs to develop a debt management plan to maintain or increase its speed.
Kruchten, Nord, and Ozkaya have developed an excellent diagram of how technical debt arises, what (likely) business value it has, and how it ultimately becomes more of a liability than an asset (Figure 9.5).
When working from scratch, teams can avoid accumulating technical debt in the first place. When performing work that has already begun, teams often have no choice but to work with the already accumulated technical debt. In all types of work, if the team is not doing well with technical debt, the speed will decrease over time.
Paying off technical debt
Different teams have different approaches to paying off technical debt. Some teams, in order to pay off the debt, distribute it in shares for each development cycle (sprint or release). Other teams add debts to the product backlog or gaps list and prioritize the debt and the rest of the work. In any case, the key feature is that technical debt is openly managed.
Types of debt and how to deal with it
Not all technical debt is the same, and there are different classifications. I find these categories useful:
- Intentional debt (short-term). Debt derived from tactical or strategic considerations, such as releasing a time-sensitive release on time.
- Intentional debt (long-term). Debt derived from strategic considerations, such as initially supporting a single platform instead of supporting cross-platform.
- Unintentional debt (bad faith). Debt that happens by chance due to poor quality development methods. This type of debt slows down work both in the present and in the future, so it should be avoided.
- Unintentional debt (good faith). Debt that arises by accident due to natural mistakes in software development (“Our design approach did not work as well as we planned,” or “The new version of the platform showed serious design flaws”).
- Inherited debt. Debt inherited by the new team from the old codebase.
Table 9.1 shows which approaches are recommended for responding to these types of debt.
Benefits of discussing technical debt
In my experience, the metaphor “technical debt” has been helpful in facilitating discussions between tech and business professionals. Business professionals generally do not know what the costs of paying off technical debt are, and technicians generally do not know the business interests. In some cases, it may be a good idea to deliberately allow technical debt to build up, and in others it won't. Debt facilitates the exchange of views on technical and business considerations, making it more meaningful, which improves the quality of decisions about when and why to take on debt and when and how to repay it.
Build your work structure to avoid burnout
The purist view of Agile assumes the same sprint duration (known as “shared cadence”). If the team tolerates the overall cadence well, there is no point in making changes. Shared cadences make it easier to calculate speed and other factors when planning a sprint.
A common complaint when implementing Scrum is that an endless sequence of sprints leads to fatigue and the feeling of running in the wheel. With consistent development, there are natural failures in performance, especially between disciplines, and balance during periods of high intensity.
Constant sprints leave no time for rest if each sprint does indeed run at a sprint pace.
One of the antidotes to fatigue after sprints is changing the duration of sprints as needed. A systematic way to do this is to use a 6x2x1 pattern, six sprints of two weeks plus one sprint lasting one week, for a total of 13 weeks, which is exactly one quarter.
An alternative would be to use shortened sprints after major releases, on holidays and at other times when the team's speed will still not be stable. During a weeklong sprint, a team may be working on infrastructure or tools, attending prep or team events, hackathons, working on technical debt, working on improvements that are too big to be completed in a sprint, or something else.
The varying length of sprint cadence is consistent with the concept of sustained pace used in Agile. A lot of Agile research equates a steady pace with a lack of free evenings and weekends. But I think this is an annoying oversimplification that ignores differences in preferences for working conditions of different people. Some suggest a 40-hour workweek as a steady pace, but for others it's a road to boredom. Personally, I did most of my best work in explosive mode - 55 hours over two weeks and then 30 hours over the next two weeks. On average, it can work out about 40 working hours per week, but different teams do not always have 40 working hours. The understanding of a steady pace is different for everyone.
Other considerations
Off-Design Software Development
Not all software development is organized into projects, even with the many definitions at the beginning of this chapter. Sometimes there are situations in which one person usually works, for example it is common in handling technical support calls, solving release problems, creating patches, and the like.
Such work is, of course, related to software development and also lends itself to Agile practices. They can be carried out more efficiently, qualitatively, methodically through the introduction of such practical Agile methods as Lean Manufacturing and Kanban. But in my experience, companies tend to have far fewer problems with this kind of work than with project-wide software development, so this book focuses on working on projects rather than ad-hoc work.
Recommendations
Study:
- Review the history of project totals. Is your company's experience in line with the general perception that small projects are more likely to succeed than large ones?
- Browse your portfolio of projects. Which of your large projects can be divided into several smaller ones?
- , . ? ?
- , .
- , .
- . ?
- .
- , , .
- .
- [ , 1975]. -. , , .
- [ , 2019]. Understanding Software Projects Lecture Series. Construx OnDemand. (2019 ). ondemand.construx.com. .
- [ , 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. , .
- [ ., 2019]. Managing Technical Debt. .
»More details about the book can be found on the publisher's website
» Table of Contents
» Excerpt
For Habitants a 25% discount on coupon - Agile
Upon payment for the paper version of the book, an e-book is sent to the e-mail.