Blog

QA and the Art of Speed

The good news is that we’ve been making great time on some of our development. The bad news is that our current process didn’t really have any QA baked into it so some of the cards that were approved by my CTO, didn’t really fully map to the requirements I drafted.

Humph.

It’s not a big deal, but I have currently working thru how to do requirements QA into our work processes so when we consider an area done, it’s really done.

I’m going to add a QA subtask for each item and then run the user test scripts. Then, I’ll create defects against the cards.

I’m trying to decide if there are new cards or just subtasks. Unsure at the moment.

The Mysteries of Jira

I am by nature or now-a-days habit a planner and organizer and I love project management tools. Our Co has used Jira for years with varying degrees of success. I’m pleased to say that over the last six months we’ve been using Jira’s basic board design pretty successfully, but I know there’s way more than can be done.

Epics, other than for their grouping feature, are largely pointless in our current setup as are other features other than the basic issues.

We found a nice BDD testing plugin about three months ago, which has been working pretty well. And, once I decided to get the team to fully embrace using the acceptance criteria for requirements has been very useful. I’m no longer doing duplicate work.

Now that we’re moving to the publishing realm, I decided to take another look at the design of Jira. This time, it occurred to me that instead of putting everything into one project, I should set up different projects according to the feature set. Our KM will be one project, publishing another with account management and security also going into their own project areas.

Once setup, I’m then changing the filter for the main dev area to include all of these projects so we have one board. But now I can build out the story maps and issues in a more narrow area.

So far, I think it’s working pretty well.

No more big questions

Our CTO figured out how to do the second part of our software. We’ve understood the requirements and generally knew that it was possible to do what we wanted but until last week there was no definitive plan.

However, last week my biz partner cracked it. This week he’s running a back-end proof of concept, which I hear has been going very well.

Once the POC is over we can jump into more prototyping and development.

I know it doesn’t look like much but it is.

Dog Days of Summer

I get the impression my CTO may be losing a little steam in our development work. I guess it’s to be expected but as the one not burned out; it is a little frustrating.

We’re about 50% through the development with another big chunk needed, but things seem to have slowed down. He has until 7/1 to get things going again or I’m going to start looking for some support for him.

He’s very good and this isn’t a replacement; more of an augmentation. He probably won’t be thrilled but hopefully that helps him kick it into gear.

A week of prototyping

I took a week off of my real job so I could basically work a full week on just the startup. We’re nearing the end of our KM build and the publishing system was nothing but a few post-it notes and dreams.

The new part was so complex that I needed day-in and day-out focus to pull something coherent together. I’m thrilled to say that after nearly a week we have a really good prototype and agreement on how we’re going to approach the UI and feature set.

There’s still a bunch of work left to do before everything is ready for full requirements, but the really hard part of just thinking about how it should work is nearly done.

Power of Prototyping

I’m now starting my fourth or fifth version of one of our features via prototyping. The first versions were okay but didn’t hold up to our internal reviews either because it was going to “eff” our technical design or because it was to busy or confusing.

The nice part is that instead of burning a bunch of cycles in development, only to come to the same conclusion, we burned no dev time.

This latest version is good, but not great. However, it should get us through the MVP.

Nearing a Milestone

Our new software will be both knowledge management solution and publishing tool. To do this, have broken the work into three big stories: collect, cross-reference and publish.

The baseline collection work is done and starting next week we start deploying the cross-referencing (CR) capabilities. Collection and CR make up our knowledge management feature and then it’s on to search & publishing.

The publishing part is the trickiest but with the continued focus and extra manpower, we should have a basic setup in about a month. This leaves the rest of the summer to harden the code and prepare for deployment.

Back to Full Power

Our CTO’s “real world” work commitments are now nearly done so he’s getting back in the swing of things. He’s made more progress in the last three days then he’s made in the last three months.

This is super good since we’re running out of cards for our developer until he puts some of our next gen functionality. We’re making good progress and sans some major issue, I think we’ll be ready to review the app with outsiders by mid to late summer.

Evolution of “Agile”

I’ve been struggling with one set of requirements for a few weeks. The prototype is basically done but I have had a bunch of trouble pulling together the card due to the complexities of the user groups and conditional logic involved.

I finally realized I was trying to do way too much with the one card sometime in the middle of last Saturday afternoon (5, 6 hours into it). The moment I decided to split the cards, the requirements became a heck of a lot easier.

I didn’t want to add more rework to the developer if I could help it, but I have since realized I was probably adding a bunch of time to him trying to figure out what I was trying to convey.

Another lesson learned. On a happy note, my requirements are moving far quicker now.

Keep those Requirements Coming

Our development velocity has certainly picked up with our new developer. Of course, it’s hard to not pick up if one starts at near zero.

The biggest challenge now isn’t the dev and delivery, but ensuring we have decent requirements in place. I’m also finding that not all requirements are created equal.

A large part of the system are complex forms with a bunch of conditional logic while other parts are fairly static. The conditional logic forms take a bunch of time while the account management pieces are fairly simple.

Originally, we were just focusing on doing the collection area (complex) but in an attempt to give me some air cover we’re now doing two areas simultaneously. The account management piece along with the collection.

I’ve love to add a UI and requirements person to really increase our velocity without having to break my back every day / weekend but it’s a cost we just can’t justify. I do anticipate making that add in the near future and might look toward the ol’ unpaid intern route with a promise of opportunities in the future route.

But, for now we’re keeping those requirements coming one way or another.