Complex software requires a lot of work to scale and stay aligned. Many companies who don't have software in their DNA think that software like many industries will go faster with more teams, more individuals working on those teams, and more people over all.
Software development does not have economies of scale. Development has diseconomies of scale — Allan Kelly
Communication might be the opposite of software development. It's hugely difficult and time consuming. People literally speak different languages. Rally Points are all about translating your now well understood approaches into work that can be done by small groups. Small groups that you are confident are already aligned because they are working off an approach.
Iterative software development is optimized to move you forward in small steps toward a goal. A Rally Point is a single increment of that iteration. It's the definition of a single step, and the outcome you expect it to achieve.
There is a lot of scalability in this definition. An entire team can define a Rally Point, or it can be just one member of the team. What should remain consistent is that a Rally Point can be achieved within a single iteration with a high degree of confidence. This is all about splitting your work up into something that is valuable, achievable and sized in such a way that your prediction is a high confidence prediction.
Estimates are one of those things that everyone thinks they want, but we all know are almost universally wrong. You should only estimate to the extent it helps you make a specific decision, so instead of estimating our approaches, we will simply break them down into a series of Rally Points as we go. Let's do that with the earlier approach:
APPROACH: Most of our checkout process is the same information for every order, we should build an account system allowing shoppers to save their information and skip the checkout process entirely.
There is a lot to this when you start to peel it apart. Just off the top of my head I can see:
- Need some sort of user storage
- New UI for authenticated users, might spill out across the entire store system
- Data privacy
- Connect the stored user data to our fulfillment system
- Need to make sure the old non-account system keeps working
- How do we expose this new account to customers and get them to sign up?
Your goal in building Rally Points is to define the specific step forward, and where you will meet up with the whole. By linking the scope to a single iteration, you can make sure that people are thinking about these things a single steps rather than larger constructs. The larger your construct for work where you are defining actual work, the more likely your teams are to get lost along the way.
If for example your company had for another product already implemented a user account on another product, and was pretty happy with how it turned out. The team might want to build on that knowledge and experience, even if they can't re-use the code/systems. They might sign up for a Rally Point like:
This iteration we will setup a basic login flow in UI and back end service in our internal development environment. This will include the UI to login, the authentication service, and a simple new account creation UI. We will put a temporary user store in place, but not create the full schema for the user profile. This will let us create users and make sure people are authenticated to their account in a secure way while we experiment with UI in the future.
You can think of it as a sort of theme for the iteration. This statement should include things you will do, things you won't do, and it should have areas called out where you plan to do less than production ready work. Hold to, or improve on whatever standards you have in place for definition of done, and production ready. For some teams this may mean a release, for others who are covering very new ground it may mean something short of that. Bias towards release, but don't be so pedantic that you don't recognize that some highly valuable work may need several Rally Points completed before it sees the light of day. All of them should at minimum get a release to a development environment, sufficient to let other people see and touch it internally.
You could theoretically have multiple Rally Points per team in the same iteration. Either set up in parallel with small sub teams tackling each one all at the same time, or in series with the whole team working to get to each step along the way.
This is another one where you don't want to bite off more than you can chew. Most teams should have a fairly good good idea of what they can accomplish in a single iteration, and if they are wrong it's likely to have a low margin of error.
Rally Points can only be set by the team of people who are going to do the work. That commitment is at the heart of any kind of predictability or consistency. Teams should be expected to post/share their Rally Points wherever things are highly visible for your company. You should find time to read every team's Rally Points, it's how you will make sure your work is aligned, and that yo know what's going on across the product/organization. Keep them short and sweet, but pay attention to them, and talk about them.
Next up: Get things done, do the work
Subscribe to partialSignal
Get the latest posts delivered right to your inbox