At InCrowd we use the Agile Methodology, aka Scrum, aka “anything but Waterfall” in our software development. The usefulness of these practices extends beyond making software. InCrowdAnswers, the product we build this way can also help you to become more Agile, more responsive to your customers.
There are twelve principles to the Agile Manifesto, but really only four main values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Despite this, volumes have been written about how best to interpret these simple tenets, as a search of Amazon for “Agile” will reveal. Agile, like a religion, is all about the interpreters who follow (both temporally and ideologically) its principles.
Scrum is the best known of all the Agile sects, and is the one we follow (mostly) in the InCrowd Engineering department, and to some extent elsewhere in the company. Scrum, like the crowd following the juniper hermit in Life of Brian attempts to read the Agile signs and come up with something concrete that you or I can do to be more Agile. Among those things are the titular scrum: a daily meeting held standing up (here come the ascetics), at which all members of the scrum team answer three questions:
- What did you do yesterday?
- What are you going to do today?
- Is anything blocking you?
Since a scrum team is usually less than seven people (making it easy to be all about “individuals and interactions”), these meetings shouldn’t last longer than eight or ten minutes, which makes them a great way to realign and energize the team while communicating essential information, without wasting everyone’s time. Shorter, more effective meetings: what’s not to like?
The sprint is the period of time during which a team works on pre-planned goals. At InCrowd our sprints are two weeks long, but you might choose a longer duration. We spend much of the first day planning in detail what we aim to accomplish during a sprint; the last day of the sprint is often the time to demo the working code (“working software over comprehensive documentation” – the proof is in the pudding) we have made during the sprint, and finally retrospect about what went well, and what we could do better.
Planning is the key moment where we need data to back up our ideas about how a given feature should work. We often reach out to stakeholders. You might want to use InCrowdAnswers to quickly get in touch with your customers – do some research to back up a hunch.
The sprint is finite, and it’s always the same length. This gives us the opportunity to learn from what we’re doing, and promotes the discipline of breaking features down into parts that we can accomplish during a single sprint. The looming demo keeps us focused on the goal of a working product.
We don’t do retrospectives as much as we used to when we were starting out as a team. I think this is a sign that they have worked well. A retrospective is like a Vegas weekend in that it’s exclusively for members of the scrum team, and what’s said in a retrospective stays in the retrospective, and shouldn’t have consequences outside of it. Done right it’s a democratic way to both clear the air, and allow the best ideas about how to work to come to the surface.
“Customer collaboration over contract negotiation”, one of the four Agile principles, might seem less relevant to an in-house software team, but we interpret as “involve the stakeholder in the design, build and testing phases of a feature”. This is just plain good sense. We might be expert in software development, but the chances that we are also subject matter experts in panel integrations, or survey design, are close to nil. Involving others from around InCrowd in the design, having them on-hand for questions during build, and requiring them to accept (or reject) the finished product brings greater knowledge to the work we do, and promotes our work throughout the company. If you’re in the business of deciding on ad copy for promotional material you might want to involve your stakeholder: the customer.
I mentioned earlier that Agile is at work elsewhere at InCrowd. This can be harder to see, but there’s a trend towards shorter, more focused meetings resembling scrums, and a movement away from rigid advanced planning towards more general themes that are planned in detail closer to execution time. Having stakeholders and experts from around the company participate in our Agile process has been the main driver of these changes. Agile may not be so appropriate for areas like sales and client services, where staff tend to be reacting to client requests, but for overall company planning it makes a lot of sense, if only on a longer time scale: as a startup we are constantly learning from what we do, such that having a rigid plan for six months hence often makes little sense. As they say in Agile: “responding to change over following a plan”.
Software is taking over the world, taking the friction out of work processes everywhere, freeing up skilled people for higher value tasks. With the amount of money pouring into software development, some of the best process thinkers are trying to figure out how to do things faster, better cheaper, to gain a competitive advantage. Most industries can benefit from this innovation. If your enterprise has an end product and a customer, you too can benefit from just-in-time planning, wider stakeholder / customer involvement, and from examining your own processes in order to adjust and improve them.
InCrowd’s customers benefit from the removal of friction between the questions they have and the answers they need, to keep their product development and commercialization moving forward without delay. This new agility allows them to get a continuous understanding of the market and relevant issues, giving them the opportunity to apply that knowledge in real time to current business problems. .