Process

The Power of Checklists

The Power of ChecklistsSurgeons, astronauts, airline pilots and software professionals. What do all these people have in common? Well, for one, all of these professionals are very highly trained – in most cases in takes many years to reach a point where you can practice without supervision.

But even highly trained, experienced professionals can have a bad day, and make the occasional mistake. The problem is, if you’re an astronaut, airline pilot, or surgeon, and you make a mistake, lives can be lost. Software development, perhaps, is somewhat less life-critical, most of the time.

Simple checklists can help reduce human error dramatically. Some reports suggest that surgical checklists introduced by the World Health Organization have helped reduce mortality rates in major surgery by as much as 47%. Neil Armstrong had a checklist printed on the back of his glove (pictured), to ensure he remembered the important things as he made history as the first person to walk on the moon.

So if checklists can save lives, keep aircraft in the air, and help take people to the moon and back, why not utilize them to keep software projects on track, and help maximize the delivery of value, and minimize the risk of project failure?

Checklists help highly trained professionals focus on, and remember, the stuff that is important, and critical to the success of the endeavor they are working on. Unlike traditional process documentation, checklists are, by definition, lean, light and concise, so work well with agile development. The point is that they don’t burden a professional with lots of extra things to remember, or try to be prescriptive about how things are done – experienced professionals can generally be trusted to do the job properly, and make the right decisions when circumstances demand it – a checklist simply acts as an “aide-memoir” so nothing vital is forgotten.

So what does a software project checklist look like? Fortunately, some smart people have already done some work in this area, identifying a core set of checklists that can be applied to any software project, regardless of practices being applied, life-cycle being followed, or the technology or languages being used. They have been particularly effective when used in conjunction with agile approaches such as Scrum. These checklists are available in card form as Alpha State Cards, or as an iOS app.

You can learn more about the checklists by attending this free webinar.

Your feedback is welcomed!

Balancing Agility with Governance

Balancing Agility with GovernanceIt’s not often that I get the opportunity to help facilitate at an agile conference, but yesterday I did just that. I had the pleasure of helping Ian Spence deliver his session at RallyON 2013 in London. The theme of the session was about balancing the goals of agility with the need for governance, compliance and standards.

Most of us by now are familiar with the agile manifesto, and how it states “while we value the things on the right, we value the things on the left more” i.e. individuals and interactions are more valuable than processes and tools, but there is still some value in the latter. The point of the session was that we need to achieve a balance between agility and other things like governance, compliance and standards – things which are very often thought of as conflicting with agile and therefore “the enemy”! This is especially true in large organisations. But people whose job is to implement governance regimes, ensure compliance, and that standards are followed, are also people – people that agile development teams need to interact with.

Anyway, theory over, it was time to play some games – card games to be precise. Ian introduced Alpha State Cards, a simple tool for understanding project health and progress, by focusing on underlying performance indicators – indicators that are essential to all software endeavors regardless of method, process, life-cycle or practices being followed.

We only played a couple of these games: the first was using the cards to understand the state of an example project, the second to determine the required state of key project indicators before a team would be ready to start sprinting. But it was enough to see that a simple lightweight card-based approach could be a useful addition to one's agile toolkit, and help facilitate conversations between different stakeholders in an entirely method-neutral manner.

Ian then showed us how, using the cards to create checkpoints, a lean and lightweight governance model can be quickly constructed: one that is based on objective outcomes, rather than documentation.

The games, and the cards, are both available here if you want to try them out.

Light Weight Software Development Process #2

The Software Development Process Challenge

*The first post in this series can be read here

Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view software development from three time-scales (see Figure 1). Successful software development process is in essence, being able to coordinate the three time-scales effectively.

  • The broadest time scale covers from the beginning to the end of a software development cycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the software is suitable for release.
  • The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
  • The lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.

Light Weight Software Development Process #2

Figure 1:The Three Perspectives to Software Development.

A major problem I see in many development organizations is the serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There is a  miscommunication between the levels, and poor coordination within the same level, which leads to blockages which should not even happen. We need to solve this.

The kernel Journals 10: The essential does not change

The kernel Journals 10: The essential does not changeIn the previous kernel journals we have explored the value that development organizations can get from a process kernel that codifies what each and every project always has to do, in a way that is distinct and separate from how different project teams might choose to go about doing it, some benefits being:

De wereld van Practices – Wat is een Practice?

De wereld van Practices   Wat is een Practice?Bij IJI staan we een practice-gedreven aanpak voor. Zoals met veel concepten en principes geldt ook hier dat een goed begrip van wat ermee wordt bedoeld essentieel is om er echt de vruchten van te plukken. Een manier om daar invulling aan te geven is om te kijken naar criteria waaraan je een goede practice kunt herkennen. Maar voor we dat doen, is het goed om eerst te kijken naar de definitie en kenmerken van een practice en een practice-gedreven aanpak.

Onder een practice-gedreven aanpak verstaan we onder meer “het samenstellen van een effectieve manier van werken op basis van relevante procescomponenten”. In plaats van moeizaam te proberen een procesraamwerk toe te snijden op een specifiek project draaien we het om; we selecteren alleen relevante procescomponenten en assembleren die tot een consistent proces. En zo’n procescomponent noemen we dan een practice. Use Cases, User Stories en Iteratief ontwikkelen zijn enkele voorbeelden van practices. Andere voorbeelden zijn Operationaliseren Systeem en Datamigratie. In deze context is het ultieme doel van een practice-gedreven aanpak “betere resultaten boeken met softwareontwikkeling”. Hierbij kun je dan denken aan betere software, goedkoper, sneller en een prettigere manier van werken. Read More

The Kernel Journals 7: SatNav for Software Development Projects

In the last Kernel Journal we looked at the problem that Barry Boehm was aiming to solve back in 1995 when he first proposed his three standard process milestones (which later gained industry prominence as the milestones in the Unified Software Development Process and the Rational Unified Process), namely that “the proliferation of software process models provides flexibility”, but leaves us “with no common anchor points around which to plan and control.” [Barry Boehm, November 1995]. We looked at how a small set of domain entities with simple state progression models (which we call “Alphas”) can make these common anchor points much more practical and useful while ensuring that they remain process-neutral and do not become “document-driven”.

The alphas, when used with common milestones such as the Unified Process Milestones, can actually give us much more than this – they can provide a project status and health dashboard that can be used by the customer and supplier organizations to assess the current status and health of any / all projects, irrespective of which processes or practices they are following. The graphic below shows just such a dashboard, with a set of kernel alphas and a traffic-light status for each alpha, which is derived by comparing where the project is now (the state machine to the left of each traffic light) with where it needs to be to achieve the next project milestone (the state machine to the right of each traffic light).The Kernel Journals 7: SatNav for Software Development Projects

In Kernel Journal 5: “Making the Invisible Visible” I described how we can easily “skin” a process kernel, by providing a portal for projects to capture, share and agree the essential project information that is needed to achieve each state progression (for example, using a set of templated Wiki pages). Once we have done this, we can make the alpha dashboard much more useful to the project teams themselves, by flagging which sections of the project portal need to be updated and agreed to get the project to where it needs to go next.

This gives us the equivalent of a Satellite Navigation System for our software projects project that enables us to:

  • Set our journey destination and waypoints (milestones)
  • Track where we are now, compared to where we want to be
  • Get guidance on what to do next in order to progress towards our destination.


 

The Kernel Journals 4: A Cure for Document and Template Addiction

The Kernel Journals 4: A Cure for Document and Template AddictionMany organizations have achieved a degree of process maturity (reliability, discipline, consistency) only by paying a very heavy price – they have become addicted to documents and document templates.

Unfortunately, it can happen all too easily. Most processes end up being document-centric even though they never set out to be so. They start by offering useful process guidance on how to progress the project in a controlled way, in the form of a set of activities, each of which is defined in terms of the artifacts it produces. Most artifacts are documents of some kind and the process helpfully comes with templates for each document – a template is better than having to start with a blank sheet of paper, after all. The project milestones we need to pass through are evidenced using the documents, and the whole thing hangs together nicely. Read More

Software development a la mode by Ivar Jacobson

The style in which we develop software is as fashion influenced as the clothing style, maybe even more.  We don’t dress ourselves dramatic different more than every five to ten years, but when it comes to software we change our development style dramatically every five years. Just a few years ago the Unified Process was a la mode and every software organization was adopting UP one way or the other.  Just 2-3 years ago the hottest style was Extreme Programming XP, but now I hear very little about XP.  Now, everyone is running after the next “silver bullet” Scrum.

 

But what about Scrum, isn’t it fantastic?  When I for the first time met Ken Schwaber, a father of Scrum, I said: “What I like about Scrum is that it describes how really good project managers motivate people and run an iterative project.”  I continued: “…and its beauty comes from being agnostic to how you actually do things…you can pick your own way to do requirements, design, code and test.” I summarized: “Can I label Scrum ‘a common sense project management approach’?”  “Yes”, said Ken, “that label works”.  After this introduction we had a lot to talk about.

 

I can assure you that the founders of Scrum didn’t view their baby as a silver bullet, but with all the pressure from people who love fashion and want to create buzz, they may very well have to accept that they have created a silver bullet.

 

I think Scrum is a great project management practice.  It also includes some good social engineering work patterns which make it agile. 

 

However, that is all it is. 

  • You still need all the other practices that a good master of software needs to excel in, such as requirements, tests, architecture, components, modeling, configurations, and tools, etc.  This is all quite basic but important stuff. 
  • You also need to know how to build complex architectures such as SOA, PLA, EDA, and EA, architectures that are not just paper-ware but executable. 
  • Finally, Scrum is not enough if you want to know how to scale to large distributed organizations which may have outsourced projects.

 

What would make sense to do?

  • If you already are a Scrum fan you can say that you need Scrum++ where the Scrum stands for the tip of the iceberg and the ++ stands for the bottom of the iceberg which constitute all the other good practices that you will need.
  • If you are not a Scrum fan, you could consider replacing your current project management practice with a Scrum practice.  You can still work as you did before so you don’t need to throw out the baby with the bathwater.  However, you would use Scrum for project management for smaller projects.  For larger organizations you will need more.
  • In both cases you need to use modern social engineering work patterns as you need to be agile.

 

The ability to mix and match practices from different camps is what I and my company have been working with over the last four years, and now we can do it.  That will allow us to move forward and stay away from the silver bullets, the hype, the buzz and the fashion and treat software with the respect it deserves.

 

This would be smart.  Smart by the industry. 

Who Loves Process? by Ivar Jacobson

Right now I am in my home in Switzerland to take a break and ski. I ski during the days and I work mornings and nights. Sleep takes too much time so I do as little as possible of that.:) One of the questions I often get nowadays is “Does Process come from the top or from the bottom?” Before answering I will start with two questions that I usually ask during my presentations. “How many of you love process?” In a group of 750 people, I usually see 3-5 raised hands. These are of course the people who work with process implementation, and they don’t have to follow a process themselves. Then I ask provocatively “How many of you hate process”. Now I get a very different answer. Usually 60-70% of the audience raise their hands!

Why is it like that? I believe that in many larger companies process has been pushed down on the people who know how to develop software. This won’t work anymore. The competent will speak up to get the process they want, which is good. What worries me though is that the pendulum will swing over to the other extreme. Instead of process push-down we will get process pop–up.

People do as they want. If every team gets their own process, they will not be able to learn from other teams, they will not get common set of tools and they will not harvest reusable assets. What we really need is a balance between push-down and pop-up.

For a very long time (since 1987) I have told my clients that one of the most important success factors for process adoption is to identify both a sponsor and a champion for the process improvement. The champion is a developer with many years of experience, great competence and with high credibility among his comrades. The sponsor is a higher level manager who wants to improve the way his organization develops software to support the company’s business. Without support from both don’t bother to adopt any new process.

Another of success factor is to use experienced people to coach the team adopting the new process. However in many cases management wants process but doesn’t want to invest in coaching. They just hope that people will adopt the process offered to them without proper coaching. As a consequence a lot of organizations have failed in process adoption. Management tried a shortcut, but it became a detour. The money an organization spends on product development is a factor of ten higher than the money it spends on proper coaching. For twenty years I have told my clients that without adequate training and coaching don’t bother to adopt any new process.

A third success factor is to balance the need for process from the top (the management) and from the bottom (the developers). This is true for any process whether it is a software development process or a business process. Only working from the bottom is a very slow process, and working only from the top creates a lot of resistance. Unfortunately, in many organizations management pushed down process on people counter to our recommendations. The developers were not enthusiastic but they tried to adopt the new process. That was not easy. Management believed their people were using the process but the developers did what they wanted to do, usually what they always had done. We got a gap, sometimes a huge gap, between what the process said and what people actually did. We call it the process-project gap. Thus we got failures and people started to hate process.

We need to change this. My recipe contains four ingredients:

  1. Reduce complexity. Instead of adopting a big process consisting of many practices, adopt a practice at a time. This will significantly reduce the complexity of process improvement.
  2. Balance the push-down from the top and the pop-up from the bottom, instead of just doing one or the other.
  3. Allow teams to change the practices so they work in their projects. The way you really work must be fed back as a change to the practices. We want a process that is alive and not just a dead book. This allows us to close the gap. One challenge here is of course that traditional process hard-heads will demand that all deviations from the described practices must be documented and perhaps even be given formal exemptions. If that is necessary then people will feel that it is easier to do what is demanded than to do what is right. What we need is a utilitarian perspective on process rather than dogma. :)
  4. Activate the practices and bring them alive in a way traditional process has never been able to do. While activated, a practice can help with all kinds of things. It can review what the developers are doing and suggest corrections. It can automate mundane tasks transparent to the developers. It can train the developers on the job reducing the need for classroom training and traditional human mentors. The selected practices should give context-sensitive help to the developers. This means that they should only give the developers help when they want it and only the help they really want and no more. The goal is to give the developers more time to think and create and to remove a substantial part of the no-brain work that developers suffer from today.

We have had a period of process push-down. The pendulum is now swinging to the other extreme – process pop-up. After a few oscillations the pendulum will hopefully swing to a new position where we will get processes that balance both the need for governance and for the need for creativity.