For those not familiar with Scrum, let me summarise the key principles quickly:

1. A project team is setup usually consisting of between 5 and 9 resources.
2. The resources within the team have the set of skills needed to develop products.
3. There are defined roles within this setup, namely

• The Product Owner: Manages a list of product features that require development. These features are prioritized by the Product Owner.
• The Scrum Master: Ensures that the processes are followed and helps the team deliver the product features by removing any impediments that prevent them from delivering.
• The Team: Self organises around the product features and collectively work together to deliver these product features.

I’m simplifying the roles here of course – there are further responsibilities that are played by each role, but this is the essence.

4. The team produces working demonstrations of the product features at regular intervals (typically every two weeks).
5. These working demonstrations are visible to the business, allowing the business to get a view on where the product is going and whether it needs refinement or a complete change in direction.
6. The refinements or improvements are then fed back into the team, prioritised by the Product owner and driven through to demonstration once again.

The framework is agile in nature. Problems are quick to identify, and quick to change. Traditional project management methodologies would allow a project to proceed down a long and drawn-out development path and if the up-front analysis had not been 100% accurate, or if external factors had required a change to the project during development, this would be very difficult to accommodate. The Scrum process by contrast makes sense – it is a simple, logical way of delivering projects and caters for changing requirements.

That said, the question of how to setup the Scrum team and environment remains. As a new team, we are facing these questions and trying to figure out the best path to creating the esteemed “High Performance Team“. There are two schools of thought here. Let me deal with the first.
As competent and experienced team members, there is a sense of “doing things right, from the start”. This includes everything from ordering the right development hardware, deciding on what software is appropriate, defining the practices and principles the team is going to follow, which languages are best suited for the projects that need to be developed, and what the collaboration environments need to look like. All good stuff, and completely necessary. The planning also includes discussion and decisions around how to test the code that is developed, how it is documented, how much of this is automated versus manual, which tools are best suited for testing, how new issues get logged and fed back into the team, and how much test coverage is considered acceptable. Again, all good stuff, and all appropriate to the work that is being done within the team. It is also a good idea to get the overall context of the project defined up front so that broad architecture decisions can be made. Where the team needs to be careful however, and we are all sometimes guilty of this, is when it comes to over-engineering a solution up-front. Chances are that this picture is changing, or will eventually change. Nothing wrong with good architecture up-front, but trying to understand too much detail too soon is probably wasted effort.

Lets take a look at the second school of though for a moment. The principles of Scrum and Agile development methodologies and practices suggest that the value lies in delivering small, incremental features, regularly. Mistakes and changes to project scope are inevitable and it is the ability of the team to correct these mistakes, and accept the changes in scope that makes them “High Performance Teams”. Through continuous feedback and team “retrospectives”, the gaps get filled, and the holes get plugged. The team continues to improve as a result and the delivery continues to speed up – well, from the initial stages anyway. Its a situation in which the team adapts the principles of Agile software development to suit their unique environment, the individual strengths and weaknesses and their team characters.

The point that I am trying to make here, is that there are two ways to try and achieve the “High Performance Team”. There is the “Lets build the 6-foot armour-plated robot with Augmented Reality vision”, or, the “Lets build the stick man and determine what he needs next” approach. There is a fine line between setting up a team that does everything right from the start, and a team that is setup to learn how to do what is right for them.

I was recently made aware of an agile development team based in the UK that has been together for the past 60 months. They deliver code weekly, have a number of visible metrics for how many bugs are in their system and how quickly they are resolved, what the velocity (capacity for delivery) of the team is, converted into monetary value, and a number of other “reporting” metrics. Incredibly useful information, and a sign that they are a “High Performance Team”, but I wonder how much of that was setup from the start, and how much of it “evolved” as the team progressed through their 60 months of development together?

To take the analogy used above, whilst it is important to have a team vision in place and to follow best practices where ever possible, I firmly believe that it is best to create the stick-man from day one, and get him running in an agreed direction, rather than spend too much time thinking and planning the 6-foot robot that potentially is only capable of taking a few steps at a time, and hopefully, in the right direction.

That being said, our team is in a good place. We are positioned nicely and are moving forward as a unit. Hopefully the discussions that our team have had, and the conclusions drawn here, can help you position and setup your own team.

Whatever the reason for neglecting security may be, such neglect can compromise much more than just the “non-sensitive” application data. Consider for example a recent incident at one of the biggest Brazilian mobile companies. An issue was found in a file called popup.php. The code in the file had the apparently simple objective of appending the company logo and loading a given file’s content into a popup window. So the excuse of “non-sensitive” data seemed to apply in this case.

We can easily imagine that the need for this page probably originated in the <insert non-tech department> and got escalated to the tech department with high priority (late on a Friday afternoon). In the rush the priority was to “Just get it done”, and ignore the worries about security. “No problem” you say, “leave it like that during the weekend and redo it on Monday following the proper protocols”. What happens of course is that code is never looked at again….until the day THE EPIC FAIL happens.

In retrospect we can easily see how the popup.php file led to THE EPIC FAIL. The final URL used by the popup.php file had a “url” GET var attached to it, the value of which usually pointed to another html or PHP file. This is an open invitation to try and point the GET to any file that would be “unexpected”, like so:

The result of this request immediately made obvious that at least 2 security issues were overlooked by the developer. Can you see which ones?

The first mistake here was leaving display_errors on – and this shows us the second mistake(s). The obvious one was neglecting to stick to the rule: “Filter input, escape output”. The developer obviously actually executed an include on the file specified in the URL. We can see that he did not check in any way the value provided in the “url” parameter, but he should at least have checked whehther the file was still in the site’s file tree.

To turn this exploit into something dangerous you simply need to start passing it sensitive files, like /etc/passwd or try to load the apache httpd.conf file (which actually worked in this case).

Analyzing these files showed that the problem was severe. The actual site had little valuable information, but it did show that the server had much more on it than just this site – this qualifies as an EPIC FAIL because it compromised all systems on that server. Another factor that contributed to the severity of the problem was Twitter. This flaw was only fixed 2 days after it was first reported and in the interval the detail of the exploit was widely circulated on Twitter, giving everyone the chance to look at configuration and other files. Only the victim knows if any sensitive data was compromised, but given the creativity of hackers nowadays, something was compromised for sure.

This demonstrates that security is not a simple “injection” or “pill” you can give your application after it is live – security needs to come from the ground up, leave the quick fixes for the occasional software bug. Your development cycle must include security concerns in the form of tests, validations or anything else you can think of. OWASP is a great source of points to think about. No feature should roll out the door if it did not take security into consideration. One approach is to incorporate security into your “Definition of Done”, so that a task can only be complete after security steps are taken to validate it. Peer review can further contribute to enhanced security – two heads are better than one. Managers should be as worried about this as the programmers should be. An example of such a Definition of Done is:

• Developed
• Tested (Unit Tests written and executed)
• Documentation (proper doc file or PHPDoc blocks for code segments)
• Peer review
• Security check (for known flaws, like input filtering)
• Load Testing

Every task should include the above. Even though it may cost some project development time, it will save you even more time and effort if someone attempts to hack your site. Including security in the set of tasks gives the developer time to plan each feature and reduces the risk of exploits being released. Taking security into account is part of becoming a professional developer and leaving behind the code-hacker ethic which means just coding and not considering the environment in which the application exists.

Needless to say the security-conscious approach has to be embraced by management because it is usually up to them to fight the battle for more development time and proper development cycles, and not to simply give in to external pressures – which leads to the risk of distributing dangerous code.