Tag Archives: agile
How to build a Lean product and UX (with examples)
I’m a big fan of the Lean philosophy for building things: businesses, products, user experiences, software, etc. This is one of the reasons I help organize the Lean Coffee meeting in SF (Tuesday mornings, come out and join!) Simple prototypes can be used to test things, rather than building a complete first version to validate an idea (which produces Waste, which Lean is designed to avoid).
This is why I’m so pleased to see my friends at Lumatic (the company formerly known as Omniar) taking advantage of this for their product and UX.
They built a static HTML version of the product that simulates many of the user interactions and the interface. At the end, they use a free survey from SurveyMonkey to collect feedback. Even better, they’re building a mobile app, and have still prototyped using HTML.
Posted in agile development, best practices, Business, testing
Tagged agile, lean, product development, testing, user experience, UX
1 Comment
What do comic books and Agile have in common?
This year, SXSW is premiering a new film, Kick-ass. If it sounds familiar, it’s because it is based off a comic book of the same name.
This matters because it’s another comic book in a long line of comic books that are being turned into artistically good and financially successful movies. There are so many of them, a whole community has formed around the comic book/movie duo.
Why are there so many, and why do they do so well in theaters? It’s all about minimum viable products, and iterating.
Posted in Uncategorized
Tagged agile, comic books, kick ass, minimum viable product, SXSW
Leave a comment
Working software is the primary measure of progress
The 7th principle of the Agile Manifesto is:
Working software is the primary measure of progress.
Let’s talk what this principle means in real projects, and then get a bit more general as to why it’s good.
How does this principle show up in a real Agile process? There’s a concept we call “velocity”. We assign velocity points for new functionality — not tickets completed! The danger of using “tickets completed” as a proxy for project value is that fixing a bug means closing a ticket. But, fixing a bug means the original ticket wasn’t done right, a.k.a: the software produced wasn’t “working software”. So, if someone spends a day setting up user avatar uploads, they’ve gotten 2 points of velocity. If someone spends a few hours fixing the login system because it was supposed to use emails instead of usernames, they get no velocity points.
Posted in Uncategorized
Tagged agile, estimation, principles, software development, velocity
Leave a comment
Agile Principle #5: A team of motivated individuals
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
This Agile principle is such good business advice, I could approach it from many other non-Agile directions. It almost transcends business and applies to all human endeavors.
Starting with the motivation issue. Larry Bossidy, one of the world’s top CEOs, says that when hiring, a person with absolute determination to succeed will always do better than someone with a high IQ and elite education who is cruising.
Agile Principles #4: Product Owner and Engineer relationships
Time for Agile principle number four, where we talk about the relationship between product owner and engineer:
Business people and developers must work
together daily throughout the project.
In the post on agile principle number two, I gave the example of a Secret Santa management system, as an example of how being able to accommodate changing requirements can benefit a project. As a refresher, here’s the key story points of the project:
- A user should be able to sign up
- A user should be able to log in
- A user should be able to get a recipient assigned
- A user should be able to add notes to their recipient
Posted in agile development, team cloudspace
Tagged agile, engineers, product owners, Project management
Leave a comment
Agile Principles #3 – Be Quick
My last two posts have both had the word “dodeca-thalon” in the first paragraph. Dodecathalon means a series of 12 things. Those 12 things are the 12 Agile Principles. So far I’ve covered the first two. If you haven’t read them, please do. And then, read this one, #3.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
As I mentioned with the last principle, we welcome change. We count on change happening, and we use it, Judo-style, to our advantage. But, part of the success to navigating change is feedback. You need quick feedback. And, when you’re developing software, feedback comes from delivery.
Posted in agile development
Tagged agile, deployment, Management, rails, requirements, verification
Leave a comment
Agile Principles #2 – Change
In my last post, I said that I was committing to a dodeca-thalon of posts on the Agile Manifesto — one for each Agile principle. I think this is great stuff that everyone should be exposed to. If you use Agile, or wonder why people are so hot for Agile, this series is for you.
And with that intro, here’s #2 of 12
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Everything changes. Software is not set in stone, and even if it was set in stone, it would still change. So, we need a process that gracefully handles change. Part of this trick is by getting rid of the idea of a 12-week project, and instead having 12, 1-week projects. You want to have small, frequent plans.
Posted in agile development
Tagged agile, Agile Manifesto, Agile software development, Secret Santa
2 Comments
Agile Manifesto Principles
If you’ve never read about the Agile manifesto, you should. It represents the absolute cutting edge of the software development industry.
I’m starting a 12-part series of blog posts on the Agile Principles, discussing what they mean, and what they look like in the real world. It’ll be like an Agile dodeca-thalon.
Welcome to #1 of 12.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
What we mean by this is that above anything else we do — above code formatting, testing, meetings, planning, sometimes breathing — our #1 goal is valuable software. If we’re not delivering value, we have no reason for existing. “Business value” we often call it. We always focus on delivering the most business value possible given the amount of time we have. Sure, the spinning cornflower blue logo is hot stuff, but we’re going to focus on the authentication system first.
Review plans every day, or “The Next Episode”
In the last episode of “Cloudspace does Agile,” I talked about the weekly meetings. I also promised a post about the daily meetings. Here you go. And of course, feel free to comment on this post, or get in touch with me if you’ve got questions. tim @ my company’s domain dot com. (Darn spammers!)
This will be a quick post. Not because I’m lazy, but because I’m making a point. The daily meeting should be quick.
Ever heard the term “stand up meeting”? It’s because people literally stand, so they don’t get comfortable in cushy executive chairs, and drag meetings out. 5-10 minutes tops.
Top 5 Attributes of Talented Developers, or “I didn’t come up with this title”
Top 5 Attributes of Talented Developers
I think this list should also include “being self-motivated” (as a subpoint of #1), and “keeps up with changes in their field” (as a subpoint of #5). Although, this is coming from Isaac Sacolick, the VP of Tech for BusinessWeek, so I’m sure they have 3-week training seminars for developers at a retreat in the woods every month. 