Build Agile. Get Results.
Agile Software/Product Development practices have its origins in multi-national companies such as Chrysler, Toyota. Interestingly, these practices are now increasingly favored by smaller software houses and internet start-ups; yet not completely accepted as a mainstream method by traditional Media Agencies and large, top-down Command and Control focused Companies.
Classic Agile Development
Consider the classic project that was essential to the creation of extreme programming, the Chrysler Comprehensive Compensation System. This was to be a new piece of software to run payroll for Chrysler. In a project like that there are lots of big questions that need to be answered in order to build a working product. But you don't generally have to ask "what problem are we trying to solve?" That's pretty clear. In the case of C3, that was to run payroll for 87,000 employees, who were presumably receiving payroll before the project began.
What causes projects such as this to fail in traditional software development is that the solution is unknown. Agile is one way to succeed, because pursuing unknowns iteratively is a good way to mitigate risk. What do you do if the problem itself is unknown?
Taking an Agile Approach towards developing Business Systems, Marketing Platforms, Account Systems or any medium/large-scale software undertaking assumes that the Product Manager and Software Developers do not have all the solutions at the onset. In the conventional Waterfall, Cascade Development Methodology, lengthy proposals and project requirements are specified on the onset. This assumption is unfortunately more often than flawed. No doubt, there is value in planning product requirements and software design (and Agile does not mean doing away with project planning), Agile emphasizes on an iterative way of solving a big picture/conceptual level challenge.
Implementation Details?
What this means is that Project Planning is done in a shorter time frame of 1 or 2 days, by writing Story Boards (User Stories) and sketching out initial User Interface workflow, instead of lengthy month-long project management meetings and time consuming, drawn-out contract negotiations with software vendors.
Established software vendors who have already internalized Agile approaches and adopted Agile Software Development can be engaged on a time-based fashion, executing project requirements and objectives on a weekly or biweekly iterative basis.
Agile focuses on
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Fixed Plan
No doubt, there are a lot of value on the items listed on the right. However, what Agile Product Owners (Customers, in relation to Vendors) and Agile Development Teams (either in-house or an outsourced Vendor) focuses on, are the items listed to the left.
How Does It Work?
So when Organisations adopt agile development methods, they often encounter new concepts, new artifacts, new planning methods and new roles and relationships. It almost seem that agile teams do everything in a new way. And as Product Owners and Organisations attempt to integrate agile into their existing systems, they often try to map these new concepts to their old, familiar concepts. Requirements are now stories; iterations are now sprints. And a product manager is now called a Product Owner... right?
Well, not quite...
Companies adopting agile methods know that product teams need a voice representing the customer. Developers need personas, market problems and most of all, a prioritized list of requirements. Agile methods advocate a role called product owner to support the product team with customer and market information. Since the closest equivalent to product owner in most companies is the product manager, it seems natural to equate the two.
But product owner and product manager are not the same. In fact, a product owner's responsibilities are just a small subset of product management. It takes effective change management to work in a truly agile way and reap the benefits of effective software development that delivers tangible results and significant cost savings.
Is it really worth it? Will the cost of change moving a Company Structure built on a traditional top-down project management structure justify the Returns on Investment expended on such a paradigm shift?
Getting Results
Agile programming is very different and new. It is a different feel to the way programming happens. Instead of mindlessly cranking out code, the process is one of team dialogue, negot iation around priorities and time and talents. The entire company commits to a 30-day Sprint and delivery of finished, tested software. Maybe it is just one specific piece of functionality but it’s the real thing, including delivery and client review against needs and requirements.
These are typical feedback from participants of truly agile projects. Where project delays and blown budgets are common place in traditional top-down waterfall development teams, agile teams often emerge from each software project feeling more confident, more assured about their own skills and abilities, raring to go for the next project and, most critically, shipping out a usable software system with minimal bugs (if any at all).
Ready for Agile Software?
Drop us a note, if you would like to find out what Agile could do for you and your organisation.