“prattle without practice”
― William Shakespeare, Othello
Enough prattle! All this theory is great, but how do we actually set the conditions for swarming to occur? How can we make it work?Initiating the Swarm
The problem with a good swarming team is that you can’t control team membership. Swarming requires a dynamic and egalitarian approach where everyone can decide what they want to do with whomever they please. Management has no role in this at all (other than perhaps creating the space). I suppose you could try and provide a few seed ideas to attract people, but you go into it with no assurance that those ideas will be what the groups coalesce around.
There should be some orientation to the values and principles to start with. We need to find a group that is interested in using the process and understands from the start that there are no explicitly defined leaders or followers. Anyone can come up with an idea, and if the idea is a good one, perhaps others will join you.
So the key ingredients to start swarming:
- People who have been introduced to and understand the swarming values and principles
- Some ideas
- A place for the swarming to take place – preferably a place dedicated to swarming
One more note on the people: radical diversity is required. It’s not sufficient to just toss a bunch of developers and QA into a room and tell them to swarm. It must be open to everyone. ABSOLUTELY everyone. That’s right, toss that cute receptionist from the front desk in there too. Customer Service, the guy from the help desk, and the janitor. Throw them all in. And a customer or two – don’t forget them. Oh, and for God’s sake, whatever you do, don’t toss an agile coach in there, they’ll tell everyone how to do it and just screw everything up.
That should get them started. It could be structured like the marketplace in open space. Everyone with an idea goes to the center of the room and writes their idea on a sheet of paper. They stand up and announce the idea, then go to some agreed upon area and wait to see who shows up. Simple. Then let people go wherever their interest takes them. They can be butterflies, bumble bees, whatever makes them happy. If you come up with a new idea (and hopefully people will) then you just write it down and announce it to the group. If there are no takers, no problem: you can decide to continue on your own and develop the idea to the point where it attracts more interest or you can dump it and look at someone else’s idea.
That’s really all there is to it. From here on out you just stand back and let it go. The teams that form will decide how to work together. If someone doesn’t like it, they can move on, make their own team or join another one. No managers. No scrum masters. Just:
Place in direct sunlight…
And let it grow…
Filed under: Agile, Coaching, Swarming, Teams Tagged: initiation, self-organization, starting, Swarming, team building, team creation
Was ist das eigentlich, das mittlere Management? Ich denke, es ist dabei zu verschwinden – zumindest in der Form, wie wir es kennen. Wieso ich das denke? Das gilt es zu zeigen, hier also mein „Beweis“.Anzug vs. Jeans
Viele mittlere Manager glauben, sie würden dazu dienen, die Kollegen auszusteuern, Anweisungen zu erteilen und dafür zu sorgen, dass die Produktivität in einem Unternehmen erhalten bleibt. Wenn man ihnen aber so zuschaut, stellt man fest, dass das mittlere Management oft 90 Prozent seiner Zeit mit sich selbst beschäftigt ist. Manager reden mit Managern. Als ich diese Beobachtung auf einer Konferenz in einer der Kaffeepausen darlegte, sagte eine Tischnachbarin: „Ja, das Management bildet ein geschlossenes System. Es gibt Management-Veranstaltungen, auf denen Manager sich zu Clubs formieren. Sie gehen zu anderen Veranstaltungen als zum Beispiel die Techniker im Unternehmen.“ Ich stutzte: War da was Wahres dran? Die auffälligste Beobachtung habe ich vor ein paar Jahren bei einem Kunden gemacht: Dort liefen die Manager ausschließlich in Anzug und weißem Hemd herum, während alle Ingenieure und Software-Entwickler in Jeans und kariertem Hemd unterwegs waren. In der Kantine konnte man die Lager besonders gut erkennen.
Nun darf man aus einer Beobachtung nicht auf die Allgemeinheit schließen, aber die Formulierung der Kollegin machte mich hellhörig. Seitdem beobachte ich in den Unternehmen – nebenbei – wie viel Interaktion, also echtes Zusammenarbeiten, zwischen den mittleren Managern und den Nicht-Managern herrscht. Das ist wirklich faszinierend: Es gibt so gut wie keine. Ein Statusmeeting von 1 bis 2 Stunden pro 60-Stunden-Woche – das sind 2 bis 5 Prozent der Zeit, die das Management mit den Kollegen, die sie führen sollen, aufbringt. Rechnen wir noch die Zeit für das Schreiben von E-Mails hinzu, kommt man vielleicht auf 20 Prozent der Wochenarbeitszeit, also 8 bis 12 Stunden, in denen das mittlere Management mit den Kollegen redet. Doch das bedeutet doch, dass die Kollegin Recht hatte: Das Management baut ein geschlossenes System, das die Realität nur noch aus Erzählungen Chats, Power Point und Reporting-Meetings kennt. Eine Kaste, die gar nicht mehr dazu dient, die Kollegen auszusteuern und ihnen dabei zu helfen, ihre Arbeit zu machen. Das kann am Ende aber nur dazu führen, dass das Management selbst eine aussterbende Spezies ist. Internet, Netzwerke, Plattformen, Tools wie JIRA und Co, die eingeführt werden, um die Sichtbarkeit für das Management zu erhöhen, machen es ja nun möglich, dass das Top Management tagesaktuell sieht, was die Teams liefern. Also braucht es ja kein mittleres Management mehr, dessen Aufgabe darin besteht, für Berichte und Informationsweitergabe zu sorgen. Das mittlere Management ist tot. Q.e.d!Der neue mittlere Manager: der ScrumMaster
Das mittlere Management wird in dieser Form einfach nicht gebraucht. Das machen Firmen wie Facebook und Co vor. (1) Dort wird man nicht deshalb Manager, weil das die nächste logische Entwicklung zu mehr Macht und Geld ist, sondern weil es tatsächlich einige Funktionen gibt, die es durch dafür geeignete Menschen zu füllen gilt. Diese sorgen dort für Zusammenarbeit. Das funktioniert aber nur, wenn das mittlere Management seine originäre Aufgabe – für die Zusammenarbeit von Teams zu sorgen – wieder erfüllt. Wie das geht?
Toyota führte vor Jahrzehnten das Prinzip des Genchi Genbutsu ein: „Go and See“ – das Management soll dorthin gehen und dort mit seiner Aufmerksamkeit anwesend sein, wo die Arbeit stattfindet. Das bedeutet in den heute wichtiger werdenden wissensverarbeitenden, kreativen Berufen, dass das Management im selben Raum wie Grafiker, Software-Entwickler, Ingenieure, Wissenschaftler sitzen und arbeiten sollte. Also wirklich dort vor Ort sein. Seien wir großzügig: Zu Beginn sollten es wenigstens 50 Prozent der Zeit sein. Sie müssten schauen, was dort geschieht, verstehen ohne zu stören und herausfinden, wie sie dafür sorgen können, dass ihre Kollegen schneller – d.h. produktiver – arbeiten können. Wäre es das, was das Management täte, dann könnte man sich Reporting, Listen und Charts schenken. Sehr viel Zeit würde dadurch gespart und auf diese Weise könnte wieder produktiv an der Sache gearbeitet werden. Trotzdem gäbe es kein Informationsdefizit, denn die Manager wüssten ja aus erster Hand, was geschieht.
Dem geneigten Leser fällt jetzt sicher auf: Das ist die Stellenbeschreibung eines ScrumMasters. Ja, der ScrumMaster ist ein mittlerer Manager. Er sorgt dafür, dass Teams perfekt zusammenarbeiten, löst Probleme und gewährleistet, dass Scrum-Teams liefern. Aus einem ScrumMaster wird schnell wieder ein mittlerer Manager alten Zuschnitts, wenn man ihm Macht über die Teams gibt. Daher gilt die klare Regel: Der ScrumMaster ist nicht personell für die Kollegen verantwortlich. Er bleibt eine laterale Führungskraft, der für sein Team da ist und den Raum aufspannt, in dem gearbeitet werden kann. Es lebe das mittlere Management.
Organizations that are attempting to transition to Agile demonstrate waterfall characteristics – residually or resurgently. Understanding these characteristics and learning to observe manifestation of these tendencies in organization systems will help you uncover impediments to your organizations Agile metamorphosis.
After reading this series of articles, you may realize that your organization is still being waterfall [...]
The notion of forming complete cross functional teams is one of the most well understood concepts in the agile community but maybe one of the least implemented in practice. Many folks adopting agile either don’t understand the importance of teams, or if they do… they don’t have the power to influence the organization to build them. Often, there just aren’t enough people with the right kinds of skills and experience to get every team everything they need… so they compromise.
What happens when we compromise this foundational principle of agile?
Assuming for a moment we actually have the ability to create a well-formed backlog… and theoretically the ability to produce a working, tested increment of the product at the end of the iteration… an incomplete team won’t be able to establish velocity, won’t able to communicate progress, won’t be able to validate the product as they go or get any meaningful feedback. Furthermore, they’ll create an indeterminate backlog of unfinished work as they go.
This is a huge problem for organizations, especially those in the early stages of adopting agile.
Why? Well think about what we are asking folks to do. We are asking them to buy into a system of delivery that is not based on heavy up-front planning and one that doesn’t make commitments to delivering a specific scope within a specific time and cost constraint. We are asking people to let us change direction when we learn new information without requiring change control. This is scary for most folks, and viewed as fundamentally irresponsible to others.
The tradeoff we are selling is that our stakeholders will have continuous input into the process, total transparency into the evolving product, the ability to unambiguously validate progress, and the opportunity to put product into market early and potentially realize an earlier return on investment. The deal is this… if you trust me to work in an agile way, I can create better economic outcomes for you in return. That is the agile value prop for our customers.
Now… think about all the things we break in this deal when we don’t form complete cross-functional teams. We cannot be stable. We cannot be predictable. We cannot produce a working tested increment of the product at the end of the sprint. We cannot get meaningful feedback on the emerging product. We cannot release early. We cannot fundamentally honor the contract we have entered into with our customers. We are frozen.
One of the most subversive things about incomplete teams is that they stop believing they can plan an iteration and deliver value for their customers. They stop believing that they can make and meet a commitment. They stop believing that they can do what they say they are going to do. They stop taking responsibility and can’t be held accountable. They go through the motions of doing agile but can’t produce any of the business benefits that come from it.
Here is my take…
There are lot’s of ways to be successful. I’ve run great waterfall projects. I’ve run projects with fundamentally no process at all. With the right people and the right focus you can make just about anything work. That said, if you want to make agile work, you have to form teams. If you are not going to form teams, don’t do agile. The worst thing you can do is adopt a process based around teams without creating the very construct that allows the process to work.
1. Teams 102… A quick history of agile and how our beliefs about adoption and transformation might be impacting our ability to form teams
2. Teams 201… a more advanced treatment of what it means to form an agile team, what to do with specialists, and where to put folks that don’t go on agile teams.
3. Teams 301… patterns for forming teams in larger, more complex organizations with legacy platforms, shared services, and shared components
Dolores, meine Editorin, sagt: „Es ist das beste Buch, dass du bisher geschrieben hast, weil es dein persönlichstes ist.“ Und obwohl Eigenlob stinkt: Sie hat recht. “Selbstorganisation braucht Führung. Die einfachen Geheimnisse agilen Managements” enthält im Grunde die Erfahrungen, die ich als Führungskraft eines Consultingunternehmens sowohl mit den eigenen Kollegen als auch bei Kunden und mit Kundenteams, mit den Managern und den Mitarbeitern dort gemacht habe. Mir ist klar, dass es eine Gratwanderung ist, wenn man nicht nur seine Erfolge, sondern auch sein Scheitern beschreibt. Aber ich sage ja auch unseren Kunden nicht, dass es ein Spaziergang wird, wenn sie ein agiles Unternehmen aufbauen wollen.
Abgesehen von meinen eigenen Erfahrungen behandelt das Buch aber vor allem die Frage: Wie kann der Manager von heute Menschen in die Selbstorganisation führen? Mir selbst ist dabei klar geworden: Selbstorganisation ist kein Selbstzweck, sondern sie schafft die Grundlagen für extreme Produktivitätssteigerungen bei allen Arten von Teams. Wichtig war und ist mir, Führung so zu definieren und zu gestalten, dass sie tatsächlich lebbar wird. Ich wollte keine agile Führungstheorie entwerfen, die im Abstrakten bleibt. Was ihr in diesem Buch nachlesen könnt, sind Praktiken, die Dieter Rösner und ich selbst erst auf die manchmal harte Tour in unseren Führungsrollen erlernen mussten und wir geben uns nicht der Illusion hin, dass wir bereits ausgelernt haben. “Einfach” sind die Geheimnisse des agilen Managements aus unserer Sicht deshalb, weil Führung in ihrer besten Form unserer Meinung nach auf keinen illustren Theorien beruht, sondern ganz einfach auf Grundregeln des menschlichen Zusammenlebens. Zuhören, mein Gegenüber wahrnehmen, es als ebenbürtig anzuerkennen und wertzuschätzen, ein simples “gut gemacht” aussprechen – in vielen Situationen braucht es gar nicht viel mehr, um Menschen zu motivieren. Und trotzdem passiert es so oft nicht.
Mein Dank geht an Dieter Rösner, der sein großes Wissen zum Thema Systemische Führung und seine große Erfahrung in das Buch eingebracht hat. Und natürlich danke ich meinem ganzen Team von Boris Gloger Consulting und all den vielen Menschen, ohne die das Buch nicht hätte entstehen können.
Ob es gelungen ist, müsst ihr beantworten – die ersten Stimmen zum Buch waren schon sehr positiv. Ich freue mich auf euer Feedback!
Boris Gloger, Dieter Rösner: Selbstorganisation braucht Führung. Die einfachen Geheimnisse agilen Managements. Hanser 2014.
- T.S. Eliot
Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way it has to be. Perhaps all great new ideas eventually become diluted in a sea of mediocrity.
I think I hear a longing in some to fight such dissolution. To resist the forces of corporate entropy. Rather than try to fit in, they urge us to confront and overturn the system. You know, subvert the dominant paradigm? Confronting this dissonance is the difference between making a living and actually living.
I wonder if that’s the difference between those who “fire” their customers and those who stay and work within the system. Are those consultants who give up and declare, “These clowns aren’t ready for Scrum.” going out with a bang? And what about those who stay? Are they afraid to make the big moves and just content to fit in? Whimper. Or are they more subtle than that? Can you embrace your client and still change them? Perhaps the “bang” approach is quicker, and more decisive. And maybe, just maybe, remaining engaged is very, very hard, but yields results in the end.
I know, I know…why so bleak? Well, I feel this tension a lot in our weird little community. I’ve been on both sides of the engagements where a respected consultant has tossed their hands in the air and walked away from the engagement because “They just don’t get it.” or “They’re not ready yet.” And I’ve been that poor fool, laboring away within the system, living on a meager diet of optimism and the occasional conference, trying to make change happen. I won’t pretend to know which approach is right, or even when to use these strategies, but I think it would be worthwhile to understand this issue better.
Filed under: Agile, Scrum Tagged: Agile, change, change management, consultant, decline, fragile, framework, mediocrity, Scrum, Scrumbut, Waterfall
Ah yes, the Business of Software Conference. We’re pretty spoiled here at Axosoft, our company generously offers every employee the opportunity to attend one all-expense-paid conference per year. This year, 6 of us decided to fly eastbound to the great seaside city of Boston for BoS Conference. If you aren’t bothered by an amateur’s enthusiasm, this lovely little video I put together (with the help of my mobile device) should provide a peek into the experience. Otherwise, keep scrolling to indulge in some highlights.
Let your outcomes drive your dev
We unanimously agreed that the conference kicked off with a bang! Tony Ulwick of Strategyn shared his experience identifying, developing, and acting on the needs of a given market. Whether it was planned or by chance, this customer-need focus became the recurring theme of the conference.
How often have you seen products that were painstakingly designed completely die in the market? Tony cited his time working on IBM’s PC Jr. and how quickly the Wall Street Journal declared the product a flop. He came to understand that if the needs of the market are being over-served or adequately served, there is very little opportunity for your new product to gain traction. It’s a simple premise, yet how do you determine what needs are under-served without gambling on your assumptions? Tony was kind enough to provide some direction: data.
If this graph doesn’t immediately speak to you don’t worry, I’ll break it down. Each data point represents a pre-determined needs statement. Something like “Minimize the time to cook mashed potatoes to eat for Thanksgiving.” Each needs statement is then rated via a survey in terms of importance and satisfaction on a 1 to 5 scale. Once you have this data, you take the average of the results, plot them against each other and voila! You now know what needs are underserved without having to guess.
Stop Saying Nothing
Joanna Wiebe Conversion Copywriter at Copy Hackers, was another one of our favorite speakers. Wiebe’s talk, titled “Writing non-sucky copy for websites, marketing collateral and newsletters” challenged those of us in the audience to stop saying nothing. Wait, really? But we worked so hard on what we wrote for our website! Or… did we?
Wiebe described the tendency for the average organization to write boring, unimaginative website copy that fails to communicate how they meet customers’ needs. She gave the audience an example of copy written on the websites of two rehab centers in Florida (one company I can’t remember because the copy was so boring so I just picked one at random to show below – point proven) compared to the second, more interesting example of copy she wrote for Beachway Therapy Center (also below).
Whoa. That second one. It’s simple yet it effectively communicates what you would be looking for as someone who needs rehab. How did Wiebe conjure this up? Luckily she shared a few helpful suggestions for the novice copy writers out there.
Wiebe wanted to understand how people seeking rehab speak. What words do they use? What phrases do they use? These two questions immediately presented a major challenge: interviewing individuals looking for rehab is neither feasible nor effective. So, she turned to the treasure trove of Amazon reviews available for rehab books. By reading through the reviews, she was able to pick up on the ethos of her audience. These are people in pain and in need of help. With this knowledge she rewrote all the copy for this rehab center in the example above, and it made for quite a striking impression.
Another thing to consider when writing copy for your site or marketing materials, is to think about ways to add notes of flair. Take advantage of your vocabulary and do something pleasantly unexpected. Wiebe’s advice was to always be clear and concise first, then focus on letting your copy speak to your readers.
There were so many other amazing speakers at the conference, and this blog post won’t be enough to cover them. For those of you perusing this blog to learn more about the speakers at BoS, please visit their site to learn all about the goodness they bring to the software industry.
The Agile Manifesto values “Individuals and Interactions” over “Process and Tools.” I suspect it was no accident that this was listed first. Lack of communication, miscommunication, or the mistaken presumption that communication has occurred, are the root cause of many problems. Yet, we still focus much discussion on the process and tools.
- When and how do you conduct a certain Scrum ceremony?
- Are you practicing pure Scrum?
- Which agile tools do you use and why?
- How do you use the tool?
- What agile metrics are you using and how?
- What best practices exist?
- And lots more concerns and questions about how to “do” process…
However, most all change transformations to “be” agile struggle with organizational culture and many organizations and teams continue to fail to reach their full potential because of issues related to “individuals and interactions.”
Teams are the heartbeat of agile development. It’s the people that produce business success. Even when the organizational culture embraces agile values, the teams must also address their individuals and healthy interactions among them to maximize value. This takes time and effort to mature. I find we mistakenly assume that since people know each other already and even “behave” nicely, they think they can skip over the team-building activities.
Simply gathering individuals together and assigning them the label of “team” does not make a team. Each team is comprised of unique personalities and thus there is no cookie-cutter best answer for every team. Each team must find its own way and navigate the uniqueness of each individual to determine the best way to handle interactions that work for their team dynamic. There should be “pacts” that everyone on the team agrees to. If there are dysfunctions (egos, prima donnas, passive aggressive behavior, apathy, poor listening skills, a presumed hierarchy, and so on), then the challenge is an order of magnitude that’s much more difficult. Each team is a unique, dynamic system, subject to changing moods and their environment.
Sadly, some agile teams never evolve beyond a collection of individuals who meet together at the prescribed Scrum ceremonies and then return to work independently with a focus on their individual tasks only. Maybe the ability to track their work has improved, but they have failed to recognize and harness the true potential that comes from working as a high-performing team. Perhaps you have seen teams who are full of energy and so you recognize the power of teams? So, why do some teams never get there? There are multiple factors that influence agile and Scrum teams.
Let’s assume that the organization’s leadership values the power of teams and has a supportive culture and vision in play. So what can be done within the team to ensure that it sets a solid foundation for growth and success?
During the team forming stage, it is important for the team members to openly discuss behaviors and expectations. There is great value in recording those discussions as a reminder to the members when they do encounter problems. But, they need to dive deeply into what each member truly believes and feels. Because what you believe and how you feel directly determines how you will behave. These team discussions must go beyond the process-mechanics agreements such as what time to meet. They need to communicate something more of an “agile team creed” or list of pacts they make with one another. Team members must be comfortable sharing their fears and concerns.
Having an agile team creed is a great starting point for deep team discussions to root out true beliefs. It captures cultural expectations and behaviors for the team which I believe lay the foundation for a great agile team. Here is my list of 15 useful pacts agile teams can make. I call it the Agile Team Creed.
Has your team had these deep conservations about what they believe? Would they agree with these items as part of their Agile Team Creed? If not, why? Perhaps, it reveals a cultural issue that needs attention.
The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.
So what are the four contexts of Swarming? Here they are in no particular order:
- Shifting Gears
Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1″ defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.
Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.
In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.
Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.
In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.
Filed under: Agile, Swarming, Teams Tagged: animals, building, context, emergencies, innovation, Kanban, methods, Scrum, shifting gears, Swarming, Teams
I posted my most recent Pragmatic Manager newsletter, Scale Agile With Small-World Networks on my site.
This is a way you can scale agile out, not up. No hierarchies needed.
Small-world networks take advantage of the fact that people want to help other people in the organization. Unless you have created MBOs (Management By Objectives) that make people not want to help others, people want to see the entire product succeed. That means they want to help others. Small-world networks also take advantage of the best network in your organization—the rumor mill.
If you enjoy reading this newsletter, please do subscribe. I let my readers know about specials that I run for my books and when new books come out first.
The second of our new role-based training classes focuses on replenishing your kanban system. We look at the risk management typically undertaken by product managers. Kanban offers very elegant solutions to the problems of large backlog management and prioritization. For anyone who has to decide what to work on now, what to leave until later and what to discard altogether, this is the class for you. If you want to understand how to select work for your kanban system, how to schedule it, how to sequence it and how to define classes of service to control the flow of work through the system, then this is the class for you. This class includes coverage of so called "upstream Kanban" and Real Option Theory. You'll learn to stop using the term "backlog" except for large projects with defined scope, and how to understand a "pool of ideas" as a set of options to be developed or discarded. You'll learn how to filter options based on risk assessment, how to hedge risk with capacity allocation, and how to schedule and select work, pulling it into the kanban system at the optimal time.
This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Product Management for Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.
Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.
Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.
“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”
While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.
I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.
When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.
Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.
“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”
So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…
Filed under: Agile, Lean, Process, Scrum, Swarming, XP Tagged: Agile, evolution, Extreme Programming, Kanban, meme, no estimates, Process, software development, XP
In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.
What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.
Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.
Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.
There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.
A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:
- The Scrum of Scrums or other program or portfolio meetings
- Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
- Attending other forums, other teams status meetings
- Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.
If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.
Filed under: Agile, Process, Scrum, Swarming, Teams Tagged: communication, information radiators, one way broadcast, Swarming
Using the Understanding of When SAFe Is Heavy Is How to Use It Properly a Organizations Smaller Than It Was Designed For
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]