What is ProcessMashup ?

ProcessMashup is an approach to devise a 'Mature Agile' process that will fit different types of projects. This site discusses the tailoring of processes with the specific goal of enabling successful project delivery for different types of projects.

By "Successful" we mean; delivering the business objectives within the planned timeline and to the budget estimates, while providing accurate reporting of progress in an environment that encourages creativity and innovation and builds a positive cross department collaborative environment.

By "Mature" we mean, tailoring the process model to meet the requirements of the business, not hindering the agility of the team, but optimising the team performance, such that it is clear what each team member's objectives are - giving the team the information they need (without wasting the team's time on tasks that are of no benefit)

ProcessMashup will discuss tailoring of processes - with respect to the level of detail that is appropriate and different levels of process for different project types.

Its clear that a PCI-DSS (Payment Card Industry Data Security Standard) development will require a level of detail much greater than a simple change to a form on an internal corporate application - the challenge is to adapt the Agile approach to the type of projects you manage, so that any upfront work is balanced by a reduction in the work required to complete the delivery.

The techniques described on ProcessMashup have been used in many different environments, across many project models e.g Blue Sky Start Up's, Outsource Companies, Corporate Organisations, Financial Institutions and Local Government.

History

I started using Agile methods way back in the 1980's. Waterfall was the predominant process and had served huge banking systems well, but, it was proving too bureaucratic and cumbersome for innovative software houses developing slick new desktop products - Something faster and cheaper was needed to get products to market. Many companies simply cut corners - Honestly, developers getting requirements on the back of a cigarette packet was not just a joke, it was a reality.

There was a lot of demand for rapid development so we tended to evolve ways of working to fit the environment - we were Agile.....

So, has Agile improved the industry ? Are all software developments sleek, fast and efficient ?

In some cases, yes, in others definitely not!

So why ? The concepts of Agile are sound, surely Agile Methods should be working in all cases ?

Well, I am seeing exactly the same issues with the implementation of Agile methods that we saw with waterfall.

Agile process frameworks are being taken off the shelf and implemented without customisation. This approach is leading to major issues in companies, where the way they are implementing Agile methods is slowing down developments and costing more than the old waterfall models did.

Also, Agile in some organisations is becoming a bureaucratic nightmare with strict rules of execution that are defeating the original objective of Agile which was a flexible approach to software development.

Here are some statements I have heard, which are purportedly required in order for a project to be truly Agile;

• Sprints can be no more than 3 weeks long.
• Testing cannot happen until the end of the sprint.
• Requirements are captured in discussions never documented.
• Designing software is pointless and not Agile.
• Agile is changing the requirements being delivered on request.

All of these statements can, when applied to the right type of project, be really positive, but apply them to the wrong project and they can cause SIGNIFICANT PROBLEMS.

Whats the problem of enforcing strict rules to Agile?

Here we illustrate how we could have drastically different outcomes if we enforce rigid rules to markedly different project profiles;

• Problems : Splitting a 3 month development, with fixed requirements, into 3 weeks sprints can add about 50% to the delivery time - for no real benefit. The tracking of progress could have been achieved simply and more efficently.
• Positives : Frequent releases of changes on bespoke projects can help build the customers confidence.

"Testing cannot happen until the end of the sprint." :

• Problems : Not being able to do testing as the development of stories complete, results in a lot of problems being identified late on in the release, this increases the risk of delaying the release significantly.
• Positives : Where there is a significant interdependence between functionality, then starting testing before all the interdependent functionality is complete could result in a lot of wasted effort, as any issues identified will be based on stand in API's and stimulated data.

• Problems : If the stories being delivered are fixed e.g (building on an existing product where the customer knows what User Experience they want delivered) then there will be confusion over the changes needed because verbal agreements can be misinterpreted, resulting in many iterations to get the features developed and accepted.
• Positives : If the project is a collaborative development (where the customer is not sure how the changes should work and wants to work with the team to try different approaches) then verbal communication is a good way to hone ideas and convey goals and objectives.

"Agile is changing the requirements being delivered on request" :

• Problems : On projects with fixed goals and delivery commitments, then this approach can cause massive delays and never ending projects, there are always changes that can be found to software!
• Positives : On collaborative development projects, then this is the only way to progress and get the best results, there are no hard timescales and achieving the best solution is the target.

"Designing software is pointless and not Agile" :

• Problems : On enterprise scale developments with teams in different locations and timezones, without design, you can end up with different software solutions to the same problem, because there is no clear guide on how the implementation is expected to be structured. The result of this is Software that isn't compatible being developed by different teams. This results in a lot of defects, a lot of development time to integrate components and a very expensive product to maintain.
• Positives : Expecting a small team developing simple changes on an existing product, when they currently work well collaboratively, to go through a design process can be a waste of their time. However it is easier to communicate technical problems and solutions using UML, so it can be beneficial to have the tools available so UML can be used to brainstorm and resolve technical issues.

  Clearly, Agile was never meant to enforce a set of rigid rules and this is the point of ProcessMashup, no one process can be deployed successfully in all environments. Hence the "Mature Agile" approach to adapt processes and working practices to fit with the project environment.