christopher bischoff's List: Agile

• Somehow, over the decade or so since the original agile manifesto, agile has come to mean ‘management agile’. It’s been captured by management consultants and distilled as a small set of non-technical rituals that emerged from the much larger, richer, but often deeply technical set of agile practices.
• Agile has indeed become a cargo cult. Stripped of actual software engineering practices and conducted by ‘agile practitioners’ with no understanding of software engineering, it merely becomes a set of meaningless rituals that are mostly impediments and distractions to creating successful software.

• The core problem is that non-technical managers of software projects will always fail, or at best be counter productive, whatever the methodology. Developing software is a deeply technical endeavour. Sending your managers on an agile course to learn how to beat developers over the head with planning poker, two week iterations and stand-ups will do nothing to save spaghetti code and incompetent teams. You might have software projects that succeed despite the agile nonsense, but that would be coincidence, not causation.

  Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation. If your role is simply asking for estimates and enforcing the agile rituals: stand-ups, fortnightly sprints, retrospectives; then you are an impediment rather than an asset to delivery.

• I don’t have an answer, or an alternative methodology to offer you, but here are some things that any software development organisation must address:

  • The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
  • The motivation and empowerment of programmers has a direct and strong relationship to the quality of  the software.
  • Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
  • The consequences of poor design decisions multiply rapidly.
  • It will usually take multiple attempts to arrive at a viable design.
  • You  should make it easy to throw away code and start again.
  • Latency kills. Short feedback loops to measurable outcomes create good software.
  • Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
  • Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.
• Because the technical and motivational aspects of software development are so key, I’m very intrigued by the zero-management approaches of organisations such as Valve and GitHub. I thoroughly recommend reading the Valve employee handbook and Michael Abrash’s blog.  Maybe that’s the way forward? The original agile manifesto was very much about self organizing teams, it would be great if we could get back to that. In the meantime, the word ‘agile’ has become so abused, that we should stop using it.

3 more annotations...

• encouraging organizations to align around products instead of projects.
• On average 29% of an IT budget is spent on new system development while 71% is spent on maintaining existing systems and adding capacity to those systems. This is because organizations do not retire applications. A lot of money is being spent on maintaining mission critical applications. Some of these applications are even running on software no longer supported by the vendor. More money is being spent on applications that have part or all of their source code missing. This is mainly because once a product is delivered to production, the project team that built it is disbanded and team members move onto different projects.  Organizations have no way to rationally decide what to retire. Everything is rolled up into one budget and there is no clear way of deciding what systems are generating value and which are not.
• Amazon applies the motto “You build it, you run it”. This means the team that develops the product is responsible for maintaining it in production for its entire life-cycle. All products are services managed by the teams that built them. The team is dedicated to each product throughout its lifecycle and the organization is built around product management instead of project management.
• Using this approach, teams can measure cost and value delivered per product team.  Teams can rationally determine what to prioritize in their product backlog and teams can self-manage using a lean startup methodology.     The architecture groups becomes responsible for regulating and monitoring system-level attributes     while the PMO regulates and measures to prevent “market failure” and external factor. Some Ops team members will move to work with the product teams while other Ops team members are no longer responsible for supporting the application but instead manage the infrastructure that applications run on. It is kind of like an in house infrastructure as a service with Service-Level-Agreements for the product teams.
• Using a product management approach, the organization now has budgets for product teams instead of new development or maintenance. Budgets are no longer lumped together, but are instead dedicated to specific product lines. Each product team needs to make the case why their product needs funding based on the business value that it generates compared to total life-cycle cost. Using this approach, organization can now make business decisions as to which products to innovate on and which to cut or retire.
  

3 more annotations...

• he short rationale is that in Agile and really any lean, successful company, you want "everyone to touch the product". Security guys need to code, those that don't (the majority) are not required.
• Paul Graham says "a programmer working as programmers are meant to, is always making new things". I would argue this should be true for everyone working on agile projects including security people. The only people that add value are coding, designing the UI, testing etc; "touching the product". Unfortunately most security people are not doing this; they create documentation, provide advice and consulting, "manage risks" or manage other security people and thus at best add zero value.  Arguably you would be far better having only security engineers that coded the security components and where they performed code reviews and security testing actually fixed the problem

• “We introduced Scrum and it works really well” and “we’re too slow to bring new features to our customers”.
• that sounds like a typical case of sub-optimization. You optimize only one part of a value stream but not others. While that one part (e.g. development) is getting faster and faster other parts of the system are not able to keep up the new pace. The development team will either run low on User Stories or it will swamp QA or Operations with features to be released. In the worst case, you end up slowing down the whole feature creation process instead of speeding it up.

• the Agile Manifesto revealed the weaknesses and immaturity of the founding principles. The two most disturbing: “Working software is the primary measure of progress” and “Business people and developers must work together daily throughout the project.”
• Using “working software as the measure of progress” is narcissistic. Rush to write code is oft the translation of this misguided principle. Software developers want to be measured on what they know — code — instead of what they don’t know: the domain, business requirements, and the user. The idea is that you’ve got nothing if you don’t have working software. The cop-out is thinking that code is the measure of everything. Software is always part of a bigger picture. It works in conjunction directly or indirectly with other software, technologies, the environment, business processes, and people to create customer experience and/or improve operational efficiency. Like most of the Agile principles, this one is developer-centric rather than user-centric.
• “Business people and developers working together daily” is lazy. This principle is a capitulation by developers who say it is impossible to understand the true requirements. Developers would much rather stick with what they know: typing class definitions, if-then-else statements, and looping constructs into glorified text editors. The absurd Agile solution to getting the requirements right is to meet with the business every day (or frequently). Often the business people who are involved are not the same as the users, and they are not domain experts or design experts. Seriously, can your best people be available to help developers do their job? The cop-out is thinking that great software can be developed through a process of dead-reckoning with business people. This is just another way for software developers to blame the business for challenged or failed software projects and a sure-fire way to propagate uncertainty and mediocrity. It is a false argument to say that developers cannot understand the requirements and anticipate changes. Development teams must understand the business and the users better than they understand themselves.
• Agile adoption at 38.6% in 2010 and notes that interest in Agile remains very, very high. Most of the evidence I have seen is anecdotal — of the “It’s a miracle. I can walk again!” kind. My take is that the Hawthorne effect is hard at work after years of brain-numbing sequential processes such as waterfall. Anything was better than the worst.
• For the future of application development to be insanely great user experiences, we need a new software development methodology. Agile is not it. Agile is a group of methodologies that came from asking, “How can we fix the software development mistakes of the past?” We need a new approach that asks, “What software development process prepares us to be experience creators?”
• One of his key conclusions is that successful software projects reduce uncertainty. Parallel work streams can reduce uncertainty and the number of costly iterations
• Immersive. Software is a means to an end. That end is to deliver applications that exhibit the seven qualities of great software: user experience, availability, performance, scalability, adaptability, security, and economy. All seven qualities are important and interrelated. But if you get the user experience wrong, then nothing else matters. Developers often blindly rely on businesspeople, business analysts, user experience designers, and customers to tell them what will make a great user experience. Writing code is the least of the talents of great software developers. Immersing is a domain that takes time and hard work. Software development leaders must deeply immerse themselves in their users' domain.
• Software. That’s what we develop. That’s what we deliver. However, the future software development is experience. Blame Apple if you want. Thanks to the mobile revolution, user expectations for software, whether that software is mobile, web, or traditional, have never been higher. People use apps that are amazingly intuitive to use and that make them feel pampered. They quickly start to wonder why all their software experiences can’t be like that. The bar has risen — big time. My view is that software developers are much more than coders. Software developers are experience creators.
• Studio. Software development is not pure coding, engineering, architecture, management, or design. It is cross-disciplinary. Better yet, it is its own discipline. It is more akin to making a movie than to building automobiles on an assembly line. The studio revolves around talent. Great software talent means renaissance developers who have passion, creativity, discipline, domain knowledge, and user empathy. These traits are backed by architecture, design, and by technical know-how that spans just knowing the technology flavor of the day
• • Software is not code. It creates experience.
   
  • Development teams are not coders. They are experience creators.
   
  • Technical talent is table stakes. Great developers must be design and domain experts.
   
  • Process is bankrupt without design. You get what you design, so you better get the design right.
   
  • Software is a creative endeavor, not an industrial process like building automobiles. The methodology is structured to support the creative talent.

8 more annotations...

• Agile is a philosophy - defined by 4 comparative value statements and 12 principles.  So the top-dog rightly focuses the company on one well defined Agile process - Scrum.

• manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:
   
   1. Individuals and interactions over processes and tools?
    2. Working software over comprehensive documentation?
    3. Customer collaboration over contract negotiation?
    4. Responding to change over following a plan

• Per sprint: 
   
   
  • Get to the daily scrums and fortnightly sprint planning sessions so I can put forward my valuable chicken advice and requirements. This will probably only work if I am in the same room, which could be a challenge since I am in a different continent but I will work on my boss on that.
   
  • Threat model. Try to get the developers and product guys to think of mis-use cases and attack trees per sprint. This could be challenging, as they will probably say NO (although Lulzsec, Sony and RSA are helping my cause here and I know a few physiological tricks now to exploit). Nevertheless, a sprint may also be too small a unit for threat modelling. This may work best per release.
   
  • Security unit test cases. Writing security unit tests along with the developers’ functional unit test. These should be from the threat model and will also be automated and added to the regression suite where possible
   
  • Static analysis. We have an automated code-scanning tool, which the developers should be running every time they check-in code. Tickets are then raised for defects. Let's see how quickly these get fixed and what priority they receive. I will also be pushing for manual peer review by both developers and me. One of the biggest problems I can for see is although there is a lot of new code being written, there is many existing assets to be re-used. The web stuff from the start-up is being manually pen tested but doubt anyone has reviewed the code and we will not have time to do that.
   
  • Dynamic analysis. We also have the Q/A group that use an automated application vulnerability scanner. I will be looking at that, working with them to tune and raising tickets for defects.
   
•  Per release:  
   
  • Manual penetration test. Sorry I promised at B-sides to call this a security controls review, as we are too soft and squishy for outcome based testing. Even if we were not the CEO is probably not going to like the spear phishing email nor our partners when we try to hack through them. Still we have an internal team for this testing and it will do what it always does give us some comfort we are running faster than the guy running from the bear.
• For the program:
   
  • Try getting the developers some secure coding training. They have already started so I like my chances of finding some time between 1-4am. Maybe bribing them with beer will work. We have secure coding standards, which I will also make them aware of, but unfortunately, they do not cover all languages in use. Enough general OWASP stuff to be of use though.
   
  • Security incident response plan. I am a big fan of having the fire engine well tuned. A full rehearsal hardly ever happens in a project but once again, at the start I am optimistic.
   
  • Security architecture. We have specialists within the architecture team drawing boxes and lines. This all looks good, reusable loosely coupled authentication services, role based authorisation, logging, and encryption in the right places, DDOS protection. Policies and standards are providing the broad requirements.
   
  • Infrastructure and network security. The ops guys will do their normal job of reviewing builds, installing configuration compliance, vulnerability scanning and setting up the correct firewall rules. YAWN.... Well until IP V6 stuff-ups makes all this important again. Manual controls review will test this all as well for what it's worth.
   
  • Security governance and risk reporting. All the existing 10 levels of security and risk committees will be used. The big test as always will be whether we can convince them to delay launch to fix the 10 medium-low risk security bugs. Think about that for a bit before you comment.
   
  • Metrics. Therefore, we can actually measure the ongoing state of security and whether the secure at source approach has been effective.
• Security at source in agile development my approach:
   
   
  • Get in the room, be a pig if possible
   
  • Write threat models and security test cases per sprint or release
   
  • Source code review on check in. Dynamic and manual testing
   
  • Developer secure coding training and coding standards
   
  • Security architecture at least conceptual
   
  • Infrastructure and network security. #bettersafethansony
   
  • Incident response plan that is rehearsed
   
  • Security governance and risk reporting and escalation
   
  • Measure everything. Especially after you release
• Do we all just have the waterfall SDL hammer and everything looks like nail?

3 more annotations...

• Some of Agile’s characteristics:

    
   
  • Low overhead methods that emphasize values and principles rather than processes
    
  • Project priorities are re-evaluated on a continuing basis in cycles of a week, a month, or sometimes longer depending on the project
    
  • Especially beneficial for small teams with rapidly changing requirements
    
  • Allows for testing of the product in components

• Some of Agile’s characteristics:

    
   
  • Low overhead methods that emphasize values and principles rather than processes
    
  • Project priorities are re-evaluated on a continuing basis in cycles of a week, a month, or sometimes longer depending on the project
    
  • Especially beneficial for small teams with rapidly changing requirements
    
  • Allows for testing of the product in components

• The Waterfall methodology has been identified by the following characteristics:

    
   
  • Classic methodology that has been used and proven effective for simple development projects
    
  • Involves a series of gates or phases that must be completed in sequence
    
  • Requires all requirements gathering to be completed up front
    
  • Requirement changes become more difficult and more expensive as a team proceeds deeper into the life cycle
    
  • Recommended – for shorter duration projects (within 6 months) where clear vision and stakeholder commitment exists

1 more annotation...

• 1. Revenue

   

  The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realised early as the product continues to develop.

   

  2. Speed-to-market

   

  Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and ‘perpetual beta’.

   

  3. Quality

   

  A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.

   

  4. Visibility

   

  Agile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.

   

  5. Risk Management

   

  Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there’s still time to make a material difference to the outcome.

   

  6. Flexibility / Agility

   

  In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it’s expected. Because the one thing that’s certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it’s imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.

   

  7. Cost Control

   

  The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.

   

  8. Business Engagement/Customer Satisfaction

   

  The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.

   

  9. Right Product

   

  Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It’s all too common in more traditional projects to deliver a “successful” project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.

   

  10. More Enjoyable!

   

  The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what’s right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.

• scrum is not the same thing as Agile. Scrum is just a technique used to foster face-to-face communication. I like scrum and have had good success with it because, a) it promotes a subtle form of peer pressure in the group, and b) developers often come up with ingenious solutions when discussing problems in an open forum. Sure, it embodies Agile’s quest for simplicity and efficiency, but that’s just facility – not the benefit.

    

  Scrum is just a technique, and some Agile techniques work in particular circumstances, while others don’t. For example, I have never got pair programming to work. That could be due to the way I paired people up, or the difficulty of those projects might have made pairs impractical, or perhaps the developers were just lazy (which definitely does happen).
• The second point is that people break process. Mr. Markham does not accept that, but sorry, there are just not that many variables in play here. We use process to foster and encourage good behavior, to minimize poor behaviors, and to focus people on the task at hand. That does not mean process always wins. People are brilliant at avoiding responsibility and disrupting events. I couch Agile pitfalls in terms of SDL – because I am more interested in promoting secure code development – but the issues I raise cause general project failures as well. Zealots. Morons. Egoists. Unwitting newbies. People paranoid about losing their jobs. All these personality types figure into the success (or lack thereof) of Agile teams. Sometimes Agile looses to that passive-aggressive bastard at the back of the room. Maybe you need process adjustments, or perhaps better process management, or just maybe you need better people.
• If you use a hammer to drive a screw into the wall, don’t be surprised when things go wrong. Use the wrong tool or technique to solve a problem, and you should expect bad things to happen. Agile techniques are geared toward reducing complexity and improving communication; improvements in those two areas mean better likelihood of success, but there’s no guarantee. Especially when communication and complexity are not your problem. Don’t blame the technique – or the process in general – if you don’t have the people to support it.

1 more annotation...

• My proposal for a new measurement framework is the Agile Triangle: Value, Quality, and Constraints. The measures are value, to the customer in terms of a current releasable product; quality (to deliver continuous value to the customer, in terms of a reliable, adaptable product); and constraints (the traditional scope, schedule, and cost). Constraints are still important project parameters, but they are not the project’s goal. Value and Quality are the goals and constraints may need to be adjusted as the project moves forward to increase customer value. Schedule might still be a fixed constraint, but then scope could be adjusted to deliver the highest value within the schedule constraint.

   

• DevOps State of Mind

  Ask your developers the following questions:

  • Can you describe the runtime environment of your web application?
  • Do you know the release process for your app?
  • What are the most critical issues operations is dealing with currently?
  • When is your work done?

  The answers to these questions tell you whether your developers are thinking out of their “code creation” box and consider deployment of their app as part of their work. Only if they show at least some basic interest in the operations realm are they ready for DevOps. If your developers think they can just “throw their work over the fence to QA” (or the build server), or, even worse, that they’re done once they commit their code to version control, you’ve got a long way to go.

• Ask your sys admins the following questions:

  • Which new features are upcoming?
  • Do you look forward to the next release?
  • When was the last time you talked to the developers?
  • Is your work creating business value?

  The answers to these questions show you how the sys admins think about their work and their areas of responsibility. Only if they are involved in development to a certain degree and welcome frequent change (i.e. creating business value) are they ready for DevOps. If they only think about avoiding change and don’t care at all about what’s upcoming or what’s creating business value, you’ve got a ways to go with your sys admins as well.

• What is DevOps?

  DevOps is a culture of talking and working together. Starting DevOps means starting a mind shift for your developers and sys admins. Only if people are ready to talk to each other and to care about each other’s work will you be able to create more business value, faster. Only then does it makes sense to look at the processes and tools that support the DevOps culture.

1 more annotation...

• Within that business process there are all kinds of activity that needs to happen, some technology-driven and some human-driven. This is where all of the different functions of IT come into play. Developers, QA, Architecture, Release Engineering, Security, Operations, etc each do their part to fulfill that process.

   

  

   

  But if you take away the context of the business process, what have you got? You've got a bunch of people and groups doing their own thing. You lose any real incentive to fight inefficiency, duplication of effort, conflicts, and disconnects between those groups. It's every person for themselves, literally.
• The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible. Without the business, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.

• Doesn't this sound a lot like the goals of Agile?

   

  If the goals of DevOps sound similar to the goals of Agile, it's because they are. But Agile and DevOps are different things. You can be great at Agile Development but still have plenty of DevOps issues. On the flip side of that coin, you could do a great job removing many DevOps issues and not use Agile Development methodologies at all (although that is increasingly unlikely).

   

  I like to describe Agile and DevOps as being related ideas, who share a common Lean ancestry, but work on different planes. While Agile deep dives into improving one major IT function (delivering software), DevOps works on improving the interaction and flow across IT functions (stretching the length of the entire development to operations lifecycle).

1 more annotation...

• Advantages of this iterative approach to software development include:
  
  
  • Reduced risk: clear visibility of what's completed to date throughout a project
    
    
  • Increased value: delivering some benefits early; being able to release the product whenever it's deemed good enough, rather than having to wait for all intended features to be ready
  
  
  • More flexibility/agility: can choose to change direction or adapt the next iterations based on actually seeing and using the software
  
  
  • Better cost management: if, like all-too-many software development projects, you run over budget, some value can still be realised; you don't have to scrap the whole thing if you run short of funds

  For this approach to be practical, each feature must be fully developed, to the extent that it's ready to be shipped, before moving on.

  Another practicality is to make sure features are developed in *priority* order, not necessarily in a logical order by function

• Pareto's law is more commonly known as the 80/20 rule. The theory is about the law of distribution and how many things have a similar distribution curve. This means that *typically* 80% of your results may actually come from only 20% of your efforts!

• Differences between Engineering Methodologies and Agile Methodologies
  

  • Predictive vs Adaptive - Engineering Methodologies are Predictive in nature and they focus too much on pre-planning of the processes in great detail. This obviously makes them comparatively less flexible for future changes. Agile Methodologies in contrast are Adaptive in nature and they welcome changes even to the point of changing themselves.
  • Process-oriented vs People-oriented - Engineering Methodologies are Process-oriented. As mentioned in the above point they focus on pre-planning of processes in great detail and subsequently come up with a defined overall process to be used by whosoever uses it. Agile Methodologies on the other hand are People-oriented as they believe process definition is not an independent thing and the development of a software relies heavily on the skills of the development team rather than on defined processes. Agile Methodologies use processes only to support the development team in doing their work more effectively and efficiently. Process never takes a lead in agile methodologies.

• Differences between Engineering Methodologies and Agile Methodologies
  

  • Predictive vs Adaptive - Engineering Methodologies are Predictive in nature and they focus too much on pre-planning of the processes in great detail. This obviously makes them comparatively less flexible for future changes. Agile Methodologies in contrast are Adaptive in nature and they welcome changes even to the point of changing themselves.
  • Process-oriented vs People-oriented - Engineering Methodologies are Process-oriented. As mentioned in the above point they focus on pre-planning of processes in great detail and subsequently come up with a defined overall process to be used by whosoever uses it. Agile Methodologies on the other hand are People-oriented as they believe process definition is not an independent thing and the development of a software relies heavily on the skills of the development team rather than on defined processes. Agile Methodologies use processes only to support the development team in doing their work more effectively and efficiently. Process never takes a lead in agile methodologies.

• Waterfall Model Vs Agile Model: Conceptual Difference
   After the short interlude of history, let us start the actual waterfall model vs agile model comparison, by starting with the major conceptual differences in the two approaches. Then we will compare the difference in software development life cycle, involved in both approaches. Let us discuss the waterfall model advantages and disadvantages after delving into the main concept. Waterfall model of software development, as the name itself signifies, is a sequential process of software development. Like in a waterfall, the water progressively falls from one altitude to the lower, in a similar way, the production cycle progresses sequentially, from one stage to the other (illustrated by a waterfall model diagram in textbooks). The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance. In this sequentially structured approach, the development team goes ahead to the next stage of development only after the first is fully accomplished. Software development companies adopting this model spend considerable amount of time in each stage of development, till all doubts are cleared and all requirements are met. The belief that drives this kind of software development model is that considerable time spent in initial design effort corrects bugs in advance. Once the design stage is over, it is implemented exactly in the coding stage, with no changes later. Often the analysis, design and coding teams are separated and work on small parts in the whole developmental process. Emphasis is placed on documentation of every stage of software development.
  
• Waterfall Model Vs Agile Model: Efficiency
   In the ongoing comparison of waterfall model vs agile model, let us see how these two ideologies compare with respect to development efficiency. Efficiency is decided by the quality of ultimate software product, the number of bugs and the development time consumed. Through my own research into the working of both these models, I found the agile models to be more efficient than the waterfall model, due to its adaptability to the real world. The 'One Phase' and 'Rigid' development cycle makes it difficult to make last minute changes in requirements or design. While the agile methods, due to their iterative and adaptable nature, can incorporate changes and release a product in lesser time. Of course, agile models are not perfect either, but they are certainly more widely applicable than the waterfall model.
• Waterfall Model Vs Agile Model: Suitability
   The water fall model is suited for development of programs that are already stable. That is, their design does not need a major makeover. In situations where the designers of a software can accurately predict the flaws that may arise can be developed through a waterfall model. Despite all its flaws, a waterfall model design is easier to manage and the development costs can be ascertained before hand.

1 more annotation...

• in an Agile development world are most security guys useless? The short rationale is that in Agile and really any lean, successful company, you want "everyone to touch the product". Security guys need to code, those that don't (the majority) are not required.
• 12 principles [2] behind Agile development are (emphasis mine):
   
   
   
  • Customer satisfaction by rapid delivery of useful software
   
  • Welcome changing requirements, even late in development
   
  • Working software is delivered frequently (weeks rather than months)
   
  • Working software is the principal measure of progress
   
  • Sustainable development, able to maintain a constant pace
   
  • Close, daily co-operation between business people and developers
   
  • Face-to-face conversation is the best form of communication (co-location)
   
  • Projects are built around motivated individuals, who should be trusted
   
  • Continuous attention to technical excellence and good design
   
  • Simplicity
   
  • Self-organizing teams
   
  • Regular adaptation to changing circumstances
• The only people that add value are coding, designing the UI, testing etc; "touching the product". Unfortunately most security people are not doing this; they create documentation, provide advice and consulting, "manage risks" or manage other security people and thus at best add zero value.  Arguably you would be far better having only security engineers that coded the security components and where they performed code reviews and security testing actually fixed the problems.
• But does the business care about any of this, or would they rather have someone that is helping to get the code completed securely and delivered?

2 more annotations...

• DevOps and its approach of blending development and operations staff together to create better products, I’ve started to see similar trends develop in the security space
• In successful and agile orgs, the predominant mindset is that if you’re not touching the product, you are semi-useless overhead. And there’s some truth to that. When people are segregated into other “service” orgs – like operations or security – the us vs. them mindset predominates and strangles innovation in its crib.
• The main initial drive of agile was to break down that wall between the devs and the “business”, but walls remain that need similar breaking down
• With DevOps, operations organizations faced with this same problem are innovating new approaches; a collaborative approach with developers and operations staff working together on the product as part of the same team. It’s working great for those who are trying it, from the big Web shops like Facebook to the enterprise guys like us here at NI. The movement is gathering steam and it seems clear to those of us doing it this way that it’s going to be a successful and disruptive pattern for adopters.
• OWASP (the Open Web Application Security Project) whose goal is to promote and enable application security. Security people and developers, working together!  Dev+Sec already exists
• OWASP is becoming irrelevant because it’s leaving developers behind. It’s becoming about “security professionals” selling tools and there’s few developers to be found in the community any more.
• about how security testers engaging with agile teams “from the outside” are failing, and shouldn’t we instead embed them on the team as their “security buddy.”
• a movement called “Rugged” that has a manifesto similar to the Agile Manifesto but is focused on security, availability, reliability, et cetera. (As a result it’s of interest to us sysadmin types, who are often saddled with somehow applying those attributes in production to someone else’s code…)
• DevOps community is already running the risk of “leaving the devs behind” too.  I love all my buddies at Opscode and DTO and Puppet Labs and Thoughtworks and all. But a lot of DevOps discussions have started to be completely sysadmin focused as well; a litany of tools you can use for provisioning or monitoring or CI. And that wouldn’t be so bad if there was a real in for developers – “Here’s how you as a developer interact with chef to deploy your code,” “Here’s how you make your code monitorable”
• not attending OWASP events any more. They’re just not hearing anything that is actionable from the developer point of view.
• A sysadmin suddenly deciding to code his own tools isn’t really the heart of DevOps.  It’s fine and great, and I like seeing more tools created by domain experts. But the heart of DevOps, where you will really see the benefits in hard ROI, is developers and operations folks collaborating on real end-consumer products.

• Why do we have this huge set of tools and techniques, of OWASP Top 10s and Live CDs and Metasploits and about a thousand wonderful little gadgets, but code is pretty much as shitty and insecure as it was 20 years ago? Because all those things try to solve the problem from the outside, instead of targeting the core of the matter, which is developers developing secure code in the first place.  And to do that, it’s more of a hearts-and-minds problem than a tools-and-processes problem.

   

  That’s a core realization that operations folks, and security folks, and testing folks, and probably a bunch of other folks need to realize, deeply internalize, and let it change the way they look at the world and how they conduct their work.

10 more annotations...