Tuesday, March 25, 2014

Agile Isn't Dead

"Best practices are useful reference points, but they must come with a warning label : The more you rely on external intelligence, the less you will value an internal idea." ― Gyan Nagpal, Talent Economics: The Fine Line Between Winning and Losing the Global War for Talent

Agile isn't dead. It's not even on life support. However, to extend an analogy that everyone in the world should stop using, it does have a couple of CAT scan anomalies it should get checked out.. I've read a few tech opinion pieces to the contrary lately, so I thought I'd throw my hat in the ring.

+Hayim Makabee wrote an excellent piece on the subject, but one that I feel missed the mark somewhat. Jim Bird wrote on a finer grained level on the subject, and if you take them together an interesting picture starts to emerge. Starting with Jim Bird's piece, he lists several "Agile" practices that aren't needed. Skipping by a few points on which I disagree, his overall point is sound. Not all common practices are necessary. Hayim Makabee takes this a step further, rightly pointing out how "Agile" or "Scrum" consultants "over-simplify the software development process and underestimate the real complexity of building software systems". And I'm not really arguing that this "one size fits all" approach is a problem. I believe that the problem's source hasn't quite come out yet.

In short, the problem is IT decision makers. Not Agile, which is just a set of principles. Not Agile consultants, who are just selling a service people have asked for. And while we can discuss the moral culpability of someone "just selling a service", the fact of the matter is that people are buying the service. And those people are IT decision makers in pursuit of a concept that has made me cringe for some time now. Best Practices. "Best practices" are like the Dark Side of the Force. Quick, simple, seductive, and once you walk down it's path, forever will it dominate your destiny. "Best Practice" is shorthand for "What everyone else is doing", and while it's the sort of thing one ought to take into account, I've seen enterprise after enterprise implement iron-clad procedures based solely on "Best Practices", or rather "Just do what the neighbors across the street are doing". And before too long, you have Citogenesis, that curious phenomena where people think something is correct because people think something is correct.

Agile is a set of principles, and as far as principles go, they're pretty darn good. Agile isn't dead because these principles are still the best way to create software. But it really needs that dark spot checked out.

Sunday, February 9, 2014

Life is Agile

"It's not what happens to you, but how you react to it that matters" --Epictetus

I'd like to pose a question to any parents reading this. When your child was born did you plan out every detail of your child's life? Did you attempt to account for every problem and develop a contingency plan before even leaving the hospital?  Do you parent in a vacuum, having no contact with other parents?

Similar question to those of you with active careers, be it in the job market or at home. Yes- being an at-home parent is a career. Did you plan out every step of your career before you began working? Do you work without interaction with others in your career? Did you plan for every problem to the most minute detail?

Of course not. To approach such a major endeavor in life is more like planning to fail. And this is why Agile is the only way to successfully complete a software development project of any consequential size. Because it mimics human behavior and human capabilities. At it's core, the Agile methodology is an admission that you can only do so much to plan for the future. It's a system built on the foundation of communication with others. It does not merely recommend regular and effective communication, it states that failing to do so will cause overall failure. It is built around doing what you need to now, while keeping an eye on the future. Similar to how you eat an elephant (one bite at a time), so do we manage our lives. Why should we assume that managing a development project should run so completely contrary to our fundamental behavior?

The converse is also true. It's been a very long time since I've had to defend Agile vs. Waterfall/BDUF. The reason appears very straightforward- the proof is in the doing. Agile has proven itself. It's not theoretically better, it simply is.

How, then, can we extrapolate this to our lives? Should you find yourself working at a company where you have no future, what do you do? Do you scrap the idea of working at your best capacity while you look for another job? Agile says differently in that a development team has the discipline to finish a development sprint, i.e. the work in front of them.

If you want something in your career, do you just keep working and hoping it happens? One of the foundations of Agile is communication. Do we keep grinding and hope, or do we approach others for advice? And then do we approach management and clearly communicate what we want?

Life is Agile is life. The lessons we learn from each can be applied to the other.

Monday, December 2, 2013

Healthcare.gov failures in leadership

"Good management consists in showing average people how to do the work of superior people." --John D. Rockefeller

"Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them." --Paul Hawken

Yep. I'm back at this well. Partially because it's a great way to boost hits (I don't use ads, but I do have an ego) but mostly because I've been there. Not in a project this size, but I've lived the nightmare. Maybe someone that can affect this boondoggle
reads this and listens. Likely not. I have an ego, but I'm a pretty small fish. More important to me is that the developers and IT staff affected by projects like this understand the failings so that they know when to update their resume.

This one is coming from a New York Times article titled Inside the Race to Rescue a Health Care Site, and Obama. And again, whether Ms. Stolberg and Mr. Shear realize it, they paint a picture familiar to many IT veterans.

Failures of Testing

I've written about the technical failures of the development teams but what has been written in this article serves to underscore something all development teams know, but fewer do. Testing. From the article:
"To do that, they would have to take charge of a project that, they would come to discover, had never been fully tested and was flailing in part because of the Medicare agency’s decision not to hire a "systems integrator" that could coordinate its complex parts." 
"The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered." 
"'There’s so much wrong, you just don’t know what’s broken until you get a lot more of it fixed,' Mark Bertolini, the chief executive of Aetna, said on CNBC."
Regression testing. Unit testing. User Acceptance testing. I can't think of a better way to talk about the dangers of not budgeting time to properly test your project.
"In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government."
Code reviews and proper architecture concern would have prevented the "sloppy code" issue. The rest of this segueways nicely into my major point, thought.

Failure to understand a software development project

Clearly, project management didn't know how to manage a large-scale project. I've said before that the evidence could not be clearer that this project was managed Waterfall-style. And while the far-preferable Agile development style can also struggle with changing requirements, the iterative workflow, combined with constant checkpoints with the business stakeholders allows for better options for dealing with the fact of life that is spec change. Here are a few examples from my playbook:

"No, we will not change specifications in mid-sprint. If you want this change, submit it to the Icebox and give it a priority. We will then do the design and estimation work and add it to a future sprint."

"No. This is a two week sprint. We will not finish early. We will not rush. We have a planned amount of work that will take two weeks to deliver properly."

"No, we will not add to this sprint. The sprint covers an amount of work that can be accurately delivered in two weeks."

"No, we will not include this work into a sprint until there is proper user acceptance criteria attached. The delivered code will then conform to the acceptance criteria listed. No more, no less. I'm here to help you write good acceptance criteria."

Enforcing this kind of project discipline is crucial. It should be well-communicated up front. Everyone should know what an iceberg is. And once the expectation is set, that expectation is enforced. But even with that, the problem runs far deeper. Some quotes from the article really chilled me:
"Out of that tense Oval Office meeting grew a frantic effort aimed at rescuing not only the insurance portal and Mr. Obama’s credibility, but also the Democratic philosophy that an activist government can solve big, complex social problems." 
"'We’re about to make some history,' she (Ms. Sebelius,) said.
"...reveals an insular White House that did not initially appreciate the magnitude of its self-inflicted wounds"
As any regular readers know, my overall philosophy comes from Marcus Aurelius:
“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.”  
By itself and in its proper constitution, Healthcare.gov is a website that allows people to purchase health insurance. It is not a justification of a political philosophy. It's not about making history. Those are incidental. You cannot make good decisions if you don't understand the context for those decisions. You can't make good decisions about a development project if you see it as anything other than a software development project. And don't think for a second that minimizes its importance somehow. Most developers I know care a good deal more for their code than they do your politics. But if management mistakenly sees a project as some kind of ideological movement or as setting their legacy then they aren't making project management decisions.

Management culture

Finally, what may be the worst failing of the management of this project. It's culture. The standards management sets for its operations. The only place I've ever heard of management leading so poorly is in Dilbert. For example:
"For weeks, aides to Ms. Sebelius had expressed frustration with Mr. McDonough, mocking his “countdown calendar,” which they viewed as an example of micromanagement."
Mocking other stakeholders. Ignoring, for a moment, the notion of expecting professionals to not act like spoiled children, why was this behavior considered acceptable? Management sets the standard for how people act. A good manager understands this. A good manager sets an expectation of professionalism. Complaining is one thing. Open mocking should be the sort of thing people are embarrassed to do, or even to listen to.
"Contractors responsible for different parts of the portal barely talked to one another, hoping to avoid blame."
There's enough written about how a management culture of blame creates a toxic environment. Problems aren't addressed. People pass the buck rather than address problems. The concern is to not be left holding the bag, rather than making sure work is done well. Fear does not create quality. And clearly, this is not known here.
 "Mr. Obama, meanwhile, was under assault. After years of telling Americans, “If you like your insurance plan, you can keep it,” he was being accused of lying. On the night of Oct. 28, Ms. Jarrett, one of Mr. Obama’s closest confidantes and a guardian of his personal credibility, took to Twitter to defend him — and to shift the blame. 
“FACT,” she wrote. “Nothing in #Obamacare forces people out of their health plans. No change is required unless insurance companies change existing plans.”
The tweet touched a nerve; it was not the first time the Obama White House had used the insurance industry as a scapegoat. Ms. Ignagni’s (chief executive of America’s Health Insurance Plans,) members were furious. “Here it comes — we knew it would happen,” one executive recalled thinking."
 The Obama administration built support for the ACA by building hostility to the insurance industry, with whom they must now work. So, in essence, the Obama Administration has taken every opportunity to publicly condemn the insurance industry and is now relying on that same industry to launch not only it's centerpiece website, but the validation of their political philosophy. A management team that does not treat their vendors with respect will find themselves very lonely once they need their vendors. UnitedHealth and CIGNA have already "mostly shied away from the online marketplace" (From the article). To assume this has nothing to do with the administration's clear contempt for their vendors is folly.

I have a difficult time summing up my shock at the sheer number of leadership failures involved here. Not just in knowing how to run a software development project- clearly Medicare and the Dept. of Health and Human Services considered this a "Fire and Forget" project and that they were absolved of all responsibility to be involved once the project started. More disturbing, though, is the culture that management allows. Childish behavior and finger-pointing should not be acceptable. And that attitude starts from the top.

Wednesday, November 13, 2013

Dedication and Vision

"If you do not have an absolutely clear vision of something, where you can follow the light to the end of the tunnel, then it doesn't matter whether you're bold or cowardly, or whether you're stupid or intelligent. Doesn't get you anywhere." --Werner Herzog

Short article today.

Ran across something that really made me think about software development projects. Three developers in San Francisco built an alternative to Healthcare.gov in two weeks.

Two weeks.

Now, you can't purchase- just search and compare rates and plans. But again. Two weeks.

No complicated procurement process. No contractors. Certainly less than hundreds of millions of dollars. Just three dedicated guys with a clear vision.

A G+ friend of mine +Chaka Hamilton took this a step further:
I bet if the gov offered a darpa style challenge, they'd have a working website in half the time, and cost. They obviously have learned nothing from open source / crowd source community.
 Indeed. What if they had.

Tuesday, October 29, 2013

A New Perspective

"I believe everyone should have a broad picture of how the universe operates and our place in it. It is a basic human desire. And it also puts our worries in perspective." --Stephen Hawking 

"Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." --Marcus Aurelius 

This  article falls more heavily under the "Musings" title of my blog. I'm less making a point than I am thinking out loud. As always, feedback and insights are always welcome.

My job responsibilities are changing. I phrase it like that because I doubt my actual title will change, merely the meaning of that title. I rarely handle project level work anymore. Rather, I'm more involved with enterprise level architecture decisions. I haven't implemented a design pattern in quite awhile. I find myself, instead, setting the standard of what patterns are best to use or avoid in certain situations. Or what frameworks we will be using or whether we will use an off the shelf solution or build our own. In other words, my implementation decisions are becoming less important than my opinions and experience with those decisions. I find this a very new perspective and more than anything else, I find myself more and more writing about new perspectives on old ideas.

For instance, take our current investigation into unit tests. The discussion started with "What mock object framework should we use?" We quickly boiled down to "Which framework will be unduly burdensome to the development staff?" This actually eliminated a couple of frameworks at the beginning. But when we settled on two that are, more or less, of equal use the conversation quickly changed to unit test standards. I have a few strong opinions on the matter. I believe that unit tests should cast a wide loop so that behavior consistency can be assured. If that means mocking Internal methods to assure their consistency, then so be it. If that means only using strict mock objects, despite their fragility, then so be it. In fact, I like fragile unit tests. If the behavior of the class changes then the tests should break. I realize that my opinions are not shared by the community at large, and I'm okay with that. I'm always open to debate, but I approach things somewhat differently than normal. I think I've made that clear. Now, of our enterprise level architects, one disagrees with me and the other is still weighing arguments and that's great. That kind of conversation is a new perspective for me.

So what's this new perspective and what does it give me? Because I'm no longer considering patterns and practices for a given set of circumstances, but rather to be followed in the enterprise, I have to more seriously consider the pros and cons of those patterns and practices. I find that thinking of effects of standards on the enterprise at large makes me think differently about the effects of my design decisions at the project level. Not just "Does this work here" but "Would this work in other, similar, situations and if not, why not?" If the answer to the second question is "No", then should I reconsider my decisions at the project level. Note that I'm not offering concrete conclusions here. I'm expanding my perspective and thus expanding the pool of questions I ask myself before making a decision.

Maybe that's my point here, although I expect I'll be getting comments about my approach to unit tests. That's fine, too. The day I stop listening to others is the day I stop being useful.

Tuesday, October 22, 2013

The Unambiguous Measure of Success

"[T]he presence of an unambiguous measure of ex-post success (profit) serves to harness the natural tendency toward overoptimism that otherwise would almost certainly be present when someone else’s money is being spent." --Robert Wagner, "Economic Policy in a Liberal Democracy"

Every once in a while I'll come across a quote or an article that makes me think about software development. Often that's because I tend to read a lot of material related to software development, but sometimes it's not. Such is the case of Donald Boudreaux's Quotation of the Day for October 23rd. The full quote is:
[T]he presence of an unambiguous measure of ex-post success (profit) serves to harness the natural tendency toward overoptimism that otherwise would almost certainly be present when someone else’s money is being spent.  The necessity of putting one’s money on the line and of being responsible for the ultimate outcome surely has a sobering effect on the assessment of the prospects for such projects [that governments typically undertake], an effect that is weakened when tax money is used in a setting where no judgement about profitability has to be faced.
I'm no economist and I don't pretend to be one. And this isn't a post about economics, anyway. What caught my eye was the idea that putting one's money on the line and being responsible for the ultimate outcome by setting an unambiguous measure of success. Even though we all know, often through painful experience, why clear and unambiguous project goals are a necessity, I think it's interesting to look at it with an economist's viewpoint.

Instead of "someone else's money is being spent", let's use "someone else's resources are being spent". In other words, not just the salaries of development staff but also time and infrastructure. If the burden of this is borne solely by the development staff, then the tendency of the customer stakeholders is toward overoptimism. Features, both initial and scope creep, and timelines all trend toward pushing the limits of what the development staff can reasonable accomplish. At least, that's been my experience.

A couple of things happen when the customer is expected to give a clear and unambiguous measure of success. Not just in terms of a requirements document, but close involvement in the development process both in defining clear acceptance criteria for user stories and in reviewing the results of development sprints. The customer is now spending their resources on the project. Their staff has to be available for clarifying requirements. Their staff is has committed their time to insuring that the "measure of success" is being met. And their staff also has to budget, and therefore use effectively, their time for the project in relation to the time needed for other tasks. The tendency of those with a stake in the game is to be more careful with how those resources are spent and to insure that resources aren't wasted. I guess this makes sense, really. People tend to spend money more frivolously when not using their money, or when it doesn't look like they are using their money. It's why managing credit can be tricky and it's why casinos use chips instead of currency. Why should spending resources on a project be any different?

I like this quote. It's a truism of software projects, for that matter projects in general, that you can't finish a project if you don't know what "finished" looks like. I'd never stopped to think about how a clearly defined measure of success affects the customer in a project.

Thursday, October 17, 2013

Health Care Exchange Project Pt. 3

"One test is worth a thousand expert opinions." -Wernher Von Braun

And finally the last piece of the puzzle. As a software developer, I find the previous types of project problems maddening. However, this last category boggles my mind. Perhaps I'm just an idealist, but I truly want to believe that this sort of thing doesn't happen anymore. Sadly, I read The Daily WTF far too often to really believe it. We are now down to technical failures.

Again, quoting from From the Start, Signs of Trouble at Health Portal
"Others warned that the fixes themselves were creating new problems, and said that the full extent of the problems might not be known because so many consumers had been stymied at the first step in the application process."
"'So much testing of the new system was so far behind schedule, I was not confident it would work well,' Richard S. Foster, who retired in January as chief actuary of the Medicare program, said in an interview last week."
We all know that maintenance, especially bug fixing, is the true bulk of any software development work. And we all know that testing is the heart of finding, and therefore fixing, bugs. This is not under dispute. However, I've been associated with so many development projects that ignore this basic principle that I want to weep sometimes. And it's always the same. "We don't have time to test because we're busy building features". Or "We'll focus on testing later". Or the worst, "We'll worry about bugs when they're reported by users". (Yes- I've been told that)

To be clear. Unit tests insure that a unit of code has a consistent result at any point in time. It doesn't insure that the code does what it is supposed to. It insures that what the code does hasn't changed due to other factors. Unit tests are how you do regression testing. At least, how you do it without resulting in Cthulhu-level madness.

User Acceptance Testing insures that the users can actually perform the tasks called for in the specifications. This doesn't happen at the end of the project. This happens at planned stages throughout the project so that testing happens on a manageable set of features. A set of features that can be easily documented, easily described, and easily managed. Failure to do this step before rollout is inexcusable.

And while we're at it, what about Exception handling testing? What effect does any given exception have? How is it reported, both to support and to the user? How are exceptions tracked? Testing isn't just about making sure the application works well. It's about insuring that it fails gracefully.
"The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring (Em. mine- MO), according to people familiar with the process."
I'm pretty okay with most of this, but the failure is so bad that it's worth mentioning. The award amount doesn't bother me. I'm also pretty okay with two years of requirements. This isn't like turning on a switch and watching everything work. This is a serious development project- far more serious than anything I've participated in. I would have been more surprised to see the award amount or the planning time significantly lower.

But read the bit I emphasized. Development didn't start at any point during planning. In other words, a project with this level of work and complexity was attempted Waterfall-style. Not Agile. Waterfall. In a project like this, the technical leadership deliberately passed on the ability to easily reach to changing requirements. And the ability to work on completed requirements as they become available. And on increased involvement between development and stakeholders. And continuous testing.

I'll take the heat for saying this- Agile isn't a buzzword. It isn't a topic for bloggers to discuss. And it isn't an alternative methodology. It's the only sane way of approaching a development project of any more than a trivial size. You simply can not anticipate everything ahead of time, and attempting to do so harms the project more than it helps. Case in point.

All of the problems the NYT article describes are serious. Any more than one or two of them will probably sink a project. The fact that people are reporting this many fundamental mistakes makes this an example everyone familiar with software development should understand. If only to protect your career.