This month I spent some time in the company of Tobias Mayer, author of "The People's Scrum" which is a collection of writings from his blog posts, grouped into themes, that speak about ideas, topics and challenges around organisation's transformation along the scrum journey, driving home a striking message that time's are changing, a silent revolution is brewing.
I chanced upon this book by accident, browsing some tweets on #agile, saw a picture of the book cover, and it struck me as odd and interesting. Have never heard of Tobias Mayer before, I was intrigued - decided to follow him on Twitter, and buy the book on impulse. Mind you, it was really good that I did!
Tobias' style of writing is literally quite deep: written with words of sincerity, openness and passion, he cuts to the core of uncomfortable-but-so-relevant truths. He writes with a depth of experience that is so poignant that it forces you to think hard about the course you're on, the things you just accept and take for granted.
I was taken on quite a roller coaster ride, experiencing moments of pure resonation thinking I am on the same wavelength as this guy (I'm not that weird after all, just been the odd one out in most of my workplaces), riding high, in-phase, I'm on the right track!!
Yet also, there were instances when I felt a little edgy, somewhat uncomfortable, noticeably shifting my position as I lay in bed reading at night. Stopping, putting the book aside, sleep over it. I have just started my stint into consulting, not a specific agile coach per se, it is one tool in my toolbox of consulting ;-) so it was enlightening & awakening at the same time to see what could be in store for me personally (i.e. self-realisation of what true happiness means, does the road to consultancy end in permanent employment I wonder?) as well as professionally (much of the experiences shared by Mayer rings a bell as I've experienced similar).
Being deeply touched by the nature of this book and Mayer's genuine disclosure of personal experiences, I decided to take a chance and do somewhat of a different book review. Because the topics struck certain nerves, either resonating (fully in agreement with Mayer) or feeling of discomfort (not sure, not convinced), I thought, let me present a review based on a picture that describes these feelings - so I graphed something that looks like this:
 |
I assessed my feelings in almost real time as I read each article - I didn't spend much time processing and deep thinking, debating or self-reflecting in too much detail. I responded with gut feel, instincts, and of course, the life/work experiences I've had along the way - take it as a rough first-cut!
Here's the detail of these comments, for each article (I've not had the time to break these into separate links yet): In what follows, read as:
Section, Title, Level of Resonance, Level of Discomfort, Comments
0 Ron Jeffries Forward 50% 50%
Haven't heard of this guy Tobias Mayer before this book, maintained open mind. Title and cover art of book inspired me to purchase it
1 Author's Intro 80% 20%
Intrigued by his journey, wanted to find out more. I have a deep appreciation for people coming from the creative, artistic, musical, social backgrounds into the world of technology and software, so was looking forward. Some of the best software guys I've worked with came from arts/music background.
Discomfort also around my realisation that this work was a collection of blog posts packed into a book. Usually, this annoys me as I've come to learn from other books that were blog copy-and-pastes, the person was just exploiting another medium to make some money. However, had I not purchased this book by seeing the cover-art from another tweet, I wouldn't have known Mayer existed. [And after reading the book, cover-to-cover, I'm damn glad I bought the book in the first place!]
2 A New Way of Thinking 75% 25%
Have my own personal biases about the reality of "happy"
Agree that Scrum is not a methodology but a framework
3 The Heart of Scrum 55% 45%
Boards work up to a point but there still comes a need to radiate information to stakeholders that don't have the luxury of walking the floor and checking a board out. Progress reports still required by management, must keep stakeholders at bay.
"Happiness" again is hard to achieve in practice, depends on the culture of not only the company but also the people / country. Some people really just want to come to work, do they bit and go home, get paid, meet commitments
It's also quite okay to get to the heart, with small teams, focused and sharing a common goal & passion
Not everyone is passionate, especially when the team consists of outsourced contractors (foreign) who really have no skin in the game
4 Self Organization and Anarchy 65% 35%
I am an anarchist myself, and take pride in not being micromanaged - just leave me alone, the job will get done! I also try to afford teams the opportunity to self-organise, to emerge from the chaos converging on a way that works. In theory it sounds great, in practice, with old-school command-and-control mentality, this is quite hard to achieve unless you have very strong leadership in place, who understands and appreciates the scrum values of self-organisation.
I did indeed have the pleasure of being in a highly performing, self-organised team, back when I was a developer, but it is something that just doesn't happen quickly. With project deadlines that are just thrust upon you, which is still the norm in most companies I've seen, we can't afford the luxury to wait for order to emerge out of chaos, and wish for a self-organising team - hence my level of discomfort is in the mid-thirty percent.
I will wait to see how Tobias manages to implement this in practice with huge companies, he's bound to have better luck than me!
5 Shock Therapy or Compassion 85% 15%
General sentiment is I agree there is no quick fix implement that results in hyperproductivity. We should also be careful not to measure the wrong things, and just implement the scrum rules and ceremonies because the scrum bibles and scrum-lords say so.
But on the other hand, I am not averse to management intervention to provide a jolt of energy that awakens the team, taking them to the next level. Call in the people who've done it before, say for example, TDD unit testing - In the past I've used an external intervention to a)enlighten the team (penny drops) b)teach them that it really can be done and adds value.
I'm compassionate up to a point, again, it depends on the culture & context.
6 Software Artisans 60% 40%
Yes, software is indeed a creative process, it depends on the nature of the product, the intended audience, usefulness, value and degree of awesomeness in the product. Of course the events leading up to the first software release, would have been an emergent creative process - from then onwards however, enhancements, maintenance, etc - is really about the factory. Churn code, test, deliver. Reach as many eyeballs as possible, bring in the money. Software engineers, unless working on esoteric, ground-braking stuff - come to work, apply their craft (from a toolbox of design patterns, or google code, copy-and-paste) and carry on. In the fast world of delivery, there is nothing "creative, artistic, philosophical" about it. Yes, there is beauty in the architecture, design frameworks - this is craftsmanship, but craftsman turn to production lines when their product needs to scale and ship fast.
This may show me as someone who is quite blunt, direct, and bland, lacking creativity. On the contrary, I've worked in R&D blue sky projects, research and production code. My view of the world is rough, based on my background & the challenges I had to personally overcome (I was once a creative person, dreaming about the beauty of code, design patterns, freedom to create, etc - sadly, along the way projects had to be delivered on time, aggressively amidst strong competition, hence my bias around delivery mindset).
I do support Mayer that maybe in the future, we just look back and see what nutters we really were. I would actually wish to see more: instead of having the same product made by different competing companies, stop and work together for the upliftment of society - stop the greed, competition & change your darwinian mindset!
Traditional manager pay lip service to these new modern, fresh ideas of autonomy, freedom, craftsmanship - they let it play out, until they get too nervous unable to tolerate this "ultra democracy" any further, step in, intervene, unless delivery happens, heads will roll! In a recent progress meeting for one of my projects, the senior exec was visibly frustrated over our team's "ultra democratic" approaches!
7 Distributed Teams are Not Teams 90% 10%
It is a reality of life that organisations will be geographically distributed. It is a fact of life that you can get engineers a dime a dozen from India, China, Russia, Poland, Korea. Heck, I've seen it even happen in South Africa, where instead of investing in local talent, grow local teams, the economics is such that: it's cheaper, and also, there is just a scarcity of talent.
Instead of vanilla scrum that promotes co-location, we should acknowledge the reality, and look for ways of adapting scrum principles, meshed with other aspects of kanban, and look to agility frameworks such as DAD to guide us.
8 With Great Power… 100% 0%
I strongly support the Team Charter principle - it should be used for all teams, even if they've not yet experimenting with scrum.
And if a team is self-organising and in control of their destiny, then not having a charter will be quite harmful.
Managers should also have a charter, which maps into the overall business vision & strategy. Quite often, the company dreams up these values that can't be plainly translated into respective team values.
9 Unearthing Impediments by Doing Less 100% 5%
Couldn't agree more - measuring tasks in hours is pointless, unless (this is where the 5% discomfort comes in) you have a massive, large-scale deployment to co-ordinate which needs per-minute tracking, which really can't be avoided. You're into measuring cycle/takt time quite closely in that scenario.
For product development though, yes, every task should take no longer than a day. I am not a big supporter of story points either, more a man-day (old school) manager :-)
10 Test(osterone)-Infected Developers 100% 0%
This one really resonated with me - I've had the same experience of getting people to change their mindset of testers and developers, even the management team suffer fro hero-worship of developers. Developers must test, period. Testers are not test-monkeys. Testers should work closely with developers, in fact, pair with developers, providing guidance to them. I get a lot of flack from developers "developers are not wired the same as testers" bullshit. In the past as a developer, we would switch with other developers and test their code, before we even adopted code unit testing. Don't develop and throw stuff over the wall for the "test" team to validate, you are all one team. I even sent people on Lisa/Janet's training course, sent both devs and testers. In time, agree with Mayer, the time is now for a change!
11 Paying off Technical Debt 90% 10%
Fully support the concepts, used it myself - the challenge though, and this is where my discomfort sets in: scrum expects complete transparency of work by way of information radiators resorts in all sorts of inventive solutions to hide & not expose the "other work that's going on, because management will question why why why" So we over estimate, we add one more person to the "resource" estimation and over-inflate estimates - the nature of the game, which is sad.
12 The Agile Explorer 95% 5%
I too, don’t appreciate the term "Scrum Master" because "Master" really denotes a great accomplishment, seasoned, battle-hardened and glowing track record. This when almost anyone can go online, or attend a SM workshop and become a certified SM professional. Another reason is that some team members still cling on to the much-ingrained team structure where the "Team Leader" is the one that holds veto power, follow-and-to the line, and have the same expectation from the SM. Project Managers too, expect SMs to do more, instead of just being a buffer, facilitator of impediments, implementor of scrum ceremonies and dreaming up new ways of making use of colourful insulation tape on walls. Where/what is the value of a SM really? That is why I feel a big part of SM is leadership, with the authority to step in and steer, making decisions, but then isn't this what a team leader is?? So what I've seen is first, the SM hat is worn by the classic team leader. Overtime the team matures, then need for SM falls away.
I also agree that agile training / refreshers are much needed.
The Agile Explorer is a concept that I really like, and I'm happy to have met a CTO who talked to me about a position similar to that: freedom to experiment and steer learnings across the organisation. It is quite tempting! I will share the concept with the CTO to see if it resonates just as well.
My discomfort though is: we need radicalised leaders - get rid of the old management folks, give them early retirement because they are so ingrained with old habits: old habits die hard, you can't teach an old dog new tricks. You spend enormous amount of energy looking for buy-in, but these guys are so set in their confirmation biases, that you wonder, what's the point of banging your head against a brick wall??
13 Heartfelt Emotionalism is the New Hardcore 50% 50%
I am not so sure about getting too touchy feely. I do resist the command-and-control style, yet acknowledge that it is a necessary evil. All for growing teams, creating space, self reflection and all that, but one also has to respect commitments for delivery. Relationships-aside, I can easily switch between the modes, wear whichever hat is required off me. It also depends on the culture of team, people and country, so I'm 50/50 on this.
14 The People's Scrum 40% 60%
I am in the camp that scrum, XP, kanban, waterfall are all frameworks that can be tailored to the specific needs of a project (yes, everything is a project cos that's how business is run, money is allocated, budgets created, and run as ""projects"") and the needs of the team appointed to deliver the project.
I am however against the classic command-and-control mindset, the old way of having project managers dream up and impose timelines on the team.
I am also of the opinion that giving the rights to the people, to the team to solve, for them to create an emergent way of working, and yet at the same time maintaining some decent productivity to get the job done is extremely difficult to get done in practice. It depends again on the nature of the individuals, the types of people and the mindset culture of the country. I always go down to this point because we can't paint all software engineers with same brush. Americans work differently to the British. Indian engineers and Chinese are not the same. South African engineers have a different culture. Most projects these days consist of a mix and blend of cultures. Getting a team to gel well, waiting for the team to form on its own can be painful, leadership needs to happen at some point.
Mayer alludes to going back to modeling nature, I hope this comparison to biological systems or nature is not the Darwinian model, where collaboration is unlikely to happen, instead, assuming this model, people would fight to survive, survival of the fittest, or assimilation will happen (resistance is futile), losing individualism, losing sense of team, the strong victor emergent as the leader??
If I had the luxury of time, the capacity for patience, and not have a project deadline looming, then it would be a nice experiment to see how giving this freedom to the people will really go down. Some people are just like sheep, they need a shepherd to guide them, and they will follow blindly because of trust, but probably more importantly, they here just to work and get-the-job done!
15 Scrum: Its Place in the World 95% 5%
Very interesting, must follow up on this plexusinstitute. I believe in the ideal of self-organizing teams, I've worked in such a team in the past -- but its few and far between. It is a journey of a good few years, requires people to appreciate the new mindset & behaviour changes.
16 When is Scrum not Scrum? 70% 30%
I am a big fan of Ken Schwaber, Agile Project Management with Scrum is very relevant to the work that I've been doing for the last 14 years w.r.t. Digital TV Software products, like set top box software. The guidance in those books are relevant because it will take time for traditional projects management to adopt the new style of agile, progress reports are still needed. Points:
Agree with Mayer, I doubt like the term ""pigs and chickens"" - yuck
Don't agree with one to two week sprints - it depends on the technology. In my line of work, 30 days is about right to get a decent, stable, shippable software stack on time, like an operating system. Simple web apps maybe can be better suited to one-two week sprints.
Agree - tasks measured in days, not hours. Exception is in deployment tracking.
Disagree about workflow boards - workflow boards work when you dealing with one small team, I tend to favour a decent tool (Excel is great!) if used correctly
Agree about backlogs on the wall - although still prefer a tool for conversation tracking and audit trails
Disagree on estimation style - Story-points just don't work for me, man-days are better, T-shirt sizes work as well, story points are just intangible to the outside world, which can't be ignored. Dev team can use story points internally though if they like.
Agree on the use of sound software engineering practices: TDD, unit testing, CI, automation, pair programming, static analysis, etc.
Agree the SM is not always necessary - this could be done by team leaders or senior engineers or even line manager until the team is running smoothly.
17 Addition and Subtraction in Scrum 90% 10%
Agree we should respect and learn from grass roots first principles of scrum, let it soak for a while and then adapt it to fit the context and nature of the endeavour. Don't like just following scrum ceremonies for the sake of ceremonies, every ceremony must be value-adding, and yes, eliminate waste as far as possible.
18 Estimation 1: Size 60% 40%
I'm probably trapped in some of the old school processes here - customers do pay for developer hours, and at some point this really can't be avoided. I agree it's no business of the customer to go down to task-level detail hour estimates, this is incredible micromanagement - I've never experienced that before. However, man-days has been the norm in my playing field, and I can't see this disappearing any time soon, we have to get paid at the end of the day.
Story points can be used internally by the dev teams no problem. I still find it intangible to move from story points to days, since I prefer tasks to be no longer than one day. How many story points per day can one achieve then? Do you even need to use story points? I prefer to use T-shirt sizes, Small, Medium, Large, Complex mapping to number of sprints.
19 Estimation 2: Time 60% 40%
There are three posts on estimation, and yes they do seem to contradict each other. I was expecting the posts to be arrange chronologically to show the flow of how the insights change over time, but instead, the posts are arranged from 2007, 2012, then going back in time to 2010.
I still prefer man-days, whether that's a translation of team days, team weeks, sprints, etc. I'm set in my ways, sue me!
20 Estimation 3: Don't Estimate 40% 60%
This post was from 2010, but after the post of 2012 - so a little confusing.
If you have seasoned developers, I'd say trust their gut feel - if you have fairly inexperienced people, don't trust their gut because they don't have enough instincts or wisdom yet.
Some form of estimation is required, with feedback loops for correction, so measure, learn and adapt.
21 Scrum Roles: an Abstraction 90% 10%
Prefer the term Jester, will have to explore if this abstraction works on people. Need time.
22 Scrum Doesn't Do Anything 100% 0%
I just love: "Doing scrum is as meaningless (and impossible) as creating an instance of an abstract class"!!
Agree that scrum is essentially a framework that everyone must try to understand, appreciate, and respect the terms of the contract. One has to be open to face the organisational, team and personal dysfunction that will surface.
23 Marriage, But 100% 0%
We're on the same page there, don't fault the essence of scrum, implementations fail, respect the contract.
24 Don't Have Meetings 85% 15%
Agree meeting must result in value, outcomes based on actions. There is a stigma around dreaded meetings, sometimes it's just the culture of the organisation. Another word for meetings maybe "conversations", although I sometimes use "Commitment Planning Session", "Iteration Planning Review"
25 Timebox != Commitment 95% 5%
Mostly agree - but if I've got a team running for several sprints, I would like to see the timebox / estimates becoming more realistic, such that the team eventually delivers everything planned, consistently as part of that rhythm. I will accept that in general, timebox isn't a commitment though.
26 The Retrospective is Now 96% 4%
I actually do encourage teams I coach to reflect daily, to the point of sharing emotions, feelings, thoughts on a daily basis, we even have a daily emotional/feelings radar board. I still see value in the end-of-sprint retro, the big picture view - hence a little discomfort there.
I am also experimenting with the concept of ""Pre Mortem"" picked up from Sutton's "Scaling up Excellence"
27 The Soul of Scrum 98% 2%
Just gotta love the opening: Scrum was designed and refined for small teams working in a co-located space, willing to innovate and able to get working software out of the door in a rapid fashion. Fantastic, that's the essence, couldn't agree more.
When I see teams trying to scale scrum by having scrum of scrums for separate functional areas, they missed the boat completely about having cross-functional teams, that are autonomous...I have seen myself the ""weird, freakish chimera..."" that Mayer alludes to.
This post would have gotten a full 100% backing, zero discomfort rating, if it was not for my own personal bias, given the state of where I currently find myself in, that achieving self-organization is very difficult to achieve in reality. Artful making in the form of fostering collaboration, being patient with failures and granting freedom to the team to find themselves, is an ideal that I definitely would like to aspire to. If I were in a position of leadership to influence such a behaviour change, I would, probably in my next role as a Development Director or equivalent. But being a consultant newbie, I find myself hard-pressed, pushing against the classic command-and-control managers to give the agile team some space to breath, at the same time, not getting enough back from the same agile team to help inspire confidence in management. I have this picture in my head, there's two walls colliding, with me in between. I'm pushing against the two, trying to fend off management, and trying to protect the agile team.
Management grow impatient with this "For this to happen, a spirit of play needs to be encouraged, risks need to be taken, failure embraced as a learning opportunity…".
My one client had this to say "I'm looking for a coach to teach best practices around agile / delivery, there is no room for failure, delivery must happen always!"...Go Figure.
28 Catastrophic Organizational Change 75% 25%
Mayer just has a way of using words to trigger emotions I never knew I had, or had them subdued for such a long time because of coming to accept things for what they are. I would like to be part of this revolution, to see a team passionate enough, with such a burning desire to resist the status quo with a patience and determination, belief and strong faith that they're doing the right thing, in the end, truth will prevail. Sounds like a fairy tale, doesn't it?? There are enough real world stories to draw from, specifically in my case, the whole story of Apartheid and how South Africans patiently persevered their way to freedom - building such critical mass, that an implosion was inevitable. Corporate life could be turned around no doubt, we would need true leadership to see it happen. Human beings are weak, we look for inspiration in others (leaders), we want to be part of a group, community. We will rally behind a leader. Leaders do emerge out of the chaos, it will take time...Still, the people doing the work themselves need a catastrophic awakening, a change in mindset to evoke a disruptive change in the workplace. The cynic in me says that most people just play it safe, follow the crowd, are part of a herd and will go with the flow. A steady paycheck, mortgage and bills to pay, mouths to feed and other realities in life places working-life in second or third place...
I have seen some companies led from the top-down to embrace agile, it worked out pretty well in the end. I have also seen companies whereby freedom was given to the team, and nothing sensible emerged from the process, people spinning wheels, chaos and misunderstanding everywhere, until someone had to step in and just lead by command-and-control.
I am on my own personal journey to work with a company or team that embrace the new-age mindset that I share with Mayer, which is one of the reasons why I branched out into consulting - to see what other teams are up to. Catastrophic change as Mayer describes it shows the resultant change is because something has been building up quietly in the background leading to a positive, undeniable change. The opposite is also true, catastrophic change can be sparked as a result of festering bad practices, that left untouched for too long, will just come crashing down like a ceiling or wall that's been slowly collecting water through many leaks that went undetected, until the whole wall/ceiling comes crashing down. Disaster management will be needed, leading to hopefully, catastrophic change. I have used this analogy recently to describe how bad engineering practices can go on undetected until you hit a critical point where we're basically fubar'ed.
29 Agile Anarchy 100% 0%
Totally agree: "One of the great things that agile offers the corporate world is the freedom to seek outside the confines of what is considered right and proper, to embrace ideas that only a decade ago would have been considered anathema to corporate entities. Courage is touted as a key agile value by some agile pioneers, and it is certainly required when we reach out beyond our safety zone and listen to good ideas hitherto considered despicable, or dangerous". Hear hear!! What is also helpful is to use other corporates that have made such transitions a reality, so we can say "Company X" is doing it like this, maybe we should give it a try?? Being a single-voice alone trying to get word in through all the noise is not going to work, seek out people who've done it for real (not just any consultant who's read a book or two, but not seen any meaningful transition happen for real)...
30 Riding a Dinosaur 75% 25%
"I have two years worth of PMI journals still in their plastic wrappers, haven't got round to reading them because I'm always trying to keep up with the more relevant topics on Software development found online through blogs, podcasts and books of course. Why then do I keep renewing my PMI subscription? Why did I attend the full PMP workshop & study the books, only to NOT attend the exam? Why then did I complete the entire IEEE CSDP course, only to NOT write the exam? Why have I NOT got my Scrum Master certification, and add to my PMP PDU points??
Like Mayer says, these are dinosaurs. I only went for these things because companies insist on certifications. I wanted to work in the USA as a Software Development Project Manager, no PMP, no interview. In South Africa, no certifications means no job -- it is crazy. I am an anarchist myself. I challenge people who ask for certifications: Why? Why is it needed? Is my track record not enough? I'm here to help you solve problems, not write an entrance exam - lets have a conversation first around your challenges, what you're looking to solve, and I can share my thoughts, you can decide to hire me or not. But please don't pin the job on attachments to general bodies of knowledge, memberships...
Yet, I still hold on to memberships -- because I'm interested in other industries outside of Software, looking for parallels to adapt to the software world.
I agree with Mayer on resisting the temptations to fold-in to existing big-brother institutes, to become part of the circle, raising in influence and status. What would be great though, is if there was a secret agenda behind this, that the very catastrophic changes mentioned by Mayer, could be applied by the scrum groups with these institutes!
Still, I am not 100% against PMI - there are very good practices and discipline required in managing types of projects, which is true to Software as well, specifically safety-critical, life-altering systems. An agile, free-for-all team wouldn't cut it in those high-stakes cases.
31 Corporate Oppression 60% 40%
I get what Mayer is referring to especially with the troubles that plague organizations where oppression is just an unintended consequence of some other actions. The workplace is still evolving, maybe we have been stuck in the industrial mindset of yesteryear of operating humans as machines, installing mass cubicle farms, drilling management boss-worker hierarchical systems for decades: eradicating these behaviours & ingrained culture is going to take time, I believe we are seeing a turn in direction to focus on value-based, social & soft leadership instead of management.
My discomfort is really around how Mayer generalises on ""oppression"" and ""oppressed people"" taking it out of the context of the workplace and trying to rationalise behaviours of oppressed people. I was born in South Africa, my family slave-labourers from India, five or six generations ago. I think I know what oppression means, and it's not that people chose not to act, context matters greatly. In most cases, people are faced with enormous challenges and situations that are just outside their control, have to live with it, have strength of forbearance and wait for the right kind of leader / inspirational human being / hero to emerge. That's just how humans operate, whilst we would like to think that every human being has the power within to change and to come out fighting, we are but members of herd, going with groupthink, until a bright-spot hero emergences, rallies us together and revolution begins. Revolution can be active and passive - but it does happen eventually.
If we were to focus on the organisation, yes, I do support Mayers points on the hidden, indirect aspects of ""oppression"". People are also complacent and comfortable in the workplace, afraid to upset the status quo, keep your head down, come in 9 to 5, get paid. Fact-of-life, that not everyone wants to be happy and content in the workplace (aspirational but not the main driver). As Pip Coburn says in "The Change Function"" that people would change if the pain on staying the current course is far greater than the pain that would be experienced on the new course.
32 Organizational Blobs 100% 0%
Agree with all the sentiments. Like the differentiation between "continuous" and "continual" improvement. Just loved the analogy of blobs, classic. "Organizations are amorphous blobs, sometimes huge ones. They resemble those strange creatures you see in Jacques Cousteau documentaries...you can't distinguish the face from the anus...such creatures may not even have a central nervous system..." #awesome
33 In a Roundabout Sort of Way 100% 0%
Just gotta love roundabouts - big fan, smooth flow, trust. Great analogy
34 The Change Agent's Blade is Thin and Keen 100% 0%
Bloody marvellous comparison.
35 Scrum Adoption: The Awakening 100% 0%
I would also include sincerity, self-realisation, firm determination to change once the awakening has been experienced. Revivalisation of the senses
36 Team Culture, Project Culture 60% 40%
I don't know…need more time to process. There are deep rooted management & accounting practices that have been around for over a century, fueled by the industrial age age, processes burnt deeply in corporate culture, fuelled further by additional brainwashing in schools, colleges, etc. On top of that, like it or not, the Darwinian model of survival of the fittest, strongest rules, fierce competition, etc - pretty much sets the scene for most of how corporates and individuals behave. To stop thinking in a project mindset would be awesome, who controls the money? Who accounts for success? Do we trust the team?? Imagine if we let people run the towns, counties and states, or even countries? I wonder if there's an experiment that's done just that: leave the running of a town to the people alone??
I agree that context switching is plain inefficient. That calling people ""resources"" is not good. That team culture is more important than project culture. But I don't see the role of delivery management, execution and wider co-ordination left up to the team, maybe it would be possible - but in all likelihood, the team would settle on an ""interface to manage the interactions"", and this interface could be called anything else but a project manager??
Google's 20% time, according to what I've read recently, isn't as good as the hype, it was manageable when the company was small, but in scaling to tens of thousands of people, it becomes difficult to manage. At the end of the day, there is still a core group of decision-makers who check if their money is being spent in the right places. Most twenty percent time is spent with people transitioning to the next project, rather than cooking up some home-brew invention.
I have advocated in the past, and continue to do so now, that engineers must be given the right to choose the projects they'd like to work on. When there's new projects or products, the product or project manager puts an ad out about the project, the type of people & skill-set required and then recruits the project team from scratch, rather than being appointed ""heads"" by some dev manager you have no clue if the ""head"" is good or even remotely interested in the project.
As you can tell, I use the word project a lot, to me - a project denotes a piece of work (activity to be delivered: research, product, report) that must be done with regular checkpoints in time (a checkpoint could mark the end of the project).
37 Don't Build Teams 90% 10%
I'm still a little edgy that these things don't just happen by magic. It needs a person act as the bright spot, that exhibits certain behaviours, characteristics and traits that fellow colleagues aspire to. By the nature of org segmentation, I see this guiding star being the development line manager or team leader. To emerge a high performing team, some monitoring by someone must be in place, to offer guidance, make course corrections, try out experiments, instills certain behaviours. Unless I see this happen in reality, I can't buy in fully to the whole, self-emergent team aspiration that Mayer is pushing for.
38 Scaling Scrum: The Alcoholic Perspective 80% 20%
I support the view that before thinking about scaling scrum, you must have lived the essence of scrum to a degree where you've made the self realisation of the impact on the changes required, the behavioural and mindset aspects, and the implications of scaling. If you've not used scrum to deliver a working product to market and been on the journey with a small, co-located team, etc -- you will be out of your depth with introducing a scrum-esque process into the wider global organisation.
I like the comparison made with alcoholics anonymous, that scaling just happens, when the core rules are clear. This is not so different to the ""guard rails"" concept in Sutton's ""Scaling up Excellence"" or the Heath's ""Switch"" book on providing some sort of ""Script"" to remove ambiguity, providing clarity of purpose.
However, I do feel that scrum is definitely not the silver bullet to solving all the challenges of software product development (dare I say "projects"!) and when it comes to scaling, one should do the research, experiment if possible, or seek out people that have scaled successfully, looking into frameworks such as DaD & SaFE for example.
39 Seeking Consent 100% 0%
I am converted! I plan to use the concepts and quotes from this piece in some of my own workshops. Thanks Mayer!
40 The Spirit of Change 96% 4%
Each person experiences the Agile journey in unique ways, it's somewhat of a personal transformational experience, it is clear that Mayer has walked and lived this journey, a journey that I myself have started only recently as a consultant, the past 8 years of corporatised-agile cloaked some of the fundamental, first-principles, ground roots experiences. I have experienced similar challenges with management trying to fix people instead of the system, execs paying lip service to agile but don't give ten minutes face time to consultants, execs building layers and layers of hierarchy that contradict the very spirit of agile. It's a pity I've not come across Tobias Mayer before this year, I would have learnt a lot from his experiences and pain points. I wish him the best with his venture, the passion, desire for action and emotional transformation are overflowing - this can only result in success eventually. Best of luck Tobias, I am a new follower, please accept me into your tribe ;-)
1% discomfort is reserved because I can't just yet shake off my personal biases and life-learnt experiences around self-organization, a Utopia outcome where businesses just run (hey, conversion takes time!)
41 Afterword 100% 0%
Couldn't have said it any better. As you can tell from my own personal sharing, I found this book giving me shock therapy, waking me out of my slumber, pushing some of my buttons to force me to rethink and re-evaluate my own understanding, as well as, reflect on my own ability to make changes in the direction of the vision that Tobias. I am now, a Tobias Mayer supporter, and have joined his revolution, my own levels of discomfort aside, I think this guy is really on to something...
No comments:
Post a Comment