So you have read The Lean Startup. Suffered through following several agile blogs (such as this one). You think you are ready to join the cool kids and have product scrums and stand-up meetings and all that other stuff. Now you need an implementation plan.

Maybe it is time to read this post by Paul Adams on the Intercon blog. He describes some of the lessons he and his development team have learned from building software and scaling it up as the company grows. I asked a few of my contacts at startup software firms what they thought of the post and there was mostly general agreement with his methodology.

Here are some of Adams’ main points to ponder.

Everyone has a different process, and the process itself changes as the company matures and grows. But his description is for their current team size of four product managers, four software designers, and 25 engineers. Like he says: “it’s not how we worked when we had a much smaller team, and it may not work when we have doubled our team.”

Create a culture where you can make small and incremental steps with lots of checkpoints, goals, and evaluations. “We always optimize for shipping the fastest, smallest, simplest thing that will get us closer to our objective and help us learn what works.” They have a weekly Friday afternoon beer-fueled demo to show how far they have gotten in their development for the week. Anyone can attend and provide comments.

Facetime is important. While a lot of folks can work remotely, they find productivity and collaboration increases when everyone is in the same room in a “pod.” Having run many remote teams, certainly local pods can be better but if you have the right managers, you can pull off remote teams too. It appears IBM is moving in this “local is better” mode lately.

Have small teams and make them strictly accountable. Adams has a series of accountability rules for when something goes wrong. Create these rules and teams and stick by them. “We never take a step without knowing the success measurement,” said one friend of mine, who agrees with much of what Adams says in his post. My friend also mentions when using small teams, “not all resources have a one-to-one relationship in terms of productivity; we find that we that the resources we use for prototyping new features can generally float between teams.”

Have a roadmap but keep things flexible and keep it transparent. “Everything in our roadmap is broken down by team objective, which is broken down into multiple projects, which in turn are broken down into individual releases,” said Adams. They use the Trello collaboration tool for this purpose, something that can either be a terrific asset or a major liability, depending on the buy-in from the rest of the team and how faithful they are to keeping it updated.

However, caution is advised: “The comprehensive approach that Adams describes would be entirely too much overhead for most startups,” says my friend. This might mean that you evaluate what it will take to produce the kind of detail that you really need. And this brings up one final point:

Don’t have too many tools, though. “Using software to build software is often slower than using whiteboards and Post-it notes. We use the minimum number of software tools to get the job done. When managing a product includes all of Google Docs, Trello, Github, Basecamp, Asana, Slack, Dropbox, and Confluence, then something is very wrong.”

Google Docs is a favorite way to build applications for lightweight data manipulation, reporting, and analytics as well as useful for building websites that can capture and display data. While it is a great tool to get started using an online all-purpose office suite, you should also know its limitations and when it is time to move on to something more industrial strength. In my post for Quickbase’ FastTrack blog, et’s look at what is missing and when you should move on.

Many of us started out with database software with something like Microsoft Access. It was part of the Office suite, fairly easy to get started and infinitely customizable. However, it might be time to look elsewhere for alternatives, especially for citizen developers who want to build more sophisticated online databases. Here are some ways to recognize the warning signs and to start thinking about its replacement.

First, Access was designed as a personal product, where one developer creates an entire application from scratch. If your need are more collaborative, or where you have a database where multiple people input information, Access isn’t the best solution and this is where having a SaaS-based app shines. Using an online product like QuickBase means you don’t have to worry about setting up a server and worrying about when more than one person is inputting records: this is handled automatically for you.

Second, when non-Windows computers are using your database it also might be time to switch. While there are now versions of Access for Macs and iOS, not everything that is developed for Windows versions works across platforms. It might make sense to build your app with something that natively speaks the Web, or that has the exact same look and interface across all versions.

Are you heavily involved in using Visual Basic? This was the underlying programming language for Access, and while it has a large ecosystem that Microsoft has done a great job cultivating, it might be costly to maintain and to hire the appropriate skilled staff to continue to build VB apps. Look at ways that you can build your apps without a lot of programming expertise, or that make use of Web-based forms and templates that can accomplish many of your tasks quicker, and with lower cost of ownership.

And when your users span the globe and are working on the same app, it also might be time to retire that Access project and find something more flexible and more comfortable working in a distributed environment.

When you can’t find your favorite command or function, thanks to yet another UI “improvement.” Tired of Microsoft re-arranging the menu ribbon yet again? It seems every major upgrade of Office comes with a new interface. Now Microsoft touts a “feature” that helps you find your favorite command.

Nearly 30 years ago, Lotus Software came out with a radical new tool called Notes that has since become a corporate staple. More than an email program, it was used by IT and non-IT alike to build collaborative apps. Think of it as the origin of the citizen developer movement.

But Notes has stalled and many corporations are looking to move on to something else. You can read my post on QuickBase’s FastTrack blog here about what can citizen developers do to get the decommissioning party for Notes started.