Directories |
Search U of M
|
|
|
|
|
||
|
|
TwinSPIN Newsletter: Volume 2, Issue 4May 1, 2000 Editor's NoteThis TwinSPIN Newsletter did not arrive earlier in the month as had been planned. Your newsletter editors have continued to be challenged by their day jobs, including intense work situations and extended travel to far-off lands. Unfortunately, these tasks and the resulting income tax filing extensions and jet lag take precedence over volunteer efforts. This newsletter is the May - June 2000 issue. In keeping with the tradition of many SPINs' meetings, and to allow your harried newsletter staff sufficient time to rest and regroup, there will not be a summer issue covering July and August. The next issue, covering September - October 2000, is planned for distribution in early September. Thank you for all the support and encouragement you give us as we work to bring you a quality newsletter in a timely fashion. As always, many thanks to our talented contributors: Duncan Stickings, compliments of SPC E-ssentials!; Pat O'Toole of PACT; and Larry Boldt of TBI for providing articles to the TwinSPIN newsletter. Also thank you to Esther Derby for coming through with a book review and for pulling together once again to publish this newsletter. Send letters-to-the-editor, comments, questions, submissions, or anything else relevant to Pat Wegerson at weger002@tc.umn.edu or at 952-448-1335. Esther Derby can be reached at estherderby@worldnet.att.net . TwinSPIN MeetingsMay Meeting: June Meeting: Meeting Directions: For maps: For the Minneapolis/St. Paul Regional Area TwinSPIN Mission Statement Meetings are normally held on the 1st Thursday of each month from 6-8 PM. TwinSPIN web site: All articles, reviews and commentaries are copyright by the authors, unless
otherwise noted. All rights are reserved to the authors. We encourage sharing
the TwinSPIN Newsletter in whole or in part if copyright and attribution are
always included. Writer's Guidelines The goal of the TwinSPIN Newsletter is to provide articles and information with a real world perspective that will be useful to you, the readers. And who could know more about real world software process improvement than the members of a SPIN? If you've ever had the urge to be an author and have an insight you'd like to share, consider writing an article for the Newsletter! In general, articles should be fairly short, not more than 1000 words (since the Newsletter is distributed electronically, we can't accommodate graphs and figures at this time). We're looking for articles with a "how-to" bias, and we also like to put a lighter piece in each issue. Articles that are academic or commercial are less likely to be of interest. If you have an interest in writing an article or contributing one that has
been previously published, please contact Pat Wegerson at weger002@tc.umn.edu
or at 952-448-1335, or contact Esther Derby at estherderby@worldnet.att.net. by Duncan Stickings [Original Editor's note: The author refers to the person being mentored as the mentee in keeping with current practice in the area of mentoring.] As a project manager in a software company one of the biggest challenges is to find and keep good people. In the high-tech industry, there is more than enough work to go around for good people and we scramble to find enough people. We (the industry) have plenty of projects with paying customers, and they always want things done yesterday. The challenge is to ramp up a project team with enough talented people to get the job done. The next challenge is to keep your good people from leaving your company for another one. Resources vs. stars In a typical company, people are called resources. You staff a project with these resources, assign them tasks, and track their progress via a series of status reports and status meetings. If you are lucky you find resources who have appropriate skill sets that match your project needs. If not, you send them on training courses, or expect them to pick it up on the job. That sounds pretty impersonal. A large company I know talks about putting "stars" on their projects. A star is a kind of person who will make magic happen and brings the project through to a successful completion. Without a star, a project was doomed. With mentoring, you are in the business of developing stars. If you think of great people, there is likely a mentor behind them that helped them rise to greatness. King Arthur had Merlin, Luke Skywalker had Obi Wan Kenobi and later Yoda. In our industry, there seems to be no end of potential stars. What we need more of are mentors who can develop those people into stars. I believe the role of project manager includes being a mentor. What is mentoring? To mentor another person takes time and effort. It is much more personal than just scheduling and tracking to a project plan. It requires "soft skills" that are sometimes undervalued (wrongly!) in a predominantly technical environment. In their book, Mentoring, authors Huang and Lynch talk about mentoring as a kind of dance like in Tai Chi. Both the mentor and the mentee enter into a unique relationship, where both give and receive wisdom. Mentoring is more than a weekly status meeting. I would say it involves creating a mutual learning environment. On an ongoing basis, you are seeking to develop the mentee, to help guide the mentee on a journey of learning and adventure. There is a shift in your focus when you become a mentor to another person. As a mentor, your focus is on the development of the person, as opposed to the successful completion of projects. This can be a difficult shift to make, since it is hard for a project manager to see beyond their schedules and delivery dates. The truth is projects will come and go, but people should be around a lot longer. You have to really care about their personal and professional development. You have to be their supporter and believe in them. The benefits of mentoring Studies show that one of the biggest motivators is not money, but recognition and respect. Being a good mentor to a person shows you care and respect them. Ken Blanchard in his book The One Minute Manager said that people who feel good about themselves perform better. Mentoring when done right, is a major contributor to helping people feel good about themselves. If you want to increase software development productivity, be a mentor to your people. Another factor is retention of key people. It is always an interesting indicator to see a project with high turnover. It tells me that people are not getting their needs met on that project or in that company. As a mentor, it is important to find out the needs of your mentee and help them to achieve those needs. As I said, it is often recognition and respect. If you create a mentoring culture, you will actually create a place where people will want to work. Good people will hear about it and will be applying to join your project/company. So bottom line, mentoring helps to find and keep good people, to develop stars, and to increase productivity. Starting to mentor If you want to get started in mentoring, here is a simple plan: 1. Read some of the books on mentoring to develop an understanding. (See Mentoring page on SPC's online Resource Center for a list.)For Duncan Stickings' biography, visit the E-ssentials! Hall of Fame. This article came from Software Productivity Center Inc.'s E-ssentials!, a free, biweekly e-newsletter with how-to's for successful project management and practical software development. To subscribe or view past issues, visit http://www.spc.ca/resources/essentials/index.htm By: Pat O'Toole (PACT.otoole@worldnet.att.net) [Editor's note: This is the fourth of several short articles on "Do's and Don'ts" from Pat O'Toole's experience working in an SEPG. This is written for managers and SEPG members who are implementing CMM-based improvements in their organizations.] DO: Align the Reward System As the annual meeting is called to order, the entire software development staff settles into their auditorium seats. The Vice President of Software Engineering covers both the quarterly and annual results, and the need for continued process improvement becomes evident - although project results are more positive than those attained last quarter, they are still below competitors' levels and well below "world class". The VP stresses the need for continued reduction of field-reported defects as the next quarter's stretch goals are presented. A hush falls over the crowd as the VP prepares to announce the winner of the quarterly achievement award. The prestige associated with winning this award is legendary, and the $5000 check that accompanies the plaque doesn't hurt either. Although many of the projects met their committed dates, two project teams worked incredibly long hours to accomplish their respective missions. The only remaining question was upon which project team would management bestow the award. As the honored recipient is named, the crowd utters a collective gasp. Their minds emerge from the fog of stunned disbelief to hear the VP saying, "... having analyzed the project's historical peer review data to determine an expected range of defect density, she then piloted an approach to re-inspect work products when an insufficient number of defects had been detected. By identifying and resolving more of the defects in the same phase in which they were inserted, the project was able to meet the committed ship date without incurring significant overtime. Let's all show our appreciation for a job well done!" It could happen! Senior management could actually change the reward system to be more closely aligned with the behavior they would like people to exhibit. After all, anything is possible! Unfortunately for many organizations, it hasn't happened yet. Think back on the last few achievement awards presented in your organization. Who received them and why? More importantly, why do people perceive they were bestowed on the recipients? Forget what senior management says about the importance of process improvement, what subliminal messages to they send through the recognition and reward system? There are two critically important lessons buried in here somewhere. An archeological dig would uncover:
Copyright (c) PACT 2000 Pat O'Toole is a Principal Consultant at Process Assessment, Consulting & Training (PACT) where he provides a variety of services to his process improvement clients. Pat is on the SEI's list of most active lead assessors, and has led assessments spanning all maturity levels, including the largest Level 5 assessment conducted to date. With over 20 years of software development, project management, and consulting experience, Pat works with all levels of management, SEPGs, and Process Action Teams in establishing, evaluating, and sustaining their process improvement initiatives. He is a popular instructor who supplements standard training material with his vast array of case studies and humorous examples. For more information contact: PACT By Larry Boldt [Editor's Note: This "List of Potential Ambiguities in Specifications" was provided by Larry Boldt of TBI following his April 2000 TwinSPIN presentation entitled "Requirements Management: An Object-Oriented Approach". This list is Larry's compilation of potentially ambiguous terms that nevertheless appear frequently in software (and other) requirements specifications. Try searching for these in the next specification you review - or the next specification you write!] Dangling Else Ambiguity of Reference Ambiguous Adjectives Ambiguous Adverbs Ambiguous Variables (project specific) Ambiguous Verbs e.g. versus i.e. Implicit Cases Logical Operators Temporal Ambiguity Totally Ambiguous Copyright © Larry Boldt 2000 Larry Boldt is a co-founder of TBI and is an accomplished information engineering manager and engineer with over 26 years of experience in managing and providing business process reengineering (BPR) services to corporate and government clients. TBI’s clients rely on his ability to synthesize TBI’s requirements management process with their system development process as an integral component of every software development project. Larry’s primary areas of functional expertise at TBI include: requirements management, requirements-based testing, business process reengineering (BPR), software quality management, system implementation and training development. Managing a team of 25 consultants and engineers, Larry provides process management engineering expertise to improve clients’ short- and long-term business performance and meet the standards of the Capability Maturity Model (CMM) set by the Software Engineering Institute. Prior to forming TBI, Larry was an Army officer where he designed and deployed information systems for 17 years. He then moved on to consultant work focusing on BPR and system development. Prior to TBI, Larry was a senior consultant at KnowledgeWare, where he guided customers in successfully implementing state-of-the-art computer software technology for client/server application development. Given his scope of expertise, Larry is a prolific public speaker, having lectured at engagements such as Intersolv’s International User Conference, Mercury Interactive’s International User Conference, Software Quality Week, Software Process Improvement Network and the Atlanta Quality Assurance Association. Larry’s discussion topics focus on quality-driven requirements management, component-based development, test management and test automation. Larry holds a BA degree in Business Management from St. Leo College, and an MS degree in Management from Maryville University. Larry can be reached at: Technology Builders, Inc. Reviewed by Esther Derby Requirements are the cornerstone of software development. Without good, solid requirements, elegant design and state of the art technology don't add up to much. Karl Wiegers' book, Software Requirements (Microsoft Press, 1999) is an ambitious undertaking. He promises useful information for analysts, developers, testers, customers, users and project managers -- "anyone involved with defining or understanding the requirements." With a promise like that, I want to know if a book delivers: is there something in this book that I can use in the here-and-now to help my clients "do requirements" better and improve on quality, costs or schedule performance? The answer for Wiegers' book is "yes." I have adapted material from this book to use with clients, and I'll wager it's already saved them more than the $34.99 purchase price of the book. That said, for skill-related areas (gathering and analyzing requirements) this book isn't enough. Wiegers covers the entire life cycle of requirements and gives an overview of key requirements topics: how requirements fit into the development cycle, how different types of requirements relate to each other, techniques for gathering, documenting, analyzing and managing requirements. Wiegers starts from the position that most organizations can improve the way they gather, document and manage requirements, and provides guidance on just how to do that. Chapter 4, "Improving Your Requirements Processes" gives advice on approaching an improvement process. Consciousness of the improvement process carries thought the book: there's a "Current Requirements Practice Self-Assessment" in the appendix and each chapter ends with a short section on "Next Steps." The book is structured with many entry points for the improvement process. I like this because it encourages making whatever improvement is reasonable and possible at the time. If a project is in the build phase, in most cases it doesn't make sense to go back and improve the way requirements documentation is written (unless the requirements documentation is so poor it can't be used). There are other improvements that can be implemented even in projects already underway. Impact analysis, for example, will help to quantify the effect of changing requirements and may help point out the costs of missed or ambiguous requirements. Here are some highlights: Chapter 17 describes the roles and responsibilities of the Change Control Board and Change Control process. I find Wiegers' description more robust and useful than similar descriptions I've come across in project management literature. In Chapter 18, Wiegers' provides checklists for analyzing the impact and effort that have been immediately useful: I've adapted the checklists for a client who is now using them to overcome the notion that "it's just one line of code, it will only take 5 minutes to make the change." Chapter 13 covers requirements prioritization. In general, the prioritization methods Wiegers presents make common sense: prioritize early in the project using an agreed-upon scale. Definitions for several three-point scales are listed. Wiegers also describes a weighting scheme based on TQM that computes a numeric ranking for each requirement. In my experience, the trade-offs are seldom so cut-and-dried, and the discussion that goes into the ranking more valuable than the resulting spreadsheet. Software Requirements talks about processes: step-by-step activities that produce an output. There are two arenas covered in the book where process is necessary, but not sufficient. In my experience, requirements gathering (Wiegers uses the term "elicitation") and analysis require skills that go well beyond a defined process. Gathering good, unambiguous requirements is a skill that is developed through practice and experience. It's not something you can learn out of a book. Software Requirements acknowledges that elicitation is "the most difficult, most critical, most error-prone, and most communication-intensive aspect of software development. Elicitation can only succeed through an effective customer-developer partnership." Yet only a small portion of the section speaks to those challenges. The bulk of the chapter describes documenting requirements with Use Cases. The sections on requirements analysis models gives examples and descriptions of various types of models (data flow diagrams, entity-relationship diagrams, dialog maps). I wouldn't expect someone to be able to use one of these notations after reading the book. However, the point of doing analysis models is to better understand requirements and make the translation between needs and design. So perhaps the activity of drawing a view of the system will be helpful, if the model is understandable to both the developer and user, whether or not it follows a particular notation. In spite its shortcomings in covering elicitation and analysis, Software Requirements provides solid information on requirements practices and making process improvements. You can expect to get more than your money's worth in cost savings by adopting and applying the checklists, document templates and other practices described in this book. Esther Derby works with software development managers and project managers to get projects on track. She focuses on helping her clients become more effective in managing complex systems -- like software development organizations and software development projects. Esther can be reached at derby@estherderby.com or 612-724-8114. |
|
|
||||
|
