Workflow – Minimally Marketable Features
As I described in the overview of Our New Development Process, the MMF (Minimally Marketable Feature) workflow is the customer facing portion of our development process. Our changes in this area have had the biggest impact upon our clients, and have met a positive response. It has allowed us to isolate our clients from the implementation, and remain focused on the behavior of their application.
Our transition to a lean development process was the first exposure most of our clients had had to any type of agile environment. Understandably many of them felt out of their element and truthfully we felt the same way. What really made the transition successful for us and our clients was the trust that came from the good relationships we’ve maintained. Being very transparent with our clients went far in cementing that trust. We let them know that this was a major change for us too, that we were (and still are) learning and refining our process. Since our clients are very much part of the project team, I openly solicited input from them on how we could improve the process.
New Years Resolutions are for Lazy People
New Years Resolutions are not agile.
With the new year upon us, it’s that time to make our resolutions. But, why do we wait to do this at the beginning of the year? If change is needed, make the change now.
I came to realize the problem with this a month ago (beginning of December). I’m a typical geek. I sit in front of my desk for about 12 hours a day, and most of my exercise comes from walking to the restroom down the hall. Needless to say, I’m not a perfect specimen of health. I’m not fat by any stretch, but I’m not in shape and I could eat healthier. So, like many I decided to do something about it this year and make “focusing on my health” my resolution for 2010.
Except for one small problem. I needed change NOW, not starting in a month. Waiting a month to start to change would make my problem worse. Suffice to say, I joined the gym that day and today (Jan 1), I’m already feeling much better.
Our New Development Process
In Agile Development for Tiny Teams, I presented an overview of our original development and project management process. I highlighted a number of challenges we encountered by using it. Thanks to Jon Stahl, Josh and I were exposed to the application of Kanban to the software development process. I was convinced that Kanban was the right tool for us. However, the question of exactly how to implement it as part of a new overall development process remained.
We determined that our new process needed to be:
- Simple – Being a tiny team, the impact of time used managing the process rather than used generating billable work product is magnified.
- Able to handle concurrent projects – We needed to be able to support ongoing development needs of current clients while continuing to develop new clients and projects.
- Scalable – We will add subcontractors to our team as needs arise. Our new process must work regardless of the team size. It also needed to be easy to teach to new team members.
- Flexible – In addition to client work, Josh and I are partners in Prfessor.com which includes a significant amount of development efforts. The process needed to be flexible enough to manage these obligations too.
- Waste Reducing – We needed to address the four top areas of waste that I identified in our original process (see Eliminating Waste from Your Agile Process)
- Work In Process (more than the bare minimum necessary)
- Rework
- Over-engineering the code
- Repetitive tasks
From Jon’s presentation I realized that we really had two separate workflows, one nested inside the other. We never formalized that distinction, but when we began to view things in terms of MMFs (Minimally Marketable Features) the nested process jumped right out. Understanding this nesting was critical to the success of our new process.
Codemash Presentations That You Won’t Want To Miss
The Codemash Conference is coming up again this year in just a few weeks. It is always my favorite conference of the year, bringing together a diverse crowd of developers to learn practices from each others industries.
I have compiled a list of talks that I know you’ll enjoy. Some of these I’ve heard previously, and others are presented by people that are always interesting/entertaining.
Can I make a living as an Entrepreneur?
I have a difficult time explaining what I do to my grandfather. He bears his skeptical face when I tell him that I’m an entrepreneur on the internet.
“Trying to strike it rich, eh?”
Truthfully, I don’t think he understands how I feed my family, but that’s ok. But, this story does bring up a question that’s raised all the time among prospective entrepreneurs.
Can I strike it rich if I go on my own?
My response is always “yes and no.” Chad Moutray, the Chief Economist of the Office of Advocacy of the U.S. Small Business Administration, published some of his research on the income likelihood of entrepreneurs. His research backs up my response nicely.
Eliminating Waste from your Agile Process
A central pillar of a lean software development process is elimination of waste. So what is “waste” in a software development process? In a manufacturing process, any amount of work in process above the bare minimum to meet production levels is waste. Keith Swenson recently wrote an an excellent article “Taiichi Ohno Reinterpreted” where he observed: Continue →
Agile Development for Tiny Teams
D-I is proud to be a tiny firm. We have always been a tiny firm, but we haven’t always been able to get big projects accomplished. While we do use subcontractors quite often, the firm is still just Josh and myself.
We believe that software should be high quality. It should be efficient, tested and intuitively designed. When it comes to features, enough is enough. We believe you should build what you need, and nothing else. We also believe that the process of developing the product is as important as the product itself.
10 Tips to Better Google Wave Conversations
Jonathan Penn and I have had a number of enlightening conversations about Google Wave which have had a significant impact on the way we converse through Wave. After reading an entry on his blog, Hardware Limits of the Human Mind and conversing with him some more, I’ve invited him to share some tips we have come up with.
Search
Popular Posts
- 50 Tips To A User Friendly Website
- My Favorite Pomodoro Timers
- How to build a Gantt Chart with the Google Charts API
- Why Flash is Mostly Bad
- Sharing the Grid
- 10 Tips to Better Google Wave Conversations
- The difference between User Research and Usability Testing?
- How to Label Submit Buttons
- Our New Development Process
- Paper Prototyping vs. Balsamiq Mockups
Latest Comments
- Nate Klaiber → “ The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual. While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain…”
- Joe Fiorini → “ The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual. While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain…”
- Roger F Carver → “ The Google Charts API is an excellent way to add high quality charting to your web application. We first started working with the API as part of the Simpli5 dashboard development, and were quite impressed with its functionality and ease of use. Wrapper classes were developed and added to our Sandstone Application Framework to make…”
- Nate Klaiber → “ The “I agree” checkbox has become an interface standard on registration forms. “I agree to the terms and conditions.” While it’s purpose is generally understood by the consumer, it is a key source of frustration for people registering for accounts. eBay's Registration, as an example Why it’s overlooked: Checkboxes are small, particularly ones which aren’t grouped…”
- Josh Walsh → “ Most of the value you gain from a usability testing session comes from the analysis after the session is complete. I have been involved in a few sessions recently where no formal analysis has been conducted. I believe this is a mistake. Traditionally, the analysis portion of a usability session takes quite a long…”