So earlier this month I attended two conferences. It was interesting to compare the vibe at each.
The first was Scrum Day 2012 in St. Leon-Rot.
In fact I actually attended PSM training with Ken Schwaber as a kind of add-on prior to the main event. This was a two day training seminar where we learn all about Scrum from Ken’s perspective in preparation for taking the Scrum.org PSM I test. It was great. Ken is one of the signers of the Agile Manifesto and has a lot of experience in the software development sector so I feel really fortunate to have had the opportunity to attend, and hear about Scrum directly from one of the two inventors. All the anecdotes he told were especially interesting. As far as Scrum content goes, well I am reasonably up to date on Scrum itself, being a regular reader of the two main Scrum mailing lists, and I am fairly familiar with the current version of the Scrum Guide, so as far as content goes there wasn’t that much new there for me.
Now Scrum Day this year had the tagline “Upscaled Agile in Large Enterprises”, so it was perhaps expected that the participants attending the PSM training were faced with issues particular to such environments, and I wonder if Ken tailored some of his material to that type of audience as well. The biggest thing that I noticed was his language reinforcing the divide between “the business” and “development”. Not just recognizing that it exists, and presenting Scrum as something to perhaps bridge this divide, but he seemed to feel as though this divide was at least inevitable, and perhaps even desirable. Now from my participation in the Scrum mailing lists, and other communities, this division is treated as something contemptible. Idealists claim there is no division, and pragmatists/realists claim that it is at least harmful, and something that should be bridged if possible. Ken’s language really made me feel that Scrum is, and even should be, something that just developers, and testers, and perhaps analysts and designers, do. “The Business” and even “Product Management” is something that happens outside the Scrum teams. My feeling is that the community has been trying to bring people involved in these mysterious leviathans in the teams, and get people across the whole value stream sitting and talking together. Ken’s vision for Scrum seems rather less ambitious. Scrum.org’s tagline is “improving the profession of software development”, which these days seems like a fairly narrow focus indeed. After all, Scrum is not specific to software development. Besides, I thought a Scrum team should be cross functional, and has to contain ALL participants involved in creating increments of customer value. So I am not sure if the implication is that “the business” and “product management” are not involved in creating customer value, or by customer value were are merely talking about a bit of software.
One of the reasons he gave for this separation, was that Scrum teams work on things like “stories”, but the business and product management don’t understand what a story is. He suggested that even the PO shouldn’t have to know too much about what a story is, because it is such a technical concept of more relevance to to developers. He suggested the PO should work with the team, and the team members should actually write the stories. I don’t have a huge problem with that, I think in smaller organizations it could work well. But in larger organizations this will lead to the situation where the majority of the process is not covered by Scrum, just the little bit in the middle where software gets developed. That leaves a gap that presumably a more waterfall-like process can cover. The business and product management will end up creating huge requirements documents for the PO to bring to the team for the team to go through and split into PBIs. Then the organization essentially pays the overhead of two processes, plus the costs associated with the cultural conflict between the two. Surely the larger the organization, the more important it is to move the aspects of agility, like story creation, as close to the customer as possible!
I should have written better notes, but I believe he mentioned the organization has 5 core responsibilities. 1 of which belongs to the development team, 2 more belong to the SM and the PO, and the remaining two, Quality and Governance are best left outside the team. I am sure I must have partially misunderstood this, but I think he claimed those responsible for various aspects of quality, like architects, UX designers, and other specialists are best left outside of the Scrum process. If I correctly understood this, I find it a fairly weak approach, and against the idea of the cross functional team.
He also explained how Kanban wasn’t as good as Scrum for a software development team, and that Kanban would be better for simple and complicated activities, but he greatly misunderstands how the Kanban community intends it to be used. Across the wider value stream, which is a huge difference to Ken’s approach of using Scrum merely in that little bit of the value stream where the software gets developed. Sure, if someone is to use Kanban just within a team of software developers then I agree it doesn’t bring much, and might even be worse than Scrum, but that is not how Kanban is supposed to be used. If I could choose between applying Kanban to bring together people involved across the whole value stream, or applying Scrum, as Ken expects, just to the narrow little bit of the process where the software gets developed, I would definitely expect to see more improvement in effectiveness with the wider Kanban approach.
One idea I did like was his idea of a Scrum Studio. The Scrum Studio concept involves setting up a pilot project using Scrum, but as separate to the existing organization as possible. (I assume it means the Scrum team is not embedded in the middle of a monstrous corporate hierarchy, but rather outside of it, with ideally nothing between it and the customer. Then, people who come to accept the agile values, and Scrum way of working, can decide to move over to the Scrum Studio, forming new teams, and taking over more and more of the old business, perhaps until the old business no longer remains. I think that is one of the few decent models I have heard of for addressing the problems that larger organizations face as they move towards a more agile way of working.
Anyway, I passed the PSM I test with 96%.
The evening after the second day of the PSM training was 1 hour open space, followed by an open fishbowl discussion (with Ken, and the guy behind the Scaled Agile Framework, Dean Leffingwell). I couldn’t really take part in the open space as the PSM training went longer than planned, but I butterflew around, and got an idea of the types of topics those presenting found interesting. I also noticed most of the open spaces were like mini-presentations, with the moderator standing at the front as expert and selling some pet-idea and participants asking questions. Half the topics were things like “how can you have a standard company architecture without a framework team?” or “how do you audit an organization’s agility”, and the other half were “Hear about how my cool new XYZ model can solve your problems”.
The open discussion brought out more of what I call the fear and mistrust type of questions, things like “how do you do agile without letting the developers have too much freedom and messing things up”, “how do you control the dependencies between teams”. There wasn’t much talk of my favorite topics like culture, mindset and motivation. Most of the discussion occurred firmly within the analytic mindset.
The following day was the Scrum Day proper with many presentations. I attended the keynote by Ken, then I manned our company stand for the rest of the day. I spent most of the time listening to the 76 year old security guard tell fascinating stories from his life, which was the highlight of the event. Conferences need more story-telling. I had the feeling most people were either sent there by their boss, to see how dangerous this new fangled Scrum thing is, or were there, as I was, to sell something. So it was a commercial conference rather than a community one. That’s cool, but it was rather different to the conferences I usually attend, and to be honest I felt a bit deflated by the vibe.
The following day I got up early and drove to Amsterdam for the Stoos Stampede.
This was an open space style community conference. One difference was the session planning occurred before the event, as an experiment. This had the advantage of people knowing what to expect, so they could decide whether or not to attend. I thought it was ok, because this stoos thing is pretty new, and you just can’t be too sure what will be covered.
I was a bit cautious. I was warned by at least 3 people whose opinions I listen to than it might not be that good. It might just be people pushing their agendas etc. Now I was pleasantly surprised. Sure some sessions were agenda-pushing, but those agendas were usually in line with my values, and were tools or ideas I could possibly use. I knew a few people there, but even when among strangers I felt as if I were among friends. We understood each other, and had similar goals. That was not the same for the Scrum Day.
I arrived late so just stumbled into a session. In fact most sessions I just selected based on the vibe I perceived and whether there was a free chair or not. I wrote down the following notes from the first session:
Middle management is not a problem, but a symptom (victim) of the problem.
Throw away your organizational charts.
Now I quickly ended up interpreting most things at the stoos stampede in terms of rightshifting and the Marshall Model, it just seems to be the structure my brain has decided to use to hang all the stoosian type content off of. So the assumption I made for the first point, is that the problem being referred to is being stuck in the analytic mindset. That second point I see as perhaps something an organization might be able to do as they rightshift, perhaps once they are partially synergistic, and wish to improve further, or perhaps it is a characteristic of the transition between the synergistic and chaordic mindsets.
I also attended a session on sociocracy, which is a tool I guess for using cybernetic principles for handling interaction between different parts of an organization. Especially for decision making. It was kind of interesting, but there was a lot of language referring to the “top” and “bottom” of the hierarchy. There was mention of those at the top having veto rights over decisions made lower. I noted that doing it the other way around would be more interesting. Imagine if those “below” had veto rights over decisions made by those “above”? It seemed to partially be a replacement for local decision making. I thought it might in fact increase the communication overhead in many situations. Rather than local decision making, I have to delegate it to a circle or something. There was some discussion about the hierarchy, and the host did not believe you can simply remove the hierarchy. He also mentioned it has nothing to do with command and control or autocracy, but that it was merely an abstraction. Hmmm.
There was also mention of a consent principle. I noted that I have to learn more about this in relation to coaching and consulting. I feel that often issues arise because coaches or consultants forgot to get consent from those being coached or consulted. I thought of asking the next team I work with if anyone does not consent to my idea and why. If anyone does not consent, then whatever reason they provide is what I have to address first.
So on the second day, I attended an inspiring (and even emotional) session on story telling. I intended to check out the story-telling cheat-sheet and use it for writing this blog post, but I haven’t done that yet. Story-telling is definitely something exciting that I want to learn more about.
After lunch I sat in on the provocatively labeled session, “does stoos need a manifesto?”. Of course it doesn’t, but that doesn’t mean we didn’t have anything to discuss. Someone discussed his vision of the movement: “Stewardship of the living rather than management of the machine”. It really resonated with me. Now can you imagine that coming out of the Scrum Day? Imagine standing up at Scrum Day and telling all these fear and mistrust managers that the best way to focus on making agile effective in larger organizations is to focus on stewardship of the living rather than management of the machine? They aren’t ready for that, but eventually that is what they will need to hear.
Still, it is almost opposite to the prevailing lean wisdom that managers should focus on managing the work rather than the workers. I dunno, I find the two reconcilable.
Some of the discussion seemed to boil down to two opposing concepts. Is stoos most concretely a statement of values, like agile, that tools can kind of base themselves on, or is it a collection of tools that support some vaguely understood yet not concretely defined value system. I would probably prefer it to be the latter, but lets see how things evolve. The values seem to be fairly well accepted by most agilists I guess, but there is a gap when it comes to concrete thinking tools we can actually apply to do whatever it is we want to do.
I led a session on Rightshifting and the Marshal Model. I was worried nobody would turn up. It took place at the same time as a very attractive playing with Lego session. But 5 or 6 of us were able to have an interesting worthwhile discussion on the topic. I explained what it is all about, drew the classic graph, showing how the ROI from change decreases if you stay in the same mindset, and that to really get improvement you have to change the mindset. I boldly suggested that the Ad Hoc and Analytic mindsets were not stoosian, and the Synergistic and Chaordic ones were. I advertised the LinkedIn group, and Bob’s blog, and I covered what I considered to be the advantages. They being:
The Marshall Model provides a language that stoosians can use rather than using more problematic words like Taylorist (Taylor said some good things too), Command & Control (the military uses it differently to how our community uses it), Agile (only applies to software development) etc.
For those using Kanban, it is useful when it comes to buy-in, you can explain that deep Kanban is all about cultural change, and is unsustainable if the organization is committed to staying in the analytic mindset, and also as one of the models mentioned by what used to be the 5th core property, and is now known as the 6th practice.
As a community.
The final evening was also a lot of fun, and very conducive to story-telling, but unfortunately this is already far too long…