Let's look at QA!

A personal note: I've formally left my BA position and am transitioning to a Project Manager role (PM) in another group at the bank I work in. Not to fear though. As a PM, I will have oversight of all the activities going on, including BA, QA and development.

I've been thinking about quality for the last few weeks and I've realized that we really put out not-so-good software where I work. At least on the first few tries! We release software that is riddled with bugs, that have data integrity issues and crash as soon as the user tries something new.

First of all, where I work, QA is given short-shrift. We don't think of them till the very end. They're out of the loop for the most part and then are brought into Mission Impossible: Make sure this application is ready to go in 3 days!

The thing they say about quality is true: You never have enough time to do it right, but you always have enough time to do it again!

How do we ensure quality? or more realistically, how do we aim for as high quality as we can get? Quality is elusive. Heck, Pirsig wrote a whole book on it (Zen & the Art of Motorcycle Maintenance).

Well, I'm no quality expert but I have learned a few things in the last few months.

1. You need to have a separation of concerns. The team pushing out the software (BAs, PMs, Devs) should not be responsible for Quality. You need a Congress to push back on the President. The mindset for driving out and releasing software is at odds with ensuring quality. I've signed off on software to be released just so I could get it out there only to find that there was a crash a day later. My goal as a BA is to satisfy the user and to get the software out, not to find fault and hold it up. As long as the former is my motivation, I cannot do an adequate job of QA'ing anything.
2. We need to have some sort of up-to-date specification to hand off to QA. I've been a cowboy for the last year or so, BA'ing by the seat of my pants, embracing agile, and iterative development. Which really translates to: No writing any specification documents. I would instead create prototypes, mockups, write up notes in Excel and have plenty of phone conversations and netmeetings with my team. This was swell and we produced some good results which were very close to the mark to what I required. However, QA suffered. The way I handled QA was to also do the netmeetings, and do demos and such and then let them play with the software. QA could write up their own test-cases based on what I showed them. Voila! No spec needed. After all development created the software without a spec either. However, and here's the kicker: I realize now that I only show QA what *I* think is important. I demo features that I think should be tested, so when they go away, they concentrate on that. Of course it's the features that I don't show them (because I don't think they're important to demo) that wind up being used by the user and then fail! It's really remarkable (and arrogant of me) to think that I know what QA should do. Again, as a BA or anyone looking to driving software into the marketplace I am severely hampered by this same motivation from ensuring as high a level of quality as the software (& user) deserve. So which translates to: have a spec ready that highlights what the software does and let QA work off that, not what I show them. Guess specification documents are a *good* thing! :)

What led me to posting this about QA was some recent experiences (or failures) with our tools. I did an analysis and here's what I've come up with.

1) Bug because of a hidden feature that wasn't tested.
Occurred because (1) I didn't demo that feature to QA (see point #2 above!), so QA never even knew to look for it or that it existed, (2) test cases from v1 of the tool were not reviewed and used for v2; the test-cases may have had this hidden-feature; in essence, no Regression-testing! and (3) there was no written spec given to QA which would have had this feature detailed.

2) Bug because a common case was not tested.
Occurred because again (1) I didn't demo this to QA or stress it at all as a point to be tested. They saw what I showed them and mimicked it. (2) Test cases from v1 not reviewed and used.

There were a few other things that contributed to the breakdown:

• Inadequate training of QA; a junior QA person with not much experience signed off on the project.
• QA not brought in early enough to the specification phase of the project
• QA spec/test cases should be developed ahead of time and be prepared/reviewed. QA needs to have this as a mandatory deliverable. Even if they are brought in dead-last in a project, their efforts should result in a test-case deliverable that can be re-used for the next go-around.

So in summary, here are some essentials:

• Always get QA to hand over a test-case or QA deliverable that can be re-used or handed over in case resources get shifted (QA seems to be get 're-deployed' more than any other group these days)
• Use above deliverable as basis for modifications and to use for regression-testing in major releases
• BAs need to write a spec specifying what the system does as a deliverable to QA (and to developers, although in my instance, I don't seem to have all that much trouble getting development to deliver what I want since we're both aligned towards the same goals) so they can poke holes and create their deliverable.

QA will either use your spec (or any other documents, literature, conversations, screenshots, etc) or if brought in really late, will use the actual working software itself to create test-cases. This deliverable is vitally important. (Implementation-wise, if QA keeps it in a doc or in a tool like Quality Center, it is irrelevant)

• 
  

A PM's utility

Warning: This post is really an experimental one; just playing with some thoughts about the PM function. Not my intention to offend but the question is:

So how useful are PMs (Project Managers just in case you didn't know)?

Frankly I'm not very sure!

Of course it depends on the project. Not every project needs a BA or PM.

Everyone on a team should be thoroughly invested in 'caring' about the product, not just task-mastering so that things get done. PM activities are essential actually. But is a separate PM truly necessary? I think the best approach is to either hire BAs with PM experience or Developmental Leads with PM experience. That way PM tasks are kept to a minimum but also reside with personnel who are invested in the product.

In Six Sigma terms, the most useful ppl to have on a project are those who are adding value to the product.

A BA talks to the business and therefore represents and speaks for the business to the dev team. The BA represents the business so s/he wants to ensure a quality product.

The developers are developing the product and so will put care and precision into crafting something of quality.

In my own (and certainly limited experience) PMs engage in many not-required non-value-add activities. Is the customer willing to pay for communication or chasing down people to get tasks done? These are overhead tasks that are necessary but also don't add value. In six-sigma terms, these are NVA, non-value add activities and should be minimized. Hence, my call to eliminate the PM position in areas where you are able and to place only the least amount of PM activity with other members of the team who also engage in value add activities.

Let's look at wikipedia's definition of the activities a PM engages in:

1. Analysis & design of objectives and events
   
2. Planning the work according to the objectives
   
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
   
9. Directing activities
   
10. Controlling project execution
    
11. Tracking and reporting progress (Management information system)
12. Analyzing the results based on the facts achieved
13. Defining the products of the project
14. Forecasting future trends in the project
15. Quality Management
16. Issues management
17. Issue solving
18. Defect prevention
19. Identifying, managing & controlling changes
20. Project closure (and project debrief)
21. Communicating to stakeholders
22. Increasing/ decreasing a company's workers ...
    

In particular contexts, these activities make sense and in others they don't. If you're running an agile or lean software development project then a lot of these can be eliminated entirely and others can be offloaded to other personnel.

The gist of this post is to just get you thinking on the type of projects you're running and not to blindly throw a PM, BA, Dev Lead team together and expect to get the job done. You could be slowing the project down actually. The BA and Dev Team could run with the project a whole lot quicker than with a PM overseeing everything trying to get updates.

In my environment, what seems to truly work is:
1) Hire BAs who are comfortable with and can talk to both the business & development on an everyday basis.
2) Hire BAs with PM knowledge
3) Hire Dev leads with PM knowledge

Lean Sigma Thoughts

I've recently been going through some training on the Lean Sigma methodology. It's all about Process Improvement and it employs the DMAIC (or DMAEC) steps: Define, Methodology, Analyze, Implement (or Engineer) and finally Control.

It's a very sequential model (not unlike a waterfall software life cycle methodology) with tollgates at each step. It's pretty interesting and I'm learning a lot of academic material. I'm doing my Green-belt training and I am using the textbook material on an actual project that is causing my boss pain. However, as I've been digging into the project, I've discovered that a lot of the steps were carried out 2 years ago on much the same pain points. In fact, there are reams of documentation all the way to the Engineer Phase. The solution was never implemented however. Now there's a big project underway (of which I'm working on a very small chunk) that is looking at the same issues again. So my question is: why? Why will the result be different from last time? Why wasn't the last solution that was brought to the table 2 years ago not carried out?
Heck, we can do a Lean Sigma project on this question alone!

And furthermore as I was digging into the items, I started getting innovative ideas. What if we could do this or that? and implement it with a small group? If it worked, we could spread it to the other groups. And then it hit me. The Lean Sigma process to some extent is devoid of innovation! That flash of inspiration; that 'hmm, what if we tried this?' is somehow lost along the way. A practitioner can so concentrate on each one of the steps at a time that s/he never sees the issues holistically. The emphasis on only defining a problem or measuring or analyzing precludes the 'what-if-we-did-this?' The problem is engineered to death.

In this project I'm on, the solutions proposed from the last go around made sense. I have a feeling that the stakeholders involved were a little change-averse to implement some of the bigger changes and didn't want to rock the boat. I also feel that our Lean Sigma group is seen as 'outsiders' or consultants who come in, do their thing, drop you the results and leave. Their stuff is good but they're done and they're off to the next thing. This is what Management Consultants do. The clients are left with a lot of analysis, proposed changes and that's about it. I think people are change-averse and they're fearful. They might like the analysis and agree with some of the solutions but they take a risk when implementing. If the proposed solutions don't work out in the stakeholder's favor, the project manager is left holding the bag. When Lean Sigma or management consultants leave, the project manager (who may have contributed to the development of the project) is not invested in the solution, so will be less likely to implement it (at least from the e.g. I've seen).

Again, on this particular project, I saw comments from one of the stakeholders who more or less shot the proposed solution in the foot. The Powerpoint slides depicting the proposed changes were passed around and then the stakeholder fwded the slides to his managers with many more criticisms rather than favorable remarks. It's no wonder the project stalled. What top level manager would give the go-ahead if their employees thought there were resolved issues?
Questions:
1) Why wasn't the solution developed jointly with the stakeholders?
2) Was there a chance to rectify/address some of the concerns of this particular stakeholder?

There've been tons of issues with this particular product line; everyone agrees it is broken; My personal feeling is that the product line manager is definitely risk-averse and doesn't want to do anything drastic.

A BA should act as PM (sometimes)

In our environment, in order to maintain quality of the project and make sure communication is flowing to the right people, the BA needs to step forward and own the PM space. Doing the requirements piece is essential and is a first step; the information then needs to flow downstream to all the other parties in IT. The BA is at the forefront of this endeavor. If the BA stops there and expects the PM to take care of the flow of communication, the project more than likely will come to a grinding halt; either that or it will start to flounder. The BA should either work hand-in-hand with a PM who does take ownership and is vitally interested in delivery of the project OR the BA should own this piece as well and ensure that the right people are playing their parts & on time; thus the BA is acting as PM.

The benefit of having a BA act as PM on his/her own project is that since the BA is present at the inception of the project, s/he has interacted with end-users and felt their pain, needs, requirements, etc. from a first hand basis. This makes the BA a representative of the business and the BA can really strive for what is important. The BA playing a PM role can stress the right areas to focus on in the short-term and push off the less important items. A separate, detached PM may not take these things into account, especially if s/he is not as invested in the project. In fact, having a PM involved at the outset may be too much overhead.

The beginning of the project is very vital. A BA/PM can push for a working first iteration of the software that does the most important things first; the initial software will have limited functionality and the BA/PM can even act as an initial QA resource, vetting the design and construction of the software as it progresses by doing quick checks of functionality; and in order to make sure the software is aligned with the original vision. The BA in fact is in a most unique position, especially at the beginning of a software project, because s/he can play those 3 roles: BA/PM/QA and the reason should be blazingly clear; The BA is the one who feels the client's pain and will do his/her damnedest to make sure that the client is being given what they need (if you're a conscientious BA that is)

As the project progresses, matures and gets more intricate, there will have been some momentum built and other dedicated resources can be brought in to handle specific areas of the project: a dedicated PM, junior BAs, dedicated QA, etc.

Get Developers thinking in terms of Features EARLY

Developers aren't used to thinking in features at the beginning of projects. They are usually so engrossed in the details that they immediately start thinking of the tasks they need to do in order to build a piece of software.

Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen

etc.

The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.

So how do you effect this transition of language that developers speak from tasks -> features?

As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.

Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.

But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.

The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.

Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.

As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.

IT is the problem!

What has slowly revealed itself over the last few weeks is pretty insane! But I had a glimmer of insight a little while ago which gnawed at me and I'm fairly certain that this is the central issue: that IT is the source of our own woes.

Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.

Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.

But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.

I find a lot of developers to be prima donnas. They think they're so smart that they can't be bothered by 'nuisance' requests from users or new requirements when they've already begun work. And they get irritated when things change. A lot of them are not very adept at handling change midstream.

What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.

IT Management needs to grow some balls and start delivering the message that developers need to be able to adapt and adapt quickly. In this day and age, only nimble (I deliberately avoided the term agile here!) and spry performers win the day. Frankly, I think IT management in a lot of big corporations have no clue about how to produce quality software, have no clue about how to become nimble, nor have a clue about the recent best practices that have overtaken the software industry at large. Producing software doesn't have to be laborious, or tedious or hard or even take a loooong time. It's crazy how management can come up with a plan, and then weeks later when much more is known about the project (including how waaay off the initial plan was), they'll still demand that the initial timeline be adhered to! Plans should be a model, but they should constantly be updated as you get more information. Don't they teach that in Planning 101?

BA Skillset

Here are some skillsets and basic tools that I feel a BA should have:

• MS Office Suite
• Word
• Powerpoint
• Excel
• Access

Word & Powerpoint are no-brainers. Excel also; but more than a passing familiarity with Excel is a good thing. Knowing how to chart, use pivot tables, sort, filter, and even do some VBA are all exceedingly good things to know.

Learning Access is one of those things that can put you over the top. You can quickly create solutions for small groups of people and do a bang-up job. There're lots of instances where a simple Access database can do the trick but many BAs don't have the skillset to address them. Instead the project become overblown and a 3 tier solution with an Oracle DB and a middle tier and a web front-end are devised. This takes too long, is too expensive and more likely than not, you'll have to wait for resources to be freed up.

Training your users to use an Access Database is also probably a good thing to do. Lots of spreadsheet users invariably complicate their spreadsheets with tons of tables and VLookups, whereas a simple join in Access would do the trick.

Another useful thing with Access is if you do lots of data analysis. Comparing reams of data and figures on multiple Excel spreadsheets can get quite laborious and tedious. If you dump each of the sheets into their own tables in Access and do joins you can quickly find which ones match and which ones don't for example. Access (or knowledge of some database) is a must for the serious BA.

Other skills:

• SQL
• Communication/Writing Skills
• A strong desire to play with & learn new software; being a software evangelist
• An ability to filter out extraneous information and to focus on the details that drive a project forward rather than getting bogged down with too much detail

There's a time & place for everything. Sometimes getting all the information up-front is not such a good thing (your head probably won't be able to process it :)