OK, I'm coming clean. My all time favorite movie is Rocky, Rocky II, Rocky II, Rocky IV, Rocky V, and Rocky Balboa. Every now and then I watch one of the movies and never get tired of the scenes of Rocky training or battling the next opponent in the ring. But, there is more to the Rocky movies than just boxing. There are lessons we can all learn from Rocky Balboa. I decided to dedicate the next set of blog posts to the greatest boxer to ever live!
Go ahead and launch the Rocky Theme Song while you read!
Mentorship
As part of our personal and career development we should all find mentors and be a mentor for someone else. There are many benfits to being a mentor including working on your listening and leadership skills. Being a mentee will allow you to learn valuable lessons from someone who has priceless experience and has been where you have at this point in your career.
Throughout the Rocky movie the concept of mentorship kept popping out to me. There is a scene where Little Marie is hanging out with some older boys on the street corner and Rocky pulls her away and walks her home. During the walk home he is trying to give her advice about life and how the people she associates herself with will influence who she is as she grows up. As Little Marie is walking into her house she turns and says to Rocky. "Screw you creepo!" As Rocky walks away he mumbles, "Yeah, who am I to give advice." Don't think you can't be a mentor. You have expereinces that can help others. Little marie ends up thanking him later.
Later in the movie after Rocky decides to fight Apollo Creed he does not accept help from anyone to help train and prepare for the fight. Finally he comes around and gets Mickey to be his trainer and even gets Paulie involved. In the end he is prepared for battle. We all need mentors, we can all learn from others that have experienced things we have not. Do not be ashamed to use a mentor. You do not have to do this alone.
As BA professionals you can find mentors and mentees within your family, company, or orginzations like the IIBA. Also, check out this site for mentoring tips. http://www.mentoringgroup.com/
Please share you mentor/mentee experiences with us.
I have found that many BAs cringe when talking about software testing. They don't want to test and don't seem to want to learn the basic testing principles. I fell in love with testing when I learned about the best practices and all of the techniques. When you are testing, your goal is to find problems. What other job encourages you to look for and point out problems?? The more problems you find the more successful you are! And of course, the ultimate goal of all quality assurance is to improve the quality of our solutions!
Five reasons that BAs should love testing:
1. Thoroughly testing (and fixing) the solution before deploying ensures that users will be very happy with your work.
2. Having testing principles in mind when developing requirements helps to improve every single requirement. If you are constantly wondering "How would I test this?" you are more likely to develop complete requirements.
3. Executing tests and investigating defects teaches you more about how software applications are created. If you don't have a technical background this is a great way to learn more about what developers do and improve your communications with them.
4. Executing tests gives the BA a hands-on opportunity to imagine the best rollout strategy for your business stakeholders. When you have entered data into the software and generated reports, etc. you will easily be able to help the business area make the transition to the new system.
5. BAs learn to really appreciate SQA professionals and treat them better when they are available. Having been involved in testing, you will understand the work of SQA people and hopefully request them on future projects.
So, the next time you are asked to help with testing - smile and enjoy!!
Recently I participated in an interesting discussion about software development projects. There was an underlying assumption by some that using a consistent software development life cycle (SDLC) on all projects is a good thing and someone asked how to best enforce it. For me, enforcement is a morale killer. In working with many companies over the years developing software, some had methodologies and used them with great success, others used them but projects still failed. Some organizations, who did not have any standards, wasted a lot of time starting over for every project and still others without too many standards remained nimble and innovative with break-through and cost saving results. Training teams to make confident choices is more essential than dictating a methodology. I have argued with many quality assurance people when my judgment calls were in violation of a methodology step that did not add value to our efforts. Organizations should concentrate on teaching their employees approaches to handle different types of projects and challenges.
With training and project experience one can balance variables such as risk, cost, complexity, and importance of the project to determine which deliverables and efforts are beneficial. Does that mean you have to create a lot of paper documentation? It really depends on the project. Are lives at stake? If not, less formality and rigor is my preference. My mantra: Only work tasks that add value. Beware that most SDLCs are written for complex projects. If your effort is small in scope, has clear requirements, and minor business impact you do not need tons of documentation. Requirements may be confirmed informally. These are important considerations for a business analyst when planning.
I recommend organizations adapt a small number of easy- to-use development life cycles, provide people training and make the lifecycle options visible and available. I appreciate the overall structure, templates and reference that most development lifecycles provide to a project team, especially as a communication tool. Trained teams can benefit and develop efficiencies by having standards that work for different types of projects. Talented, experienced people can be creative and use good judgment to tailor the SDLC to what is important on their projects.
In other words, I know what I like to eat but it is also nice to select from the menu of my favorite restaurant. I can make my choices more easily, request menu adaptations as needed, and get to the fun part faster which is enjoying a good meal. Using software lifecycles for guidance, consistency and flexibility, need not constrain, delay, or negatively impact the project results or the team. They just let us get to our dinner faster and so we can enjoy the meal. I would love to hear your stories about methodology implementations at your organization.
