Regardless of what kind of team you have, it is a given that if you keep the wrong focus you are going to be in some kind of trouble. It is very important for a team to have a clear understanding of the project’s goals and constraints. That sounds like PM-speak but it’s not only relevant for business/management side of things but for the technical team as well. I’ve been to many projects in big trouble just because the technical team focused on the wrong goals.
In short, there are three things that I think all software development teams should be obsessed with:
1 – What does “Done” Mean?
The whole team has to get a shared understanding of what done means. This must be defined by the team, including non-technical people and it is expected that no one accepts half-baked software.
This is not about test coverage or any other metrics. This is about having software that does what the user wants with the quality that the team considers acceptable.
One practice that I’ve used to help make this process more straightforward is the Sandwich Model for stories. Before a card is played the users, BAs, QAs and developers get together. The user and/or BA present the card to the technical people. First questions and answered and acceptance criteria is defined. After the developers finish the card they perform a walkthrough with BAs/users and QAs so that they can verify if it looks like Done. If more work is required the developers get back to work, if the card was accepted it moves to the next stage.
Other practice, one that I would expect all teams that call themselves Agile to follow, is to always have Potentially Shippable Software, from day zero. Unfortunately it is very common for teams to have a product that can only be tested in a development environment and can’t be deployed to a server or workstation.
I am not saying that you need a fancy Capistrano deployment script or to make your application WebStart/ClickOnce ready. What I am saying is that there must be an easy way to install and run your application in a production-like environment -and production like probably means no compilers, no build tools and no damn Visual Studio.
An user story is only done when it can be tested in the production-like environment, before that it is only “90% Done”.
2 – Flow
After deciding what Done means, the team should be concerned about how fast things are getting there. Agile software development is based on short feedback cycles. When cards move from Doing to Done at a reasonable Velocity you empower the stakeholders to make the right business decisions. When changing is cheap you can delay technical commitments until you have enough information to make your decision. If you don’t have a short feedback cycle you may be iterative and may be incremental but for me you are certainly not Agile.
Feedback cycle is often related to technical issues and the team must make sure that those issues are not slowing it down. My main metric on that is the Rule of The Second Card: The first card played on a given area of the code base is expected to take a long time. The second card should take at most half of the first card’s time.
This is just a rule of thumb but it helps measuring the pain. The first card played in a new area will always require a lot of thinking and learning. Even when the simplest solution is implemented I expect it to take longer as people learn how to connect the dots –remember: it’s about the Simplest solution, not the Hackiest.
The second card shouldn’t take that long. User stories represent small chunks of change and the second one is often just an addition to the first (e.g. First is “User should search by state”; Second is “User should search by state and city”) and if the first card was played with reasonable quality standards then we can only expect that it has built the scaffold for the second card.
If your second card takes about the same time as the first one -or even longer!- then your team may be in trouble. It may be that the pair playing the first card took too many shortcuts in order to get the first card delivered and produced a lot of technical debt. If it becomes clear that this is a common pattern in your project you guys should sit down and work out what is happening.
Another thing to pay attention to is the build time. The build is the main feedback cycle for a developer; builds should not be long and should not fail for unknown reasons. There are many techniques one can use to keep build times slow, we are going to talk about them in future posts.
One level above the build time is how Continuous Integration is done in your project. Julio Maia has a very interesting article describing its importance.
3 – Readability
It may be odd to see this as the third most important thing in a blog from someone that works for ThoughtWorks. I do believe that writing code that is readable is extremely important, I just don’t think that, in a project, it comes before the two other topics we previously talked about.
The Tech Lead should make sure that the code being written is readable by people that have enough knowledge. What is “enough” means depends on who you ask but for me there are at least two groups in this situation:
- People that are proficient in the programming platform (e.g. Java, .Net, Rails, etc.) but not necessarily in the domain
- People that are programmers, know the domain but don’t master the platform used in that system.
There are multiple ways of doing that. In ThoughtWorks we love to have people coming to our projects and working with us for a couple of days. When a skilled ThoughtWorker has trouble trying to understand the code this is a very bad sign and we need to work on that. I’ve heard about people that are going even further and asking for people from other companies to come and pair with the development team for some time.
Everything is Connected
The items above are presented as three independent units but that is not the case. There are many dependencies between items and they become clear as you start thinking about them.
Of course the list is not exhaustive, there are many other technical aspects that must bee considered in a project, but in my experience if you get at least those three right it is much more likely that your project will be in good shape.
Great post Phillip. These 3 items are surely very important to build a good quality software.
BTW: “it’s about the Simplest solution, not the Hackiest” -> very good sentence!
Great article!
One thing I do different is that I do count spike in velocity.
Even being time boxed, I always consider a spike to be sized as the smaller sized being used (typically a one story point). The reasons I like this are: (1) if the spike is too small, it is not even created and done as part of some Story, and (2) if the spike is too large, it is broken into smaller spikes.
At times I prefer to use Set based design instead of having a spike. I like set based design when I have to make design based on a set of alternatives. The design alternatives are developed as tasks in a story, and its effort are considered while estimating.