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. :)
“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
Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe. (Thanks to Gerry Kirk for bringing this article to my attention!)
As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK. I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights. I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption. I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.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!
High functioning agile teams are able to complete stories in an iteration. Newer teams struggle, with stories spilling over from iteration to iteration. Why does this matter? Well, focusing on things being done is an effective approach to risk management. When something is 100% done, you’ve eliminated some risk associated with the development of your […]
The post Why does Agile Obsess about Product Features being 100% Done? appeared first on BigVisible Solutions.
The most important thing a Product Owner needs to do is say NO. If they don’t it results in a huge backlog with lots of items, and usually pressure to deliver more than is realistically achievable.
Many people fail to realise that Scrum is not about building the same stuff faster. The Chaos report tells us that 60% of features are never or rarely used. The point of Scrum is to identify this 60% early and to not build them in the first place. If you do this, you have doubled your productivity by doing nothing except saying no.
I drew the following PO decision tree to help new PO’s understand how often they need to say no.
Cycle time (the amount of time customers wait for a requested item) is related to the length of the queue. Think about grocery shopping or the bank. The longer the queue, the longer you have to wait right?
What happens for you when you wait in a long queue? Do you enjoy it? I usually start tweeting about how poor the service is
At this point I’m hoping you agree – a short queue is a good idea.
Now consider your current queue. Either your backlog, or your ticketing system, or your bug tracker – whatever holds the list of all the work your team needs to do.
- What is the current size of that queue (open or in progress items)?
- What is the input rate. i.e. how many new items are created each month?
- What is the output rate i.e. how many items are closed each month?
- What will your queue look like in 6 months time
Imagine your ticket system currently has 1000 items open. 100 tickets are opened per month and 50 are closed each month.
In six months time your queue will be 1000 + (100 – 50)*6 = 1300
That means customers will be waiting even longer. On average they will wait 26 months for their ticket to be solved! (queue size / output rate) Chances are they won’t be a customer anymore after that amount of time.
What if you only wanted customers to wait max 1 month?
In this example, you would need a max queue size of 50 (monthly output rate).
If you wanted your queue size to be 50 in six months time, what would you need to do? For the sake of this example you can’t just throw more people at it. (And usually that is not an answer).
You would need to say no to some requests.
How many would you have to say no to?
Currently you have 1000 requests. You will get another 600 in the next 6 months, so in total you have 1600 requests.
Your team can do 300 requests in 6 months, and you will allow 50 to be in the queue. So you can accept 350 requests.
You need to say NO to 1250 out of 1600 requests, or 78% !!!
You might think this is unrealistic, but what is unrealistic is believing that you can service 1600 requests. Don’t fool yourself or lie to your clients. Start saying no, so that you can say Yes to the 20% of the work that is essential to your customers and products.
In a thread about estimation in hours and whether it’s a good idea (IMO it’s not the best idea by far), this morning Robin Dymond tossed me this challenge:
You have advocated for years that teams should be able to slice stories to the point where they can complete a story in a day. My request is that you show the Agile community how to do that in writing and some exercises that use non trivial examples. I would appreciate learning more about how you do this.
Here, off the cuff, is one reply:Single Acceptance Test
The most elegant way to do this that I know of is to consider acceptance tests for the feature. Then do them one at a time, simplest first. I first became aware of this idea from Neil Killick (one of the #NoEstimates guys), though I’d like to think I’d done it automatically a million times.
But there is another fun way.One Dumb Idea
I’m often challenged to come up with something that could be done, even in a week, and that would look like the product. It’s rare that I can’t come up with something. But what happens next is what’s interesting. An example, from memory, cleaned up a bit to make the story clear at small expense to the facts:
Chet and I were visiting a cable TV company. Their challenge was about something they had already done, the old way: “What if our product was pay-per-view movies? The viewer has to be able to select any movie from a menu of them, watch the movie, pause it, wind it back, …” They went on and on. Then they said, “There’s no slice of that that could be done in a week.”
We talked a bit. I asked, “At the beginning of this project, did you have the ability to play a movie over a channel?” They said that they did, because (of course) they had movie channels playing all the time.
So I said, “What if the first slice is that you’re playing some movie on some secret channel, all the time, and if the viewer wants to watch it, he clicks that channel. That would nearly be done already.”
Some of them hated that example. Some liked it. There were lots of objections to how one could imagine that as “done”. The objections were all about additional features of pay-per-view: “He doesn’t get to see the movie from the beginning.” “What if he wants a different movie?” “What if we don’t know his credit card?”
Chet and I probably said a few times “Well, rewinding the movie is a new story,” or “Not switching to the secret channel without his credit card is a new story.” I remember that at one point we said “What if we started just using your boss’s credit card for everyone?”
Pretty soon — in minutes, not hours or days — some engineer in the room said “Well, that wouldn’t work, but what we could do is …” and described something they could have done.
That’s what always happens. Someone comes up with a stupid example of a story that could be done in a day or a week, whatever the then-current target is. That someone is usually me, because I am full of stupid ideas and I don’t mind putting them out there.
Suddenly things change. We’ve gone, in one step, from “impossible” to knowing a stupid, but possible, thing to do. The tone of the meeting changes, instantly, from “no way to do that” to improving the idea or bettering it.
Chet and I have done this, time and again, separately or together, in domains of all kinds. One dumb idea that could almost work is enough to switch the team from “can’t be done” to “yeah, but this would be a better way.”The Real World
Referring to Alistair Cockburn’s “Elephant Carpaccio” exercise, Robin said:
I am familiar with Alistair’s elephant carpaccio, however his exercise uses a calculator, and developers just don’t think the example is applicable to their problems.They always think that
A million examples, not in their domain, and they’ll still think that.
Yes, but in the real world, we have to deliver every movie ever recorded, to anyone’s house, in real time, together with all the reviews from the major outlets, with or without surround sound, wide or narrow screen, 3D or flat, with subtitles in every known language including FORTRAN, color-enhanced to support red-green color blindness, using every major credit card plus any authorized Canadian grocery store coupons, with the naughty bits either covered or enhanced, with pause and zoom in available, in fast motion and slow motion as well as regular everyday motion, using no wires or cables of any kind, without emitting any electromagnetic radiation on any spectrum, delivering to any television, computer, tablet, phone, watch, or pinkie ring, at any location in the solar system, with zero delay. You can’t do that in the real world.
Yeah, well, we just did. I doubt it took an hour.Nonetheless
All you need is a stupid idea, or one acceptance test. I’d typically start trying to get one story that a PO could imagine was nearly “end to end”, that can be done in a week. A day probably isn’t something the team can do right out of the box.
Or is it? In our CSD class, we do a real application and we run 90 minute Sprints. The teams deliver multiple stories in those Sprints. Not the first Sprint, mind you. :)Yabbut …
Robin, of course, seemed to be asking for a more comprehensive compendium of ways to slice stories. I think he just wanted me to go away for a while. It might be fun to generate a whole list of examples. They would all have the same characteristics, though. It seems like you have to sit with the team and talk with them, or at least get them to talk among themselves.
My way requires someone to have a dumb idea, which isn’t that hard, but it also requires them to say it, which is harder. And — I’m just guessing here — they have to be respected enough, or enough of a stranger, to get the idea discussed instead of dismissed out of hand.
Neil’s way, doing a single acceptance test, might be better. I’ll know when I’ve tried it a few times. My way is more fun, though. I’m sure of that.
By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:Swarming
There you have it. A complete method for swarming. Wrap it up and ship it.
“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?
First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS! We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.
Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.
So feel free to take this methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.
Filed under: Agile, Swarming Tagged: creation, Manifesto, methodology, practice, Swarming, theft
Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.
Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!
Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.
In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.
Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:
- Sind die neuen Features sinnvoll – sind es also die richtigen Features?
- Können die Teams diese Features überhaupt umsetzten?
In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.
Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle
Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.
In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.
Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?
Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.
Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.
- 5 min on Scrum | Business Value
- Dr. Scrum – antwortet
- Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
The 'Why' part is perhaps the most important aspect of a user story. This links to the sprint goal which links ultimately to the product vision and organisation's vision.
Lately, I got reminded of the very truth of this statement. My youngest son is part of a soccer team and they have training every week. Part of the training are exercises that use a so-called speedladder.
After the training while driving home I asked him what he especially liked about the training and what he wants to do differently next time. This time he answered that he didn't like the training at all. So I asked him what part he disliked: "The speedladder. It is such a stupid thing to do.". Although I realised it to be a poor mans answer I told him that some parts are not that nice and he needs to accept that: practising is not always fun. I wasn't happy with the answer but couldn't think of a better one.
Some time passed when I overheard the trainers explaining to each other that the speedladder is for improving the 'footwork', coordination, and sensory development. Then I got an idea!
I knew that his ambition is to become as good as Messi so when at home I explained this to my son and that it helps him to improve feints and unparalleled actions. I noticed his twinkling eyes and he enthusiastically replied: "Dad, can we buy a speedladder so I can practise at home?". Of course I did buy one! Since then the 'speedladder' is the most favourable part of the soccer training!
The goal, purpose and the 'Why' is the most important thing for persons and teams. Communicating this clearly to the team is one of the most important things a product owner and organisation need to do in order to get high performant teams.