dgoerlich
Technical Stories in Agile Software Development
I just read this interesting post on technical stories by Jack Milunsky. In the article he addresses the question of “Should technical stories appear on the product backlog for a Scrum project?” For billable client projects, a related question exists of “Are technical stores billable to the client?”
The answer to both of these questions is yes. Technical stories represent efforts necessary to improve the infrastructure of a system. While they do not add value to the system through the addition of new or refined functionality, they do directly add value to the system in other ways.
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.
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.
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.
How to build a Gantt Chart with the Google Charts API
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 the addition charts to Simpli5 and other applications as simple as possible.
An application we are developing for a client requires some graphic representation of progress along a timeline of multiple steps. A Gantt Chart is the obvious best solution, but alas that is not a chart type available from the Google API. However, a Gantt chart is really just a special type of bar chart, and bar charts are available in the API. So the question was, how can we make the standard Google bar chart display as a Gantt?
The Google Charting API Developer’s Guide does an excellent job documenting the “how” side of things, so to avoid repeating a lot of stuff from there, we’ll just focus on the “what” of building a Gantt chart with Google.
Bridging the Gap Between Compile Time and Run Time
As the lead systems architect here at Designing Interactive, I enjoy reviewing new code patterns to see if there are areas in our codebase in which they could be implemented. Recently I spent some time digging into Martin Fowler’s Active Record pattern. While a direct implementation of this exceptional code pattern doesn’t fit within our Sandstone Application Framework, I was inspired to review how we have implemented our business entity classes to see if we could implement some of the more fundamental concepts of the Active Record code pattern.
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…”