How can I get my startup working with Agile development?

Question

In our startup, we've worked until now using the traditional waterfall model, but we want to try our next project using Agile Methodology.

We are pretty much alien to the entire Agile process, so considering this, what is the best way to understand Agile (resources and a practical handbook can be of help), decide on a specific methodology (Scrum, etc), and start it in our next project?

Answer 1

You have said that you want to adopt Agile because it decreases the time-to-market and increases the productivity of your developers, so I'd like to focus on those particular aspects.

Time to market

In traditional Waterfall products, stakeholders only get one chance to sign up for requirements. In Agile, you can produce a much smaller vision and then add additional requirements afterwards. That's your best way to get to market quickly. To do this, you'll need to ensure that

• your codebase remains easy to change
• you can deploy your code easily, repeatably and reliably
• your stakeholders are prepared to engage and talk about what they truly need, instead of what they want.

So you'll need to do a bit of educating your stakeholders. Read around subjects like Story Mapping and Feature Injection, and talk to them about what they'd like to get from Agile. Bear in mind that the certainty they used to get with Waterfall's analysis won't be there (if it ever was!), but they'll get more chance to change their mind and shape the direction of the product, instead.

For the practices which will help you keep your codebase easy to change, I suggest Kent Beck's "XP Explained". Also look extensively at TDD, BDD and Continuous Integration and Deployment.

Having showcases to your stakeholders within an environment that's as close to production as possible really helps. I recommend doing this every two weeks. If you find it's very easy to deploy and your stakeholders want more engagement, you can shorten iterations to one week. If you find it's very hard to deploy, make sure that you can get feedback in some form every two weeks - even if it has to be on a developer machine - then release every month or two if you can. While you're doing this, work out what's making deployment so hard and start automating that. If there are political bodies stopping you from deploying regularly, work out what you might be able to show them to shortcut their gatekeeping processes, and see if you can move them into a role where they educate the team and continually check instead of having one big check at the end.

Increased Productivity

Agile isn't really a way of getting developers to do more work in less time. Instead, developers have less rework, less wasted effort in terms of work done "just in case", and a more collaborative approach that lets them learn from each other and from the rest of the team.

Having the team co-located is the single biggest factor in enabling this to happen, IMO. Developers have to be able to collaborate with testers to find bugs early, while they still remember how to fix them; with analysts so that they can question any part of the requirements they don't understand; and with each other so that they can share new ideas, designs, and things they learn. Most of the XP practices, especially pair-programming, collaborative code ownership, and TDD, will reduce bugs and therefore rework too.

A warning about Scrum

This applies particularly if you're using estimation and velocity measurements.

A lot of what you're about to do will be new to you, and it'll be hard to work out to start with just how long things are going to take. If you start using estimates and velocity measurements to track the work, the estimates might be quite a way out to start with. This is normal.

Scrum also doesn't mandate any technical practices which will help keep code easy to change. For the things you're after - time to market and productivity - those technical practices will be essential. For that reason, please don't just put Scrum in place - also start adopting excellence within your development work, and flex your process around that. You'll get a lot of benefits just from having higher quality, collaborative code and a high-learning environment.

Coaching and training

It's highly likely that you'll run into problems. I've only met one company who self-coached from a couple of CSM classes, and they had an amazing culture. Don't be afraid to ask for help, and read extensively. Scrum isn't the only methodology out there and you may get ideas from other sources too.

Answer 2

For agile book read. I would strongly recommend hiring someone with experience in agile projects. Also start by reading agile manifesto

Answer 3

I like the approach outlined in Jim Shores book.

He recommends that the organization spend one hour per day, for a week or two, learning the values and practices of XP. He calls it études, and the idea is to read about an agile subject and then discuss it in pairs while being time boxed to a certain time answering certain questions (how is this new to us? what might be a problem with it? etc). Eventually people should begin to grokk it and be able to make an informed decision if agile seems like a good idea or not.

I've personally used this approach and it worked very well. I like that it introduces people to agile practices (time boxing, pairing, collaboration) which might might be just the kick-start your organization need.

Answer 4

I have found a lot of great guidance in the presentations from the NDC2011 conference: http://ndc2011.no/agenda.aspx?cat=1071&id=-1&day=3726 look for the Agile tags on the schedule. As for how to get started. Start with something small, preferrably a project that will be targeted for internal use of your organisation. That way you have more insight in the effects and choices you have to make to make the process work for you.

Answer 5

We are pretty much alien to the entire Agile process, so considering this, what is the best way to understand Agile (resources and a practical handbook can be of help), decide on a specific methodology (Scrum, etc), and start it in our next project?

Of course, do what everyone else here has said and start reading/learning.

Beyond that, don't pick your "next project", pick a project that will succeed using agile methods. To succeed, the project must be small in scope, have low risk, high customer value and is achievable. The team should be small, co-located and willing to embrace change. You must also have automated processes (especially build & test) in place.

Once you have those things, set the team up to succeed by: have an excited customer committed to partner with the team for continuous feedback and open communication. Make sure the product owner is willing and able to articulate what the customers need and prioritize what should be worked on first and what should be worked on next. Then have the team deliver a build weekly to the customer/PO for their acceptance and feedback.

What I described above is only part of what you will need to know but it's the essential parts that will lead to continued and sustainable success.

Answer 6

I wouldn't start with the "I need to do agile" point of view.

Instead, look at your existing process and see how you can fix issues that you see. Continuous improvement, starting with what you are currently doing, is the key IMHO.

Why? A lot of "standard" agile process isn't well suited to a startup (funny as that sounds).

Instead, pick and choose practices that help solve your current problems, and plug in practices one by one as and when you need them.

At a meta level:

• Focus on feedback. A startup lives and dies on how well you can respond to user feedback and how well you can iterate. This means being able to quickly develop a feature and put it into production. Choose practices that help you build faster and deploy easier.
• In a startup 80% is "what to build", 20% is "how to build". Focus on practices that help you decide "what to build"

At a practice level:

• Investigate user story mapping. This is a technique that allows you to understand the scope of what you are trying to build. Very useful for keeping in mind the vision and the "big picture" of what you are doing.
• Automated testing is a good idea. Learn about unit testing frameworks like jUnit etc (there is one such framework for every programming language, google " unit testing").
• Focus on one feature at a time. Don't build multiple features in parallel.

And if you read a book or attend a training on scrum or agile, then these are the parts that I wouldn't use

• Estimations: A startup rarely needs to do long term planning or roadmaps. Even a 3 month roadmap is likely to get out of date. So dont bother with estimations, its just a waste of time. You will hear about story points and all sorts of complicated things. Just forget it all.
• Iterations/Sprints: Too much overhead for startups.

Instead, I'd do something like this:

1. Get a piece of paper. Write down the features you want to implement (these can come from the user story mapping technique I mentioned above)
2. Pick one feature that you want to implement next
3. Everyone works on this feature
4. Deploy the feature
5. Look at the user / customer reaction
6. Go back to the story map / feature list with your new learning and make changes to the story map / feature list if needed
7. Go back to step 2
8. Once in a while see how you can improve. What problems did you have, and do you need to do anything differently, or add in new practices.

Thats it! You're agile now :)