So we’ve decided to work together. Good call.
Getting to know the people
First order of business is to get a feel for where the development team is at in terms of skill and workflow. Being agile is not about following a strict set of guidelines and rules. Being agile is about doing what works, and what works depends on context.
Getting to know the code and the business
Next up, unless this is a green field project, I’ll spend time understanding the codebase. Bugfixes and small features. In the process I’ll get an idea for where the business is and how good the communication lines are between stakeholders and production.
At this point I have a pretty good feel for the project and the people working on it. I’ll present work plans going forward, as sprint cycles, milestones, or whatever combination makes sense for the team.
For instance. . . .
The early stage startup, ready to turn the MVP into a product
Your idea is world shaking. The plan is perfect. The MVP does a bunch of what you’d like it to do. It’s also held together with twine and was hacked into Wordpress or glued together with IFTTT scripts.
Now there’s some seed funding and it’s time to build the foundation of your product. The decisions you make now will have reprecussions for the life of your business.
This is where I come in. There are a myriad of tools to choose from to build modern applications. The implications can mean:
- Having access to developers, even to developers that are willing to work for lower rates because they like the tech.
- Being optimized for scale, if that is truly a demand of your startup (it usually isn’t).
- Being optimized for productivity, allowing for rapid prototyping of new features.
These are the choices I am good at making.
The next step is building out your team, instilling the right code culture from the beginning.
As luck would have it, I can do a lot to help with that, too. Contact me
The agency team that needs to get across a new programming language or technology
The principal of a small agency approaches me because her developers are building a project in React and they seem to be struggling with it. They are capable and have a perfectly serviceable workflow. All they need is some information and a nudge in the right direction.
This is one of the few circumstances where I feel pair programming is appropriate. This team knows what they’re doing, they don’t have a sprawling codebase in need of surgery. All they need is some help and the total time spent is likely three to five business days.
The large corporation with a new project
Perhaps the project has been attempted before and a trail of dead lies in its wake. Maybe it’s a green field. In either case, the “getting to know you” phase can take between one and three weeks. This includes learning about the crucial systems that are a part of the company’s ecosystem.
The next step is fitting the demands of the business into a cycle that works for the development team. The business needs big monthly milestones? Fine, but the dev team can still work in short, one-week sprints.
The development shop with its biggest project ever
The team is smart but maybe a little inexperienced. The project is big enough to send a few shivers down the spines of the project manager. People are concerned about their eye to stomach ratios and things are only just beginning.
The “getting to know you” period in a situation like this is mostly about observing how a team works. What are the natural inclinations and personalities of the developers? How do they fit with the rest of the business, with the client managers and with the design team?
Given all of that, how can work be structured in a way that helps everybody succeed?
Designing a process for the team doesn’t happen all at once, especially if there wasn’t much of one to begin with. This is an organic event that takes place over the course of a project.
People talk a lot about reusable code, but a good development culture is infinitely more reusable.