Process Tips

It is one thing to have a process defined by a small group of people that are leading the parade, yet another thing to have it understood and followed effectively by the masses. This requires far more than capturing the intended steps, or identifying the book or website that describes the approach to take. It even goes beyond educating the group more closely to ensure they can recite the approach as it is defined. What is really needed to internalize and have an effective approach within the team is for everyone to have experienced that approach enough so that they can trust that it will work. They need to have built faith in the process.

Without faith in the approach, it becomes far too easy to fall back on an old, trusted approach at the first hint of trouble. not only do we need to understand the steps in the process, we need to know, to have internalized, that the process will work even in the face of adversity. This is not something that others can tell us, this is something we need to experience. For those that are driving process in their organizations, or are consulting into shops as a process champion, this is a critical stage in the change cycle that we need to manage carefully. It is not something that can be trained or passed along in a lunch and learn session, it takes time and personal experience through the lifecycle.

This is true of any process, not just for software development lifecycles. As we run diagnostics in more and more organizations, I am always faced with skepticism that such a light approach can yield the sort of results we often see. I can tell people about the experiences I have had with other groups, and that is often enough to convince people to give it a try, but there remain those that are not fully bought in.

From the thinking perspective, I know that the combination of involving everyone, promoting open honest discussion, and allowing the team to drive their own conclusions about what reasonable next steps should look like is a formula that has been successful and repeatable from place to place. It is only after having run the diagnostic dozens of times, though, that I am at a point where, from the sensing perspective, I know it will work, and have complete faith in the process. It would be naive to assume that others will have that same level of faith without the same degree of experience, no matter how many testimonials I throw at them.

I would look at teaching development processes in a different way than past vs. future (to avoid that corresponding inappropriate implication that past = failed and future = successful). After all, some approaches developed long ago resulted in project successes, while some more recent approaches are contributing to project failures today.

A defined approach in itself is neutral, it is the application of that approach to a specific project situation that begets success or failure. Instead of past vs. future, I would suggest we have a lot to learn from all approaches over the ages, looking at projects where these processes have been positive contributors and where they have really just been barriers to success. There have been successes and failures in every approach, at least the ones that have survived to the point where they show up in the literature. There will continue to be failures as long as we believe that the right process, any right process, is a magical formula that allows us to stop thinking throughout the project, or that we can define the right process in advance of understanding the product and the stakeholders involved.

I see the history of approaches as an evolution of thinking, with a couple of key themes that continue to weave in and out over time. The most prominent of these is the hysteresis of process 'weight' over time, from little or none to way too much and back again (and I'm sure the pendulum has not yet stopped - back to those ongoing failures and the magical formulas above).

I would show how much of the 'new' thinking in processes has existed for decades, but I would also recognize that the rebranding and repackaging has made these practices more broadly acceptable, which is a very good thing. Each process has it's strengths and blindsides, it's area of focus and implied assumptions, and a challenge it was meant to address. The trick when studying processes is to recognize the relevance of an approach to a given problem, and make a conscious selection of the right path forward. Unfortunately, many process consultants, old and new, internal SEPG members or external consultants, come to the table with experience in one approach that worked well somewhere else, or feel obliged to identify a standard process for all forthcoming projects.

I would also highlight that there is currently a dangerous false dichotomy of thinking for many that there are successful projects and there are projects that are not Agile.

There is much to learn from the past, particularly that there have been many successes and failures to learn from. More often than not, it is not that the process applied was bad for failed projects, but that the process applied was not wisely selected, or that it was not followed in the heat of battle. We also need to learn that this is still going on today on many projects, and the results will be the same.

The most appropriate process is extremely dependent on the team, the culture, the client, the product and myriad other factors: it is dangerous to say a priori that this or the other process is the right one (or conversely, to say a priori that an approach should not be considered). As with anything, decide for yourself rather than listening to one salesman's pitch for their wares. Understand a range of different approaches, the relative value of each, and decide for yourself.

This is a clearly identified stage in Virginia Satir's change model: Resistance. Even though our brains will be telling us that there is a better way to do things, a real opportunity to improve on our existing level of performance, something inside us holds us back. It is comfortable here, we tell ourselves, it's not so bad now that we are used to it. Let's just stay put - that's so much easier.

No learning, no disruption, no chaos. Just the current status quo, which in many cases is the devil we know. While the allure of this current way of doing things can pull us back from almost any stage of change, it's primary strength seems to be in keeping us from heading down the path of change at all! Resistance = inertia.

As agents of change, our most critical task is to understand all of the barriers to change that are put up, and to break them down. For many of these barriers, our job is to expose them for what they really are: excuses and rationalizations that won't hold up to scrutiny. It is one thing to present a better future, but a strong change agent understands that we need to sell to overcome the resistance.

In changing how we develop software there are many forms of resistance, but the primary ones fall into a couple of categories. We will often hear things like "we tried different ways of doing things, it didn't work", or "we don't have the time to learn new approaches", or my personal favourite, "we can't afford to do those things". There will be variations on these themes (the latest I heard was that the group was operating under spending constraints), of course, but these are the big three (and actually, the last two are different spins on the same resistance). Listen closely as people put up their barriers to doing things differently, there's a good chance that most of what you hear will fall into these areas.

Let's start with the second barrier, the 'there's no ROI in this stuff' resistance. This can take the form of not enough time, money or resources, but these are essentially equivalent for the purposes of selling change. It is interesting to note that most teams cite 'not enough resources' as the greatest issue they face, so it is worth starting there: even if it is not cited as a barrier, bring it out for discussion. In almost every situation I have come across, this barrier arises because it is the numerator that is not well understood. Even if we can clearly cite the value of the proposed changed practices, few organizations have at their fingertips the current cost of non-quality. We need to expose that blackened lung that incents people to quit smoking, or those jeans that won't button up to get people to shed pounds.

In software teams, this is the elephant sitting in the room that nobody talks about. Almost every team can quickly start to appreciate the costs associated with their current practices with a few nudges. Anecdotal recollection can be quite generous, but even then if we sit back and ask how often we deliver on time, or how much time we spend cleaning up messes, people will start seeing the potential for return. Then we can walk down the path of taking a few measures. Grab the first 20 or so defects you have in your defect tracking system, and count how many have their basis in something that could be reasonably have been identified in early-stage analysis (typically it is half or more). Get people to measure how much time they spend working on things they thought they had washed their hands of, even for a week or two (again, numbers around a half are not uncommon). On-time delivery? Unmanaged scope change? Employee turnover? Overtime and burning the midnight oil? Heroic efforts? Lost customers? Customer reported defects?

The list goes on. We can very quickly build a compelling argument that there really is a return to be had, it simply was not top of mind, and almost certainly was not being measured. Armed with this, we can have a rational discussion that addresses this barrier, and we usually get to the point where the discussion becomes "we can't afford NOT to change". The more real and more personal the data we can provide, the better.

That first barrier, the 'this stuff didn't work in the past' barrier, usually comes as a result of misdirected or overwhelming change that has been inflicted on the group in the past. Once incented to actually change, we need to be careful to identify the smallest possible change that will provide the greatest impact against the most relevant cost. Too many change initiatives take on too much, which dilutes the value of the return, increases the cost of the investment, deepens the chaos and lengthens the duration before we start seeing value. "We're going to follow the Unified Process" can literally destroy a business, and even "we're going to do Scrum" can inject too much change if the team is not ready for it. Better to go with something like architecting the system, or starting a daily status meeting, if those things are the ones that will provide the best value.

In the software world, we have a bad track record of adopting wholesale change, or swinging this way or that way with fads that come and go. We can all chase statistics that would claim that the industry is not getting appreciably better or that the industry is doing a lot better than it used to be. Regardless of which stats we chose to believe, regardless of how successful we feel or what our bottom line is telling us, most teams struggle with how to change for the better. As an industry, we are looking at it from the wrong angle: it's about the people first, not the practices.

First off, we can't expect any change to be successful if we don't understand where we are moving from. Good or bad, our current practices, attitudes and results constitute a status quo. While the practices are easy to discern (though the perception of which practices are actually applied will differ, even within the same team), the attitudes will vary greatly across the team, as will the perception of the results (as very few teams quantify success in multiple dimensions). Some will feel that things are going OK while others will see the same projects as a disaster.

The better we understand all this, the better we are equipped to initiate change. With knowledge of the range of perceptions in the group and awareness of the motivating factors that drive the entire team, we at least have a chance of visualizing what a better future might look like. What is critical here is that better future will look different from each set of eyes. With each person that we neglect in this stage, our chances for overall success will diminish significantly. Everyone needs to be able to see where they are headed with the initiative, what is in it for them. Interestingly, there are times when the best alternative for change is not actually change itself, but driving a more consistent common understanding of what practices are currently in place: this will set the stage for an easier facilitation of change downstream, with fewer different perspectives to manage.

Anecdotally, we tend to perceive that things are going fairly well (or that those challenging spots are just the way it is in the software industry). When we compare that perception against the prospect of adding new practices into the fray, we have a strong bias towards keeping things as they are. We have an inertia towards remaining in our status quo. A key part of motivating the team, helping everyone understand what's in it for them, is to expose the inefficiencies that exist today. Few measure the cost of the weak components of current practices, often called the cost of non-quality, and without these measures we tend to see the world through rose-coloured glasses. In any team, even the most successful I have encountered, the existing costs of inefficiency will outweigh the costs of effective change.

Given baseline measures and an understanding of the range of motivations across the team (and knowing that for some, it is these baseline measures that are the prime motivating factors), we can start to identify what would be reasonable to do differently. If we have done our job well to this point, we have already lowered many of the barriers to change that would otherwise exist, and the challenge becomes more a matter of constraining the things we would take on at this point, through a triage of potential changes. We need to recognize that we won't go from the status quo to a perfect situation in one change cycle. The most effective route is to carefully select a few small changes, and the best way to do this is to help the group to decide on their own what makes sense to bite off.

Each potential thing we can change has its own cost-benefit relationship to what we are doing at the moment. Some will be highly disruptive to the team, and may actually result in a negative overall impact to our performance. Others, the ones we are looking for, will be a natural transition from what we are doing now, but will provide significant improvement in our results. It is impossible to identify the prime candidates for change without understanding the current situation: the practices, the results, the culture of the existing team. Despite this, there is no shortage of consultants that are willing to sell their pet approach to you without this knowledge.

The benefits of selecting a few small things to change need to be emphasized here. Culture shock is dramatically reduced, the time required to realize the benefits of the change is reduced, and these benefits will in turn demonstrate to the group that effective change does not have to be a painful experience (sowing the seeds for ongoing evolution). With the baselines that we have gathered, we can quantify the value of the effort, which will further motivate (and educate) those that would otherwise suggest that they can't afford to take the time for improvement.

Finally, we need to see these changes through to the point where they become part of a new status quo. This is the point where people recognize the value of these new practices, and will continue to work in this way, particularly when pressures rise on a project. How often have you been involved in a project where the deadline looms, and the team abandons all manner of practices in the name of meeting their goals? Peer reviews will be dropped, end-product testing will be reduced, even rigorous change management will be short-circuited. In situations like these, we haven't made it through the complete change cycle. We haven't improved until our new way of doing things is ruthlessly preserved, particularly when the pressure is on.

Business cases and measurement of ROI are the holy grail for disciplined decision making in business, and proponents for almost any best-practice or new approach (and we all know how often these pop up) will cite the numbers or walk through a justification indicating that their pet approach is the one to tackle. Formal inspections studies often cite ROI numbers around 10:1, there are many reports that suggest that improvement in requirements analysis provides strong returns, while others suggest that agile approaches are the way to go. I just received an e-mail this morning suggesting that, based on the often cited and frequently maligned Chaos Report, weak configuration management practices are largely to blame for the two-thirds of software projects that fail.

For every practice, we will get justification of their value through studies or reports, even if those practices are in direct opposition to one another. And you know what? I would guess that each of those studies has a strong basis for pitching those numbers. For the groups involved in the study, for the practices that were implemented, some value was gained. In many ways, the Hawthorne effect comes into play, and the fact that groups are consciously aware of the new practices makes them better in the application, regardless of what that practice is. I would not be surprised (though I would be amused) to see a study indicating that making no specific changes whatsoever will result in an improvement in productivity. Making the practices top-of-mind, whatever those practices may be, will have some positive effect.

This is all to say that while any practice can be justified by a business case or ROI numbers, each group will get wildly different results in the application of new hard skills. While some groups may see a 10:1 improvement with the application of formal inspections, another might see a net loss in productivity due to the cultural barriers associated with exposing their work for external review. The citations might cover the mean, or the median, or sometimes the peak results from the study (depending on how rigorous the study is and how motivated and biased they are to show strong numbers), but they rarely if ever show the variability in the numbers.

Just like early-stage project estimates, it is this variability or uncertainty in the business case that is far more important than any single-point values cited. ROI for the application of hard skills massively depends on the context. That's where the business case for soft skills begins.

If we look at all the hard skills that can improve software projects, they can almost all be bundled into the category of collaboration tools. That is, while a technique such as requirements analysis or design or exploratory testing can be done by an individual, they provide greatest leverage when used as a vehicle for increasing the shared understanding on a project. Many techniques, such as inspections or pair-programming or daily scrums, are structured such that they don't make sense for an individual. Indeed, the more we think of software as a team sport, the more we leverage and apply techniques to coordinate the team to work together more effectively, the higher our rate of success.

The reason each individual hard skill can see such powerful value in some teams while showing almost no return in others is the difference in how the team collaborates. The stronger a team is in open and empathetic communication, in appreciating the strengths and motivations of others, in consciously working in congruence with their own values, and in resolving warranted conflict in a reasonable manner, the more effective any application of new techniques will be.

From my experience, every failure in application of hard skills has its basis in a weakness in some aspect of soft skills within the group. If Bob doesn't appreciate Fred's contribution to the team, pair programming is doomed to failure. If there is a history of bad interactions in the group, formal inspections can easily degrade into personal attacks. If the structure of the team has contributed to silos between different groups, specifications will be thrown over the wall rather than developed in a collaborative fashion. The ROI on the hard skills will be diminished in each case.

Here's an exercise to run with your group. Ask everyone to complete these sentences individually: "the characteristics of my best project experience were..." and "the characteristics of my worst project experience were...". There is a good chance that the majority of the characteristics cited are based on soft skills: "I felt I was being listened to", "we worked well as a team", "we had fun together". You will encounter very little about the application of specific techniques, and almost nothing about the inclusion of tools. Based on our own experiences, we know intrinsically that it really is all about the soft skills in a team environment.

Back in the day, traditional approaches advocated a waterfall approach to software development (never mind whether or not you still think that way – in some ways, I do – but bear with me on this). A big monolithic analysis phase, followed in succession by design, implementation and validation. Great in textbooks, but in practice it never goes that smoothly. Change happens, it needs to be accommodated. History has shown that many of these projects don’t go as well as expected: you could take it from the Standish Group that uses their stats to sell their services, or you could base it on personal experience. I know I can.

Dig a bit deeper, though, and we can start to understand that a big requirements stage doesn’t necessarily mean an effective requirements stage. Indeed, it is rarely the case that projects move ahead with an effective common understanding of required scope, it is more often a period of wandering about and asking the customer what they want, then timing out, signing a big fat document and finally getting on with the ‘real work’. Even a first draft of the SWEBOK asserted that requirements analysis is an overhead activity on projects (they got a real earful for that one!). I certainly know now that I had the title of analyst long before I had the proper skills to extract and analyze the right information from stakeholders. Excelerator and Software Through Pictures and Rational Rose helped me make syntactically correct drawings that were really irrelevant in the context of the problem space.

It is a rare university that actually has a full course on requirements in their CS or Software Engineering curriculum. That’s not what the industry is looking for in grads, so the inertia continues. We learn primarily from experience and our peers, working in companies that have traditionally muddled through this phase, and we learn and reinforce substandard approaches. That’s just the way it is, we say. With this less-than-stellar definition of scope that we’ve taken some time to build, struggling along the way, we then move on to a similarly managed design stage, then finally get rolling as we come into the niche we were actually trained in and implement the system. Most of the grief we encounter here actually has its basis in the earlier design and analysis stages, but we forge ahead, and finally ship something through heroic efforts, often late, with less scope, and to a quality level of, well, since we didn’t quantify our quality objectives, we get what we asked for.

In some ways, the whole agile movement is a big backlash against this ‘traditional approach’. Rather than spend all that time up front producing a sub-standard specification that will be subject to massive change anyways, let’s get busy building things in a way that we’re good at, and learn and refine based on our mistakes. Makes a lot of sense, in some ways. Clip off that big fuzzy front-end, use early validation of builds with our customer to converge on the end product. From that perspective alone, there is a good chance that selecting this lifecycle can give you shorter schedules than the traditional approaches.

Where this theory falls down, though, is the expectation that software development is a necessarily un-deterministic process – that discovery is rampant in all projects throughout the lifecycle, so agile approaches will be better in all cases. I strongly disagree. I think most projects are rife with discovery throughout because even if we spend a lot of time up front, we’re not very effective at it. While the practices of strong analysis have been understood for years, they are rarely applied effectively. Even more rare is the conscious consideration of which of these practices will provide the most value on a given project. Most projects I have seen, big or small, innovative or not, would have benefited from a more focused analysis of needs from all stakeholder communities.

Indeed, many of the successes of agile approaches stem from the fact that they are simply removing a big chunk that added little value, and saved some time overall. Agility has tempered expectations, but has not effectively managed them. They have cut waste, but have actually increased uncertainty and risk on their projects without recognizing it. Their implementation stage now takes the lion’s share of the overall lifecycle, but that stage is rife with as much discovery as in the traditional approaches. Arguably more discovery, as any value that the analysis stage would have brought has been removed, injecting more discovery into that implementation stage. But that’s our comfort zone, so we live with it, you may say. Problem is, that there have been projects where that additional discovery has overwhelmed any cost savings gained through elimination of an explicit analysis stage. Embracing change has become a nice way of saying we are going to live with even more uncertainty and risk than before, because we have thrown out the analysis baby with the bathwater.

And lo, development teams and agile consultants rejoiced everywhere. But sorry, businesses still aren’t getting the level of value they deserve.

Just because we’re pretty bad at doing something doesn’t mean we should stop doing it. While that is the easy way out (and a great selling feature), it is far more effective to improve our approaches for analysis, and to recognize that every project merits a deep common understanding to some degree. That point is deeper on most projects than we typically run with, and the value of doing so is the dramatic reduction of risk and uncertainty downstream on our projects. If you have selected your lifecycle before you made it to this stage, that selection has been made with insufficient information. Are you confident enough in your approach to developing software, traditional or agile (if you feel you must be in a camp), to bid fixed-price on a project after a brief analysis of the client’s needs? Do you think you can make money with this approach?

Let me explain, as that last statement may not easily parse. I’m not saying that we can’t head into a project knowing how to approach the problem. I’m saying, rather, that most reasonably sized software projects are large enough, complex enough, multi-faceted enough to warrant a number of different approaches, for different aspects of the problem. I can’t think of a real-world software project that is perfectly tailored, in its entirety, for one specific approach. Not waterfall (...a few zealots go "yay!"). Not Agile (...a few older zealots go "yay!"). Nothing.

Let’s look at a concrete example. We’re tasked with building a real kick-butt first-person shooter game. Ask almost anyone in a game development company, and they’ll probably tell you this thing is perfect for an agile approach: build some elements, play with them, make them better. Evolve the artwork and the story as you go, and you will eventually converge on a winner. Cool, sounds like fun, but is this the right approach for the whole project?

Well, maybe not. Unless you want to develop the characters and story line from scratch, you are bound to the comic book/historic battle/sci-fi story that is the basis of the game (and much of this will become business rules to abide by, where you don’t have the option to deviate). What about the platform you are running on? Are you going to stick to the lowest common denominator of hardware and software capabilities and settle for lowest common denominator of sales as well, or really go for it? Do you head to the PC and it’s capabilities, or the gaming consoles? If you had started 2 years ago (or plan to start a couple of years from now), you have a new generation of game consoles and their not-so-subtle nuances to contend with. If you are going multi-console, how do you reconcile all of this without too much redundant development? All of this sounds like interface requirements and architectural considerations to contend with. While agility will help you with determining feasibility and selecting among different options, you probably won’t get away without some deep analysis.

OK, let’s go the other way. Many would contend that it would be insanity to head down an agile path for a large safety-critical product like an air traffic control system. There are lives at stake, we have good representation from the user community and they know what they want, and we just can’t afford to ship a little, learn a lot. Waterfall all the way, maybe big-chunk incremental, right?

Not so fast, buckaroo. No matter how big or safety-critical a new product is, if there is no novelty in its implementation you should really be asking yourself why you are investing all that money in the first place. Even if that novelty is under the hood as you port the system to the new platform while keeping the user experience nominally the same, there will be some areas that are ripe for experimentation, discovery, iteration. You won’t be able to nail everything up front, and agility will be required for you to adjust to what you learn. Feasibility issues in the platform you are using, novel algorithms that you will need to explore and tweak. If you are doing your job right, even with what might originally appear to be a vanilla port, there will likely be opportunities to tune the interface to refine the user experience, sometimes dramatically. While deep analysis and specification will be necessary to nail down much of what you need to build, there will be areas that require some agility.

If you can imagine an application that can be built most effectively with purely agile approaches, you probably have an interesting widget that doesn’t provide deep value to someone, or doesn’t interface with anything, or something that has mysteriously popped out of a lab, and not been devised with a clear vision of a problem to be solved. On the other hand, if you can imagine an application that can be built most effectively with purely traditional approaches, you are failing to push the envelope and extrapolate the possibilities for the user, or to explore possibilities before settling on one implementation. The key phrase in both these sentences is 'most effectively', as systems have been built, and success has been declared, from both camps many times in the past. I’m sure, though, that a better job could have been done with more balance.

Shades of gray rather than black and white. The industry is brutal for people taking sides in the battle over which development approach is the best. Some would suggest one approach is correct for everything, some would suggest it depends on the business or team. At the very least, in my books, it is project dependent, but more and more it makes sense to look at an even more detailed level. Even within a project, there needs to be a reasonable balance of flexible and rigorous approaches to be most effective.

First off, I think that if you are not Nokia and you have decided to use this test as your golden standard, you have already missed the point about agility. No single defined approach will ever be optimal for all your projects in your organization. Any organization should have a step zero where they look at the proposed project, look at the team and culture, look at the business objectives, and consciously decide the most reasonable approach for attacking the problem. While some elements of Scrum can be generalized, not all of it can be. Nokia’s spin on Scrum won’t work for everyone.

Into the test itself. The first few elements identify whether or not you are really iterative.

Iterations must be timeboxed to less than six weeks. I think iteration is imperative, but I have a problem with a magic number in the mix. Most of us as developers have learned that a hard-coded number is a sure-fire way of giving us problems at some point, and this is true here as well. Six weeks might be fine for Nokia, but that might be the entire project lifecycle in some shops. Too few iterations and you don’t have enough visibility into true progress, or natural points for allowing feedback to improve the existing product. Too many iterations, and you run the risk of excessive overhead. Lose the magic number, be iterative, but select an iteration cycle that works for you.

Software must be tested and working at the end of an iteration. I’ll buy that, pretty well as is. The point here is that we don’t want a gradually increasing bow-wave of loose ends that totally consumes the last iteration or two. When you have implemented a feature, it should work. If there are any loose ends, there should be an understanding of where they will be tied up in a later iteration.

Iteration must start before specification is complete. This one is interesting. Without insight into the thought processes going on, the intent appears to be avoidance of analysis paralysis, and that is a good thing. The idea of the specification ever being complete is a powder keg, though. The iteration needs to have clearly defined goals (that can be objectively assessed at the business value level), but the details can and must be discovered during the iteration. Ideally, the backlog of features (or whatever terminology you use) is defined to a level where the scope of the next iteration (or the next few iterations) is understood before the current iteration finishes.

As noted in some of the discussions around the Nokia Test, another key part of iteration that needs to be explicitly identified is that the team actually takes the time at the end of an iteration to consider the results, and feed the learning into future iterations. A retrospective that impacts future development is imperative. It wouldn’t hurt to explicitly identify that anytime someone sees behavior that is at odds with project and team success, they should step up and address the concern. Retrospectives aren’t the only point for this.

The next few elements identify whether or not you are really doing Nokia’s idea of Scrum. I’ll look at these and try to generalize to be more widely applicable, as Scrum is not part of the lexicon in every software shop (please don’t be shocked at this).

You know who the product owner is. Another straightforward element that is critical for any project. Someone has to have clear responsibility for ensuring that the product delivers the value to the end user, and to the business. Done correctly, the expectation of what that ROI should look like is defined in advance, as part of the overall vision for the product. That’s an element that many product owners conveniently neglect to do (giving them an easier task of artificially declaring victory), and is the accountability side of the issue.

There is a product backlog prioritized by business value. The product backlog has estimates created by the team. I put these together because I think there is value in looking at this element of Scrum from a different perspective. Business value and effort estimates are two valid viewpoints, and I think both should contribute to the overall prioritization. There may be features that involve little work but provide moderate business value, and could easily be implemented in an early iteration to beef-up the early feature set. There may be high value features that are difficult to implement: the job might be made easier by implementing other components first. I would suggest bringing both perspectives to the table, respecting them as reasonable (see the next point), and having the important discussions.

The team generates burndown charts and knows their velocity. Very Scrum-speak here, but can be generalized to suggest that estimates from the development need to be credible, and based on past experience with similar work. This is still one of the weakest areas for most teams, agile or otherwise, in the software industry. To be fair, the business owners should be striving to be quantifiably defendable from their perspective as well. In both cases, this is impossible if you do not track performance (time or value) against categories that can be mapped to future work products. Scrum does a nice job of providing a simplified model for doing so and gives teams an easier opportunity for getting started, but this remains a glaring hole in most shops.

There are no project managers (or anyone else) disrupting the work of the team. Wow. The way I read this, there are some serious dysfunctions to be addressed in how project management is perceived here. Sorry, but it is not a matter of telling everyone to get the hell out of the way, we have some code to sling: we are trying to develop commercial-grade products, not get our assignments to compile before the deadline. The business and the customer should always have a voice in what goes on, and this needs to be balanced. If project managers are seen as disruptive, that needs to be fixed. Call them Scrum masters if you need to, but in any shop, the project manager needs to be there to facilitate the team’s ability to get work done.

There is great value in having a standard way of doing things we need to do more than once. My wife has a way of dealing with the laundry as it goes from the hamper to washer to dryer to drawers, and she knows where the dirty clothes are and where the clean ones are. I’ve got my system for loading the dishwasher, to make sure I can pack it as completely as possible but still making sure they come out clean. We each have our own distinct way of getting the kids ready for school in the morning, and it is best to let one person take the reins if we are both around.

Our standard approaches have evolved over time, and with depth of experience comes efficiencies that we have made standard practice. We’ve grown our approaches, we are comfortable with them, and to some degree we are attached to them. They are ours, after all.

While we each have our way of doing things, there are clearly times this way is not well understood by others that may have to deal with it. I’ve been known to yell upstairs to to ask about the state of this or that pile of laundry, and while I’ve never been asked my opinion, there are times I’ll dive in and shuffle things around in the dishwasher. I’m sure I will learn the truth when my wife reads this entry.

As we develop software, especially when we are in an environment that does not provide an established and managed way of doing things, we come up with our own way of dealing with repetitive tasks. At the detailed level, we might follow our own approach to interacting with our CM systems, or for validating our code. If we’re charged with managing the daily builds for our product, in most places any automation is supplemented by a series of simple little manual steps that we know by rote (after learning the hard way). We develop a standard place we refer to for information about the latest part of the application we are building: while the ideal is to refer to well-managed and current scope or design information, the standard place is more likely to be the copy of the spec that we keep in our own space, or to go to the source (the analyst, or architect, or end user) for their latest opinion of what to build.

Many of the approaches we use to build software are carried over from our last jobs. Changing jobs or companies can be quite disruptive, and to bring with us our internalized approaches gives us that little bit of comfort, that jump-start of knowledge, that one less thing we need to learn here. There are even times where we simply assume that this is the only conceivable way these things could be done anyways ("Who in their right mind would think that the effort to build an automated test suite would save me time?")

Our systems give us individual efficiencies, but these rarely scale well to a team environment. I’m sure you have collided with other people’s systems when they were out of the office for a day or two and you had to pick up where they left off. For more than a few teams, there is one go-to person that can build the product successfully, or even manage the nightly backups without a hitch. When we need to swap roles, even temporarily, the challenges of individually built approaches to work become painfully apparent.

One of the things that I ask teams when I start to work with them is their approach to development. The response for almost every team has been the same, in that they are all inconsistent. While they may identify one approach over another, few teams are consistent in their understanding of how they get things done. Even when most people on a team suggest that they have adopted one of the agile approaches, or a variation of the unified process, or are CMMI-based (though I can’t quite comprehend how that maps to a specific approach), there are problems.

One problem is that it is only most of the team, not all of the team. There are always those that either haven’t subscribed to that party line, or haven’t been told what it is to begin with. The second problem, likely related to the first, is that once we dive into the details, even with a named approach, it has rarely been appropriately tailored, consistently deployed, and conscientiously monitored for application and effectiveness. Almost every team, when we get down to it, is ad-hoc.

If the team is small enough, this is not an overwhelming problem. If you can call over your shoulder to discover where that last build component is (or whether this load of whites should have bleach), you can still do well without much more fostering of consistent practices. Indeed, keeping the team small is one of the more credibly justified practices for project success, if it is appropriate for the problem at hand. As the team grows, so will the cost of the collisions associated with ad-hoc practices.

Given my experience, most teams would benefit from a bit more careful management of the approaches to getting things done. Individual perspectives can be leveraged to develop approaches that are both commonly understood, and eliminate the pitfalls of either of the earlier viewpoints. Team members become more interchangeable, and the bus-hit-the-hero corporate risks will drop. Most importantly, you will reduce the frequency of the phrase "What the heck were you thinking?!" on your projects.

As we start to recognize this, there is the danger that we go overboard in the other direction. There is no need to make every practice consistent, as long as the product of that effort satisfies everyone’s needs. It’s not critical to identify a dress code or a time when people should respond to e-mail, but issues like where to go for critical information, how to manage change, or what closure means for a piece of code being developed should all be carefully managed. If doing things in different ways will disrupt the project, it is worth making consistent. If the end result is still adequate despite a different approach being taken, don’t sweat it.

It is likely that "best practices" is the most overused term in software development today. Anyone discussing what needs to be done to improve the situation on projects will use the term. It is the basis for almost any consultant’s pitch. We train in best practices, we study and promote best practices, and we still face challenges. What is it about these best practices that makes them so compelling, and why don’t they seem to work as well as consultants would suggest?

The term "best practices" is not new. The idea of activities or techniques that are the most effective at solving problems was bantered around in the early 1900’s. There are best practices in manufacturing and agriculture, among others. There are Generally Accepted Accounting Practices (GAAP) - while not quite best practices, they are an expression of the way things are done for accounting.

For any practice to become a good practice, it needs to be shown to be effective in the real world. To become a best practice, it needs to be seen as the most effective approach to accomplishing a goal, in a repeatable fashion over a large sample space. Let’s consider each of these achievements, good and best, in turn.

There are many practices that have been shown to be effective in the real world, with truly amazing results. Studies in formal inspections, for example, often show a return on investment as high as 10:1. A dramatic reduction in lifecycle costs, and improved delivered quality. Most other practices demonstrate less compelling results in studies, but many are still seen as worthwhile investments. Iterative lifecycles, change management, software reuse, prototyping, metrics programs. They are all good practices, and the overall list is far too large for this forum.

All of these practices have been shown to work on real projects. Certainly the literature leans toward publishing the results of successes in applying these practices. Quantified data from my clients indicates that there are strong correlations between many of these practices and improved performance on teams. Actually, this data shows that these practices have a stronger positive correlation to performance than any demographic element in the study.

But are these best practices? Because projects and project teams come in all shapes and sizes, it is never safe to say a priori that any practice is the most effective approach a team can take on. While formal inspections can provide tremendous value for some projects, cultural considerations may make this practice difficult to implement, or even counterproductive with some teams. You could easily make a similar argument for any of the practice that is discussed. From that point of view, when we are talking about software development in general, the term "best practices" is hyperbole.

Under the right conditions, though, many of these practices can be very effective. This is the key point, that any practice is only situationally valuable. Short agile iterations may make sense for some projects, while deep analysis and design would better serve other projects. Some cultures may easily embrace a flattened, distributed decision structure, while others thrive under a stronger hierarchy.

The fact that ‘it depends’ whether a practice makes sense to apply is generally lost in software development. Consultants will pitch their specific flavor of practices as the solution without regard for the client situation, and sometimes the results are disappointing (how often is the consultant held accountable?). On teams, we tend to accept the advice of consultants without deeper study of the ramifications of our actions. We try to apply best practices, and find we are often disappointed with the results. We conclude that this process improvement stuff doesn’t work.

One of the most widely exposed catalogs of best practices is in Steve McConnell’s Rapid Development. The last third of the book consists of 27 best practice chapters, each one selected as an effective way of optimizing speed on projects (indicating that there are other practices that optimize other factors). A critical part of each of these chapters is an identification of the situations where the practice is effective, the major risks associated with the practice, and the major interactions and trade-offs. Again, this information is often overlooked during the consultant’s sales cycle, and neglected by many practitioners.

This may be one of the reasons why Fred Brooks asserted in his No Silver Bullet essay that "The gap between the best software engineering practice and the average practice is very wide – perhaps wider than in any other engineering discipline." This assertion was made in the context of expert systems that could someday disseminate the "experience and accumulated wisdom of the best programmers" to inexperienced programmers. We’re still not there over 30 years later, and the gap remains wider than it should be.

(Don’t get me going on why even the most revered experts persist in thinking of practitioners in software as programmers. If we are doing our job right, programming is but a small part of what we do.)

So there are many good practices, each having merit in some situations, but the insight of how to select and apply them is not generally exposed or recognized. Schools tend to emphasize technical skills because that is what the industry demands, and many of the practices we talk about are largely ignored or simply covered in a survey course. Many development teams rely on technical skills and heroic efforts to complete their projects. For many of the good practices that have been identified, in my experience there remains an alarmingly low rate of adoption. There are very few teams with disciplined estimation techniques, there are generally glaring omissions in analysis and design on projects, there is little conscious selection of project lifecycles. Similar gaps exist for any practice I can think of.

On top of all this, it is important to recognize that there are other factors that drive project success. We can’t just build a product and automatically be successful. The product needs a market, and the message needs to find that market. There is as much science in all the other disciplines as there is in product development, and any aspect of the business can make or break product adoption. Some would suggest that luck and timing play a major role as well.

With all the factors outside of software development, the apparent cost required to select and implement practices that improve product development, and the experience of poorly managed change, it is no wonder that best practice discussion quickly fades in most shops.

There are no best practices, only good practices that may help you if the situation warrants. You need to be aware of the practices, understand whether it makes sense to apply them, and then apply them correctly. This entails a great deal of effort and discovery, but done right, the payoff is enormous. With all this, there are no guarantees of success, as the most effective practices for your situation may be outside the software development discipline altogether. - JB [top]

There have been a large number of companies that have decided to adopt one of the Agile Approaches to software development over the past few years. Indeed, some of these have been quite successful in making the transition, but there are some that have not, for a variety of reasons.

Since the Agile Manifesto was published in 2001, the hype and success stories have been enough to drive many organizations to try something, anything that would make software development more effective than the approach that has been in place.

While there were some considered reviews of what Agility was all about before diving in, many went from an ad-hoc approach to one that remained essentially ad-hoc, but at least had a name. Often, few of the practices in any of the complete, well considered forms of Agility such as Extreme Programming or Scrum were put into place. For some organizations, Agility has been seen as a failure because they weren’t really being agile after all.

For others, though, even with a thorough understanding of the new approach, Agility has not brought great success. For those companies, perhaps the decision to become Agile in the first place was the wrong decision, a decision made for the wrong reasons.

If you think about it, agile approaches work well for teams and projects that are structured in a certain way. Let’s look at some of those drivers that would make a team or project a reasonable candidate for one of these approaches:

• Business Domain Knowledge – If the group does not have (or cannot expect to get) a clear complete picture of what the end product will look like, there will certainly be value in acknowledging that scope for the project will evolve dramatically over its life, and it makes sense to steer away from any plan-driven approach that would suggest a deep monolithic analysis up-front.
• Technical Domain Knowledge – Teams with a strong knowledge of the technical domain are at less risk in moving to an agile approach, which typically reduces emphasis on up-front analysis and design in favor of exploration, and deferral of decisions downstream where possible. Youthful, inexperienced teams will often suffer from their lack of tacit experience in this environment.
• Engagement and Participation – When the entire team is fully engaged and decision-making can be safely delegated across the group, there is less need for the rigid structures and the team can be much more flexible in how they achieve their goals.
• Ownership and Commitment – Similarly, when the team members understand their roles, the relationships between them and are fully committed to taking responsibility for their actions, an agile approach can serve to unleash team members, empowering them to achieve great things.
• Shared Understanding – On any project, shared understanding is critical as a prerequisite for successful decision-making. Given the relatively light demands for formal shared understanding on agile projects, there is a greater reliance on the team’s technical background and capacity to retain knowledge, and a greater imperative that the documentation that exists is up-to-date and consistent. To some degree, this informal approach drives the project size and duration to be smaller to avoid risk.
• Governance and Control – With agile projects, there is generally a relaxed approach to governance and control, again relying on the maturity of the team to ensure the decisions that are made are vetted as appropriate. This will tend to make agile approaches less amenable to high risk projects.
• Leadership and Direction – One of the key characteristics of agile projects is that while there is a vision of where the team wants to end up, the specific path to getting there is not clear, or extremely volatile. An a-priori plan of development would be difficult to construct, and many of the decisions to be made throughout the project are determinations of which direction is appropriate at that point to progress to the end as efficiently as possible.
• Integration – A strong agile team is one that has a strong understanding of the strengths and weaknesses of all the team members, and works well with one another to leverage these strengths and compensate for any weaknesses. Cooperation and sharing of information is absolutely essential, and the trust that is built through familiarity and past successes is extremely valuable.

[Note that these drivers were devised by Rob Goatham, and are very useful for determining the effectiveness of a team for making decisions in general. I would expect you will see more about these in the future...]

As we see, a team that is a strong candidate for adopting an agile approach has strengths in some of these drivers, but in others it is the nature of these agile approaches that compensates for any weaknesses the team may have. If we tie an understanding of how the team fits in each of these dimensions to the factors surrounding the product to be built such as the size of the effort, the time involved, the consequences of failure for the project, the team can make a far more mature decision about whether it is appropriate to use an agile approach to solve the problem.

There are teams, managers, and organizations where Agile approaches are a strong cultural fit, but this is not always the case. Similarly, there are some products where discovery is an ongoing element of the journey, while others will suffer greatly with such an approach.

Made consciously, in the context of how effective the team is at making decisions and the nature of the product being built, the decision to adopt an agile approach can be an effective one. - JB [top]

It seems to be pretty rare for people to consciously undermine any established system that has been put in place to develop software. At least, few will admit doing so. What usually happens is more subtle, an erosion over time of the good practices that make the software development machine tick.

A lot of software teams start off with wonderful intentions. There is a conscious decision to put in place a collection of practices that will help them build great software, within reasonable expectations of time and cost. Sometimes documented, sometimes not, but at least there was some gray matter applied to try to ensure the right things would be done.

Unfortunately, though, life quickly gets in the way. Erosion usually occurs in the name of time, with an unconscious degradation of quality.

There might be a quick patch needed in the field, and there just doesn’t seem to be the time to shore up the fidelity of the system afterwards. This can soon become a cascade of patches that undermines any fidelity the originally configured system may have had.

Perhaps the decision will be made to skip the peer reviews on this module: "Bob knows this part of the system inside and out and there's no way we could contribute." Actually, even those brand new to the organization or totally unfamiliar with the product can contribute significantly to a peer review. They’ll ask the naïve questions that expose the underlying assumptions that really need adjustment.

Sometimes it happens as people join the team without a deep understanding of the agreed-upon approach that has been established. When people start, there’s discussion of the business and product, but rarely an explicit discussion of process (except, of course, for how to make the coffee). This is where documenting your actual approach comes in handy (rather than pointing people to some theory that is never applied).

Some of the deepest erosion occurs when push comes to shove for a project’s schedule. "Let’s skip that big chunk of testing and hope that nothing bites us, the customer is screaming for the system". This can hurt you either way: if you get away with it this time, there will be some serious pressure to not even schedule the time for the next project. If you do get burned this time around, there can be some serious ramifications.

Regardless of how it happens, skipping steps that can save our bacon is rarely done with quality as a consideration.

There are often comparisons between a software development project and a manufacturing production line. For most software projects, though, the comparison should be to the design of the production line, not the line itself.

In a manufacturing plant, on a production line, it’s pretty clear what happens when a piece of the system is removed – the wheels can literally fall off (trust me, I know this first hand from a summer job of shuttling new cars across the border for Chrysler years ago). The production line is built to produce a quality product, and is optimized so that this product can be built efficiently. Once in a while one of the pieces of the assembly will break down, but nobody really thinks that removal of one part of the system, in the name of saving time, will turn out a good product faster – unless of course, they are consciously optimizing the assembly line.

So it goes in software. It is critical that we decide how we are going to build our software, and put in place some mechanisms that will allow us to ensure that this originally designed system remains intact. As we are tempted to make changes to how we build our product, we need to be focused foremost in the fidelity of the development process, rather than merely looking at how to get the product done more quickly. We need to build in checks and balances – retrospectives at the end to be sure, but also intermediate checks along the way – at key milestones, periodically if necessary, that check the fidelity of both our product and the approach we use to build it.

We need to avoid erosion of our system for development, regardless of the weight. - JB [top]

Idiot Lights (Compendium 6.18)