Agile is No Substitute for SDLC

Agile software development, as defined in Wikipedia, “refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams“.

Many articles, blogs, and discussions have been written over the past few years regarding the benefits of Agile development. In fact, as a management method, Agile has peaked as the latest fad to sweep software management consulting, and as a result, it has become very popular with IT/development managers. Is it just a fad? Perhaps in some ways, but its value can’t be understated when utilized for the right type of project and under the right circumstances. Specifically, Agile targets small software projects with teams of 10 or fewer, which are focused on the delivery of user interactive software. In these projects, the customer is often better able to fully envision/specify final product requirements through a small series of prototype iterations.

While the need for Agile is real and clear for this kind of development effort, I do wince every time I hear some consulting organization promote Agile as an alternative to SDLC (Software Development Lifecycle).

In fact, the Agile methodology is only applicable to a few project types and lifecycle phases (namely software design, coding, and unit test) within the overall SDLC, and finally, it is very “design/coding focused” in its aim. Agile is a concept produced by software designers/coders for software designers/coders, rebelling against strict waterfall methods that held them accountable for highly accurate requirements and design plans, in situations where iterative passes at requirements and design made much more sense. It quickly became obvious to many, that Agile was a clear improvement for a subset of smaller projects, focused on more user interactive products, and better served by an iterative process.

Agile adheres to a unique set of core principles (listed below) that define its purpose, but it’s important to understand that while those principles are a good match for some of the software development efforts described above, they’re in no way universally advantageous. I’ve provided some competing considerations for each, in an effort to underscore their limits.

Agile Principle		Competing Considerations
—————————-		————————————————-
Individuals and interactions over process & tools		Advantageous for small projects with straight forward single dimensional software deliverables.
		Can really get you into trouble as requirements and / or design size and complexity increases.
Working software over comprehensive documentation		This is no different from SDLC – great documentation is only a goal in as much as it drives quality in software and software related deliverables.
		A poor SDLC management culture can skew quality priorities to the point that it may seem as though the documentation is “the point”, but like any methodology (even Agile), it is only as good as those who use it.
		When requirements come up front or result in a complex design or system of designs, then cycles of documentation and review are absolutely critical to 1. success at any level and 2. achieveing the level of quality required.
Customer collaboration over contract negotiation		An oxymoron if contracts exist at all – contracts/other agreements must allow (enforce) the Agile management dynamic in a way that doesn’t increase risk for the software producer.
		Potentially disastrous if they don’t and you’ve taken shortcuts in documenting requirements.
Responding to change over following a plan		Perfect where the customer priority is the quality of the outcome, especially when they aren’t clear on what that outcome should be when the process begins.
		A recipe for trouble when dates and quality are both important. Which is almost always the case.

Given that Agile is limited to a subset of project types and SDLC phases, it follows that Agile cannot act as a replacement for SDLC. In fact, Agile isn’t a comprehensive project methodology at all, it is a component methodology. As a result, a large system development effort may be separated into a number of individual user focused design efforts that use Agile during development, while other design subsystems within the same project follow SDLC, even for the design, coding, and test phases.

Agile only makes sense as a component of an overarching end-to-end SDLC model despite the tendency of consulting organizations to expand the scope of Agile in an effort to extend the scope of their consulting engagements.

My purpose for writing this piece is to continue to challenge management executives to exert due diligence when it comes to the selection of contract professionals, methods, and the use of consulting organizations. Management methods and tools must be applied to the specific problem space they were designed to address, to avoid poor or even damaging outcomes.

Despite the claims made by some consulting professionals, Agile cannot replace SDLC and cannot meet full lifecycle needs. Agile may in fact be a superior process approach for the software projects you manage, but it only solves part of your project / lifecycle problem. You still need an integrated project level SDLC framework (perhaps with both agile/waterfall component development methods) to manage project initiation through planning, and post development lifecycle activities.

At PMOSoft, we provide the PM Office information and quality management systems (web applications & procedures) needed to achieve the PMO mandate in as little as 3-4 months. Please visit us at
http://pmosoft.com
to learn more.

PM Office Productivity – Make or buy?

Make or buy questions are a common thread in any business function that requires an extensive set of support tools to automate time-consuming manual work. This of course includes PM office management of portfolios, programs, and projects. After all, each PM team is only as effective as the collaboration tools they use to get the work done.

What is meant by “make” or “buy”? In fact, “custom” or “off-the-shelf” is a better way to express the question. The real question being, is a custom solution required/better than an off-the-shelf (OTS) solution?

With so many OTS project and portfolio management platforms to choose from, it’s easy for anyone to believe that at least one will meet their particular needs. In truth, it’s very unlikely unless the function is truly non-unique ( e.g. HR) in terms of methods used and work performed, when compared to similar functions in other companies. Project management rarely falls into this category since projects tend to vary significantly in terms of both methods used and the type of projects being undertaken from company to company. As a result, it is almost impossible to find an OTS PM collaboration system that isn’t an poor fit for team productivity.

The unavoidable truth for all those executives looking for a quick fix that can be obtained with a checkbook, is that “make” is very often the only viable option for real productivity improvement. Most OTS solutions are designed to meet the generic needs of any project in any industry. While that enables a greater number of sales, productivity is better served by tools tailored to the specific needs of the organization. When it comes to quality and productivity, OTS is a path to mediocrity.

So what about the make (custom) option? The advantage of course is getting exactly what you want and knowing exactly what you’re getting. The cost may be competitive too, given that most OTS collaboration systems are very expensive to buy and implement (configuration is often as difficult as development from scratch). On the other hand, building your own is more time consuming and it requires expertise more common to an IT organization than a PM office. If you don’t have the expertise in house, the development can be outsourced, but arrangements will need to be made for long term incremental development as your methods change and to provide ongoing support.

Looking at PM office automation from a top down holistic perspective, it’s clear that methodology and management tools must work hand in hand. Methods are the top priority, and must come first, since they define how work is done and therefore have a direct impact on quality and performance. Tools selection is lower in priority since tools simply make doing work easier and less prone to error. It follows then, that tools should be designed/configurable to meet the changing requirements of PMO methods. It also follows that improvements to methods will often necessitate improvements to the tools that support them (hence the need for the long term commitment from custom developers mentioned above).

Looking at automation from the bottom up, it’s evident that simplicity and ease of use are critical to success. Complex environments with multiple application platforms make training, maintenance, the distribution of work, and data integration and reporting more difficult to manage. When users are required to move in and out of different applications to make progress, they become frustrated and less productive, defeating the purpose of automation. In most cases some mix of enterprise and desktop platforms will be needed, but the total solution should be kept as simple and elegant as possible to reduce the potential for failure.

No matter what direction you take, a successful productivity system offers significant cost savings and increases in both speed and competitive advantage, but only when well planned and executed. Additionally, most of the value is realized via incremental improvements over time and not upon delivery of the initial system.

Some things to consider before you begin: Why are you asking the question, make or buy?

• What is the scope of the problem/opportunity being addressed? Do you need a complete system redesign or would some limited or specific improvements achieve most of the gains you’re seeking.
• What constraints (cost, duration, strategic alignment, …) will be applied to any given solution you identify?
• How detailed and specific are existing management methods (steps, forms, templates, reports, …)? As methods evolve, the need for customized tools increases.
• How flexible can you be with respect to existing methods and where?
• Do you have a well formed evolution plan for the organizations that will utilize or be impacted by the solution you implement?
• What ancillary methods/systems will  your solution be required to support and how?
• What off the shelf tools are available in the market?
• What resources and technologies can you draw upon to develop (and maintain) custom solutions?

It will pay huge dividends to begin with a detailed and well vetted list of system requirements. Just like any development project, it’s critical to prioritize each in terms of cost and payback. Use those requirements as input to a high level design that seeks to identify the best approach for realizing the system considering OTS and make options for each component in addition to the system as a whole. However comprehensive the list of requirements, start small – don’t try to boil the ocean. Since most of the real productivity gains will be realized when making post implementation improvements, it makes sense to start with a small first offering.

In summary, while most PM office organizations don’t have the skilled resources needed to develop and maintain a best in class productivity system, a custom (not OTS) solution is the only viable option to long term productivity gain. To effectively drive both quality and productivity the solution must be designed to support the requirements established by PMO methods and change as methods change.

The beliefs expressed above form the basis for PMOSoft’s PMIQ quality and productivity platform. PMIQ is the custom solution that each PMO needs. It provides tools to manage both PM office methods and collaboration and/or productivity tools that support project management in alignment with your own methods.

PMIQ supports ongoing improvements to both methods and tools while PMOSoft provides the long term expertise to help each client PMO improve and maintain their system over time.

Please visit us at
http://pmosoft.com
to learn more.

Sharing the Stage to Win in Project Management

What kind of manager are you, theory X (TX) or Y (TY)? As we all learn at some point in our education, TX generally assumes that employees are shiftless and lazy, and will only work if they’re forced to do so. TY on the other hand assumes that all employees want to do a good job, and if given the responsibility, authority, and tools to get the job done, they will devote themselves to the best outcome they can generate.

In reality, of course, things are never this binary. Any group will have some people that generally fit the TX profile and others who better align to TY.  It’s the job of each manager to extract the maximum value from the teams they manage, and within the framework of project management, that requires more than their obedient follow through on assigned tasks (i.e. TX). It requires each team member’s best research, critical thinking, and independent action towards the best possible project outcomes. In short, they have to own the problem right along with the PM. It is the PM’s job to make sure they’ve identified resources that can and will do just that.

Getting the best work from a team necessarily means placing trust in each team member. PM’s with a proclivity to “play the hero”, will often claim that project responsibility falls squarely on the their shoulders alone, but such statements smack of a TX mentality. The PM hero will often shoot from the hip, make decisions in a vacuum, and under utilize team members by limiting them to assigned tasks and not utilizing them as subject matter experts in planning and decision making efforts. While it’s true that the PM is ultimately accountable for project outcomes, those with highly developed management skills will involve their team members in identifying what needs to be done and providing expertise in decision making, as well as actually doing all the work. This level of engagement is important since projects, in addition to meeting business requirements, also have a significant impact on team building, professional development,  and employee on the job training for employees and partners.

So what does it mean to “share the stage”?  It means, making important delegations that challenge team members, helping them to exceed those challenges, and then giving them the credit when they do. This behavior builds leadership skills for tomorrow and motivates employees to do their best work for the PM. It motivates them to work with the PM again whenever the chance arises. Employee satisfaction improves when team members are given the chance to have an impact and are recognized for good work. Gallup (the poll production company) made the connection years ago that customer satisfaction follows in a direct correlation to employee satisfaction, so there is a direct impact on customer loyalty. OK, all good stuff, so what’s in it for the PM.

Well here’s the odd part – the part that doesn’t really seem logical. The good  guys really do win in the end. Although it’s hard for some the get their heads around (you know them), when someone takes on a management role, it becomes less about them and what they do personally, and more about what they are able to accomplish through others. While the PM was busy delegating all the interesting work to team members, selflessly helping them win the glory, and openly praising their efforts, all eyes above were fixed on the PM. Why? Their team was well motivated, engaged, and productive. They obviously selected the best and used them wisely because project outcomes were very good and  this was highlighted when the PM personally took steps to praise the great work done by key team members in project reports. In general, this PM seems to be creating win-win scenarios in every direction.

I heard it best stated in an old AMEX advertisement where the young restaurant owner says, “My father told me, you can do anything you want to do – you just can’t do it alone.” Absolutely right – you need the team. PM’s who don’t realize that, won’t get the best their team has to offer, and all project related outcomes will suffer.

PMOSoft provides the PM Office information and quality management systems (web applications & procedures) and consulting expertise needed to achieve the PMO mandate in as little as 3-4 months.  Please visit us at
http://pmosoft.com
to learn more.