Work with old kingdoms to establish new republics
Everyday, agile changers face the same challenge : how to create a system with shared responsibility and collective decisions when there’s a hierarchical organization in place ?
In 2005 I travelled to Cape Town, South Africa. I was impressed by one particular event faced by this 400 years old country. The apartheid was ended by white people. Exclusive owners of the voting right, they voted a new constitution to share that right with everyone, no matter their skin color (note : they were more than one step leading to this, refer to wikipedia if interested).
13 years after the events, I was amazed when visiting Cap Town at how much a country with such a heavy burden was able to move forward so fast. They already had gay mariage.
Last month Alexandre Boutin told me another related experience he had when coaching a Korean company. His attempt to promote collective creativity was stuck. He was informed after a few hours that what he promoted was in contradiction with local manners : you don’t challenge in public someone else’s idea. A brainstorm, based on that precise principle, was impossible. After this social trait had been made explicit, they worked a way to circumvent this social convention in brainstorms.
But who did explain this cultural trait to him? The big boss. Who proposed and allowed criticizing ideas inside the group? The big boss.
The power in place allowed another distribution of power. It was peaceful and with immediate effect.
For change makers like me, there’s a lesson here. To change an organisation, the most efficient course of action is to have the current one doing it. So work through the system, not apart from it, not against it.
This led me to a few recipe when spreading agile in a hierarchical organization (with a tendency for command and control) :
Look for the person with a crown
Working from the ground level, doing more agile rituals, more « let’s prove them … », more « let’s have them understand that … », that’s not working. If you want your agile zone to spread, go up the power ladder and start where the power lies.
(How up the ladder ? enough to rule the whole organizational zone you want your new organization to reside in)
Deal with local lords
Unless you have a feature-oriented organization like Spotify, an efficient agile team usually unite skills from different divisions (business, IT, etc.). There’s as many managers to convince. Learn to sell them the change, let them deal with their current restraining forces (local power, budgets as a social status, etc), mobilize them.
Usually, these guys will introduce you the queen is she’s hard to talk to.
but all this requires to
Respect them, learn their etiquette
Understand their constraints, their social codes, their decision ecosystem, what subject triggers their interest. Just ask them, if you respect them some will teach you, even offer their help. They will tell you what is needed for this change to happen.
Is that encouraging the current system ? I don’t think so. Going along with the rules is not giving up. It just means you need to respect the system in place if you ambition to change it.
Agile explained in 3 paragraphs
I said earlier (in french) that being able to explain agile in any time frame from 1 minute to 2 hours is a key to agile adoption. Sometimes it’s also in a written manner. As years goes by I have stacked some short descriptions of agile I use here and there or rewrite.
Here’s a 3 paragraph explanation I wrote for a client’s HR division, whose people had no knowledge in software development. Feel free to reuse / modify / share.
Iterative implementation
In a classic waterfall development process, the software is exhaustively described, then developed at once, then validated.
Every evolution during the project disrupt the schedule. In agile development, features are added little by little up to the wished goal, refining requirements and validating as implementation goes on. This approach enable innovating during the project, and shortens the time between idea and implementation.
For agile mode to work, the implementation organisation must remain stable : a dedicated team, stable over time ; fixed-duration iterations (one or two weeks) ; and a regular work rhythm.
The agile team
Maximum proximity of all contributors is seeked as to benefit from face-to-face communication and the best emulation possible. Through specific meeting rules and visual management, shared responsibility and self-organisation are encouraged : success is everyone’s business, and the team operates day-to-day the way that seems relevant to it.
3 roles are distinguished in agile :
- the product owner (*) defines thinly the functionalities and their relative priority of implementation
- developers are in charge of end-to-end implementation
- the facilitator run the meetings and watch after the team dynamic. This role is endorsed by either a developer or the technical manager (**).
Handling risks and work pace
Progress indicators and risk indicators are evaluated by the contributors of the project themselves. With ground people driving the project, incident and delays are detected earlier, enabling structural decision to be taken by the top management soon enough, thus reducing further rush hours. (***)
(*) I used in fact « responsable produit », french translation of « product manager », a term more suited to the client’s usual terminology. The intended receivers weren’t about to run projects themselves so I choose not parasite their understanding with our agile-specific metaphor
(**) This organisation used to put apart technical people from business one. Coaching some of the technical managers into becoming agile facilitators of their team, aka Scrum Masters, was a choice we had made in this particular organisation.
(***) … Which was a way to tell the HR that a more efficient project management, i.e. Agile, enabled a healthier way of working
My meeting attender manifesto : be useful or don't be
Proclaiming that meetings are evil is common these days. I'm rather part of the people who proclaim that meetings are useful and precious but expensive. Meaningless and inefficient meetings are evil. There are plenty of advice around on how to run efficient meetings, like setting up agendas, protocols and decision report. After trying to bring these practices to various clients, I find this group approach too slow, it does not spread fast enough.
Why not starting by working on our own individual behavior ? More precisely : our will to be useful in meetings. Not having meetings useful for us, no, the other way around. As to support this statement you could for example
- decline the invitation if you don’t expect to be useful
- get out if you think you are not useful
- when in doubt, ask if you will be, otherwise leave
- leave in the middle of the meeting if need be
- ask to bring the items you’re useful for on top of the agenda
- delegate if you are not available
It doesn't mean you will go to less meetings. You can go there differently, learn to improve your usefulness, even if your involvement to the subject is low. Like
- ask for a wrap up of the further discussion if you've lost the point, offer your wrap up if no one answers
- ask candid question
- ask quiet attenders for their opinion when a conversation gets stuck
- bring out new perspective through suggestion
- propose various way of deciding
- start making a drawing or give a pen to someone
- follow the time and make time announcement
- ask for the agenda and purpose of the meeting if unclear
- go write key points and decisions on a paperboard
- show a good mood and a comforting smile
You can also ask yourself if you are still useful if
- you will bring no difference in opinion, position, perspective, culture from the other attendees, at least regarding the agenda
- you just want to be kept informed
- you need to see someone you know will be there
- you will hide your disagreement
- you chit-chat and whisper with your neighbors
- you will check your emails
A set of tricky questions
- What if I'm not concerned at all ? Facilitators and role models are useful. Ask if one is needed. Otherwise decline.
- What if I just care and want to bring my support ? This is a wonderful motivation. Now show your support even more by trying to be useful.
- Who cares if I'm not useful ? Your silent presence distracts others from feeling committed to the usefulness of the meeting. By the way, don't you have anything else to do ?
Now the last question will draw the conclusion. What about the others ? What can I do to have the others follow the same path ? I don't want to be alone driving things forward.
Don't distract yourself teaching others. Focus on yourself. Your own attention to be useful (or moving out of the way) will inspire others.
Kanban, because you’re worth it
A manager working for the media industry asked me a few month ago whether his teams should use Scrum or Kanban. He had sponsored agile teams I coached for 2 years. We worked together but didn't get into the details of methodology, so we knew each other (explains my familiar tone). Here’s my answer.
——
Hi O.
TL;DR : since I’ve been working at France Televisions Editions Numériques I’ve already been coaching your teams to Kanban, so you’re not going to get lost. You’re already doing flow development, like M. Jourdain speaking prose.
WTF are Scrum & Kanban ?
- two variations of Agile methods = two subset of practices, not necessarily exclusive
- Kanban (also labelled Lean IT or Lean Software) is a software development flow = you pop functionalities from a backlog and you check the counter every iteration
- Scrum follows the same principle but with strongly imprinted iterations, more protocol and meetings, in particular iteration planning, detailed task decomposition, estimation and a « commitment to deliver » at the beginning of the iteration. That’s not far from being a mini-waterfall cycle.
These methods are just starting points. While continuously improving teams will perfect them. Over the course of the project new practices will be integrated, modified or removed in regard of the time and context.
Kanban, because you’re worth it
My reasons for recommending you a development flow are
- it encourages better coding practices : baby step development, systematizing development and quality processes, emerging and minimalistic design
- Scrum do recommend good coding practices but enforces nothing and it’s a lack. I find that teams doing Scrum usually do not care enough about their coding practices, or too late in their product development.
- In a flow you're more reactive, you can introduce minor evolutions on the fly (just in time), let an ambulance pass through the traffic, which is more adapted to your activity [my client was working in the web / news media]. It’s never a 0 cost operation but it’s never a problem of methodology. With Scrum, adding a feature inside an iteration is seen as a disturbance (translation : violating the dogma)
- Kanban is just more efficient, drier : less chit-chat, less fuzz, simpler to deconstruct and to adapt to each context. Scrum needs half a day of ritual meetings per week of iteration, with Kanban you get down to 2 hour.
This evolution is where, by dint of continuous improvement, long journey team goes (after more than 50 iterations), or projects with high stakes or high risks, or mini-projects (having an implicit risk level due to their size).
It’s been 3-4 years I’m asking myself « what if we start by the best of ? » and it does work : young teams reach in a short time the maturity of long journey teams.
What duration for iteration ?
Apart from questioning the coding practices, the underlying question is the duration of the iterations : Scrum is more 2-week suited, but become too burdensome on a shorter pace (cf half a day of ritual).
Today I always recommend 1 week long iteration when a team starts : twice more learning because twice more retrospectives, short-term adjustment to their functioning, etc. I’ve let the [XXX] team start with 2-weeks iteration and we kicked ourselves (waiting 14 days to see if problems get resolved was unsustainable as the project start).
On the contrary, a seasoned team can be caught in the day-to-day (which is the point at early steps) and lack vigilance on long term planning. Some teams do like 2 week-long iteration to bring tempo within a long journey without specific deadline (like 4 month of development without a planned public release). That’s what the [YYY] team has chosen for example.
I think it can be meaningful to go on 2 weeks pace to a far away release for any team older than 10+ iterations, that already masters its flow with 1 week rhythm.
Like I usually tell the teams I coach,
I could have you do Scrum, but you’re better than that.
Use meaningless techniques when sizing a complex project
--- Note ---
this is a rough draft, barely re-read, that I may reedit / republish one day. You may find misspells, incorrect grammar forms and unclear ideas made into twisted sentences. This is a desperate try to publish early and often instead of rethinking and rewriting my posts for month... then loosing the initial impulse to publish them.
----
Collectivelly or individually, we seem to suck at evaluating complex project duration. We’re subject of numerous cognitive bias, such as optimism, social alignment on the leader, etc.
To succeed in sizing, I think the best approach I’ve seen working are the one that go round these bias, dodge them we could say.
Considering optimism, the baseline I use with agile teams sizing the remaining work : get numbers and global sum as later as you can. The evaluation has to be globally meaningless as later as possible. What you can’t see, like the full duration of the project you’re talking about, or the total sum of money it costs, can’t bias you.
Let me explain with concrete tips :
- use symbols, like t-shirt size or bike/car/truck/train/plane, or triangle, square, circle, etc. The less interpretable these symbols are, the less optimism can apply.
- compare and categorize work chunks by estimated size. Is X bigger than Y ? no, so it remains an « M » category
- as much as you can, try to compare every pieces in one batch. Dont evaluate pieces one by one, slowly, sequentially. Do it fast, evaluate in parallel, put aside the pieces that are problematic. I usually have all pieces printed and sort them physically on a table.
- use real references to compare to, so you keep an homogeneous scale month after month. Define piece of A as best representation of « S size », another piece of work B as example of « M » size », etc. Then when a new piece of work Z has to be evaluated, compare it to previous pieces of work A, B, and C. Not to meaningless symbols like « S », « M », « L », or too engaging-but-not-more-meaningful numbers.
- at the end, evaluate the references of each category with real numbers, like days, ideal man.day (erk), Euros, or complexity points as we use in agile. But let the math do the sum. Do not let that to a human brain.
Regarding leader bias and group bias, I use facilitating techniques to avoid polarity like
- use a facilitator!
- have people evaluate all at the same time on a first batch. Avoid one person taking the list of pieces and controlling the process, even for « helping »
- make people move physically around the evaluation table / wall /excel
More could be said on the whole process but I was willing to remain as less « agile-software development » oriented as possible.
Hope it helps.
Roleplaying teams’ dynamic from 2 to 5+ person
Yesterday I gave my opinion on why a team of 4 or 5 is preferable in the context of a student team learning agile. On the contrary, when facilitating a group I would advise no more than 3 or 4 people : to get cohesive thinking without preliminary team building.
But where do I get this from, exactly ?
Well, you know, over the course of my career I… well, not exactly.
I get that from roleplaying games. Dungeon & Dragons and Cyberpunk, mostly. My fellow dungeon masters and I shared our views and came to this observation:
From 2 to 6, the big tendancies we’ve seen among players
A pair of 2 works but may lack balance
and improvement over time. If they fit, they are like dancers. But if they are not, like an unbalanced leader/follower relation, they may lack any system to re-equilibrate themselves during the course of a game session.
2 points does not tell a circle.
So having a random team of 2 requires luck. You hire a pair that works well together, usually because they worked together beforehands, or you roll the dices and hope for the best.
A team of 3 is immediately fluent
in terms of decision making and coordination. This may be the most efficient team system we’ve seen.
1 on 1 dynamic are usually balanced by the 3rd teammate who provides circularity and stands back. This kind of team can smoothly reconfigure itself depending on time and context.
They tend to work focussed. Usually a pair is taking care of a major file, while minor stuff around is handled by the third one, sometimes in a facilitator-like position.
But these teams usually lack muscle. In Dungeon and Dragons, they may be warriors lacking offensive magic or curative powers, or being skilled in magic but lacking toughness for frontal fight.
A team of 4 has power with a proper coordination
The team wins ubiquity : they can focus on 2 subjects at a time with the resilience and insight of 2 people. no one works alone. Also, there’s a higher chance to find two pairs fitting together among all combinations.
Regarding muscle, this kind of team usually gets a broader skill spectrum. Weapons, endurance, magic, healing power, leadership, etc. They may not be powerful on all domains but they rarely have any criticAal weakness.
Now they need little time before they become efficient and team building is required. There’s a risk of a 3 + 1 dynamic, and to the teammate involved in the 3-person triangle the lack of circularity may not be obvious. It’s harder to realize that the 4th teammate is left apart or underused.
To sum up, a 4 person group can not only be efficient but also powerful. However it requires more warmup and a bit of training. It’s rarely top notch on day one.
A team of 5 requires training to be efficient
With a team of 5 you start to be in a 3+2 dynamic or 2+2+1 facilitator… or 3 against 2 or… 4 and a black sheep. With this size a real attention needs to be paid to coordination and alignment regarding decision making.
If that’s where you want to dig with your students, then that’s the size you’re looking for.
But, again, longer time slots are required for rituals or work chunks. Self-awareness discussions often require « warming up », which is slower when there’s more attendees. Disfunctioning of the group requires time to reveal itself and more time to be addressed properly.
One final word : on complexity thinking and self-awareness
Group are like systems : their complexity grow exponentially. There’s exponentially more relations involved, and exponentially more parameters to any decision.
A little experience : draw your team on a paper. One dot for each teammate placed on a circle. Now draw a line each time there’s an activity shared by 2 person. Some patterns emerge.
(this drawing is called a sociomap, by the way)
Not only on smaller teams the patterns are simpler, but also more obvious because the strokes become thicker.
Same goes for the team. Self-awareness is difficult for a team bigger than 7 because communication patterns are more spread and confused, while small groups experience more dense interpersonal relations with a simpler dynamic.
For all these reasons, if gathering a team bigger than 3, I would suggest that a) you start with 3 and bring new people 1 by 1 (each week for example), or 2) have them work in small subgroups for a short period of time before merging.
Playing dungeon and dragons would be, of course, my best recommandation 🙂