This last week featured, for me, the monthly meeting of the GR Testers Meetup Group. We are a bunch of folks who get together and talk, present ideas, share ideas, ask questions, eat pizza, eat stuff that isn't pizza and things of that ilk. We are not terribly formal. We rarely have a topic more than one meeting in advance.
It is funny. I was asked once "How do you come up with ideas for meeting topics?" One of the ways we find topics is in the course of discussion of another topic. That is where this month's topic came from.
A couple of months ago, in the course of discussing bugs or some such, one of the participants asked a question:
What Makes A Software Project Successful?
Awesome question. That became the topic for July. It would have been the topic for June, but we had already lined up an international jet-setting speaker presenting (informally) some ideas on test automation. So, this landed in July.
Talking with my colleague Matt Heusser on the topic, he said "Man, that is a huge thing. There are so many things that go into that. How can we make that work in such a short time?" And the answer presented itself - LeanCoffee: Time-boxed discussion around ideas proposed and voted on by the participants.
Perfect.
Since it was an evening meeting, and coffee seemed inappropriate, we had BBQ wings chips and soft drinks and a room with whiteboards so we could draw and a door we could close so we could be boisterous.
Boisterous? Testers? Really? Yup. Boisterous.
I was minding the time and trying to keep notes and capture ideas. The attempt to write up a post for the group became challenging. It also dawned on me that the ideas presented from this mix of testers, developers, designers, PM types and even a recruiter type (who was a developer before turning into a recruiter) was an interesting collection of ideas - particularly as they were discussed and debated in very short increments of time.
The summary below is in the sequence of the discussion. The topics are in descending order by the number of votes each topic received.
The Topics:
1. Define Success
Right. That was the point of the discussion, right? But in this case, after a fair amount of round-about discussion around what was meant by success, we landed on an idea started by one participant, honed a bit by a couple of others and the result was: Establish a shared vision of what success looks like for this project.
The last bit is really important. We can't define what success looks like for every project we will encounter. Many of the folks participating don't work for software development companies per se, the work for companies that do other stuff and need software to do that or do it better.
We can't promise we will "please the customers" if we can't communicate with them, directly or indirectly. We can't promise anything around bugs or adherence to requirements or any of the oft-stated measures of what good stuff looks like.
However, as testers we can help shape the shared vision of success with the project team and stakeholders. We can help form an unify that vision through our dedication to service to our craft and the organizations we are working with.
2. Communication/Honest Communication
Two people submitted the same basic idea. A central tenet of anything that touches on getting people to actually work together is clear communication. In that, being honest within the communication cycle is a challenge.
The farther up the food chain a story goes, the less accurate/more embellished it becomes. Isn't it amazing how some test progress reports morph from "We have some concerns with problems found in function X and function Z. Because of these we have not been able to exercise function L or function Y at all." and magically turn into "Things are going great! There are just two more functions that need testing."
Being willing, and having the courage to deliver difficult messages crucial to success in a project. Likewise, people being willing and open to receive difficult messages are essential. We must be open to delivering and receiving honest communication.
To help make that happen, we must be certain of the clarity of words and thought used within the communication cycle. It is easy to bury meaning if we want to with techno-babble or intentionally obfuscating if we choose to. Don't do this. Call out others when they do. If you are not certain what something means, ask that it be explained. Even if you are certain, asking that something be explained might be a good idea.
3. Project Vision That is Worth Working For
People tend to do better work if they can identify with the project at some level other than some VP wants a change made. Projects where the goal, the vision, is clearly laid out along with the impact and benefits that are hoped will be achieved tend to get stronger affiliation from people working on them
When no one on the project team has any idea where the request came from, or why, that is a really bad sign. In contrast, if it is clear why the request was made and what the impact will be, these tend to get more emotional investment from the team. That tends to, though not always, result in people being willing to do better work.
There must be clear identification why we are doing this project and why it is important to the business and customers. The scope and context must work together.
4. All Projects Are Failures
This was submitted by a developer/designer type. His point was, simply, if there is more than one team or group using a piece of software, it is entirely possible that someone may not like the changes resulting from the project.
That is amazingly true, particularly in the area of bug-fixes. One group hates the way something works. One group doesn't like it, but has found a way to make use of it. By fixing the bug, the first group may not be happy, but the second is most likely going to be unhappy.
And then there is the problem with political capital in software projects. People want enhancements made, submit proposals for them - and then don't invest the time, energy, whatever, to make sure that what is being developed is what they actually want or need. If the requester/product specialist folks who insist that enhancement K be included no matter what and then "can't waste time in meetings talking about stuff they have already explained" this is an almost certain instance of pending failure.
Things will not go well for this - no matter how well the team pulls off the crazy-nuts request, no matter how close they get to hitting the expressed need - something is going to be missed. Mostly because the team doesn't have a clue that it is expected. And they don't know because "it should be obvious" according to the folks who don't have time to waste in meetings.
Are people overly critical? Sometimes. Well, maybe not. Well, maybe. It kind of depends. And in that exchange the seeds of failure are sown.
5. Within Time / Within Budget
Ya knew this or something like it would appear, right? While some manager types will define success in those terms, can testers? Can the project team? Really?
Who defines the timeline? Well, most folks would say that if you plan out the project needs and what can be done when, that will give you a timeline. Unless there are hard-dates that must be met for legal, regulatory or other reasons. Or unless someone promised the project would be delivered by a given date. Or unless... right, you get the idea.
Who defines the budget? Most teams can make time estimates, which is a form of budget. But who decides if extra equipment can be purchased? Who decides if we can bring in more people to the project to help? What about bringing in experts in the area to shore up the staff/project team so they can learn from working with the experts? Can the project team make these decisions? How many times have our well-considered estimates been rejected as "too high" and slashed by a third, or more? Can we really control that?
(I think my favorite line from that part of the discussion was "If the software doesn't have to work, I can get it done really fast.")
What the project team may be able to do is schedule the tasks or features to be worked on so the most critical features can be finished by the delivery date. In some instances, this may mean putting the most critical features at the end, particularly of they involve changes that would require a process audit, e.g., a PCI compliance audit.
Awareness of these concerns is crucial to having any form of success in a project.
6. Buy-In From Management
Sometimes the view from upper or senior management may not be in alignment with what the project participants might call a success. Simply put, if management folks call it a success, officially, it is.
Having said that, managers (both line and upper managers both) can smooth the waters and eliminate road blocks. This can take the pressure off the staff/project team and allow them to focus on getting the job done.
However, managers can't do these things without the project team communicating clearly what is going on and the actions being considered. Translated - the communication must be clear and bi-directional.
7. Software Works As Intended / Fit for Use
The last topic we could fit in for the night to discuss. This boiled down to a couple of very salient points:
* What is happening when we use the software?
* What did we expect to happen when we use the software?
Pretty simple, eh? Of course, the details are what make this a challenge.
Conclusion
With that, time was up. We picked up the room, put away the stuff that needed to be put away and headed home.
Observation - notice how many of those actually focus around "communication"? Yeah. I kinda thought that in the course of the discussion.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment