My daddy left home when I was three
And he didn’t leave much to ma and me
Just this old guitar and an empty bottle of booze.
Now, I don’t blame him cause he run and hid
But the meanest thing that he ever did
Was before he left, he went and named me “Sue.”
-Johnny Cash, A Boy Named Sue
I love this song. It makes me chuckle every time I hear it. Its a story about a man who names his son “Sue” because he knows it will be the source of mockery and make him into a stronger man. It’s a tongue in cheek little rhyme that covers themes of fathers, sons, manhood and what’s in a name.
Today I was looking at a list of team names. Every single team in the list had named themselves after whatever they were working on. For example, there might be names like Printing Team, or UI Team, or Database Team. And check this out: if there was more than one Printing Team, guess what they called the second team? You got it: Printing Team 2.
I shook my head and thought to myself, “Who named you Sue?”
Right off the bat, I have to confess that I’m really a bit mystified by this kind of behavior. I refuse to believe that a normal human being, not coerced by any outside force, would name themselves after whatever they are working on. I’m working on a Mac right now. Maybe I should change my name to Mac too…nope…not gonna do it. It doesn’t make any sense to me (and I’m not really Scottish). I would rather name myself after something fun or aspirational. I’d use things like:
- Mountains (Team Everest, Denali, or K2)
- Animals (Team Angus, Viper, or Gerbil)
- Cartoon Characters (Team Mickey, Goofy, or Donald)
- Tools (Team Hammer, Bandsaw, or Monkey Wrench)
- Rock bands (The Police, Metallica, or Tower of Power)
The possibilities are endless…just like my cliches. Often I think that a team is either intentionally or unintentionally given a name by those who are sponsoring or responsible for setting up the team. After all, early in a project, before everyone shows up, you need a name for this new thing. Often this name is used purely for utilities sake, perhaps with the assumption that the team will replace the name with one of their own. The team adopts it by default, because that’s what everyone else calls them, and they never bother to change it again.
I’m sure there are also places that just tell teams what they want them named. Hello, welcome to Acme! We’re going to put you on team “Sue”. I think that’s ridiculous. Here are my rules for team naming (don’t worry, no one will adopt them):
- You can’t name yourself after what you are working on
- No one individual can name the team. The team must name itself
If you want someone to feel empowered and respected, you really need to let them decide what they are going to be called. If you can’t even do something as trivial as that, then you are probably going to struggle in other areas too.
So what are your rules for naming teams?
Filed under: Agile, Coaching, Teams Tagged: empowered, Johnny Cash, label, naming, Teams
Im Business ist es wie in anderen Bereichen des Lebens auch: Es funktioniert in erster Linie über persönliche Beziehungen. Mag ich jemanden persönlich, nehme ich sogar fachliche Mängel in Kauf.
Glaubt Ihr nicht? Ich wohne in Prenzlauer Berg in Berlin, da gibt es eine Weinbar, die von einem Italiener geführt wird. Niemand nennt den Namen der Bar, wenn er da hingeht, alle gehen zu Johnny. Johnny begrüßt alle herzlich und persönlich, egal wie groß der Stress ist. Für die persönliche Begrüßung nimmt er sich Zeit. Und er macht ganz klar, dass gerade Du ihm besonders wichtig bist. Außerdem ist Johnny großzügig. Es gibt zu jedem Wein immer ein großes Glas Leitungswasser, das ständig nachgefüllt wird, und zu jedem Getränk gibt es einen kleinen Teller Tapas dazu.
Der Laden ist immer voll. Die Leute mögen es gemocht zu werden und nehmen die mittelmäßige Qualität in Kauf. Die Weine sind so la la. Geraucht werden darf auch, was im Winter in dem kleinen Laden zu tränenden Augen führen kann. Im Sommer sitzt man draußen und ab 22:00 Uhr kommt er alle 5 Minuten vorbei und macht “psst” wegen der Nachbarn. Das hindert niemanden daran, zu Johnny zu gehen.
Wenn ich den Menschen Wertschätzung entgegenbringe, ihnen zeige, dass ich sie mag und gern mit ihnen arbeite, ihre Stärken sehe und kommentiere – dann muss ich mit meiner fachlichen Kompetenz schon sehr neben den tatsächlichen Anforderungen liegen, bevor der Kunde sich gegen eine weitere Zusammenarbeit entscheidet. Solange ich noch etwas finde, was mir bei Johnny schmeckt, Bier statt Wein z.B., werde ich weiter hingehen. So lange ihr einen Mehrwert für den Kunden liefert, wird er einen Grund finden, euch zu halten. Wer sich jetzt an das super-leckere Restaurant erinnert, in dem der Kellner so pampig war, der weiß genau, was ich meine.
Jetzt glaubt ihr mir vielleicht und sagt: “Gut, dann bin ich eben nett zu den Leuten.” Aber es gibt da eine Schwierigkeit. Ich kann nicht vortäuschen, dass ich jemanden mag. Und ich werde die Person nicht mögen, ihre Stärken gar nicht sehen, wenn sie Eigenschaften hat, die ich an mir selbst nicht mag. Das heißt, um stabile, wertschätzende persönliche Beziehungen aufzubauen, werde ich an mir selbst arbeiten dürfen. Schatten integrieren, wie es so schön heißt. Mich also mögen lernen, so wie ich jetzt gerade bin. Johnny hat eine intakte und stabile Familie. Er ist emotional satt und genährt und kann dadurch ganz viel Herzlichkeit verschenken.
Wem es zu anstrengend ist, das Herz des Kunden zu gewinnen, der kann natürlich weiterhin durch hohe fachliche Qualität und zeitliches Engagement den Verstand des Kunden überzeugen.
Wo und wie nährt ihr euch fachlich und persönlich?
- S wie Scrum
- Mr. Change, könnten Sie meine Gefühle bitte etwas weniger aufwirbeln?!
- Reading: Johnny Bunko — The Last Career Guide you´ll ever need
I’ll be teaching my next SPC certification in Boulder October 21-24. This is the second US course I’ll be teaching based on SAFe 3.0 and, the first from a recent update to Leading SAFe 8.1. This should be a fun course; at least I’m excited about teaching from the new baseline! It will probably sell out, but there are a few seats left add of today. You can register here.
Hope to see you there.
Making and keeping commitments is often a controversial topic within organizations. In my experience commitment-making is more challenging than it might seem on the surface and a lot of bad feelings and unfulfilled expectations arise because people lack some of the basic tools in the language of commitment. A commitment exists in language. “If you […]
The notification system now supports ignoring cards that are not assigned to you. Head to your settings page (top right when logged in) and click on the Notifications tab. Check the box below to only receive notifications for your cards:
I want to give some perspective on SAFe and the training that I have been attending these last few days. The training itself is not actually over, but we are very near the end. Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics. In other words, we have covered the essence of SAFe.
Ad Hoc, Pragmatic and Transformative
When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.
The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means. A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes. When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations. Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.
The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management. There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom. These pragmatic approaches typically have low risk and good results. SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.
The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so. There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours. These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture. LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.
SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.
Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile
One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto. I want to say clearly and unequivocally that SAFe is most certainly true to Agile. This fact was demonstrated multiple times and in multiple ways throughout the training:
- Explicit statements that SAFe is based on the Agile Manifesto. At one point, Dean Leffingwell emphatically repeated several times that “we live or die by the Agile Manifesto!”
- Clear examples of SAFe implementations making choices based on the values and principles of the Agile Manifesto. It was common to talk about situations where SAFe ScrumXP teams, Agile Release Trains and the people involved made decisions based on “individuals and interactions”.
- Practices and guidelines that implement the values and principles of Agile are pervasive throughout SAFe. The Inspect and Adapt meeting, Program Increments, daily business collaboration with SAFe ScrumXP teams, customer collaboration through various forms of backlogs, reviews and demos, focus on simplicity and technical excellence with Architectural Runway, Test-Driven Development and other Agile engineering practices.
- The instructors (not just Mr. Leffingwell) often mentioned their own philosophy of being flexible with the SAFe “framework” by making appropriate context-specific changes to the details.
- Even participants in the class who have already started using SAFe in their organizations shared stories that clearly indicated a strong emphasis on the values and principles of Agility.
At the same time, SAFe manages to create a relatively simple interface with a traditional management organization. This is critical and what makes it really effective as a pragmatic approach to enterprise agility. For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners). The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level. This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.
Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile. But a different way of looking at the diagram is that it is comfort for management. I really appreciate this. Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort. The project manager for an important project was very nervous that there was no Gantt chart in Agile. At a personal level, she needed the comfort of having a Gantt chart to track the work of the team. The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.” Most Agilists are anti-Gantt. This was a real eye-opener for me. That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.
SAFe isn’t just a framework, it’s actually a scaffolding. When you build an arch, you need a scaffold to keep everything in place until the keystone is in place. In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.
Lean, Agile and Leadership
This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership. SAFe asserts four principles of Agile Leadership:
- Take a systems view
- Embrace the Agile Manifesto
- Implement product development flow
- Unlock the intrinsic motivation of knowledge workers
I like this list. I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.
There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”. There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”. There is also a lot of time spent on value stream thinking including some great discussion exercises.
Organizational Structure in SAFe
SAFe does not define all the structures throughout the whole organization. By design, it is not end-to-end, top-to-bottom. It does define a structure for three levels of activity: the team level, the program level and the portfolio level.
At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP. As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations. One example is in the idea of commitment. Scrum espouses the value of Commitment. In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope). SAFe keeps this concept. However, if you look in the most recent version of the Scrum Guide, this concept is no longer present. One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring. I wish that Scrum would get around to officially requiring these practices. This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers. And, in my not-so-humble opinion, SAFe is providing the right answers. Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.
At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept. The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150). Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks). Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level. Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations. This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features. There are even a number of recommended metrics for evaluating the performance of the program (not the people).
At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small. One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level. At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership). At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost. This comes in many of the details, but may be a bit difficult for middle managers. Fortunately, the Portfolio level includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains. SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.
I’ll admit that overall I didn’t particularly enjoy the training. I love SAFe. As a trainer myself, I’m too critical perhaps. Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship. However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.
There are a also some general comments about the training that I would like to make that are about personal preference.
First, I would prefer more small exercises that are experiential. For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally. The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).
Second, the slides. The slides. The slides. The slides… and more slides!!! Too much by far. And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly. This is anxiety-inducing and boredom-inducing for me. Some people like lots of slides, but most people don’t.
Third, not enough breaks for a 9 to 6 training session. Usually just one break in the morning and one in the afternoon as well as a short lunch. Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level. At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.
I’m happy I invested in this for both myself and for Travis. We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients. At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.
I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
You probably already know that emotional intelligence, or “EQ”, is a key to success in work and life.
Emotional intelligence is the ability to identify, assess, and control the emotions of yourself, others, and groups.
It’s the key to helping you respond vs. react. When we react, it’s our lizard brain in action. When we respond, we are aware of our emotions, but they are input, and they don’t rule our actions. Instead, emotions inform our actions.
Emotional intelligence is how you avoid letting other people push your buttons. And, at the same time, you can push your own buttons, because of your self-awareness.
Emotional intelligence takes empathy. Empathy, simply put, is the ability to understand and share the feelings of others.
When somebody is intelligent, and has a high IQ, you would think that they would be successful.
But, if there is a lack of EQ (emotional intelligence), then their relationships suffer.
As a result, their effectiveness, their influence, and their impact are marginalized.
That’s what makes emotional intelligence such an important and powerful leadership skill.
And, it’s emotional intelligence that often sets leaders apart.
Truly exceptional leaders, not only demonstrate emotional intelligence, but within emotional intelligence, they stand out.
Outstanding leaders shine in the following 7 emotional intelligence competencies: Self-reliance, Assertiveness, Optimism, Self-Actualization, Self-Confidence, Relationship Skills, and Empathy.
I’ve summarized 10 Big Ideas from Emotional Capitalists: The Ultimate Guide to Developing Emotional Intelligence for Leaders. It’s an insightful book by Martyn Newman, and it’s one of the best books I’ve read on the art and science of emotional intelligence. What sets this book apart is that Newman focused on turning emotional intelligence into a skill you can practice, with measurable results (he has a scoring system.)
If there’s one take away, it’s really this. The leaders that get the best results know how to get employees and customers emotionally invested in the business.
Without emotional investment, people don’t bring out their best and you end up with a brand that’s blah.You Might Also Like
I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.
Yes, have a real, honest-to-goodness release once a month.
I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”
Okay, release every three weeks. I’m easy.
Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.
Large programs magnify this problem.
If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.
Here’s what you do:
- Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
- If you have three-week iterations, plan to release every three weeks.
- Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
- The teams integrate all the time. No staged integration.
Remember this picture, the potential for release frequency?
That’s the release frequency outside your building.
I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.
In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation: “Your stuff is too big. Make it smaller.”
Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.
When you make everything smaller (remember Short is Beautiful?), you can go bigger.
As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.
- All start up founders are really enthusiastic and dream of becoming rich –> Nothing wrong with it
- All start up founders have a strong idea in mind ---> Nothing wrong with it
- Most start up founders believe that their idea would take over the world, even though they have never tested beyond one user ---> Something wrong with it
Recently read a story about startup failure “Patient Communicator”. The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.
As the founder shares his experience, PC began as a product for my father’s medical practice. Plain and simple, I never assessed the market need for a patient portal. It’s extraordinarily difficult to take a product that was built perfectly for a particular user and commercialize that into a broader market.
If you are in start up journey, think beyond one particular user !
Is there a rule you’d like to turn on in SonarQube, but you just can’t find it? Well, wish no more, just tweet your missing rule and if its valuable, we’ll implement it.
With coverage of more than 15 languages, developing our own source code analyzers to deliver the most valuable coding rules and bug detection mechanisms is a key mission at SonarSource. In the past, we’ve mainly worked to offer better covererage of rules offered by other rule engines like JSLint, PMD, Toad, CodeSniffer, PHPPMD, CPPCheck, and so on. But the time has come to fly, and now we’d like to know what rules you’re dreaming about.How to participate
To participate, just tweet the title of your rule and a link to a short description using the tags #1rule1tshirt. If we like it:
- We’ll add this rule to our Rule Repository, the well from which all new SonarSource rules are drawn.
- We’ll send you a SonarSource t-shirt.
- And obviously we’ll do our best to implement this rule and make it available quickly.
That’s it !
- You can use whatever’s convenient to host the rule description, such as a Google doc to provide a short description of the rule.
- The goal of the rule can be either to reinforce a coding practice or to detect some bugs.
Whether or not a rule is valuable is subjective. Like any benevolent dictator, ours will be the final word. :)
Here are the slides for my talk “What is Scrum?” at KTH (Royal Institute of Technology). It was a guest talk at a course called Projektstyrning. Hoping to inspire young entrepreneurs to plant agile DNA in their companies from the very beginning. Last time I spoke at KTH was 6.5 years ago, that’s when I met the first Spotify team, and I’m really happy to have been able to influence and participate in their journey!
Here are some sample slides from the talk:
“The most critical aspect of the work, both artists said, was not the objects themselves, but the space between objects.”
-Daniel J. Levitin, This is Your Brain on Music
As I was reading Levitin’s book this evening I came across the quote above and had to pause. Levitin does an excellent job of explaining musical concepts like pitch, timbre, tempo and harmony in an easily accessible way. He was making the point that the art in music can be just as easily found in the absence of things as in the presence of the aforementioned properties. The moment between each note being just as much a part of the music as the actual notes themselves.
It made me wonder where “the space between objects” could be found in our teams and our processes. I think there are a few different ways you could interpret that sort of space in terms of how we work with teams. With any methodology that you practice, there are well established notes that you play. There is a cadence or rhythm to the standup meetings. You find a tone or pitch of the conversation. And sometimes, if you get really lucky, you just might find harmony.
So what would we find in that space between the notes? If I’m assessing a value stream, then you could describe the work steps as the notes and the delay between steps as the waste or absence of value adding work – the empty space, if you will. Can a value stream have a rhythm and a meter? In other words, although you can reduce waste, perhaps even eliminate some of it, you never get rid of all of the waste. The speed with which work flows through the process increases, and you have a faster tempo.
Another way of considering the space between notes would be to observe that all of our work gets done at a different pace depending on what we are trying to accomplish. There are times when the pace is slow, when we are learning and struggling with new ideas. And there are times when the pace is fast, and life goes all “Heavy Metal” on us. What varies is the slack that you give yourself when you work. I find that when I want to come up with ideas, I need a fair amount of slack, or unscheduled time. I need to doodle and noodle and put spit wads on the ceiling. I need space to think or perhaps more importantly, to NOT think. On the other hand, when the work is coming fast and furious, I know that I’m very likely going to have a hard time creating anything new, let alone remembering what I had for lunch.
The real work lies in the space between our ceremonies. What sort of tune are you playing?
Filed under: Agile, Process Tagged: Agile, music, notes, rhythm, space, Teams, work
Mit Neugier und Aufregung hat die easy+ Mannschaft von EWE am 8. Oktober 2012, also genau vor 2 Jahren, ihr erstes Scrum Intro Training erlebt. Inzwischen sind bis zu 12 Scrum Teams für die Weiterentwicklung des Abrechnungs- und Kundenmanagement-Systems zuständig. Wir sind stolz, dass wir diese großartige Mannschaft in den letzten zwei Jahren begleiten durften! Alle haben mutige Schritte zur Agilität gemacht, mit den unvermeidlichen Höhen und Tiefen – vor allem aber hat es auch viel Spaß gemacht. In unserer Case Study könnt ihr nachlesen, welchen Weg wir gegangen sind. Inzwischen sind im Konzern andere Initiativen entstanden, die von Lean und agilen Prinzipien inspiriert sind. Um den Austausch zwischen diesen Initiativen zu fördern, haben wir vor Kurzem sogar eine Community of Practice gegründet.
Ich habe ein paar Kollegen bei EWE gefragt, was sie für sich und das Team mitnehmen, wenn sie auf die letzten zwei Jahre zurückblicken:
“Rückblickend finde ich es spannend, dass ich von einem Skeptiker (“Wie soll das denn für eine Organisation unserer Größe funktionieren?”) zu einem Verfechter des agilen Mindsets geworden bin und mir nun gar nicht mehr vorstellen könnte, so zu arbeiten wie früher.” Nils Mathiesen, ScrumMaster of ScrumMaster, EWE swb ISIS GmbH
“Ich habe nicht geglaubt, dass wir in nur zwei Jahren so viel erreichen könnten. Und auf dem Weg ist uns klar geworden, dass wir noch viel mehr auf immer höheren Ebenen bewegen können. Ich bin sehr zuversichtlich, dass wir noch einen langen und lohnenswerten Weg vor uns haben. Vor Kurzem war ein Kollege aus einem anderen Bereich bei uns. Er war gerade ziemlich im Stress bzw. unsicher in einem neuem Projekt, bei dem gerade niemand die Anforderungen kennt. Er wusste einfach nicht, mit welchem Vorgehen er dieses Projekt angehen könnte. Ein Kollege und ich arbeiten jetzt schon seit 2 Jahren mit Scrum und haben oft die Rolle des PO übernommen, daher waren wir von dieser Situation wenig überrascht. Sofort hatten wir eine Vorstellung davon, wie wir damit umgehen würden: ein Discovery Workshop mit Kunden, ein erstes Backlog Grooming, etc.” Markus Theilen, Domain Architekt easy+, EWE swb ISIS GmbH
“Im richtigen Moment gab es immer den richtigen Gloger, um uns zu unterstützen.” Nils Nussbaumer, Domain Product Owner, EWE isis swb GmbH
Danke, dass wir diese Entwicklung begleiten durften und dürfen!
Gemeinsam mit Markus Theilen berichten wir auf der OOP 2015 am 27. Januar 2015 in München über unsere Erfahrungen (Track Di 6.2). Hier geht es zum Abstract.
- Mehr wissen! Moderationstraining
- Coaching Ausbildung – Contrain – Mantz/Rösner
- Ich bin aus jenem Holze
"I've been working in this company for a long time, we've tried everything. We've tried involving the teams, we've tried training senior management, but nothing sticks! We say we want to be agile, but..."
Many people in organizations that try to adopt agile will have said this at some point. Not every company fails to adopt agile, but many do.
Why does this happen, what prevents us from successfully adopting agile practices?Learning from our mistakes
Actually, this section should be called learning from our experiments. Why? Because every change in an organization is an experiment. It may work, it may not work - but for sure it will help you learn more about the organization you work for.
I learned this approach from reading Jason Little's Lean Change Management. Probably the most important book about Agile adoption to be published this year. I liked his approach to how change can be implemented in an organization.
He describes a framework for change that is cyclical (just like agile methods):
- Generate or gain insights: in this step we - who are involved in the change - do small experiments (like for example asking questions) to generate insights into how the organization works, and what possible things we could use to help people embrace the next steps of change.
- Define options: in this step we list what are the options we have. What experiments could we run that would help us towards our Vision for the change.
- Select and run experiments: each option will, after being selected, be transformed into an experiment. Each experiment will have a step of actions, people to involve, expected outcomes, etc.
- Review, learn and...: After the experiments are concluded (and sometimes right after starting those experiments) we gain even more insights that we can feed right back into what Jason call the Lean Change Management Cycle.
The overall cycle for Lean Change Management is then complemented in the book with concrete practices that Jason used and explains how to use in the book. Jason uses the story of The Commission to describe how to apply the different practices he used. For example, in Chapter 8 he goes into details of how he used the Change Canvas to create alignment in a major change for a large (and slow moving) organization.
Jason also reviews several change frameworks (Kotter's 8 steps, McKinsey's 7S, OCAI, ADKAR, etc.) and how he took the best out of each framework to help him walk through the Lean Change Management cycle.The most important book about Agile adoption right now
After having worked on this book for almost a year together with Jason, I can say that I am very proud to be part of what I think is a critical knowledge area for any Agile Coach out there. Jason's book describes a very practical approach to changing any organization - which is what Agile adoption is all about.
For this reason I'd say that any Agile Coach out there should read the book and learn the practices and methods that Jason describes. The practices and ideas he describes will be key tools for anyone wanting to change their organization and adopt Agile in the process.
Complications, contention, and complexities will often emerge when attempting to integrate a non-Agile vendor implementation within an Agile organization or team. From my experience, many vendors already have a phased project plan template established for their portion of the work and this can seem somewhat. What is an Agile team to do if they are dependent on a vendor for a piece of an overall solution?
While this can be a challenging scenario, here are the elements I look at when establishing a framework for “blending” agility between seemingly dissimilar frameworks and mindsets:
Shared Language. Establish a common and shared language. Are we going to have a period of requirements gathering or product discovery? Are we going to use function points or story points to size and scope? Remove any ambiguity between the two groups. Infuse as much “agility” into the language as possible. Developing a language map will anchor and guide our future conversations and frame the context of our working relationship. While a coach may need to initially help with this, developing a language map works best when co-created by those performing the work. Ideally, this language is worked into the contract but this often happens after the contract has been signed.
Note: Without establishing this shared context, everything else becomes challenging.
Roles. Ensure roles are clear and concise across all team members. Is there a Scrum Master locally but a Project Manager coming from the vendor? Will testing be performed by local testers or by the vendor? Does everyone understand their role and how each role should interact with each other? Here is an exercise to develop role clarity if you need one.
Developing empathy between roles and understanding the expectations of each role is important here. For example, the Project Manager from the vendor is most likely being requested for specific information and status from vendor leadership. What can we do to help them get what they need while still aligning to Agile values and principles?
Work Products. Each role, spanning both groups, should know what they are responsible to create or build. Will we have a project plan, product roadmap, or a release plan (or all three…or none of the three)? How will requirements be captured? Will we be writing user stories or work items? Will we have one shared product backlog or will there be a separate one for the vendor? Much of this can be resolved by aligning around the common language established together.
Ceremonies. Determine how and when we will communicate and synchronize with each other. Will we have daily stand-ups or weekly check-ins? When and how will we demonstrate working software? This is often when it gets tricky as the vendor may pull out their phased project plan and expect the Agile team to wait until they complete a phase before seeing any progress. Again, fall back to the common language and find opportunities to see progress frequently and iteratively.
Activities. Determine the activities each role will need to do to support the creation of the work products and facilitate the ceremonies. Who will be facilitating the ceremonies? Who will be responsible for grooming the backlog, how will we size the work, etc.? When will we plan, build, and test together? Be explicit but modify and improve as you go.
Information Radiation. Establish the means to communicate our progress and be accountable to each other. Vendor teams are often remote so this obviously means setting up some kind tool for shared visibility and interaction.
Escalation. Establish the approach to escalate impediments across all groups involved. Who needs to know what and when? What is the protocol when the team can’t solve something or doesn’t have what they need?
Have you worked with a vendor to create a blended agile environment? What worked for you? What didn’t? Would love you hear your thoughts.Becoming a Catalyst - Scrum Master Edition