Process Improvement

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!

A Hammerhead Shark versus James Bond in Speedos

A  Hammerhead Shark versus James Bond in SpeedosI’ve often found that most of the questioning about the worth of agile tends to come from the Project Management community. That’s not a criticism on PM’s but an acknowledgement that for them it’s probably more difficult to see how this agile concept can work.

Traditionally PM’s have tended to need their eyes pointing in different directions – one on the day to day development activities of the team, the detailed planning and daily progress, and one on the bigger picture, the long term roadmap and strategic planning side of a project. And, unless you’re a Hammerhead Shark – this is always going to be a tricky feat.

The trouble with agile, or more accurately, the trouble with some people’s interpretation of agile, is that it can be seen as an excuse to just focus on the tactical side of planning which leaves PM’s wondering what happens to all the stuff their other eye is usually pointing at.

So does being agile really mean ignoring the high level strategic side of managing and planning a project? Will the scent of burning Prince2 manuals soon pervade?

Fortunately this is not what agile means at all – in fact Scrum, which we all know and love, is pretty keen to remind us that we should still do release planning, risk management, and all those important things, it just doesn’t presume to tell us how to do them (in much the same way as it doesn’t tell us how to breathe, eat, sleep or do any other number of bodily functions we should still be doing whilst we’re Scrumming). What we are left to figure out for ourselves, as fully capable agile dudes, is how to ensure that we can stay agile for the long haul, which means having a sustainable and scalable approach to agility.

So how does that work? Is it really possible to add the governance, compliance, risk management and high level planning elements of managing a project to an agile approach without losing the agility? (Let’s hope so, for agile’s sake, because it is clearly and undeniably necessary).

Well, yes, of course, it is possible – otherwise agile just wouldn’t work. But it has to be done in a certain way. Let’s face it – you wouldn’t send James Bond out in full suit of armour, a wetsuit, padded ski suit and a parachute every time he went on a mission. Not only would it be a tad cumbersome, it would also be unnecessary (given that sometimes he gets away with just a small pair of Speedos). What you would do is give him exactly the right amount of kit required for a given situation. The same applies to agile. What’s needed is exactly the right amount of governance, planning and compliance for a given project – no more, no less.

So hang on – what have we got so far? James Bond in Speedos and a hammerhead shark. Which one is the PM? Well in a way it’s both, and neither. Confused? Good. Me too.

And I guess that is the point. A PM’s job is not easy and while they would love to be 007 in speedos (figuratively) – agile, unencumbered, able to work quickly and focus on getting the job done, they still need that hammerhead with one eye on all the ‘other stuff’.

I don’t think we can ever get rid of all that ‘other stuff’. It’s necessary and important. But we can minimise it so that only the right amount of ‘other stuff’ is put in place and we do what NEEDS TO BE DONE, building up from a minimal set (should I mention speedos again?) rather than starting out with everything, including the wetsuit and the parachute. This then, in essence, is the key to disciplined agile.

The PM still needs and will always need to be able to look at both the strategic and tactical side of a project, but with this approach maybe they need be less of a hammerhead. With agile self-organising teams the tactical planning side of a project is very much a team effort and, along with release and sprint burn-downs, daily stand-ups and sprint retrospectives, the tactical management is much less of an overhead.

So maybe, now, a normal shaped head will do, with just two eyes and some kind of innovative mechanism that will turn that head, allowing the PM to focus on the strategic but throw a glance towards the tactical when necessary.

Or maybe I’m just sticking my neck out.

Learn more about lightweight essential governance for agile projects.

Read the article: Agile and SEMAT - Perfect Partners.

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.

Shop Floor Agility Resistance

Agile software development can be an answer to over-prescriptive, over-documented and command & control style development. Agility is by no means anti-methodology, anti-documentation or anti-control. The idea is to restore balance and put people first.

In my experience most people think that, foremost, customers and management have to be convinced that adopting agile practices will lead to better, faster, cheaper and/or happier software development. And they also assume that transitioning to agile practices on the shop floor is a piece of cake. It is about more freedom, craftsmanship and collaboration, so who will object to that?

Well, in reality there are lots of reasons why analysts, developers, testers and people in roles alike object against agile. For example, there are people that object against teamwork because it threatens their knowledge based status.  Or what about team members that consistently refuse to update their tasks preventing them from having an up-to-date sprint burn chart. Another example is team members that just cannot focus on one of two user stories, always do work outside the scope of the sprint and never finish their tasks. Normal project or people management you say? What about team members that tell you that they do not have the required discipline nor are willing to try. Or what about staff who get violent when they are asked to move to another office space in order to create a co-located environment? Read More

Potential Barriers to the Adoption of Iterative Practices

Understanding the potential barriers to change will help you make the right choices of timing, project, and approach. Some of the more important questions to ask include in the following:

  • How supportive is senior management of the change? The measurements and milestones
    they establish can easily derail an iterative approach, as is the case when they ask even seemingly
    innocent questions such as “When will the design be completed?” or “When will requirements be
    signed-off?”
  • What is the scope of your authority to make changes? How much of the development lifecycle
    are you responsible for? For example, the requirements might have already been specified in a
    format and to a level of detail that would make it more difficult to adopt an iterative approach.
  • What are the team’s feelings about the changes? How enthusiastic is the team about iterating?
    To achieve the transition to iterative development, you will need the support of the team,
    especially the other members of the leadership team.
  • What else does the team have to do? How many other projects and initiatives is the team involved
    in? If the team is not focused on and dedicated to the project, the transition to iterative
    practices will probably be slower and take more time and energy to complete.
  • What capability do you need to improve? It is important to understand the capability of the
    team and how well the current capability supports the proposed iterative approach. For example,
    is there any testing capability in the team? Testing will be needed from the first iteration, which is
    often a problem in companies organized around the phases of a waterfall approach. Read More

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.

Stimulating a discussion: Getting to needs

Stimulating a discussion: Getting to needsOne of the frequent questions we are asked is "how can I get the time to explore needs when the business says that it is already done - "it's in the business case", even when it is obviously not complete?  This is actually a pretty common occurrence - nobody wants to take time to understand needs because they think it has already been done. Read More

Attitudes regarding risk and change

Attitudes regarding risk and changeMost project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read More

The Kernel Journals 8: A little help here!

The Kernel Journals 8: A little help here!In the previous kernel journals we have looked at the many practical applications of a process kernel that is based on the key software development entities (known as Alphas) that software projects add value to by progressing through their value states. We have seen that there are many advantages to separating these “whats” (progressions) that we are trying to achieve, from the many possible “hows” (software processes and practices) that describe how we might achieve and evidence these progressions, including the ability to set objectives and track progress in a common and consistent way irrespective of what specific practices a project happens to adopt.

Read More

Let’s measure the things that really matter

Let’s measure the things that really matterAs technologists, we tend to collect very detailed information and present it in a very technical way.  We talk about things like process maturity levels, and productivity indexes. I have even seen some measurement data about Agile maturity models that attempt to show how agile we are.  The problem with this kind of approach is it doesn’t provide anything that the business and the customers can relate to. 

The business does not really care how agile we are, they want to see results.  They want to be able to set targets, see improvements, and understand the benefits and the quality of the results being generated by IT. Only then can they begin to put the value of Agility into context – the context of the value and improvement generated by the move to agility. Read More

Page 1 of 3123