You’ve managed projects but they are never quite right. They don’t fit into the nice definitions in project management books. Your schedules are generally off. There’s always some surprise. You’re not failing, but you feel you should be more successful. Is there a solution?
Perhaps you can take a more pragmatic approach to project management. To manage the risk of not knowing what to do, use iteration to explore alternatives. To manage the risk of not knowing how far along you are, use incremental steps to finish features. To manage the risk of overrunning the schedule, make sure your project team and stakeholders agree on what “done” really means. Developers may think “done” means the code compiles cleanly. That’s not how system users define “done.” Another way to ensure success is to escape the dreaded trap of multi-tasking. It’s a popular management style right now, but it drains time from everyone every time there is a task switch. Protect your staff and yourself with timeboxed chunks of time when only one task is worked on. One final secret every project manager must know there is no “one right way” to manage a project. Everything depends on your context, which includes the company and its products, the people on your team, and on you. Keep everything in balance and you’ll have a successful project. But let something get out of balance, and kiss all your good work goodbye.
Johanna Rothman helps leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management.
Johanna publishes The Pragmatic Manager, a monthly email newsletter and podcast, and writes two blogs: Managing Product Development and Hiring Technical People. She is the author of several books: Manage Your Project Portfolio: Increase Your Capacity and Finish Projects; Manage It! Your Guide to Modern, Pragmatic Project ManagementHiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People; and Corrective Action for the Software Industry (with Denise Robitaille).
I keep hearing that more rigor is good and less rigor is bad. Some managers who’ve never studied testing, never done testing, probably have never even *seen* testing up close, nevertheless insist that it be rigorously planned in advance and fully documented. This is a cancer of ignorance that hobbles our craft.
I have done some of the most rigorous testing any tester will do in a career, as part of winning court cases. Let me tell you, extreme rigor costs a lot of money and brings a laser-like focus to testing. But if you were in a dark room, you wouldn’t use a laser scanner to find your car keys, would you? A soft light would do.
In this talk I will describe and dispel various myths of rigor, so we can apply rigor without obsession or compulsion, and let our testing be flexible and inexpensive, too.
James Bach has been a test manager or consulting tester since Apple lured him from a programming career in 1987. He spent about 10 years in Silicon Valley before going independent and traveling the world teaching rapid software testing skills. James passion is to teach testers to think, which is why he strongly opposes thoughtless programs such as ISTQB tester certification (and every other certification program currently out there). He is the author of Lessons Learned in Software Testing, and a new book: Secrets of a Buccaneer-Scholar, which describes his approach to self-education.
Many people believe that expensive or complicated tools are required to test performance. I’ve frequently told those looking to break into performance testing to start by becoming a mid-level everything. Once when I mentioned to a friend that I was considering writing a how-to style book on performance testing, he quipped “You’re going to fill 150 pages with the phrase ‘Hire a consultant’ in a bunch of different languages?”
While there is at least some truth to each of those statements, many performance issues can be uncovered with exactly the tools and knowledge you have at your disposal right now. In fact, much of the performance related information that stakeholders need to make good decisions and development teams need to dramatically improve system performance is easily obtainable by the performance-testing layman. During this presentation, Scott Barber discusses, demonstrates, and even asks you to participate in a variety of these 30-second performance tests for non-performance testers.
This presentation looks at how to create and foster successful professional relationships with teams and people. An alliance goes beyond building a relationship. Alliances are about building reciprocal relationships. Alliances look to not just foster a collaborative spirit but also look for ways that teams can look out for each other and work together.
Come and listen to tips and techniques to build relationships. Karen will specifically discuss:
How to foster collaboration and keep communication in sync across teams.
How to look for opportunities in work deliverables that build reciprocal alliances.
How to find ways to keep team tensions down at the critical end game of the development process.
Karen Johnson is an independent software test consultant. Karen has been involved in software testing for more than two decades. Karen has extensive test management experience. Her work often focuses on strategic planning. Most recently, her focus has been on developing a sense of community for software testers working in the area of regulated software testing. Karen is a frequently invited speaker at major conferences and has published numerous articles and recorded webcasts on software testing. She blogs about her experiences with software testing http://www.karennjohnson.com
Karen is the co-founder of the WREST workshop http://www.wrestworkshop.com/Home.html. She is currently writing a chapter for the tentatively titled Beautiful Testing, an O’Reilly imprint, available in late in 2009.
