Dreamfeed

Routine - we follow our routines (except when we panic)

Willem wrote that a routine culture is not focused on results. Instead, it’s focused on methods, processes, and procedures. The underlying assumptions are that you are in a known, more or less predictable context and that you know that certain procedures and methods predictably lead to desired results. So to get to your results, focusing on steps, procedures, methods should be enough. It’s basically feed forward control of your software development system.

Working from these assumptions, it could make sense to blame the method or blame the person following the method if you don’t get the desired results: by following the method in the right way, you should get the right results, hence wrong results mean either the method doesn’t work or the people didn’t follow the method.

A Routine culture can work, as long as its underlying assumptions hold. A pitfall here is that when the methods are working well, they get reinforced, making them more and more efficient. The software development system gets more and more adapted to its context, but also less and less resilient to changes in that context. The assumption that the correct method produces a correct result becomes a ‘truth’. The system will get into trouble when either the context remains the same for a long time and then changes radically or when the context changes subtly over time and these changes are detected when they’ve grown big.

If a method doesn’t work any more, most people still try to make the best of the situation. There grows a tension between the espoused theory - the official method - and the theory in use - what people actually do to get results. This tension can be useful to stimulate process innovation (for more information about espoused theory vs. theory in use, see Organizational Learning II by Argyris and Schön).

A dysfunctional reaction is to cling more and more to the methods and blame the people for the results becoming worse. Now the theory in use and the espoused theory start to run widely apart. The link between them gets lost, some people focus on the method, trying to carve it in stone (without a defined process, how will we know who to blame?), others just try to get things done in spite of the Method. The painful tension between what actually happens and what ought to happen is covered up with a blanket of undiscussability - if you try to discuss the gap, you’ll be punished. Even the undiscussability is undiscussable. This is basically a Train-Wreck Management culture, with lots of blaming from management towards development. Now your organization is in deep trouble, a useful intervention could be to get a new job. There are other ways to get your organization out of this mess, but that’s a topic for a future blog entry.

A congruent response to the tension between espoused theory and theory in use is to acknowledge the end of the illusion that your methods are working, embrace the chaos, and move through practice and integration into a new status quo (in terms of the Satir model of change).

So within a known, more or less predictable context, a Routine culture can work. You should however frequently verify the underlying assumptions and improve your methods if they aren’t working any more (see also the Standardized Work principle of The Toyota Way). If you’re doing this, you’re in fact moving towards a Steering culture, by using feedback from your results to manage your software development system.

The next installment will be about why a Routine culture is often not appropriate for IT projects.

As promised, here is the first installment of a series of blog entries about cultural patterns of software organizations. Jerry Weinberg distinguishes the following patterns:

• Oblivious - we’re not aware that we’re developing software; there is no separation between user and development, e.g. a manager who writes Excel macros to support his decision making process.
• Variable - we do whatever we feel like at the moment; performance depends mainly on individuals (superprogrammers, “heroes”), e.g. a small startup with a few very skilled programmers developing the first product version quickly and efficiently.
• Routine - we follow our routines (except when we panic); e.g. an IT department that establishes a waterfall project management methodology as the right way to run all IT projects; this kind of works for projects that aren’t too complicated, but when applied to a brand new, important, complex project, everyone drops the standard process and works 60+ hour weeks towards the end of the project, in a desperate attempt to get the project finished.
• Steering - we choose among our routines by the result they produce; e.g. an agile project with short iterations provides insight in the results at the end of each iteration, through product demos and iteration retrospectives. This gives the product owner the opportunity to steer the product and the team the opportunity to adapt their way of working.
• Anticipating - we establish routines based on our past experience with them; e.g. explicit risk management activities that help to anticipate or prevent troubles instead of reacting to the troubles when they arise.
• Congruent - everyone is involved in improving everything all the time; it’s a culture of continuous reflection and improvement of processes, continuously improving the baselines; as a non-IT example, the idea of the Toyota Production System is to establish and sustain such a culture of continuous improvement.

If these patterns look familiar to you, that’s not a coincidence: they have the same origin as the CMMI maturity levels (they’re both based on the ideas from Quality Is Free by Philip B. Crosby), except Oblivious which was added by Jerry Weinberg. The patterns are not maturity levels however. Steering or Anticipating is not necessarily better or more mature than Variable or Routine. It’s all about whether a specific pattern fits your context or not.

In the context of strategically relevant IT projects, I believe it’s worthwhile to transition from a Variable or Routine culture to Steering and then to Anticipating. I’ll elaborate this in one of the next installments; for now, I’ll just mention that agile development principles and practices help you a great deal in making the shift to steering, but they don’t provide enough to help you establish an anticipating culture.

The next installment will be about the Routine pattern.

This week I got a notification that our proposal for an interactive presentation called People vs. Process: Cultural Patterns of Software Organizations has been accepted for both XP Days Benelux (15 and 16 November) and XP Day London (19 and 20 November). I’ll run this session together with Willem.

In this session, we are going to present different cultural patterns of software organizations, as described by Jerry Weinberg in his 4-volume Quality Software Management series. We’ve found this model of cultural patterns useful as a tool to understand IT organizations and to know where and how we can intervene effectively. The model gives a fresh perspective on software organizations, with a people oriented instead of process oriented view. It focuses on subculture and people’s behaviour.

During the next few weeks, I’ll write a number of blog entries about these cultural patterns. If you want to read ahead, here are a few links about the patterns:

• Welcome to Humane Architecture by Nynke Fokma and Becky Winant
• Our Management Process Can’t Tell us How to Get From “Repeatable” to “Defined” by Nynke Fokma and Erwin van der Bij
• Shooting And Aiming Stances on the systemsthinking.net wiki
• Blog entry by Willem van den Ende relating the Cynefin model and the cultural patterns

I’ve decided to leave PricewaterhouseCoopers by November 1st and become a full time in(ter)dependent coach/trainer/consultant.

Through my company Piecemeal Growth, I can help you to get a better grip on your projects, to improve project cycle time, to reduce the number of defects, and to make your IT more nimble and able to cope with continuous change. I have a background in agile and lean software development, systems thinking, organizational learning, and (open space) facilitation.

Some of the services I offer are:

• workshops that will give you a taste of e.g. agile development or systems thinking, to find out how you can benefit from it;
• training and mentoring individuals and teams, both in technical skills (like refactoring and automated testing) and in the area of processes and project management; I can e.g. coach teams in adopting a cycle of reflection and continuous improvement through frequent retrospectives;
• training and mentoring teams that would like to work and think in an agile or lean way;
• coaching and training agile coaches, agile project leaders, and Scrum masters to become effective change artists;
• facilitating Open Space and World Café sessions addressing the issues that really matter to you and your organization;
• facilitating peer supervision groups, to increase the learning capability of your organization.

If you’re interested in getting better results faster, by focusing on doing what really works instead of what others say you ought to do, feel free to contact me. I’m also available if you need a sparring partner.

In How to Destroy your Company by Implementing Packages or Oursourcing, Hans Konstapel writes about his experiences with large, failing IT projects, in particular package and outsourcing implementations, and how lots of time, effort, and money is wasted on such projects. An excerpt:

Do you now understand why there is such a shortage in IT specialist? About 30% of IT-projects is succesfull. This means that 70% of the IT-specialists are working for nothing. If we add the amount of “succesfull” projects that were delivered too late or the amount of projects were the implementation phase took so long because the software was “not-usable” the percentage is even lower.

(…)

Adapt what is working as long as possible.

A team of 15 people is capable of doing more than a team of 1000.

Perhaps this is the key to solving the current shortage of IT people:? Just let everyone work on the 30% successful projects and don’t do the unsuccessful 70% - shortage problem solved

It’s not as simple as this. First, although there are lots of practices, principles, and processes (e.g. from the field of agile software development) that increase the chances of success, we often can’t predict whether a project will be successful. Predictable projects are not interesting, not in a strategic sense. If it’s predictable, there’s probably someone who has already done it or even created a product or service for it. Most interesting, strategic IT projects are in the complex space, where cause and effect are only coherent in retrospect and do not repeat. Best practices, recipes and step-by-step methods don’t work here. You need to steer based on feedback instead, through a cycle of probe, sense, respond (or apply-inspect-adapt in agile terms^*)

Second, we need failures to learn from, especially if we’re in the complex space. But we do not need multi-million, multi-year failures. Instead, get early feedback by releasing early and often; fail fast, fail often, reflect and learn through retrospectives, apply the principle of poka yoke (mistake-proofing), and try again. Don’t hide your failures, celebrate them! (by avoiding bet-your-company ventures, you will actually get the opportunity to celebrate your failures…) Failures help you explore the space you’re operating in.

^* The phrase apply-inspect-adapt was coined by Joseph Pelrine, as an improved variant of the well known Scrum phrase inspect and adapt.

Willem has written a nice blog entry about eXtreme Customer Collaboration - about getting into the skin of the customer and operating as a whole team. We’ve had some discussions lately about the different roles in e.g. Scrum and the effect that these roles have on teams. Scrum and Extreme Programming distinguish explicit roles for the customer/product owner and developers/rest of the team. This distinction helps to think explicitly about how to fulfill certain important responsibilities in a project. The pitfall here is taking it too far, so that people start focusing on their own defined role only and state things like “that’s not my responsibility”. The team slips into an us vs. them mentality.

Remember, as team members, you’re all in the same venture, whether you’re a product owner, developer, tester, project leader, or Scrum master. You’re all in the same ship and if it sinks, you’ll all go down together; finger pointing and saying “it’s his fault!” doesn’t help you a bit… In Holland we have a saying “samen uit, samen thuis”, meaning we’re in this together - if you start something together, you also finish it together.

Listen for phrases like “that’s not my responsibility”, “that’s her job, not mine”, or “we’ve implemented it as specified, it’s not our problem the customer isn’t satisfied”. If you encounter this, you might want to check the team’s shared vision. If there is no shared vision, (re)establish it as soon as possible and make sure the team owns it. Explicitly share your goals as team members - everyone has his or her personal goals and the project’s goal should be in the intersection of all the stakeholder goals and interests - if you find out it’s not, you have a different problem to work on - more about that in a future blog entry.

Physical distance between the product owner and the rest of the team also reinforces the us vs them thinking, e.g. if you’re a few doors away, in the other building, or even on other side of the country. Get the team physically close to each other; rearrange the furniture and walls, try to co-locate everyone if possible. If it’s not possible, get everyone on site together at least part of the time, e.g. 1 day per week. The overhead incurred is worth the productivity gain.

The roles as defined in Scrum and Extreme Programming (and in many other process models) are ‘just’ tools: they help you in getting your processes going. They’re not carved in stone, so make sure the roles won’t become a goal in itself. Keep trying, inspecting and adapting; and remember that you’re all in this together.