Tuesday, March 29, 2011

Scrum, XP and what about Self-Organizing teams?

A foundational principle of Scrum (and other Agile methods) is that we get better results from self-organizing teams. The Agile Manifesto says
“The best architectures, requirements, and designs emerge from self-organizing teams”
so it must be true.

A lot of Agile teams see improvements in productivity and quality. But how much of this comes from people working in self-organizing teams? And how much comes from better control and focus: from breaking work down into smaller pieces, working in timeboxes, holding frequent reviews. From faster feedback and more transparency with the customer. And how much from following disciplined technical practices, like developer testing, and code reviews or pairing, and refactoring.

How far do you need to go to get good, or even exceptional, results? Do you need to flatten down your organization, change your culture, change your management structure, change your HR practices and compensation model, change the way that you work with and communicate with the customer and with other teams… do you really need to change all of this to get better software out faster?

Learning from Survivor

In self-organizing teams, people are supposed to make decisions together, through consensus. Consensus works if you have a team of equals, or near-equals, and nobody (or buddies) can dominate the others. In reality, teams are dominated by stronger personalities or, if they are big enough, cliques.

We can learn some simple lessons from the TV show “Survivor”. Leave some people on an island, and pretty soon you will get politics. Some people will avoid responsibility, retreat from conflict: they don’t want to argue, they just want to get to work. Or they want to find ways to avoid working. Or they just don’t care. Some people will leave if they can find a way out. Others look forward to a good fight, get energized by it, but don’t have staying power or don’t know how to follow-up and get what they want done. So power and influence will go to people who are more articulate, more politically savvy, more confident, better at selling. Or to people who are more determined, more passionate about how work should be done, more willing to push for change, who have more to gain or less to lose. Or to people who are more manipulative and controlling.

These people will emerge as leaders in the group, and now you have replaced the role of management in the organization with new leaders who realize their agendas through cajoling, conning, convincing, ignoring, bullying, pressuring, outwitting, outplaying or outlasting the rest of the team into decisions.

I think that this is why some consultants are so strongly in favour of Agile teams and Agile methods: because in an Agile environment they can exert more influence, have more control over the outcome in a shorter time, play a bigger role on a team and have a chance to dominate it; rather than accepting, fitting into the existing organization and culture and “playing a role”. And if your team is having problems self-organizing and self-managing, well, there are consultants to help you with that too.

Swarm Intelligence?

I’m not convinced that the team needs to, or should, make all decisions together, and that the best decisions are always made by a “collective mind” or “swarm intelligence”. There is an important place for technical leads and experienced designers and technical specialists with valuable experience and skill. And there’s a good reason to let them do what they are good at. Even when you get a consensus-based democratic and fair decision from a team, as John Sonmez points out in When Scrum Hurts: Mob Architecture you tend to get average results, not exceptional results. If you have an expert on your team, why not let them make these kinds of decisions, so that you can aim for something better than average?

Management and Anti-Management

A common argument is that managers are not needed with self-organizing teams in Scrum – instead you have coaches who guide the team through their decision-making. This is part of what Uncle Bob Martin calls the anti-management bias in Scrum
“Scrum carries an anti-management undercurrent that is counter-productive. Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit to how much a team can self-X. Teams still need to be managed by someone who is responsible to the business. Scrum does not describe this with enough balance.”
Martin Fowler captured the importance of this balance in The New Methodology
“Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.”
The emphasis on equal is his, not mine.

Many people in the blogosphere take the position that if the teams are not self-organizing self-responsible self-directed (good), then the only alternative is hierarchical exploitative bureaucratic Command-and-Control (bad). But we need, and can have, a reasonable, middle path between extremes, a real-world and practical way of working.

Managers, good managers, respect and trust people to care about what they are doing and to do a good job, while still staying actively engaged. They offer direction, help define goals, help set priorities, step in and help when things are going wrong, handle conflict, and take responsibility when the business demands it. Good managers can help a team solve problems – or avoid them – because they have been in these situations before, and learned the hard lessons. A good manager understands that there are decisions that can be made and should be made by the team or by individuals on the team – and that there are other decisions that aren’t the team’s responsibility. That’s what managers get paid for.

Decisions about how to structure teams and how to get work done shouldn’t be about fear, or lack of trust. Or an organization’s culture, or inertia. Or politics. Or the current fashion. Instead, these decisions need to be about what’s best for the business. How to take advantage of all of the skills and capabilities that an organization has to offer – including management. And maximizing this advantage to the benefit of the team and of the customer.

Friday, March 11, 2011

SANS Appsec 2011: No easy answers, at least not yet

Earlier this week I attended the SANS Appsec Summit in San Francisco. I’ve taken SANS training before, and so have other people at my firm, but this was my first time at a SANS conference. It was well-organized and the quality of the speakers was high, especially for a smaller event like this.

There was a good mix of perspectives on software security problems: real-life examples of secure SDLCs and managing app sec programs; vulnerabilities and tools and methods; the problems and challenges that companies are facing putting in web app security; the very scary state of mobile app security. And there were a couple of cool and fun (if not immediately practical) presentations from smart guys at Google: one on their ballsy bug bounty programs, and another by Billy Rios on how botnets work, and what kind of application security programs botnets have. (I'm not sure what I can do with what I learned on this one, but it was definitely cool).

Around 2/3 of the crowd were app sec or other IT security people, the rest were developers or managers who wanted to learn more about how to build secure applications, based on a show-of-hands poll that I took on the first day.

I presented on How to Build Bridges between Development and App Sec
I was part of a panel on the divide between software development and security, together with exploratory software testing guru James Bach and Marisa Fagan who was representing the Rugged Software movement. James was entertaining and provocative as expected. He made the case that we will never be able to build secure software if we want to innovate. Marisa presented an update on what’s been happening with Rugged since it was announced at this same conference a year ago. While I appreciate the good intentions, I still don’t understand what difference Rugged is making, or will make soon.

Hilights and key take-aways for me:

You can’t get secure if you can’t convince software developers to take the bad guys seriously, and to take problems found in test and review seriously. “Developer looking at bug: that’s not a realistic case, nobody would actually do that”. This goes back to the Attacker’s Advantage: all it takes is one mistake, one soft spot that can be exploited for the bad guy to get in. “A lot of threat modeling is all about convincing developers that threats are real”. Even many testers don’t have an adversarial mindset. Find real problems and show that they are real and exploitable, especially in training.

Developers hate silly checklists and policies. Don’t expect a secure development program heavy on checklists and policies to succeed.

Logging, logging, logging. Good logging is an important line of defence for online systems. Logging inbound and outbound information with enough context to figure out what the hell is going on; logging all exceptions; making it easy for ops to monitor logs and to see what is important.

Big apps keep getting bigger, with lots of frameworks, external components, open source stuff. It’s not just your code you have to worry about. Big apps keep getting bigger and less secure. Small mobile apps are even scarier: there is no such thing as an expert on mobile app security today, because there is no such thing as mobile app security.

Robert Fly at Salesforce.com had a more upbeat story. Salesforce has found ways to make its appexchange program secure for its customers and partners. By limiting what partners can do in the system and how they do it through the salesforce development and run-time platform; by building a set of app sec tools and resources for its development community; by opening office hours to help developers inside and outside of the company with security issues; by enforcing regular code scans and reviews of every partner application. They’ve put a lot of work into their program, it seems to be paying off.

Last year everyone’s major vulnerabilities were XSS and SQL injection. This year the major vulnerabilities are XSS and SQL Injection. And next year, the major vulnerabilities will be… We don’t seem to be learning or getting better. Even with auto-escaping libraries and many of the world’s smartest programmers working there, Google is still getting caught on XSS vulnerabilities by bug bounty hunters.

Anonymous has shown that application-level DDOS attacks are real, and real hard to defend against.

The closing panel was on the future of software security tools. Tools are getting better, but not better enough, soon enough. IBM is working on much faster, incremental static analysis tools to provide quicker feedback to programmers so that they will use them more often; and end-to-end analysis that will look at code in the context of the bigger system to find real problems. Brian Chess at HP is working on integrating the results of dynamic run-time testing tools with static source code analysis tools to provide a more complete and accurate picture of vulnerabilities in the code. Ivan Ristic and Jim Manico talked about still-emerging secure, open source frameworks and template libraries and application sandboxes – technology that isn’t ready today, but that in 2-5 years will make it easier for developers to start building software secure by default.

So, there were no easy answers, at least not yet, but there are a lot of smart people taking these problems seriously, let's hope that better answers will come.