Tag Archives: Software Development

Please Stand-by to be Processed

process2

Let’s begin with a quote from Alistair Cockburn, one of the initiators of the Agile movement in software development.

‘While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

In case you haven’t figured it out by now, this post is about process. What it is. What it isn’t. Common misconceptions. Benefits. Implementation strategies.

What is a Process?

An established, step-by-step way of doing things, and a well-articulated set of internal and external documents and tools supporting it.

This is, of course, one definition of any number that may be out there. Another, more succinct definition (of sorts) that I’ve heard used is, ‘applied common sense’.

What isn’t a Process?

Magic. A silver bullet. A panacea. As the first quote above notes, a good process can’t assure delivery. That said, it’s a place to start. A baseline from which to begin and to continuously improve from. Even for the Agile purists that declare as part of their Agile Manifesto to value ‘Individuals and interactions over processes and tools’, are in fact rather processes driven in their own way through adherence to Agile processes and practices such as user story modeling , iterative development and time-boxing.

Preferred methodology aside, we could all benefit from a little bit of process – though not everyone is convinced.

Common Myths Associated with Process

  • Adds unnecessary steps and time
  • A form of micro-managment
  • Adds documentation for documentation’s sake
  • Limits creativity
  • Limits flexibility

These are common reasons why establishing (and documenting where appropriate) processes on a team or within an organization is often met with resistance.

On the other side of the coin, having a solid process that is understood, documented and followed can truly be the difference between success and failure on a project. And while it may not always be readily apparent from the outset, process can have numerous benefits for everyone involved. Here are 10+ that come to mind.

Benefits of Process

  1. Repeatable. Predictable. Manageable. Having a process in place will help to ensure that your delivery process is repeatable, predictable and manageable which has obvious associated benefits – as well as others explored in the subsequent points.
  2. Maximized efficiency. Minimized waste. To be able to hit the ground running on the actual work to be done vs. spending time defining the steps (the ‘how) and/or the creation of templates/documents/assets etc. to facilitate the work.
  3. Clear expectations. So everyone knows what they need to do, what everyone else needs to do, and what the timing and dependencies are.
  4. Reduces risk. By having processes in place related to the risky areas of delivery, risks are identified and mitigated early.
  5. Reduced re-work. With risks and/or issues caught earlier, the likelihood of costly re-work is reduced.
  6. Better quality product. With risks and/or issues caught earlier and the ‘how’ figured out in advance, the time and energy on the project can be focused on developing and testing the product, and the results will show.
  7. Reduced interruptions. Increased focus. Increased productivity. If there are still any skeptics, hopefully this one will help to convert them. While still having processes and steps in place related to the above points (e.g. risk identification and mitigation), an objective of any process should always be to provide more focused time for the team to do their work.
  8. Better awareness of the big picture. With a process in place and documented, everyone can see how their contributions fit into the larger picture.
  9. Cross training and professional growth. When processes are established and documented, it’s easy to train team members and new hires on how things are done to allow people to advance their career and not be ‘stuck’ having to take care of a certain task because he/she is the only one that knows how to do it.
  10. Increased customer satisfaction. Increased employee morale. With all of the above considered and addressed through the implementation of a process what works for your particular project/business unit/organization, the collective result will be increased customer satisfaction and increased employee morale, which is obviously good for everyone.

So now that we’ve seen the benefits of process, here are a few strategies for successful implementation.

Implementation Strategies

  • Alignment. When developing, documenting and improving your processes, take the time to step back and make sure it aligns with the goals and values of your organization, project and team members. Much like understanding how a work package or a test case maps back to a requirement in a delivery project, the way you get things done should also map back to individual, team and company goals.
  • Collaborate. Work collaboratively to develop your process with the people that will be using it. Seeking inputs from everyone will go a long way to ensure you have considered all of the areas and will also increase likelihood of adoption.
  • Don’t over analyze. While it’s important to not create a process in vacuum, not consulting and collecting inputs from all the stakeholders, be mindful of getting into analysis-paralysis mode trying to make it perfect for everyone. Take a page from the ‘Lean’ start-up playbook and seek to get your MVP (Minimum viable product) out there and then improve it over time.
  • Continuously improve. Further to the above point, processes should evolve and improve, so be active with looking for ways to make this happen. Process is not a one shot deal. Continuous improvement is key.
  • Understand that one size doesn’t fit all. Figure out what works for your team, your customer and your project and tailor accordingly. Consider having a step in the process to evaluate and tailor the process for each project, adjusting up or down based on factors such as the project’s size, type, technology and customer.

Leave a comment

Filed under Business, Business Analysis, General, Innovation, Management, People, Project Management, Strategy, Uncategorized

Broken Windows. Software. Process and Disorder.

broken window

Studies in the fields of criminology and urban decay have repeatedly found an interesting trigger mechanism – one that turns a clean and intact building, into a smashed and abandoned one. Care to hazard a guess what it could be?

A single broken window.

That single broken window, left unrepaired for a period of time has invariably lead to the rapid decline of the building and its community.

How does this happen?

It happens as a result of the sense of abandonment felt by those that live in and around the building; the sense that the powers that be don’t care about the building. So another window gets broken; then another. Later graffiti appears, followed by damage to the structure of the building. The spiral then continues until it gets to the point where the damage is beyond the building owner’s desire or willingness to fix it.

In one experiment in 1969, Stanford psychologist Philip Zimbardo arranged to have a car without license plates parked with its hood up in the Bronx, New York and another in Palo Alto California. In the New York example, vandals attacked the car within 10 minutes of its ‘abandonment’ and within 24 hours everything of any value had been taken. In California, the car sat untouched for more than a week. At this point Zimbardo himself smashed the windshield with a sledge hammer and then within minutes people passing by were joining in and then within a few hours the car was turned upside down and completely destroyed.

Social scientists Wilson and Kelling wrote about this ‘Broken Windows Theory’ in the March 1982 issue of ‘The Atlantic’. In this article they made these ‘inextricable linkages’ between disorder (or at least the perception of disorder) and crime. The New York vs. California example above – also referenced in the piece – notes how ‘untended property becomes fair game for people out for fun or plunder and even for people who ordinarily would not dream of doing such things and who probably consider themselves law-abiding’, and further, ‘vandalism can occur anywhere once communal barriers – the sense of mutual regard and the obligations of civility – are lowered by actions that seem to signal that “no one cares”’.

The Broken Windows theory has been credited in part for community based policing initiatives in various cities, perhaps most notably in New York City under the leadership of Rudolph Giuliani in the 1990s, where the focus was put on small crimes (e.g. vandalism, subway turn-style jumping) as a means of the prevention of larger crimes – by creating an atmosphere of order and lawfulness.

So, what does this have to do with software development?

Since the Broken Windows theory was theorized, software development teams have found inspiration in it, as a metaphor for focusing on the small things in order avoid larger problems down the road. Dealing with the ‘broken windows’, if you will, since ignoring them can result in ‘technical debt’ that will eventually have to be paid.

The idea is, that in addition to ensuring you’re doing all the right things – sweating the [seemingly] ‘small stuff’ – you’re not only developing a higher quality solution, you’re also creating an atmosphere on your project/team/company where process and quality matters. The Broken Windows theory as it applies to software development – generally speaking – asserts that issues should be dealt with before any further code is written. If the build doesn’t compile – fix it now. If there are bugs – fix them now. While this sounds simple enough, it’s not always the way it goes for one reason or another.

While each team and even each project for that matter will have different sets of processes for different reasons, there are still principles from this theory that can be used. Make it a point to agree on processes and standards for delivery. From unit tests, to comments and documentation, continuous integration and bug fixing – establish what your process and expected quality levels are and stick to them; even when you’re busy.

Especially when you’re busy.

In fact, ensure you’re working closely with whoever needs to be involved to make sure that you don’t find yourself constrained to the point where you’re unable to do all of these ‘little’ things, since that is a slippery slope to somewhere you don’t want to be.

I would further assert that this goes far beyond strategies related directly to the software development/coding aspect of solution delivery. Teams should also ensure that the overarching processes for solution delivery are agreed upon and maintained. While adherence to processes around things like communication, status reporting and risk analysis can sometimes seem like easy-pickings for corner cutting, the outcomes of doing so can lead you to a place where you could find yourself wondering how you got there.

One broken window at a time.

Reference: http://www.theatlantic.com/magazine/archive/1982/03/broken-windows/304465/

Leave a comment

Filed under General, Management, People, Project Management, Strategy