Rusty Divine

Live, Love, Learn, Teach

Business Analysis / Requirement Gathering Exercise

goal settingRecently the software development team that I lead decided on a new team goal to work on together – improve our business analysis and requirement gathering skills.

The Project Manager of our team, Brad, had an idea that he could be the customer for a software project that he actually wants built – something that will add a set of user stories and tasks to our Team Foundation System (TFS) for him. This takes him a few hours each iteration, but more importantly he just dreads doing it because it should be easy to automate.

Here is the text email I sent to the team earlier this week:

We have a fun exercise to work on requirements analysis that we will be starting this Friday during our tech training session. Brad has an idea for a real piece of software he wants to use (it has something to do with TFS tasks) and he wants us to help figure out what this thing is and what it should do.


We will break up into two groups so that we can spread the learning out. This is not a competition, but the two groups should work independently so that everyone has the opportunity to struggle a little.

Blue Team: Suma (Team leader), Ryan, Padma, Rusty

Green Team: Adam (Team leader), Dan, Satish, David

The team leaders will decide how to organize the team and should take the lead responsibility in getting the requirements right. Rusty and David will take off their tech lead hats and play the role of team member suffering from minor and temporary business analysis amnesia (basically we’ll try not to steer so that others can exercise their skills).

  • 10-10:30ish – Brad will present the overview of his idea to both teams.
  • 10:30-11 – Brad will “leave” the room (pretend he isn’t there), both the teams will independently organize and decide what questions they have and how they want to proceed
  • 11-12 – Brad will actually leave the room. The teams will take turns of no longer than 15 minutes to ask Brad follow-up questions and do whatever work they see fit in defining the project.

At noon we’ll assess where we’re at. It’s quite likely that we’ll need to spend most or all of next weeks’ time (and even more?) doing analysis.

When a team feels like they are ready to go, they can present their plan to Brad and he can decide whether or not he wants to sign off on it. If not, revise the plan and re-submit.

Each team will then actually build their version of the tool during tech training time in the following weeks. There’s no better validation of your requirements gathering than having to build what you defined! We’re not sure how much work will be involved at this point, so we’ll adjust as necessary.

In the coming weeks we’ll also spend some of the time during each tech training working on quick business analysis exercises or demonstrations. I may also send out some 15-minute drills occasionally that you can do during the week.

By the time we wrap this all up in a few months, we’ll do a retro of how this initial requirements went considering the things we’ve learned along the way. We may do a final requirements gathering exercise like this first one using the skills we’ve learned, but likely won’t build that project.


Blackboard time quality moneyThe first meeting was pretty fun. I had a good time sitting back and letting everyone else on blue team take the lead in eliciting the requirements from Brad.

Next week the team will get an email every morning with a practice exercise that shouldn’t take more than 15-20 minutes; I’ll post them here, too. They will cover things like, “What is the Project Management Triad?” to give each of them a chance to think about requirements daily. is great for Beginning Hunters and Expert Hunters

pwdrhkIf you know how to hunt and need to find some people or places to go, or if you don’t know how to hunt and need to find some people to show you the ropes, then is a great resource for you.

I’m a good shot and have been around guns, but have only hunted a few times in my life. This year I would like to learn how to hunt whitetail deer and I have a lot of questions about how to prepare myself, find the deer, and what to do with the deer after its harvested.

I am going to be learning by following the hunting learning path at, watching some videos, and checking out the library. I also would feel better getting out with someone with experience that can answer questions I will certainly still have my first few times out.

At Powderhook I created a discussion room (called a Card) for Lincoln Nebraska area hunters that is meant to connect beginners and experts in this area so that the experts can mentor us beginners and we can all have a good time and make new friends.

Not long after I posted Eric Dinger, the CEO and co-founder of Powderhook, dropped in to answer some of my questions! Hopefully it will be of some help to you, too, and I hope to see you there on Powderhook if you are interested in hunting:

My beginner-hunter questions:

  1. Where to go (Powderhook should be able to help there!)
  2. How close should you be to confidently make the kill (depending on your own skill of course); is 80% sure good enough for example?
  3. What happens if the animal is just wounded; how to finish it as cleanly as possible?
  4. What do you do after its dead - field clean, how to get it out to your vehicle, where can you take it (esp. deer)?
  5. and of course tips and tricks for tracking and finding game and general etiquette so that I don't feel like a newbie.


Eric’s answers:

  1. We can help. And, you've got a bunch of time to get ready for next year. Let's talk again this summer about finding a spot.
  2. I think many people would answer this question differently. The idea is if you're going to shoot at a deer you should be really confident you're going to kill it. Not sure if that's 80% or 95%, but it's probably a highly situational deal no matter your confidence level. For example, with some practice, a good scope, rest and a standing deer you could be accurate to several hundred yards. I've never killed one over 200 yards. Boone and Crockett would tell you that anything over 300 yards is not considered fair chase. I fall in the camp of 'if you're confident you'll make an ethical shot, then shoot.' Much of the fun is about getting close - so if I were just getting started I'd force myself to get really accurate up to 150 yards and hunt until I had a chance at an animal in that range. Doers choice, though, no judgment here!
  3. If you wound a deer you want to give it ample time to expire. Most deer you hit solidly with a rifle will die within a few hours. The last thing you want to do is chase them when they're wounded - they'll run for miles and you'll never find them. If you're confident you hit the deer a good rule of thumb is to give it at least an hour before you move. That hour will feel like 4 hours... which is why I'm saying an hour and not 30 minutes! If you pick up a really good blood trail you're probably safe to continue to track the deer. If there is scattered blood and you're not sure you made a lethal shot, I would back out and give the deer a few more hours. If you come up to a deer that hasn't expired but doesn't run, the ethical thing to do is make a lethal shot or use your knife do the same. Use the barrel of your gun to touch the deer's eye to make sure it's dead.
  4. Field dressing a deer is not nearly as difficult as you'd think. That said it's definitely intimidating at first. My suggestion? Find a friend who will show you in person. Or, there are lots of "how-to" videos online. The long and short of it is you have to get what's inside out - ideally without cutting into the intestines and getting deer musk all over your new jacket. Ha! My Step Dad showed me once and I've been good to go ever since. If you end up shooting a deer on your own, hit me up and either I will come help you or I'll find you someone who will - wherever that might be. As for where to take it, Schuster's is what I hear everyone talk about [Other spots in NE]. I always took mine to C and C in Diller, Ne, but I think they're done doing it as of this year. You can also do it yourself, but I don't because I don't have a good place to do it. Most importantly - just make plans to go. The rest will come together for you. There are hundreds of people like me who would love nothing more than to help you get started.


I have a lot of time to prepare before next season and am looking forward to finding some great places and new friends over at Powderhook.

Don’t use Social Security Numbers as Usernames

Under Practices To Avoid: "Never have a computer log-in system where a person has to use their SSN", and "Organizations should avoid using Social Security numbers (SSNs) as identifiers for any type of transaction. The SSN should only remain in a database as a secondary identifier. Organizations should exercise limited use of an individual’s SSN", and "Organizations that maintain SSNs in their system of records should consider encryption of this data."

The government is cracking down on bad security practices including a $150,000 fine for HIPAA violation, and taking a closer look at themselves.

That was the TL;DR; version of the simple advice given by the Social Security Administration website and the Office for Civil Rights who levies fines. You would think a health insurance benefits company would know better than to play fast and loose with their customer's personally identifiable information, but imagine my surprise this autumn when I got an email with the following instructions:


WAT? My username is my SSN followed by 624, and my password is the last four of my SSN? You just emailed me…why didn't you use my email address as my username? What is with the 624, is that some sort of security-through-obscurity so that if someone had my SSN they couldn't log in? When I went to their website, I saw that no, the 624 was used for everyone and the username and password pattern was put on their home page for any would-be hacker to see.


Ok, so there are only one billion possible SSNs, and about half of those have been assigned, and there is a pattern you can use to narrow that down, so a potential hacker could probably pretty quickly gain access to a valid SSN by a brute force attack that just tried different combinations of SSN on their website until one worked. What could they do then? Well, they'd see their victim's name, address, birthday, and voila they could steal their identity. An angry ex could add themselves as their victim's beneficiary and enroll them in some life insurance that would be paid out of their victim's pay check.

I contacted the benefits provider to let them know this was a bad practice and that I wanted my information either removed from their system or my username changed. Their response to me was that I shouldn't worry because their website was secure, and that I could change my username and password in a few weeks when the open enrollment began (which means my SSN-username and last-4-password have probably been sitting on this site for a year without me even knowing it).


I can only assume by "secure" they mean it was encrypted with SSL. What about line-of-sight vulnerability of a co-worker seeing me log in? The website does use autocomplete="off" on the username input to tell most browsers not to cache that information. What about a disgruntled employee who has query access to the database? Is the username hashed and salted? I'm guessing it is not since that isn't a common practice for a username, so any disgruntled employee could potentially walk out with a disk full of SSNs, names, addresses, and dates of birth.

When open enrollment came, I noticed that there was no way to change my username; I did change my password though, so I let the benefit provider know and their response again was to assure me their site was secure.


I started wondering if their site had been vulnerable to the Heartbleed bug, so I checked LastPass' website tool to find out. LastPass says they were using open SSL prior to July 2014 and may have been vulnerable to the Heartbleed bug prior to that (the vulnerability became public in April).


Finally, I filed a complaint with the Office for Civil Rights, even though I'm not certain if the benefits company is under the jurisdiction of the OCR (they did levy the large fine mentioned above). I will also send a link to this blog post to their company and hope that they take this situation seriously.

A coworker of mine also complained to our employer, and they said their security team and VP is taking a look at this issue.

What should you do if your identity is stolen?

I have heard from friends that having your identity stolen is a burden that lasts for years as you try to repair or just out-wait the damage it causes to your credit and your ability to rent, borrow, and buy. I hope you never have to deal with something so awful, but if you do or are, check out this guide for What to do if your identity is stolen.

If you're a developer, here are some guidelines from the Office of Personnel Management to safeguard SSNs. Also, you should check out the OWASP website and find your local chapter to meet other security-conscious IT folks.

I'd like to thank a colleague of mine, Rob Temple, a security analyst and OWASP member who provided some of the links for this blog post.

Tech Training–Hour of Code, CSS3 Selectors, new Team Goal

TechTrainEvery Friday our team meets for two hours to work on something together. We’ve scratched the surface of many topics to get a feel for what is possible and dug deeper into others that we want to implement on our project. The adjacent mind map shows about a year’s worth of training (taken from our PM’s whiteboard for his talk on why we do technical training).


Hour of Code

Today our PM presented some things his young daughter did in the recent hour of code – a fantastic event to get kids (and adults) interested in programming. We also took a look at the similar Santa Tracker by Google where like an advent calendar there’s a different programming game or puzzle available every day in December leading up to Christmas. We had a ton of fun navigating our elves through mazes and flying them through the sky to pick up presents.

CSS3 Selectors

We’re always looking into fun ways to practice our skills, and what better way than a rewarding little game of CSS3 selectors! If you do any web programming, you should try this out: It took our group anywhere from 30-45 minutes to complete the 26 challenges and along the way you could hear many quiet refrains of “Yes!” and “oh-yah!”. It’s great to hear everyone having a great time and learning, too.

I gave the team some more resources to read up on in their own time, too:

Docs -

Interactive -

Tutorials - (work through the menu on the left or click Next Chapter)

Team Goal

Our team works on personal goals and team goals. An example team goal was to upgrade our source code tool (TFS) and development tool (VS) to the latest versions. That took a major effort because it ended up getting bundled with an operating system upgrade (Win 8.1) and pushed out across our organization.

During the last 20 minutes of our tech meeting today we brainstormed what our next team goal should be. It needs to be something that takes a few months to a year and benefits the whole team.

We put up a list on the whiteboard as we brainstormed, and then each team member emailed me their three votes from the list (and they could vote more than once for any idea). The final tally of votes was:

  • Kendo UI upgrade (4)
  • MVC 5 upgrade (3)
  • EF6 upgrade (2)
  • SQL 2012 upgrade (0)
  • Visual studio upgrade (0)
  • Requirements Gathering/Analysis training (6)
  • Mainframe administration training (2)
  • JavaScript testing/improvements in our project (2)
  • Move automation/dev ops for better continuous integration (2)

I was excited to see the team want to work on requirements gathering and analysis training because I really enjoy those (I’ve given a couple of talks and am working on a Pluralsight course on the subject), and because it was one of the soft skills in a team who really loves the tech-side.

We’ll work on how to learn about a problem from our customers, how to ask why enough times to find out the real business reason, practice how to come up with a good plan for a complicated process, and more. We’ll watch some Pluralsight courses and dedicate some training days to getting better – I can’t wait to get started! It’s so good to get a direction set by the team that you know has the whole team’s buy-in; everyone wants to get better, we just need to provide the right environment to make it possible.

A System for Technical Training–How and Why Your Team Should be Learning

Graph drawing on blackboardThere is something you should be doing to help yourself grow - practicing your craft. You may feel like you don't have the time or the energy to do it outside of your regular responsibilities. Maybe you've tried off and on, or maybe the thought of it conjures negative feelings. Sometimes it feels more rewarding to just keep working through tasks and checking them off the list than to switch to work on something that by its nature makes you struggle and thrash and can feel aimless like you are putting in more work and just not having any way to measure a payoff. Sometimes you aren't even allowed to study on the job.


You need to remove as many obstacles as you can to make Learning something that you practice consistently. So, what is stopping you? What's getting in the way of your team from spending the time it needs to get better?


Common obstacles include the following:

  • Why should we set aside time for learning?
  • When can I study and practice?
  • What do I study? Where do I start?
  • Should it be something directly related to what my company does?
  • How much time should I spend?
  • What's more important, learning or finishing a task?
  • How do I know I'm getting better?
  • Do I have to?


Let me tell you what my team is doing to remove most of these obstacles and how it is invigorating us.


Hamster Running WheelWe have recognized that there is a significant risk of burn-out if a team has a never-ending backlog of work to do. We need regular breaks that mark and acknowledge the work we've done while allowing our minds to relax and regroup for the next push. Our team plans three weeks of work at a time and marks the end of the cycle with a demonstration to the end users, a retrospective of what went well and what could have been better that helps us continually improve, a day off from our daily 15 minute stand-up meeting, and an afternoon with nothing to do other than learn something new.


We also dedicate two hours every week  on Friday mornings from ten-to-noon to group training where the tech lead (that's me for now) prepares something for the team to work on together. It could be improving a skill that helps the team or training on a new technology that we are considering adopting. We've used these meetings to learn and practice TDD, explore Azure, test out new versions of Visual Studio and TFS, start new projects from scratch, and pick a new technology to implement a small prototype in, just to name a few.


Our team has MSDN Universal, which comes with $150/month credit to Azure that we can use to run virtual machines and websites. We also all have Pluralsight Annual Plus subscriptions that we are encouraged to use for our allocated training time and also that last 30 minutes of the day that can be otherwise unproductive if you've wrapped up your work.


We enter our time in TFS for our stories and we track that we are each entering at least six hours a day. We have set aside time in TFS for training that including the two hours each Friday comes out to at least four hours per week (a little more would not be frowned upon).


At one of our retrospectives recently we talked about some problems we were having making ourselves take the allocated time for training instead of just working on tasks. We made some adjustments to our schedule, agreed as a group that training is higher priority than adding unplanned tasks to our iteration, and decided to assess our skills so that each of us can focus on the areas we needed most.


We each took the Pluralsight tech pro challenge over at Smarterer and had a lot of fun grousing about the questions and learning how we stacked up to the average developer. Based on each of our lowest scores, we picked courses from Pluralsight to watch that would most help improve our skills. We will then take their assessments to demonstrate our proficiency and also come up with a simple project to present to the rest of the group that covers the new skills we learned. Our progress will be tracked by our supervisor, but also the team as a whole will benefit because each of us will be better at our jobs and each of us will teach what we have learned.




Sometimes the best solution to a problem is creating a system or process that you can follow where the solution just falls out naturally. We have to learn because we've setup a process that leaves us no choice; we have the time set aside, we have identified what we need to focus on, and we have made ourselves accountable to our supervisor and to each other. We no longer struggle with not knowing what direction to go, or whether or not we should study or find a task to do, and it feels empowering and easy and just downhill.

Some Highlights from HDC14

When I go to a conference I am always re-energized afterward from having learned about tools that I’d love to try, techniques others are using, and finding common ground with other professionals I wouldn’t otherwise get to interact with.

This week I went to, and spoke at, the 2014 Heartland Developer’s Conference in Omaha, NE. I was impressed with this year’s selection of talks – it seemed more were really well designed than I’d seen in years past.

Jack Skeel’s Master Agile and Write More Code

The highlight for me was a keynote delivered by Jack Skeels of Agency Agile titled Master Agile and Write More Code (slides). Jack talked about how agile processes may not actually improve productivity, especially for shorter projects and projects that have constraints of budget and schedule. He made some points about how agile can work in a constrained environment, which all really hit home for me and my experience in custom software development through various consulting firms.

  • Small scope is better
  • Direct communication is critical
  • Learning constantly via process improvements is important

Those points really tied in nicely with my talk title From Idea to Core Feature Set which covered how to get started on the right foot on a project that may be constrained by budget and schedule.

He also emphasized the importance of flow – keeping interruptions to a minimum – so that a team can be most productive. I was excited to hear about how important he thought this was because I’m working on a side project that deals directly in this problem space! Now that HDC is over, I intend to turn back to that and bring something out by early next year.

One of the books he highly recommended was: Practices for Scaling Lean and Agile Development Practices for Scaling Lean and Agile Development, which he said he owned two copies and both were dog-eared and bookmarked and well-worn. He also mentioned Thinking Fast and Slow and his Amazon Bookshelf.

John Wirtz’s Stakeholders and Persona’s are for Wusses – Everyone go Meet Your Real Users

John’s talk on the importance of integrating with your users was enlightening. I had met John for coffee one time to talk about how his company Hudl manages their teams and their agile processes, so I was really looking forward to hearing what he had to say and I wasn’t disappointed.

John told us a bit about what Hudl does and how they modeled their teams after Spotify’s tribe-guild-squad model that scales agile teams very well.

One technique Hudl uses to get raw feedback they call the Noob Gut-Punch – they go sit with a user who is pretty new to their software and ask them to navigate around and tell them what each button and menu means to them. John played a brief clip of one of these interviews and it truly was hard to listen to how confused the user was! I can only imagine being the software developer responsible for creating a pretty decent interface only to see someone struggle with it that much. The uncomfortableness of that moment is going to drive the developer to think like someone new to the system and give them someone to talk about when they argue over how features should be implemented so that someone who is new to the software can understand it.

He also said that they have their developers ask the customers in a 5-why's type of style where they just keep drilling down into what the customer is saying until they can find the root of the problem. 

One other point he made was that they try to hire developer’s with natural user empathy. If someone really cares about finding out how users are using software, then they will feel welcome in Hudl’s culture.

He mentioned tools such as: WuFoo, and UserVoice.

Miscellaneous Highlights

  • Pete Brown talked about the Intel Galileo, an arduino-type board that runs windows! He highly recommended everyone should watch the IT Crowd and get Little Bits for their kids or themselves.
  • Bill Fink showed us the Kinect v2 and said it will be priced at $199 and be incredibly much better than v1!
  • Andy Ochsner recommended the ELK stack for log analysis, and showed how awesome Kibana is at charting log data – suggested you could do some cool things with public data.
  • Dave Royce sat next to me at one session and told me his team is using Liquid Planner, Confluence, and Box to manage his custom software projects for his team.
  • Paul Oliver gave a spectacularly funny talk on Git (slides) where he showed us how to beat-box, too. He recommended this interactive tool to help learn Git, and SourceTree for a beginning IDE, then GitExtensions for advanced, and said not to use the VS IDE in a team because merge conflicts are a pain. He gave out a few copies of the Git Pocket Guide and had some great things to say about it.


Also, I got a chance to chat with Jim Collison:

From Idea to Core Feature Set–Heartland Developer’s Confernce 2014

Thanks to everyone who worked on HDC this year to make it a great success!! I really enjoyed meeting with everyone and talking with those that came to my talk From Idea to Core Feature Set.

Here are the slides and examples for download: (3.4MB)

Let me know if you have any questions!

The Costenburger

This summer one of my goals was to make a gourmet burger so good that my friend Adam Costenbader would choose it over his favorite 1809 burger at Honest Abe’s.

I mostly succeeded today at the unveiling. I’m happy with the outcome – it was generally agreed that it was on par with Abe’s burgers – but there is still room for improvement!

The Costenburger Recipe. Feel free to fork this recipe and send me pull requests!


Edit 8/25/14:


Heartland Developer Conference 2014

I’ve been attending HDC for about 4 years and I’m happy to say I am presenting this year! Register now and come see my talk titled From Idea to Core Feature Set where I’ll show you how to take an idea for a product or an initiative at work and get to a shared vision of what is really most important and what really needs to get done first.

Problem with Authenticated Proxy with PAC file in Windows 8

We had a small problem on our team since we upgraded to Windows 8.1 from Windows 7 last week – only Internet Explorer was working 100% with our proxy server. Other browsers, such as Chrome, would let us get out to most sites, but some sites that were on our active directory group’s allowed list (like were not working.

The problem kept aggravating us as we found more and more sites and services were broken, but none of which were serious enough to enter a service ticket that would get our network team involved; one of which did look at it briefly and found it worked fine on his machine.

I love how the solution came forward through team effort on the part of Grax and Costenbader and myself: each of us chipped in a few minutes of toying with it throughout the day and did a great job of reporting what we’d found to each other. We even put a bounty of a burger at Honest Abe’s on the line, although in the end we all earned it.

Our proxy server requires authentication and has a PAC file for configuration. Again, these were working great in IE, but not in anything else. I realized we were getting a 407 Proxy Authentication Required error by using LINQPad’s check for update’s tool (chalk another win up for that great tool!).

Grax took the information from the PAC file and was able to manually authenticate using LINQPad’s update tool and got that working. BAM! That was a great break through.

Costenbader then went into Window’s Network Proxy Settings (type that from the start screen to get there) and set Auto Detect Settings to On, but turned off the Auto Configuration Script that was trying to load that PAC file. He then turned on the proxy server and used the information from the PAC file to enter the server and port, and checked the box to not use the proxy for local services.

BAM! That fixed 98% of our problems. I put the finishing touch on when I entered a few of the “except for” addresses into the proxy settings that I grabbed from the PAC file. DONE! We now have access to all the sites we had access to in Windows 7.

So, in summary, the PAC file combined with an authenticated proxy made it appear that Chrome wasn’t working, as well as some other services and tools (we didn’t try FireFox). Chrome uses the computer’s proxy settings though, so by fixing our network proxy settings we fixed Chrome and all the other tools we were trying to use. We aren’t bypassing any restrictions, we’re just changing the way it is configured so that it works on our machines, too!