CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell’s Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role.This seemed to make the most sense to me, and to the others present.Mike J. Berry, PMP, CSM, CSP, ITIL

Agile Development and Requirements Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  Scrum is intentionally quiet about software requirements so that groups can use what works best for them.At Red Rock Research,  we show groups practicing Agile how they can benefit from a high-level “strategic” use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow requirements that were missed in the inception phase.This technique has proved quick and effective.Mike J. Berry, PMP, ITILv3, SCM, SCPOwww.RedRockResearch.com

Software Development Best Practices – Software Requirements Management

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 technique.  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 industry 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

Software Development Best Practices – Software Estimation

Posted by mikeberry | Plan-based Development,Software Estimation,Software Requirements,Uncategorized | Friday 10 July 2009 11:02 am

Red Rock Research held our first of a weekly series of seminars on software development best practices yesterday at the Miller Campus – Professional Development Center.  Our topic was Software Estimation.

We covered the typical informal methods: Fuzzy Logic, Wide-band Delphi, Planning Poker, and the primary formal methods: Function Point counting, the Putnam Model, COCOMO II, and COSMIC-FFP.   We also discussed how to estimate the percent of defects still in your application at the time of release.

Along with ‘how’ to estimate software projects accurately, we discussed how to manage the expectations of the executive team and the investors who typically want everything now.  Chris Perry, from the Utah iEEE CS chapter was in attendance and said “All the things your talking about I’ve been living for the past 10 years!”

Join us this Thursday, July 16 for our 2-hour seminar on Software Requirements Management.  The cost is only $10!

Mike J. Berry
www.RedRockResearch.com

Don’t miss these Software Development Best Practice Workshops…

I’m hosting weekly Software Development Best Practice workshops each Thursday during the next four weeks.  These are held during work hours so ask your manager/VP/CIO and perhaps they would like to come along.  The topics are different each week.

This is basically a summary of my three day courses that I am now offering.  I’m giving the info away to get some attention in the valley.  Each workshop is from 3:00 – 5:00pm Thursday afternoon at the Miller Campus – Professional Development Center  This represents a tremendous value as I have put over 3000 hours of research into the material and consumed over 100 industry books.

Topics

Software Estimation – July 9th

Software Requirements Management – July 16th

Software Quality Systems Management – July 23rd

Software Development Life Cycle (SDLC) Management – July 30th

Event Calendar and Info

http://www.utahtechcouncil.org/Events/Community-Events/Community-Calendar.aspx

Hope to see you there!

Mike J. Berry
www.RedRockResearch.com

A Free Software Requirements Specification Template (SRS)!

Need a good software requirements specification (SRS) template?  Use an industry-standard SRS.  Can’t find one?  Well now you have-get it here for free.  Enjoy!

Mike J. Berry
www.RedRockResearch.com
Software Development Process Guidance

25 Most Dangerous Information Security Programming Errors

Want to visit ground-zero for data security?  Experts from SANS, MITRE, SAFECode, EMC, Juniper, Microsoft, Nokia, SAP, Symantec, and the U.S. Department of Homeland Security’s National Cyber Security Division last week presented a listing of The Top 25 Most Dangerous (Information Security) Programming Errors.  Expect to see future government and big-money RFP’s mandate these items be addressed.

Mike J. Berry
www.RedRockResearch.com

Anatomy of an Execution Plan

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here’s an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  OnLine Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system’s business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the ‘rollback point,’ which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to ‘check’ completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a ‘lessons learned’ section to be completed later, and keep a copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

Why you should stop using SQL Server 2000+ (even though it’s a superior product!)

SQL Server 2005 is fantastic.  SQL Server 2000 was wonderful.  SQL Server 7 was OK.  I hear SQL Server 2008 will be even better…

…but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives?

Don’t get me wrong.  I’ve grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name.

Because SQL Server (and Oracle) are highly visible in the public’s radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier.

So my client is spending $500,000 and seven or eight months upgrading their core product–and all of the internal support tools that must work with it–to SQL 2005.  Again why?  To ‘add value to the customer experience’…meaning that the salesperson can say “yes, it works with SQL 2005.”

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for ‘clues’ of what should separate an inferior product from a superior product, and–well–version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer’s radar.  This way, they would have no ‘journal information’ about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft.

PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn’t affect you, but if you make a commercial client-server product, there’s no doubt you’ve experienced this already.

Mike J Berry
www.RedRockResearch.com