Last week I was fortunate to attend Jurgen Appelo‘s class on Management 3.0 in Hamburg, Germany. When Matt Heusser hit me to Jurgen’s Top200 Blogs for Software Developers in 2009, I sensed that Mr. Appelo had a unique view on software development. Last year he finished his book on Management 3.0, and accompanying the course we got a free copy of it. While I had read the stuff from Weinberg on Management, one of my goals was to find out what management is. Though I couldn’t achieve this goal in Jurgen’s class, I got some nice and unexpected take-aways from the training.

Jurgen split the day course into eight parts. The first part reflected on Agile methodologies and the various manifestos around. All of them I have seen before, while I was involved in getting the principles for one of them down, as well. Of course Jurgen left out the most important manifesto of all, but considering the audience of the course, this seemed ok.

Jurgen continued to develop his management model, which consist of six parts – and that formed most of the remainder of the course:

• Energize people
• Empower teams
• Align constraints
• Develop competence
• Grow structure
• Improve everything

For each of the six topic we collected some open questions which were going to be answered after we dealt with each part respectively. One theme struck me when I read the questions: “How can we introduce the will to change?” Reflecting on the exchange I had with Michael Bolton in December 2010 at EuroSTAR, I was immediately thinking: “Stop sucking the will to change out.” This refers to the discussion that the best motivation for people is to stop demotivating them. Since people like to change themselves, but don’t like to be changed, the first thing to consider is probably to switch your mindset.

Energize people

On energizing people Appelo referred to several models and evaluation formats. Myers-Briggs Type Indicator, one-on-one meetings, happiness index, and social networks are just some of the tools a manager may use in order to get to know her employees. We had a fictional employee which we had to manage. We could “buy” some of the answers to the models in order to get to know her better, and find ten meaningful things about her. While the team I was in – yes, it was even me you brought this into play – noticed that this woman had a serious health problem which even the doctor couldn’t help her with, and she wanted to have settled a change within the next six months, we suspected the woman to be pregnant. I approached Jurgen later on this, since I also wanted to find out about her Myers-Briggs type. First off, the woman is fictional. That said, Jurgen told me that she wasn’t pregnant – at least the doctor would have known what’s up with her, isn’t it? On her Myers-Briggs type it seems that my first intuition was right, but my final impression was that she’s an INTJ, but it turned out that I was wrong on that. Just in case you’re going to visit the course, I don’t want to spoil you with the type here, either. Find out for yourself. :)

Empower teams

On empowering teams, Jurgen presented his model of different software development approaches. On extreme there seems to be the rather chaotic cowboy programming. On the opposite of unstructured cowboy programming stands the ordered software engineering. In Jurgen’s model, Agile software development trades of the amount of order with the amount of chaos a project needs. Agile methodologies stand between the the fully ordered software engineering and the completely chaotic cowboy programming. This was a nice take-away for me.

On empowering teams, Appelo mentioned that this idea is nothing new, and can be found even in 1960’s literature on software development. His view, though, consists about the degree of involvement for teams in decisions. He showed us the situational leadership model, and combined it with the key decision areas and RACI matrix to get his seven levels of authority. The seven levels consist of telling people what to do, on to selling them your idea, consulting them, agreeing on a common decision together, advise, but leave the team to decide, inquire, – that is have the decision sold to the manager – or fully delegate. Having run into the situational leadership model beforehand, the model made a lot of sense to me.

On Visual Management Appelo mentioned that he likes to use authorization boards to make decisions about decision-making transparent. Similar to an Information Radiator a manager can use the board to make team involvements into decisions transparent. Appelo also stated that there are decisions which a manager probably can’t fully delegate to the team for legal consequences for example.

In the wrap-up we played delegation poker. Delegation poker is built around a decision which a participant was previously involved in. Each participant then turns a card with the involvement of the team based on the seven levels of authority, and when everyone has made a choice, the cards are turned. Just as in planning poker, the outliers are discussed. In my group we had decisions like salaries, and who to hire. Through the conversations interesting insights aroused for me.

Align constraints

On aligning constraints, Appelo mainly referred to goal setting criteria. He presented a variation of the SMART criteria for goals. In Jurgen’s goal setting checklist, he listed the adjectives actionable, ambitious, inspiring, measureable, memorable, realistic, relevant, simple, tangible, and time-bound. In the wrap-up we defined goals, and reviewed them afterwards from other groups.

Complexity thinking

On the second day in the morning we had an interlude with complexity and systems thinking. From my perspective I would move this part to front, not only caused by the fact that I finally got some Weinberg references here. Appelo described the difference between complex and complicated. In his model the ability to predict the outcome of a project goes from ordered to complex to chaotic. On the other hand, in an orthogonal direction, the ability to understand what’s happening may be simple or complicated.

Develop competence

Personally, I was a bit surprised when Jurgen referred to the culture model from Weinberg’s Quality Software Management series as a model of maturity in discipline. On developing competence he referred to other models as well. The Shu-Ha-Ri model, and the Dreyfuss model are just two which I had run into before attending the course. Jurgen explained that competence takes both skill as well as discipline.

In order to develop competence, Jurgen explained that a manager needs measurements. I referred to first-order and second-order measurements, but couldn’t explain it in the course. Later I remembered an article from Michael Bolton, Three Kinds of Measurement and Two Ways to Use Them where he explains the differences way better than I can.

In the wrap-up exercise we discussed several measurements and metrics, aligning them on a matrix consisting of different things to measure. On one axis where the different stakeholders of a particular metric: Individual, Team, Organization, Customer, Supplier, Shareholder, or Community. On the other axis where different dimensions of measurement: Time, Tools, People, Value, Functionality, Quality, and Process. I found Value and Quality ambiguous, since Quality is value to some person (Quality Software Management Volume 1 – Systems Thinking). But the matrix pretty covered the “to some person” attribute of Weinberg’s quality criteria. The teams came up with different measurements – first- and second-order – for the various combinations of measurement stakeholder and dimension. This was a nice exercise, but I seemed stuck to think about metrics – probably by remembering the paper Software Engineering Metrics – What do they measure and how do we know? from Kaner and Bond. So, just in case you’re planning on attending the course, don’t read it now; read it afterwards. :)

Grow structure

Appelo presented different structures for teams. One dimension to come up with structure is the segmentation of teams. You can decide to have them work in functional groups in several projects at the same time, or to have them work in cross-functional teams. For some roles it makes sense to include them in your cross-functional team – like programmers and testers. Other might be included on a on-demand basis, like database experts, or deployment specialists.

Regarding communication across teams Appelo proposed two structures: either through a manager that supervises both teams, or direct communicate. This organizations yields four different structures: functional teams with a manager, functional teams without a manager, functional teams with a manager, cross-functional teams without a manager, and cross-functional teams with a manager.

Appelo explained that Agile teams over time build up generalizing specialists. This matches my experience. No team initially has complete generalists. This does not mean that Agile won’t work for them. Instead over time the specialists start to generalize by learning what their colleagues do. This still means that they are in a lead position for their specialist topic, but they can also step for a colleague. This might mean, that a tester still is a specialist in testing, but he may also volunteer to work on a programming task as well. If the team is short on testers on the other hand, programmers are likely to step in with testing related work. Having everyone else step in for someone else is what I define as ultimate measurement of team-building.

In the wrap-up exercise we built some structures for teams based on first some pre-defined goals, like a company with 20 employees delivering software to a single customer. In the second part of the exercise we created a challenge for another team, and got one ourselves. We deliberately questioned the underlying implications, and decided that we would deal with the problem of growing a framework on another level of management. We created a structure, and wanted to deal with the imposed personal conflict not by providing a structure, but by working on the people relationship. (I hope my mind serves well here, as I didn’t take notes on the exercises.)

Improve everything

The last part dealt with change management in organizations – and the question on how to make people change from earlier. Appelo proposed his ADKAR model: Awareness for necessity to change, Desire to change, Knowledge for the change, Ability to change, and the Reinforcement to make the change stick. We played two games on change management, one that Deborah Hartmann-Preuss had brought based upon Fearless Change called Fearless Journey, and another one that Jurgen wanted to try. I played the latter one. He had prepared two pages of powerful questions to make the changes stick before starting the change effort. The questions helped to get to know what others would think about it, or how it would provide the right environment. It was fun, and I will keep the list with questions as they are a great list for any coach.

Personal reflection

Personally, I perceived the first day a bit weak. Delegation Poker was the highlight, but it was the only one for me. Considering I had some previous knowledge, this could be just me, but I would love to see Complexity Thinking on the first day as well. That would have given me a good mix of high energy and low energy topics.

As stated earlier, I still don’t know what management consists of, and one pointer in my session notes is to deal with the question, whether “management” is “management to some person (at some time)”. Considering the different things I can do as a manager – e.g. project manager, company manager, product manager, test manager, etc. – there seems to be a point of truth. But I liked the leadership and management model that Appelo proposed. I am sure that I will discover some additions over time – maybe while reading his book. Overall it was a great experience, and the group exercises helped to foster the theory that we dealt with in too short of time. I fully recommend this course to anyone considering her- or himself a manager, and wanting to become one. Surely enough I would add some books like Becoming a Technical Leader, Quality Software Management, and Perfect Software to make the picture more complete.