SEMAT Initiative

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!

Alpha State Cards in Practice: Experiences from an Agile Trainer

Having had the opportunity to incorporate the Alpha State Cards within some recent training classes I have been delighted to see the enthusiastic reaction they receive. The cards are great at bringing what can sometimes be complex and difficult concepts to life and making them of real practical value to people.

In each Agile training class I deliver now, I use the cards to support an exercise that challenges the groups to determine the current status of a sample software development project. In the discussions afterwards, the groups have consistently reported:

  • They were really impressed on how the cards enabled more effective team communication and collaboration
  • The cards demonstrated in both a tangible and visual way that significant progress was being made, as the Alpha State Cards made it quick and easy to cut through the “noise” to the heart of what mattered
  • The whole experience showed how quick it was to come to a useful conclusion and each group found it an enjoyable way to work

When asked how the cards might support other team activities the feedback included the following:

  • The cards offer a great set of objectives to assist with task identification, task planning and  prioritization activities
  • The states on the card provide a basis for simplifying governance objectives and evaluation criteria, as well as making the whole process leaner
  • Revisiting the card abacus during iteration reviews to demonstrate iteration progress from a state perspective
  • They recognize the ability for the cards to advance and retreat along the abacus, to reflect significant change impacting one or more Alphas

I get a lot of satisfaction from using the cards in these courses as they really act to break down the barriers early in the course by helping the attendees to relax and to build their confidence working collaboratively together. They also gain a sense of experiencing something not only new, but highly effective too, and something they can easily apply back on their own projects to add value and improve ways of working.

For me as a trainer and coach, the cards significantly contribute towards an enhanced learning experience, and in so doing, increase the knowledge retention for the key learning points. The bottom line is it’s best to use the cards in a group situation to truly appreciate their value.

The Alpha State Cards, games and further guidance is available here if you want to try them yourself.

Also there is now a Alpha State Card LinkedIn group which is a great place to share ideas & ask questions about using the cards.

Semat – moving forward by Ivar Jacobson

Semat moving forward

During the last many months I have been very silent, but not inactive. I have been very active working with a dozen other people on moving Semat forward.  You will soon hear a lot more from us, but I would already now like to give you a quick update on the progress.

As you may recall, the Grand Vision of Semat was to re-found software engineering based on a widely agreed upon kernel representing the essence of software engineering.  The kernel would include elements covering societal and technical needs that support the concerns of industry, academia and practitioners.

The troika (Bertrand, Richard and I) were pleased, honored and gratified to find that in a short period of time, a dozen corporate and academic organizations, and some 3 dozen well-known individuals from the field of software engineering and computer science, became signatories to support the vision.  In addition, more than 1400 other supporters agreed to the call.

In November 2010, the troika agreed that we would move the work on the kernel to OMG (Object Management Group) to get the proper governance we needed.  Since then we have been working in three different but overlapping groups on three tasks:

Moving the development of the kernel to OMG.

In order to move the work to OMG, OMG first needed to submit a request for proposal (RFP).  A couple of people from Semat have worked together with a couple of OMG members to specify an RFP for what now is called 'A domain-specific language and a kernel of essentials for software engineering.’  Early December 2010, an early version of this RFP was presented to the Analysis and Design Task Force of OMG in Santa Clara. It was very well received.  Several other OMG members have now joined us to work on the RFP, which will be published within a few weeks.  March 21-24 the RFP will be discussed at an OMG meeting in Arlington/Washington DC.  We hope and expect it to be approved, and thus the work on proposals can start.  Anyone can submit a proposal, and so we will too.

Our proposal to a kernel

Semat itself will of course not give a proposal to the RFP, but key players are now working together to continue the work we started within Semat.  There is one team lead, Paul MacMahon, who along with 12-15 participants will now continue the work in a couple of tracks.  The idea of doing architectural spikes is continued.  The plan is still to be able to deliver something that can be used by the industry by April 1.  Personally, I think the work has slowed down because of the work with OMG and the continued work on Semat, which I will describe next.  However, we will deliver something of interest and also of value in a couple of months.

The kernel is just a first step in the Grand Vision of Semat.  However, much more work needs to be done.

Even if the development of the kernel now has been moved under the OMG’s umbrella, Semat still has a lot of work to do. We need for example to:

  • be a demanding “customer” of OMG, making sure that as a community, we get what we want,
  • support the community in its effort to get reusable practices,
  • move the work to the academic community to inspire the development of new curricula and useful research.

Thus, a vision for the next couple of years is needed.  A team of 8 people have been working for more than a month to develop a proposal for a Three Year Vision of Semat. This proposed vision should be published within a couple of weeks.  We will focus on what impact we expect to have on three key user groups: the practitioner, the industry and the academia.  The impact should be measurable and not just hand-waving.  How we will work to get the results specified in the vision will be discussed separately.  First we want to agree on where we want to go.

As I am sure you understand, working to ensure that the vision of Semat becomes reality is a challenging task to say the least.  However, it is one well worth the effort.  Please join us.

Model Storming by Ivar Jacobson

Model StormingLast week, I attended a workshop of a new initiative in software engineering (SEMAT see www.semat.org). This was the first real f2f meeting we've had. 28 people attended the workshop and one session with around 12 people were working on developing more detailed objectives of the entire initiative.

To develop the objectives we appointed a facilitator. He suggested that we make a usage model for the Semat initiative. But for this blog, what we modeled is not so important. It is the principles that are important. We built up the model on a large bulletin board using yellow, rectangular post-it stickers. A usage was like a use case or a user story.  Long side up for usages. Short side up for users outside the system. These were in essence all the instructions we got.

Read More