In the not-so-distant past, IT professionals and consultancies would execute extremely large methodologies that were designed to ensure that details captured during business and technical interviews were used to complete “as-is” detail requirements. They then go into future state business design, or the “to-be” phase.
Although I actually have no issue with this as an approach, all too often this leads to further technical design, elaboration, security, testing, and deployment strategies. This can mean that you wind up with an invaluable book of documentation, but generally, you end up with a very specific and semi-static end state.
Before you all react and say that people don't do projects this way any longer because of scrum and agile, etc.: well, I will tell you there are still a lot of organizations and executives that like to know exactly what is in and out of scope, with a defined end state and a known total cost.
The problem isn't that people don't understand there are other ways of working. It's just that there are some folks who either can't live with the unknowns, or, more often, it’s simply that they are being asked to make a personal commitment and put their job/career on the line, and this changes their behavior.
So, what about scrum, agile, lean, etc., which are designed to address most of these problems? Well, from what I have observed, there are pockets of extremely efficient co-located agile teams that have embraced all aspects of the methodology and really maximize its full potential. I find a lot of teams that embrace the iterative implementation style do so because it allows for better adaptation, but they are not entirely ready for user stories, story points, and velocity measures. Quite often, this is because the teams are not co-located, or the team is made up of employees, subcontractors, consultants, and in many cases, loosely connected business teams or IT operational teams, all with different levels of training and experience. The byproduct is to drop to a common denominator that isn't entirely in-line with the spirit of these methodologies.
In most instances, these teams know what they are doing is more agile-like than true agile, but it lets them tell business groups and sponsors that they are as up to date as anyone. In many cases, it’s the business itself that makes the agile “fr-agile” (bad joke, but I have said it way too many times for it to still be funny). The business still wants a committed scope with progress milestones before they will authorize the spend. Or the even more fun one is a fixed-price agile project, which almost makes no sense if you take into account that one aspect of agile development is that everything can change, and the other aspect is that nothing can change.
I have seen fixed-price agile projects work, but they get a little complicated. The milestones are for a number of story points delivered based on velocity. So the team is committing to sustain a specified velocity give or take some margin of error. The actual scope can vary, but the business unit needs to do story point trading. If they want to add something, the story points are assessed and they have to harvest them out of current or future sprint story points. If they have to have the new item but they can't harvest it, then it becomes a change order, just like a traditional fixed-price project.
I am a big fan of test- or behavior-driven development, but you can really use this in conjunction with any of the approaches or methodologies.
So where is all this going? Well, we don't just staff one the projects with "rockstars" to be agile and successful. We want all projects to be successful. Rather than rely on a set of individuals, we need to encourage broader team collaboration, participation, and buy-in to team success.
You may have heard of some of the newer concepts, and they do work in the majority of cases, but this may be in part due to not divulging why or how they work. One of these techniques is called gamification. Another, this one from IBM, is called design thinking. These all apply techniques and methods that stem from behavioral psychology.
In gamification, the project or application gives recognition and rewards for positive behaviors, and either does not reward or gives penalties for negative behaviors. This technique works when there is a healthy spirit of competition between individuals or groups. These same techniques tend not to work if there is an unhealthy competitive bias or if the team is already suffering from morale or burn-out issues. In these cases, you may just be adding fuel to the fire.
In design thinking, we are trying to give everyone an equal opportunity to influence the outcome for the better. The old adage is that two heads are better than one. Well, this is not true if one head always speaks up and the other always says sure, let’s just do that. Until you take the time to pay attention, you don't see it, but this is entirely normal in most teams because of the alphas who tend to take charge and dominate the decision-making process.
In design thinking, ideas are written down before evaluation. The team is asked to write at least one totally fanciful and impossible idea. This engages the creative brain (some people say "right brain,” but there seems to be some debate on the right versus left brain concept, and we don't really care which side does what). The technique then goes on to give an even (though small) set of votes to each participant. This neutralizes the dominant behavior and should mean the concept that the team is most supportive of bubbles to the top. Once the team has bought in and is behind their ideas, then it’s much easier to get everyone working together, and you can add gamification at this point too. These techniques are not mutually exclusive.
So what does all this have to do with the cloud, Mr. Cloud Musings guy? In the world of cloud, we often have the concept of being "born on the web." This is basically saying we start with a blank slate (or a green field, etc.) and we design everything, leaving behind the baggage of the past. All too often, people can't wrap their heads around how to make what they have work in a web, cloud, and mobile context, and there is a reason for this. It wasn't designed for cloud, web, or mobile. Making what you have work could be as much work or even more than getting the technical and business teams to focus on what is important. You have to take the partial solution to the consumers and get real feedback as it evolves.
This technique is considered the best practice for web, cloud, and mobile applications because the end state may have nothing in common with what you start with, but it’s probably the application you really needed—or if it isn’t, then you find out quickly, learn, and move on.
About the Author
Mike has been with Prolifics since 2006. He has over 20 years of IT experience covering project management, enterprise architecture, IT governance, SDLC methodologies, and design/programming in a client/server and Web-based context.