blog.RedRockResearch.com

I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public.  Our topic was Software Requirements Management.Requirements Management is perhaps the most controversial topic in software development.  Everyone seems to have their own technque.  It is also the most important skill-set–statistically more important than development skills–to the overall success of a software project (Standish CHAOS Report, 2009).Let me say that another way because this principle is not intuitive…if you want to improve the performance of your development projects, improve the skill-sets of your business analysts who generate requirements.  Statistically, this has more of a performance boost on a projects outcome than any other skill-based area.Many published requirements management techniques exists, and yet in a $220 Billion industury with a project failure/delay rate of 64%, it appears that most of these published techniques are not embraced.Our seminar covered Eliciting, Prioritizing, Validating, and Documenting a requirements baseline.  We discussed the progression of system context diagrams, UML actors, use cases, data-flow diagrams, High-Level Overview diagrams, High-Level Design diagrams and finally the Software Requirements Specification document.   We talked briefly about  a Concept of Operations document and a System Design Description document.We discussed the difference between a plan-based documentation stack, and a minimized Agile-development documentation stack–which would be generated during a Sprint-Zero.  (Yes BTW, you DO create documentation for Agile projects!)We discussed techniques to control scope creep after the requirements baseline, and then discussed techniques for dealing with what I call ‘approval noise.’What puzzles me the most about this topic is an entrenchment I encounter occasionally, as expressed by one of the seminar participants.   He stated, after the seminar, that all of this was interesting in a textbook-like manner, but that he felt none of it was pratically applicable.I asked him to explain how his company performs requirements practices and he said “Well, we have nothing written.  We have everything in our head and we just talk across the cubicles.”  He then told me he was frustrated at some additional items he was asked to add to his project that morning because it was supposed to be completed two weeks ago.  He also told me that the owner of his organization wished they had a structured approach to software project management, and that–oh, by they way–many of the programmers were given layoff notices at the beginning of the week because the company is failing.Hmm, it’s almost as if the problem is not properly in focus.  Downstream problems are caused by upstream actions or omissions.  I mean no disrespect, I just wish to point out the obvious that if companies like this would adopt upstream structure they would benefit from downstream success.You see, the problem proper requirements practices solves is not at the development effort level, it is at the project management, estimation, budget, and strategy planning–or business level.Software centric business level practices become predictable and executives can be proactive if their projects properly consume the time estimated.Projects will consume the time estimated if they include all of the functionality needed for a desired level of business value, and those functions are identified in whole, at the beginning of the project.  This way the software project time-frames and feature-sets can be included accurately in the estimation, budgeting, resource planning, and strategic planning of a company.  This way, scope creep will be minimal, and the whole company will benefit from a predictable project delivery process.Without proper requirements skills, entire feature-sets get missed upstream and need to be added ‘at the last moment’ downstream,  the risk of re-work increases drastically, and recurring cycles of this erode project managers and the development team’s credibility in the eyes of the executive team and the waiting customers.  In worst case scenarios, this can lead to layoffs and finally company failures.If you haven’t been trained on proper requirement management techniques, you are holding your organization at risk.  Attend our next three-day Software Requirements Management training course held September 7-9 in SLC.Mike J. Berry, PMP, CSM, CSPMwww.RedRockResearch.com

Recently, while attending the ‘09 Agile Roots conference in Salt Lake City, UT, Alistair Cockburn–the keynote speaker–referenced Miyamoto Musashi’s 16th-century book called The Book of Five Rings. 

I like Asian philosophy (and swords and such) so I picked up the book and read it.  The book was written in 1643 by an undefeated Japanese samurai master who was so effective he was rumoured to have spent the latter part of his career entering sword-fights purposely without a weapon.  Although meant as a battlefield manual, the book has gained popularity as a handbook for conducting business in the 21st century.

The book was translated into English by Thomas Cleary at some point and the edition I read was published in 2005.   Improperly named “The Book of Five Rings,” the book is actually a compilation of five scrolls.

The Earth Scroll: Musashi talks about how a straight path levels the contours of the Earth and how various occupations provide life-improving principles.  He talks about observing patterns and learning from them.  Certainly a great primer for any business trying to get across the chasm.

The Water Scroll: Here Musashi talks about how water conforms to the shape of its container.  He suggests a separation of one’s inward mind against it’s outward posture, maintaining that one’s control over one’s mind must not be relinquished to outward circumstances.  He translates these philosophies into about 80 pages of sword fighting techniques.  An interesting modern parallel is found in Jim Collins book, Good to Great, where he talks about how the most successful companies are able to say ‘No’ and not be influenced by immediate but non-strategic opportunities.

The Fire Scroll: As with any book written by a 16th century samurai master, you’d expect a core discussion on combat strategy.   The fire scroll is full of combat strategies, positioning, and pre-emptive theory.  Very interesting.  Did anyone notice how Apple’s announcement of the latest iPhone came about 1 day after the Palm Pre phone was officially launched–killing it’s market blitz?  No coincidence there.

The Wind Scroll: The wind scroll contains a directive to study and be aware of your opponents techniques.  Translated into business speak, this means one should always study ones competitors.  Be aware of new offerings, partnerships, markets, etc. that they persue.  Emphasis is placed on observing rhythms and strategically harmonizing, or dis-harmonizing with them as appropriate.

Finally, The Emptiness Scroll:  This scroll discusses the value of escaping personal biases.  Emphasis is placed on not lingering on past situations and being able to adjust quickly to new scenarios. 

Overall I found this book ‘enlightening’ to read.  If you like metaphors and inferences, or sword-fighting, then you will enjoy this book. 

Mike J. Berry
www.RedRockResearch.com

I recently attended an Agile Development Product Owner class taught by Alistair Cockburn.  The content was excellent.  He taught us about the proper perspectives an Agile Product Owner needs to successfully interact with the project sponsors, users, and the development team.Alistair Cockburn has authored several books on Agile Development, and is one of the original signers of the Agile Manifesto.I would describe Alistair’s environment as squirrely and fun.  We built user-stories out of the Rumpelstiltskin and Cinderella stories (from the original Nicht fur Kinder european versions–full of voilence and gore!)We also discussed the differences between Use Cases and User Stories.  I was happy to hear he prefers Use Cases, because so do I.All class attendees had already been through the ScrumMaster course, so as we executed sprints for our product backlog, it was interesting to see how many attendees actually sought the sponsors/users feedback during the iterations–without being reminded.Overall it was an educational and enjoyable experience.Mike J. Berrywww.RedRockResearch.com

Recently someone on StackOverflow.com asked me to explain how to compute the defect removal rate for release candidate software.  There are two methods for producing this number and I teach both in several of my seminars, but I’ll explain the simpler method in this post…

Lawrence Putnam presented this model in his 1992 Book titled Measures for Excellence.  His book reads more like a math text than a software development guide, and suffers from an unfortunate formula typo which has lead to widespread confusion about his models in the industry, but I will  explain his defect removal rate calculation process.  (I hired a math wizard to examine his data and correct the formula!)

1. For a typical project, code is produced at a rate which resembles a Rayleigh curve.  A Rayleigh curve looks like a bell curve with a long-tail.  See my ASCII graphics below:

        ||||
    |||||||||||
 |||||||||||||||||
|||||||||||||||||||||||

2. Error ‘creation’ typically happens in parallel and proportional to code creation.  So, you can think of errors created (or injected) into code as a smaller Rayleigh curve:

        ||||
    |||+++|||||
 ||||+++++|||||
||||+++++++||||||||

where ‘|’ represents code, and ‘+’ represents errors

3. Therefore, as defects are found, their ‘detection rate’ will also follow a Rayleigh curve.  At some point your defect discovery rate will peak and then start to lesson.  This peak, or apex, is about 40% of the volume of a Rayleigh curve.

4. So, when your defect rate peaks and starts to diminish, factor the peak as 40% of all defects found, then use regression analysis to calculate how many defects are still in the code and not found yet. 

By regression analysis I mean if you found 37 defects at the apex after three weeks of testing, you know two things:  37 = 40% of defects in code, so code contains ~ (37 * 100/40) = ~ 93 errors total, and your finding about 10.2 defects per week, so total testing time will be about 9 weeks.

Of course, this assumes complete code coverage and a constant rate of testing.

Hope this is clear.

Mike J. Berry
www.RedRockResearch.com

I value Excellence over Heroics. 

‘Excellence’ can be defined as “the crisp execution of established procedures.”  Think about that for a minute.

Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires?

The thrill of delivering when the whole company’s reputation is at stake can be addictive.  I remember once staying up 37 hours in-a-row to deliver an EDI package for a bankers convention.  I was successful, delivering the application just before it was to be demo’d.  I went home and slept for 24 hours straight afterwards. 

The problem with ‘Heriocs’ is that the hero is compensating for the effects of a broken process.  Think about that for a minute.

If heroes are needed to make a software development project successful, then really something upstream is broken. 

Most problems requiring heroics at the end of a project stem from improper effort estimations, inability to control scope, inadequate project tracking transparency, mismanaged Q/A scheduling, unnecessary gold-plating, or inadequate communication between the development team and the project users/stakeholders.

A well-organized development group humms along like a well-oiled machine.  Proper project scoping, analysis, design deconstruction, estimating, tracking, and healthy communication between development and the users/stakeholders will bring that excellence that trumps heroics.

Hey, I hear that Microsoft is looking for some Heroes.

Mike J. Berry
www.RedRockResearch.com

A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.

Companies that don’t have a quality system are commonly reacting to production and support issues due to omissive events.

A simple rule of thumb is to ask yourself how many fires your development team has put out this month.  If any come to mind, then chances are you don’t have a proper quality management system in place, and should read on…

I remember early in my career I struggled to get my employees to follow our procedures.  Whenever we’d encounter a production problem with our software, it would inevitably be a result of someone not having completely followed an established procedure. 

We would have a big discussion about what should have happened, and about how “we can’t forget to do that next time,” yet we’d experience the same omission later.

I would get frustrated because I could never seem to find a way to get my team accountable for following our established procedures–until I discovered the “Quality Management System.” 

A Quality Management System has the following three elements (the Three P’s!):

1. Process (documented–most of us have processes or procedures we are supposed to follow.)
2. Proof (a separate checklist, or “receipt” that the process was followed for each software release.)
3. Process-Improvement (a discussion, and then an addition or adjustment to the documented process.)

Most companies have an established–and hopefully documented–software development process.  (If you don’t you can download one from my website for Waterfall, or Agile here.)  This is the first ‘P’ and should be in place at every established development shop.

A great question to ask the team is “How do you know the process was followed for each release?”  This is where you may get the deer in the headlights response.  This is the second ‘P’ and is the piece missing from most software development shops.   

Think of this ’Proof’ document as a checklist accompanying each software release.  The checklist would include every major step in the documented process, names of team members performing specific functions, and locations of final source code, test scripts, install files, etc.  The checklist would also require a series of quality checks.  Ie: Were requirements signed off by the customer, stakeholder, tester, and developer?  Was the help file updated with the new release number and appropriate functionality?  Was the source code checked in?  Where is it located? 

As problems occur, the checklist would be added to so that the product would be protected against a similar failure in the future. 

The governing driver considered here is that one particular problem might broadside the development team once, but after the process is improved, that problem should never occur again.

For example, you might have a stored procedure that goes into production without a “Go” statement at the end.  After the error is discovered, and fixed in production, your team should have a discussion and conclude that a checkbox needs to be added to the quality document stating “All Stored Procedures Confirmed to have ‘Go’ at the end.”

From that point on, whenever a stored procedure is moved into production, the developer presenting it must check for ‘Go’ statements at the end and then sign their name at the bottom of the checklist.

This is the difference between process improvement, and hope.  Many companies view process improvement as a discussion and some verbal affirmations.  What they are really doing is “hoping.”

Actually, the “act” of process improvement is physically altering a written process or procedure.  This is the real definition of process improvement–the third ‘P.’

The final endpoint of a quality management system is to achieve excellence.  I’ve heard excellence defined once as “Crisp execution of established procedures.”

You can’t have excellence without procedures, proof, and process-improvement.

Mike J. Berry
www.RedRockResearch.com

Do you have one of those executives that harasses you with status updates to projects, yet never attends the status update meetings?

Perhaps they call you, email you, stop in to your office, and want to know what the latest on project X is?

Is the behavior effecient?  What suggestions do you have about how to convey project status communication within your organization?

Mike J. Berry
www.RedRockResearch.com

John C. Maxwell’s book,  The 360 Degree Leader, is an excellent field-guide for navigating the challenges of leadership at all levels of an organization.

Maxwell starts his book by dispelling many common dysfunctional myths that are found at line-level, or middle-level management.  Ideas such as “When I get to the top, I’ll be in control,” and “If I were on top, then people would follow me” are inaccurate adolescent attempts to understand the true nature of leadership–which is influence.

Maxwell continues by explaining the characteristics of influence:

1. Position - Influence because people have to follow you.
2. Permission - Influence because people want to follow you.
3. Production - Influence because of what you have done for the organization.
4. People Development -Influence because of what you have done for them.
5. Personhood - Influence because of who you are and what you represent.

Maxwell gives examples of effective leadership in all directions: up, across and down.

To lead up well, he suggests you lighten your leaders load, anticipate your leaders needs and use their time wisely, and invest in Relational Chemistry–get to know what makes your leaders tick.

To lead across, Maxwell suggests you focus on completing your fellow leaders, instead of competing with them.   Be a friend, don’t pretend you’re perfect, and avoid office politics.

To lead down, Maxwell suggest you develop each team member, place people in their strength zones, model the behavior you desire, transfer the vision from above, and reward the results you desire.

Overall this is a good book worth reading and re-reading every so often.  I recommend it for managers at all levels.

Mike J. Berry
www.RedRockResearch.com

Ed Sullivan’s book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.

In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do.  It’s refreshing to read a software development book that tells you ”what to do” for a change.

Sullivan skips past conventional theory and provides real-world experiences and wisdom for how project managers and software development teams can succeed in this challenging industry.

Novel to Sullivan’s recommended approaches is the concept of one-team-per-project, reporting to a single manager.  Conventionally, most companies split out development, quality-assurance, and product management into different departments.  Sullivan describres this configuration as a model set-up-for-failure.  Too many factors, he says, complicate team performance when each team-member is reporting to a separate manager.

I consult with software development companies to improve their product delivery speed and product quality.  I call Sullivan’s single-team suggestion the “lean model,” and I agree with his conclusions.

In the manufacturing sciences, there is a belief that the production manager and the quality assurance manager have an inherent conflict of interest, therefore, they should be separate departments within a manufacturing organization.  Many business books are written about this.

In software, however, this model is a less-effective approach.  It can work, but it creates barriers between project teams for several reasons:

1. Contention can arise as an “us vs them” mentality builds when team-members go back to their respective departments dougouts, to commesurate with their non-project department staff.
2. As team-members need each other to succeed, it becomes easy for a team-member in one department to delay requests, or grandstand, because their department manager “has asked them to work on other things this week.”
3. A department manager will tend to be uninformed about upcoming urgent project team needs and may unintentionally delay the project by asking their employee to do other things at the most inconvenient time for the project.
4. A lack of focus will accompany any project team-member who has continuous department responsibilities outside of the project team.
5. If contention arises, the project team-members from different departments may value disparaging another department, rather than working together to solve the problem at hand.

Sullivan goes on to discuss effective hiring techniques, retention techniques, and general healthy corporate culture factors.  He talks about ranking employees in terms of inner-circle, middle-circle, and outer-circle.  This reminds me of Jack Welch’s theory on differentation.

Another novel concept Sullivan describes is his simple but effective project scheduling process.  He breaks each month into daily rows, listing team members names as column headers.  Inside of each cell is a letter/number combination representing who needs to be finished with what task on that day.  In my opinion this is much better than a gantt chart.

Sullivan goes on to describe meetings, schedule management, release management, and project closure.

I found this to be a beneficial book to read.  I would recommend reading it topically, as a reference, rather than cover-to-cover.

Mike J Berry
www.RedRockResearch.com

In Steve McConnell’s book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.

Researching from NASA, IEEE, and some other industry giants like Grady Booch  and Tom Demarco, McConnell summarizes software development into six stages:

1. Planning
2. Design
3. Construction
4. Testing
5. Release
6. Wrap-up

McConnell also offers some great ideas like keeping a project history to record lessons learned and actual project data (time to completion, lines of code, etc.)

He talks about Quality Assurance practices and team development.  Interestingly enough, his book starts with a diagram and commentary on Maslow’s human needs heirachy, and how the needs of a software development group are similar.  He proposes a Bill of Rights for the project team, and a Bill or Rights for the customers.

He offers a project health quiz–allowing you to measure your project to see how probable it is at succeeding.

McConnell ends his book with a chapter on project do’s and don’t, borrowed from NASA.  These are:

Software Development Project Do’s:

1. Create and follow a software development plan.
2. Empower project personnel.
3. Minimize the bureaucracy.
4. Define the requirements baseline, and manage changes to it.
5. Take periodic snapshots of project health and progress, and replan when necessary.
6. Re-estimate system size, effort, and schedules periodically.
7. Define and manage phase transitions.
8. Foster a team spirit.

Software Development Project Don’ts:

1. Don’t let team members work in an unsystematic way.
2. Don’t set unreasonable goals.
3. Don’t implement changes without assessing their impact and obtaining approval of the change board.
4. Don’t gold-plate (don’t add features no customer asked for).
5. Don’t over-staff, especially early in the project.
6. Don’t assume that a schedule slip in the middle of a phase will be made up later.
7. Don’t relax standards in order to cut costs or shorten a schedule.
8. Don’t assume that a  large amount of documentation ensures success.

 Overall, this is a great book for new software development managers, and software development mangers who have chosen SDLC, or other non-Agile development methods.  Published in 1998, this book came out before the Agile software development movement.  Regardless, it’s a good book to refer to occasionally.

Mike J Berry
www.RedRockResearch.com