What is the best way to achieve success with software development management? Mickey W. Mantle and Ron Lichty address this question in their new book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams.
In this tip, I share the authors' advice on successful software development management.
Defining the project
As any seasoned software team knows, the difference between failure and success in software development management often lies in the quality of the requirements. "Getting the requirements wrong is a sure recipe for failure," say Mantle and Lichty. Citing an idea by advanced software industry veteran Dean Leffingwell, they write, "Studies have repeatedly shown that building to ambiguous requirements -- or to the wrong requirements -- is among the costliest errors in software development and among the top causes of project failure."
The Scrum methodology addresses the issues associated with unclear requirements. It does so by formalizing the role of a product owner, who has responsibility for delivering requirements using "stories" written in a particular format that focuses on the "what," not the "how." Agile methodologies, in general, promote the continual collaboration and communication between business owners, development and QA.
In recent years, tools designed to remove ambiguity from requirements have become available. "There are now commercial tools on the market that read use case requirements and use natural language understanding to identify and highlight ambiguity. They enable product managers to ferret out and fix requirements ambiguities before ever delivering them to the programming team," write Mantle and Lichty.
Colocating programmers with product managers and even customers is another technique Agile teams are using to promote continual collaboration. A key differentiator between excellent programming managers and competent ones is this: The excellent ones strive to truly understand what their business partner is trying to accomplish and seek to delight the customers.
Executing the work
Coding starts with a design, and though Agile methodologies do not require a complete design before coding can begin, the technical design should address the nonfunctional requirements and chart the flow of control and data through the program. The design should specify protocols, APIs, security measures, timing, threads, interprocess communication and scalability. "Some claim that Agile methodologies like Scrum and Extreme Programming (XP) would have programmers skip design entirely. But in our experience, what Agile coaches tend to argue heatedly are the timing, granularity, and depth of design, not whether there's any at all," write Mantle and Lichty, who caution against diving into code with no attempts at design. Not only is designing important, but holding a design review allows the team to flush out issues and cross-train.
Another recommended tip is for the team to leverage prototypes. Completing proofs-of-concept or prototypes will help the team flush out risks early on and is useful for initiating conversations with the business users in order to hone in on exactly what they are looking for. One danger here is that prototypes might appear to be more complete or ready than they actually are, which may result in less feedback from customers. "Study after study has shown that polished UI prototypes fail to get the critical customer feedback that designers desire, and that has led to a surge of paper prototyping, hand-rendering wireframes, and use of tools like Balsamiq Mockups -- walking customers through rough sketches instead of finished screens looking for feedback," say Mantle and Lichty. Another downside of prototypes is that they may set unrealistic expectations, giving the customer the impression that the code is almost done.
Delivering the software
Once the code is delivered, the job is not over. Mantle and Lichty remind readers of five additional tasks that need to be done before project is complete: celebrate, retrospect, share, refactor and deliver point releases addressing customer feedback.
Many development teams launch into the next project before the last one is complete, but taking the time to celebrate success in a memorable way is important. This will help keep the team members motivated and foster further teamwork for the next project. A retrospective will also provide the team with an opportunity to express what went well and what could have been done better. Take the time to gather the lessons learned and apply actions in the next project to continually improve. This is also a good time to refactor where needed, so that the next project is set up for success. Examples might be refreshing the platform or handling any organizational or process cleanup efforts that have been identified but put on the back burner. Finally, gather feedback from customers and quickly address concerns with point releases.
What is your advice for software project success? Email SearchSoftwareQuality.com editors and let us know.
"Managing the Unmanageable" is published by Pearson/Addison-Wesley, Copyright 2013 Pearson Education.
This was first published in January 2013