On Judging the Value of a Dev Team
I wrote a post last week on InfernoRed’s blog on how to judge the value of a software development team.
I got some interesting feedback from the people who’ve read this post (namely, my two partners) that this post was “harsh” and might be misinterpreted.
Importantly, I wrote this from the perspective of an outsider looking in on a software development team, trying to figure out how to make an objective assessment of the team’s capabilities. I don’t think you hear this perspective often, especially in the Agile community. And there’s a good reason for this, our community is focused on improving software teams, not evaluating them. If we evaluated every software development the way I’d proposed, many would fall short, including some teams I’ve been a part of. That doesn’t mean a team is doomed, won’t succeed, or is beyond help.
We’d frame development short comings in the Agile community as opportunities and that’s right. Agile is about making things better: faster development, higher quality, improved process that makes work more meaningful for stakeholders and developers. And in the DC area, where employers across the board are having a hard time finding development talent, it doesn’t make a lot of sense to evaluate or judge a development team on relative measures. The question IT leaders need to ask that’s the most pressing is: what can we do to get better?
That doesn’t mean there’s not a time and place to ask the other question — is my dev team any good?
It’s Official: I’ve Started with InfernoRed
My last day with Excella was Friday, I’ve now moved on full time to getting InfernoRed Technology running.
Agile isn’t a Sham
I feel obligated to react to William Edwards’s “Agile is a Sham" post. Edwards’ humorous takedown of Agile processes and engineering techniques resonated with many people today; it blew up on Ycombinator, DZone, and reddit. It was a huge hit on Excella COE distros, where lots of good conversation was had.
Even though mine will be the 87th unoriginal rebuttal to this post, I feel obligated to comment because Edwards and I are kindred spirits. We apparently both share a deep appreciation for minimalist Tublelog themes. (Thanks, Bill Israel.)
In any case, I have three thoughts on Agile being a Sham:
- I understand why this idea is so popular. Process is an impediment.
- Agile is NOT at all a Sham, but there are hucksters who sham people with Agile.
- Agile works and we need it. Winston Churchill understood why 65 years ago.
Process is an impediment
I write code, and I get why there’s a resentment for Agile methodologies. Edwards likens writing coding to playing “Legos without gravity.” When you’re having this much fun, anything at your job that doesn’t involve writing code is an annoyance, at best. Agile methodologies require process, and process requires developers doing lots of activities that aren’t coding.
This sentiment isn’t new. My favorite (and likely not at all safe for work) take on Agile being an impediment is Zed Shaw’s “Programmer’s Manifesto”. What self respecting programmer doesn’t want to be left alone to just do “Programming, mother@#$%!”!?
I understand the frustration, and I agree with the anti-process sentiment. Developers need liberty. Edwards is right that process is like a tax. He’s right that processes that evolve organically are better than prescribed processes. Says Edwards:
"Iterative development is what we used to do when we got things done, and we didn’t have some process we had to follow to do it. Common Sense. Get Things Done. Not so far from the agile manifesto, even. A long way from the sham that is the Agile business though."
Great points, all of them. Edwards almost seems to agree that the principles behind Agile support the common sense approach he describes. So, why is it a sham? And, what does he mean by “the Agile business”?
Agile Hucksters in our midst
The “Agile business” is big. There’s tons of different services, software, and other products to sell, and there’s oodles of companies selling these things. But it’s a lazy and inaccurate generalization to say that all of these businesses are a sham. There’s tons of companies that are generating great value in the Agile space. There’s ALM products that have rabid fan bases. There’s Agile coaches who help teams make sustainable improvements. There’s trainers who legitimately put teams on a path to success.
And, there are hucksters in the Agile business. I agree with Edwards that a four figure sum is too high of a price to pay for a pack of planning cards and a class that does nothing but certify you to use them.
The question is, why do the hucksters offend Edwards so much as to reject the entire idea of Agile, which he seems to agree with in principle?
There will always be snake oil salespeople in IT. IT, as a business, changes rapidly, which makes it vulnerable to exploitation. Rapid change makes it difficult for customers to make good acquisitions because being informed comes at such a high cost. Evolving technology makes it harder still for business providing IT services to provide consistent and high quality service. Any IT exec will tell you that “caveat emptor” is a motto to live and die by.
There are businesses who will do a terribly shoddy job putting your enterprise in the cloud, or helping you virtualize. These aren’t reasons to avoid upgrading your infrastructure. There are technology certifications and training on every platform that are a complete waste. That doesn’t mean that all training is without value. There are software development body shops that will provide you with small armies of software developers that can’t code their way out of a box. That’s not a reason to stop buying software development services.
There’s hucksters in the Agile space too. That’s not a reason to reject “SCRUM and TDD and all the rest”.
The bit about Churchill
Agile means doing many of the things that Edwards values. Minimizing impediments, evolving processes organically and continuously improving our processes, these are things that we value in the Agile community. But at the core, Agile processes are about improving collaboration, a consideration that Edwards mostly avoids.
Few developers are lucky to work on projects where we can work independently and build whatever we want: we’re working in places where we’re solving business problems, and we need to collaborate with people who understand these problems better than we do. Most of us are working in teams that include people with different goals and different needs, and to deliver software, we have to find ways to collaborate effectively.
Collaboration is hard. Really hard. Winston Churchill, having led Britain through the biggest existential crisis in her history, understood how hard. In a speech to the British House of Commons, just after the end of WWII, he quipped:
"Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time."
Churchill understood that getting people to cooperate towards a common goal is difficult. Even if we all want the same results, and that’s not always the case, people have different opinions on how best to get there. Getting people to work together effectively is a tall order. Democracy is empirically, the best way to do this at a macro level. Churchill knew it wasn’t perfect, but it was still the best we had.
Similarly, Agile methodologies are far from perfect, but they’re still the best way we know how to enable effective collaboration on software development teams. Agile’s core principles, things like self-organizing teams, a product owner empowered to call the shots, and conversation over documentation, simply work. These principles have helped tons of software teams communicate better, learn more, and evolve their products quicker. Agile engineering techniques streamline collaboration. It still amazes me that I can write a test capable of identifying a bug in the code that my teammate will write one day in the future.
Democracy and Agile methodologies have this in common: they’re the best ways to get people to work together while preserving as much individual liberty as possible. There’s also plenty of opportunities to claim to be democratic or Agile, while being anything but. The Democratic People’s Republic of Korea is not a democracy, teams that develop “Agile” methodologies that are drenched with heavy process aren’t being Agile.
In the future, we’ll understand human interaction even better. We’ll probably have a better way to govern than democracy, and we’ll definitely discover better ways to develop software. Edwards is right that we’re probably due for a paradigm shift soon. It’s been more than a decade since the Agile manifesto was written.
But let’s hold off on throwing out our Agile values until we have a better answer in hand. And let’s not let the hucksters drag us down. Agile is flawed, but it continues to do a whole lot of good for software teams. And it’s been great for developers who just want to use common sense to get things done.
How to Sell and Implement Pair Programming, the Middle Way
On an Excella COE distro, we recently had an interesting discussion about pair programming, and how to sell the idea to a reluctant client during an Agile adoption. Through this discussion, I learned that I believed two things:
1) Incredibly strict regimens for pair programming aren’t always optimally productive arrangements.
2) In an Agile transformation, Agile coaches and practitioners need to be careful about advocating too fiercely for pairing.
I believe that it’s generally a good practice, but I think often, the Agile community is a little too dogmatic about it’s approach to this technique. Adopting more productive pairing practices should be a goal in any Agile transformation, but I also think there’s a middle way to sell and implement the practice. Specifically, those tackling this issue should do three things: be specific about the evidence, understand the nuances, and understand the people issues.
Be specific about the evidence
This excerpt from a blog post by Katie McCroskey at Thycotic is a fairly typical assertion from the Agile community: "Case studies have been conducted, the experts have weighed in, and the results are unequivocal: the benefits of Pair Programming can result in significant advantages for an organization developing software."
Well… what studies? What benefits do these studies prove conclusively? Are they really “unequivocal”? (Answer: NO.) There’s a lot of unsubstantiated claims from the Agile community about pairing, and unsubstantiated claims aren’t going to convince a skeptic.
If I’m Joe Waterfall with a super long Gantt chart that needs people on line items, why should I put faith in what sounds like a statement of opinion? “Pair programming is more productive” isn’t an intuitive conclusion for someone who hasn’t done it before. If you’re selling the idea, you need to bring more concrete evidence and examples.
This Cockburn/Williams study is a great piece of evidence in favor of pair programming:
Understand the Nuances
The research is not as conclusive as hardcore pair programming advocates make it out to be. Some examples:
The Cockburn/Williams study actually demonstrates that pairs suffer a 15% decrease in productivity. Notably, defects decrease 50% with pairs and pairs build better designed software, so that more than makes up for it. This nuance is important, because it might help your client get over the idea that two people can’t possibly do more work than if they were working in parallel: They can’t! Pairs do write less code than solo developers, but they write better code.
Experts are relatively less productive in pairs than novices. Teams comprised of seasoned veterans are going to get less out of pairing than rookies. This nuance is especially important to anyone in consulting. Consultants are often high skilled engineers, but we’re noobs when it comes to a new client’s systems and architecture. Pairing is especially important to us because we have a lot to learn. It’s not just about enforcing good engineering habits, pairing is about sharing system and domain knowledge as well.
The biggest benefit of pair programming is in software design, not implementation. There’s an uncomfortable implication here for pairing advocates — you get most of the benefits of a pair approach if you have an environment where developers collaborate around a whiteboard to design software. The advantages are less profound when a pair is sitting around one machine trying to get unit tests to pass. Pairing also is more productive on complex tasks and less valuable for simple development tasks.
Be Flexible, and Understand the People Issues
How common is this anecdote: an Agile expert, with buy-in from executives, stakeholders, or management, tells a software team that starting next week, they’re going to write all their code in pairs. Shockingly, there’s lots of resistance from the development team, and eventually, the practice gets shelved, or maybe it doesn’t even get off the ground.
Even if pairing were an absolute slam dunk, offering 400% gains in productivity, it will still fall on it’s face if implemented in a way that fosters dissent or reduces moral. If you’re setting out to change how someone actually does their work, seek to do it with their involvement, buy-in, and un-coerced commitment. It’s completely worth “being Agile” about implementing pairing. Work up to it incrementally and allow the people doing the work to own the pace of adoption.
The most productive software team I’ve ever served with was a dot-com I consulted at a five years ago. At this dot-com, developers almost always pair up when designing new features or debugging troublesome issues. They write a lot of code in pairs, but they also have the flexibility to go it alone, and they do so when it’s appropriate. I think this approach makes a lot of sense. Pairing is essential when working on the transactions for their ordering system, it’s not as valuable when converting fairly static classic ASP pages to ASP.NET. I believe that their flexible and developer-driven implementation of pair programming is superior to a rigid top-down mandate.
The Bottom Line
My own experience in a project with rigid pair programming requirements lead me to believe that something like the more flexible approach I described above is more productive. Certainly, if I’m writing code as part of a software team, I prefer a more moderate approach to pairing: let me pair up when we’re launching a complex re-design task, or slaying a dragon-sized defect. But if I’m tasked with changing some button colors in a bunch of CSS, give me the flexibility to get this done on my own without having another developer sitting next to me, feigning interest while checking his phone.
Having said that, I can imagine a many scenarios where that approach wouldn’t work, and a more rigid pairing arrangement would be beneficial. I can’t imagine a scenario a lack of support or encouragement of the practice at all would be beneficial. The trick is to find out what works for the team, project, or enterprise that needs to make the change. There’s probably a middle way that will elude you as long as you’re thinking dogmatically.
As Agile practitioners, we could certainly afford to be less dogmatic, more thoughtful and flexible when it comes to the direction we’re giving teams about pair programming.
Don’t tell me what NOT to do!
When I was a snowboard instructor, a clinician gave me some very effective advice: “Don’t ever tell a student NOT to do something. Always tell them what to do instead.”
Putting aside it’s self-contradictory nature, this is the best little gem of coaching advice I’ve ever received. Adhering to this rule made me an much better instructor. Intermediate snowboarders commonly make their turns by failing their arms and rotating their upper body. I’d struggled many times with students trying to correct this behavior. Telling a student not to turn the with their upper body had the effect of preventing them from turning at all. Plus, it made them angry at me. I found that completely ignoring the ugly upper body movements, and instead focusing on teaching students to turn with their feet, knees, or hips made things click immediately.
I think this idea is incredibly relevant to working with teams on an Agile adoption. That hour long daily status meeting that the team is having every day? It’s ineffective to say it’s a waste of time and they should stop doing it. It also makes you sound like an Agile jerk. What works is to figure out why stakeholders or team members need to have such a meeting, and to work with the team to adopt other more effective strategies for collaborating, such as co-location, daily stand ups, more transparency and more ad hoc interaction between stakeholders and developers. If the team or stakeholders decide on their own that their daily status meeting is a waste of time, you’ve helped them make a sustainable and positive change to their process.
I also believe that it’s advice many in the agile community could afford to embrace. I’d be rich if I had a dollar for every time someone in the community has told me what I’m doing wrong. I’m certain I’m not the only one in the community who has had a negative reaction to advice like “You’re a Scrum Master, you shouldn’t be solving a team’s people problems!” Advice like this makes people defensive, which makes the advice pretty ineffective.
It’s understandable though, it’s easy to point out flaws. It requires a lot of thought to craft suggestions in positive and non-judgmental ways. Being an effective Agile coach means doing this consistently.
But how can we sue our contractors if we’re Agile?
Computer Weekly just published an interesting opinion piece from a UK attorney named Alistair Maughan, who contends that Agile can’t work in the government:
I’m prepared to accept on trust that, if all goes well, Agile may reduce the risk of project failure. But Agile simply won’t work in the real world of government ICT. We need a Richard Dawkins to bust the myth of the Agile gospel.
The whole article is worth a read. He makes good many points that will resonate with anyone who has tried to do Agile in the federal government. No doubt, it’s hard.
Maughan’s conclusions are all wrong, however. Most of his arguments stem from the unique cultural issues involved with working with the government. Certainly, there are big cultural impediments in the government to being Agile, but I’d assert that these impediments are impediments to successful software development in general, not just to being Agile.
People issues are the biggest liability of any project, those issues include organizational culture. One of the partners I work for at Excella states this as a consulting rule: We solve business problems with People, Process, and Technology, and in that order. If you want Agile to succeed on a federal project it’s essential to address the people issues first. CYA and anti-collaborative behavior are commonplace in the government.
Maughan seems to assume though that these things can’t change. He implies that the lack of trust between customer and supplier are inevitable, and hierarchical, centralized decision making are permanent fixture. I believe, perhaps naively, that we CAN change these things in the government. In fact, I think it’s essential that we work to change these things. If we’re talking about a new federal Agile contract, or an Agile adoption for an existing federal team we should start by asking questions like:
We should be asking these types of question before we discuss Scrum logistics and start deciding on Jira vs. Mingle or Jenkins vs. TFS. I do think that it’s possible, certainly on smaller government projects, to chip away at the margins on the cultural impediments. I think that many feds really want to see us do this as well.
Here’s where Maughan really misses the boat: Waterfall is not the answer either. He writes as if the majority of non-Agile federal development efforts have “watertight contracts, clear deliverables, and open procurement.” Maybe the UK is a magical fairyland of Waterfall goodness, but I’m certain that no one involved in the Hewitt-OPM debacle would argue that the current state of software development in the federal government is just fine the way it is. Most of the liabilities he discusses are just as present in well-structured Waterfall efforts, they just manifest themselves in different ways.
For me, when he says that Agile isn’t the answer, he’s saying: it’s impossible to do effective software development for the government. If you work in government IT, that sounds like a terrible thing to believe. Unless you’re a lawyer, I guess. Really, his arguments here can be condensed to: Waterfall makes it easier for the government to sue contractors when things go wrong; Agile makes litigation harder for the government, but increases the chances of a project succeeding.
How many federal executives would accept a higher risk of project meltdown in exchange for more “appropriate remedies for litigating failure?”
Even traffic lights can self organize!
Typically, traffic engineers manage traffic by using historical data and a central model of control. But Swiss researchers are now experimenting with traffic lights that adapt independently to changing traffic conditions:
Lämmer and Helbing wondered if traffic lights might devise better solutions on their own, if given some simple traffic-responsive operating rules and left to organise their own on-off schedules. To find out, they modelled the flow of traffic as if it were a fluid, and explored what happens at road intersections, where traffic leaving one road has to enter another, much like fluid moving through a network of pipes.
The idea doesn’t seem terrifically analogous to how an effective scrum team self organizes until you consider this:
They found, however, that this simple rule isn’t enough: the lights sometimes adapt too much. If they are only adapting to conditions locally, they might stay green for too long and cause trouble further away. To avoid this, Lämmer and Helbing modified things so that what happens at one set of traffic lights would affect how the others respond. By working together and monitoring the lengths of queues along a long stretch of road, the self-organised lights prevent long jams from forming.
Despite the simplicity of these rules, they seem to work remarkably well. Computer simulations demonstrate that lights operating this way would achieve a significant reduction in overall travel times and keep no one waiting at a light too long. One of the biggest surprises, however, is that all this improvement comes with the lights going on and off in a seemingly chaotic way, not following a regular pattern as one might expect.
In other words, the traffic lights are programmed to share the same goal of reducing travel times overall, and they’re armed with information about the traffic conditions at other intersections on the grid. It’s just like the shared commitment and transparency you’d see in a high performing scrum team.
In Lämmer and Helbing’s models, travel times decreased 10-30% overall. Performance at any given node varies, but overall, you can expect to get to your destination quicker. It’s all eerily similar to the way that software managers can expect to get working software quicker when teams are given the freedom to overcome their own obstacles.
Team Velocity and a User’s Heirarchy of Needs
A colleague and I ran into a dilemna when working through a recent presentation to a long time client. It’s not an uncommon one: we needed an easy way to convince the client that with the team’s current velocity, they weren’t likely to get the product they envisioned in the long term.
More specifically, this client wanted a “sexier” application. The reality though was that everytime the team estimated work items that would improve the application’s desirability, they’d be left out of iteration plans, or they’d be significantly scaled back. There were always more important things for the team to work on.
Re-prioritizing our backlog to invest more in presentation wasn’t a realistic silver bullet; we were supporting an application with a user base that had constantly changing needs. Those needs always ended up coming first, regardless of how we planned our releases.
The challenge came in finding a way to communicate this problem to the client, which we did with the handy pyramid below. I culled this together and customized it based on our several similar pyramid ideas I found on the Interwebs. (And for the love, I wish I’d have known to say “desirability” instead of “sex appeal” earlier.)
We put a few animations in to walk up to the point where our application was currently hovering (in the third tier), and everyone got it right away.
I see several obvious ways for a scrum team to solve this problem; though I’m sure there are plenty more:
- Improve the team’s velocity (new resources, eliminating waste)
- Improve the team’s efficiency in UX tasks (different resources, training, inspire a shared ideal of beauty through regular team outings to art galleries)
- Convince our users to have less needs
None of these seem particularily easy, but importantly, we’re now taking steps to really solve this problem, instead of just doing a lot of wishful thinking.
I think this blog needs some content
I have a blog
I’m fresh off of the Agile 2010 conference in Orlando, with a head full of ideas. One of them: I’m going to start writing. (Well, blogging, anyway.)
I’ve discussed the idea of having a professional blog with a number of my colleauges before, and the idea always seemed to fall flat. There are already a million blogs on software and agile development. It always seemed a little egocentric for me to assume that I’d be able to generate a steady stream of original thoughts that people would be interested in reading.
But, there’s an important angle I’d been missing: writing is a valuable tool to learn. So I’m going to start doing it.