A few months ago I posed the question to a vendor of mine — what do social media technologies have to do with software quality assurance? Does it even matter? I still think they are or should be connected but I don’t know exactly how. So, I am creating this post to hopefully generate some discussion and more ideas.
Here are some ideas I had:
1. Use microblogging technology (e.g. Twitter) internally within the dev team to quickly communicate what is happening real-time.
2. Could a test plan be a Wiki page rather than a document? I suspect this wouldn’t work in a regulated environment, but maybe not?
3. Use microblogging to ask quick questions to anyone on the team — might reduce email clutter?
4. Analyze social media traffic to determine how the customers are using the product being tested. Could this influence the direction of the test plan?
5. Microblogging with linking to point to specific issues in the team system (e.g. TFS) needing attention – maybe a defect, or a user story?
6. Other indirect uses: development team morale, searching microblogs for internal trends (create some retrospective ideas?), etc.
What connections do you see? Can’t wait to uncover some ideas!
The good news is that the product my team is developing is being adopted broadly within the organization. The bad news is that in the future in order for my software to be used in products subject to regulated enviroments we will not pass scrutiny. Seeing this problem out there on the horizon has inspired me to challenge my team to take the next step of the maturity journey and evolve our Agile/Scrum process. I am not an expert on the specifics of achieving compliance, but it seems to me it is pretty simple. Basically it entails documenting what is to be built, build what you say you will build, then show evidence you tested that you built what you intended. Also, involved is change management over the whole lifecycle. So if that’s the general process, I keep peeling the onion back and finding traceability at the root.
I brought this to the team, and we’re having some trouble getting traction on trying to improve our traceability story. The lack of action makes me wonder if I am asking for the wrong thing. How do the rest of you Agile-ites deal with traceability? Specifically, I am looking for the ability to look at the potential impact of change by knowing all stories impacted should we change a particular story. In the RUP, we had a neat little report called the traceability matrix. It was easy to see impact of changes.
Please feel free to share your tips to getting to a solid traceability story. Without it, I am likely shut out of some important business opportunities to “sell” my application into scenarios where regulation is required. Looking forward to getting some ideas.
In a perfect world, we’d like all of our Scrum team members to be fully dedicated and committed to delivery on a project. The reality is that scrum masters and product owners have to deal with less than perfect conditions under which they have to deliver high-quality software. It’s always the “other project” that prevents our resources from executing on the project we are managing. So, what do we do? I think there’s a simple strategy that can help everyone involved.
I recommend deliberately and consistently scheduling project available time. Let’s say you are 25% allocated to another project. In a 40 hour (yeah, right!) work week, which equates to 10 hours of available time to work on that project. That could be done 2 hours per day, or maybe one full day plus a couple of hours on another day. What that means is that during those scheduled times, you are unavailable to do anything but work on the other project – no meetings or anything – like you are not even there. Use your online calendar or team project management system to clearly lay out the schedule for the whole team to see.
Consistently following a schedule will help you time-box this effort, help with consistent planning and execution, plus it will help colleagues respect these boundaries such that everything can get done. It will take a little discipline to respect these boundaries, but I believe it is what is necessary to mitigate the risk of partial resources being on the project.