Das Team von Boris Gloger Consulting besteht nicht nur aus Beraterinnen und Beratern. Unser „Backbone“ ist im wahrsten Sinne des Wortes das Rückgrat, das dem Unternehmen seine Stabilität gibt: Die Kolleginnen kümmern sich um die Finanzen, ums Marketing und um den Kontakt mit BewerberInnen und Freelancern. Seit August unterstützt Diana Eiswirt das Team. Sie absolviert bei uns ihre Ausbildung zur Kauffrau für Büromanagement – unser allererster Azubi, darauf sind wir sehr stolz! Diana hat sich bereit erklärt, das Arbeitsleben für einen Blogartikel aus ihrer Sicht als junge Einsteigerin in die Arbeitswelt zu betrachten. Danke Diana!
Man sollte nicht auf Mitmenschen hören, die sagen: „Du wirst die Schulzeit noch vermissen.“ Es ist zwar gut möglich, dass dies passiert, wenn man z.B.eine tolle Schulzeit mit vielen Freunden und Ausflügen hinter sich hat, aber einen großen Unterscheid zwischen Schule und Arbeit sehe ich bislang noch nicht. Seit ich am 01.08.2014 bei Boris Gloger Consulting meine Ausbildung begonnen habe, weiß ich, dass Arbeiten auch Spaß machen kann.
In der Schule lernt man, aber in der Arbeit gibt es auch noch genügend zu lernen.
In der Schule hast du deine Freunde, aber du kannst deine Kollegen auch zu deinen Freunden machen.
Man muss für die Schule morgens früh raus, das muss man bei der Arbeit auch.
Wo liegt also der große Unterschied? Ich finde, so viel anders ist es gar nicht. In der Schule geben die Lehrer die Anweisungen und Aufgaben, in der Arbeit wird der Lehrer durch einen Chef ersetzt – es funktioniert also nach dem selben Prinzip. Ob du letztendlich die Schulzeit vermisst, liegt in deiner Hand und daran, was du aus der Arbeitswelt machst. Es ist ein neuer und wichtiger Lebensabschnitt, um den keiner drumherum kommt, früher oder später muss da jeder durch. Doch dieser Abschnitt lässt uns nochmals mehr erwachsen werden und anders denken.
Als Auszubildende habe ich mittlerweile schon meine festen Aufgaben, die ich zu erledigen habe, und trotzdem lerne ich so gut wie jeden Tag etwas Neues – das bringt Abwechslung in mein Berufsleben. Abwechslung ist für mich gut, da es das Arbeiten nicht langweilig werden lässt.
Momentan gehören zu meinen Aufgaben:
- Reisekosten bearbeiten
- die Kontakte in unserem CRM-Programm verwalten
- Trainees für Trainings anmelden und Bestätigungen versenden
- Zertifizierungen bearbeiten
- Vorlagen erneuern bzw. in unser neues Corporate Design bringen
Bis jetzt ist es zwar noch nichts Großes, das ich eigenständig machen kann, aber trotzdem macht es mir Spaß! Es macht Spaß, auch wenn es nicht immer ganz einfach war: Immerhin musste ich erst einmal mit den Programmen zurechtkommen. Doch das wird von Tag zu Tag besser und ich werde immer sicherer.
Ich freue mich jeden Tag aufs Neue, zur Arbeit zu kommen, um Neues zu lernen. Ich hoffe, es bleibt mein ganzes Berufsleben so – dass meine Arbeit mir Freude bereitet und ich jeden Tag gerne dorthin gehe.
Sicherlich wird es den einen oder anderen Tag geben, der nicht so läuft, wie ich es mir gewünscht habe, und dennoch wird mich das nicht abschrecken. Arbeiten muss nicht so schlimm sein, wie viele es sagen. Arbeit ist das, was man daraus macht!
Man sollte sich immer fragen:
- Mache ich meine Arbeit gerne?
- Ist es das, was ich bis zu meiner Rente gerne jeden Tag aufs Neue machen will?
Warum sollte Arbeit eigentlich Spaß machen? Aus dem einfachen Grund heraus, weil wir einen großen Teil unseres Lebens damit verbringen! Es ist es für den Mitarbeiter selbst, aber auch für den Chef nur von Vorteil, wenn jeder Angestellte gerne jeden Morgen zur Arbeit kommt. Das bedeutet nämlich, dass wir keine schlechte Laune haben und viel motivierter sind. Geht es uns gut, sind wir fröhlicher, aufgeschlossener und bereitwilliger für Neues und tun damit auch etwas Gutes für unsere Gesundheit. Die falsche Arbeit kann nämlich auch krank machen. Warum also nicht die Chance nutzen und Berufliches sowie Privates auf diese Art und Weise zu vereinen? Was gibt es Schöneres als glückliche, zufriedene Menschen, die nicht in jeden ihrer Tage lustlos hineinleben und schauen, was heute wohl so alles auf sie zukommen mag, sondern den Tag in die Hand nehmen und nicht den Zufall über ihr Leben regieren lassen!
Unser Leben heißt es. Also sollten wir auch etwas dafür tun, damit unser Leben läuft, wie es uns gefällt. Denn wenn wir es nicht selbst in den Händen halten, wer dann?
- Bin ich am Arbeitsplatz zufrieden?
- Eine Erleuchtung: Scrum als Coaching-Tool!
- Komfort-, Stress- und Panikzone im Change Prozess
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
Good move @scrumalliance #unity #agile
I see us frustrated when we aren’t given the time to do the right thing. Hierarchy leaves us vulnerable to pressure. Encouraged to take short-cuts, we’re nervous and tense.
Those unwilling to cave to the pressure learn their craft. Creating code that’s solid, elegant, creative, not reactive. Fulfilling for the craftsman, but the result is hollow, when the care put in is misunderstood as waste.
Economics can quantify the value of quality and expose the cost of waste of endless rework that rushed code brings. Yet without a shared understanding the pressure to take shortcuts remains.
When we can’t communicate the value of what we do, we hide the truth, for fear of how it may be interpreted. The tension between us kills openness, honesty and collaboration, replacing them with frustration.
Separation builds a class system between business and technical people. Unappreciated, we lose. Can this gap closed, the technical glass ceiling smashed?
Could we speak the same language? The language of economics, of value and cost, leading to profit and loss, and options.
I hear developers talking of Right and Wrong. What would happen if we got better at describing Cost and Value?
Guest post by Bob Schatz of Agile Infusion, LLC
The interest in expanding agile development practices is growing at an increasingly faster rate. The good news is that this indicates that companies are seeing positive results in their initial experiences on projects and are looking to further the expansion, even beyond product development. The challenge is recognizing that these early successes required overcoming many obstacles and shifting the mindset of a number of people. And that these things get exponentially harder as you introduce change across the enterprise.
The pressure is also put on consultants, trainers, authors, speakers, agile software tool vendors, and coaches to codify and simplify models to reduce the strain from employing agility at scale or “super-sized agile). When success happens, everyone wants to share the experience, but they often focus on showing the model that worked for them in a specific case. Since the structures are simple by design, this creates a feeling that it must be relatively painless to just replicate the experience in other parts of the company, and then to other companies.
This is similar to what we’ve seen in the past with the basic Scrum process, Lean/Six Sigma, the Toyota Production System and just about any process improvement strategy that has a significant success story to tell. As a result, there has been a flood in the community of scaled agile methods that are all too similar to be called different. Arguments ensue on a daily basis; thought leaders pit their methods against the others trying to prove why they have the right answer. A slew of marketing professionals try to position each method as the better answer in hope of attracting a “big fish” company that will tout how successful the method made them. Right now, we have no less than six scaled agile methods actively being marketed, not to mention the hybrids that companies are presenting in conferences, articles and such. And the methods just keep coming! Ultimately, success will require:
- Identifying the problem you are trying to solve
- Understanding your current organization and its ability to satisfy consumers
- Identifying the gaps
- Designing an organization and process
- Growing your leaders at all levels
- Execution and relentless continuous improvement
In order to bring us back to the ground, I would like to tell a couple of my own stories which might help you and your organization focus on keeping things simple and overcoming the struggles that all organizations will eventually face in order to instill a culture of continuous improvement and process innovation. These will be critical to serving your customers better than anyone else can.
Back to the Future
My first story is from what seems not too long ago, but I guess that’s what all of us “old-timers” say. I came into the software profession as a programmer in 1984. I was hired by GE in Valley Forge, PA in the start of my senior year of college when defense contractors were building up at an incredible pace. I was really looking forward to seeing how the little projects we were doing at school would apply to working on a massive Department of Defense project. And just to be honest, a lot of my school projects involved punch cards. So, the first scaling problem I had was keeping a huge deck of cards in the right order!
The first project I was assigned to at GE was a massive system involving hardware, space vehicles, communications, ground stations, and a host of other components and challenges that made my head spin. The system involved thousands of people across multiple contractors and government agencies all working together to solve a huge problem. It was even more complicated by the fact that this was a classified system where we had to deal with compartmentalization and people with different need-to-know levels that restricted with whom you could collaborate. The project management was mostly visual techniques and we relied heavily on interface control documents, which let us know the inputs and outputs for our piece of the puzzle. (In reality, those documents were not entirely accurate, coordinated, or followed, which caused more than a few defects later in the project).
We all relied heavily on each other to communicate from one component or process to the next. System integrators tried to keep an eye on all of the parts to ensure a smooth system-wide deployment. These projects went on for years. We employed what we now know as the waterfall development model, but at the time we just referred to it as MIL-STD version 2167. Now, I’m not claiming that these were smooth projects. They were terrible and required massive amounts of overtime (which luckily we were paid for), rework, and heroics of some of us to pull it off. These were much different times, but looking back, we did what always worked, and used common sense and a will not to fail. We were motivated to serve our nation’s best interests and we were young, enjoying cashing in those big overtime checks. Organizing ourselves was less of an issue, knowing that we had to solve important problems and everyone was focused on success.
For my 12 years there, the projects got bigger and more complex. We kept using the same organization techniques because they worked for us in those circumstances. Every project required a level of heroics at the end, which nobody would tolerate today. These were different times. Today’s software development environment requires faster speed, much higher quality, and the ability to adapt to a much higher rate of change. My point here is that we didn’t need a model to tell us what to do and, to my knowledge, there was never a Scaled Waterfall Model.
A Burning Platform
Fast-forward through a number of great experiences, including a very successful start-up where I really learned the value of agility in its purest sense before “agile development” was a term. At the end of 2001, I wound up as the vice president of development at Primavera Systems. Now part of Oracle, Primavera makes enterprise portfolio, program, and project management software. This was where we used Scrum staring in early 2003 in an organization with almost 150 people — that became one of the first, and certainly well-publicized agile success stories.
We started off with the goal to improve our lives, our products, and our relationships with other groups in the company. We had serious issues with our product and process. More importantly, our people were suffering. Nothing I tried in all of my leadership experience to date had worked to my satisfaction in my first year there, so it was time to radically re-tool. Scrum was just a leap-of-faith decision to attempt to save us.
Our challenges began with figuring out how to create Scrum teams. We wound up with about 20 of them all working on a single, large enterprise product. We ran into a lot of issues with builds and people stepping on each other, so we innovated. We set our focus on stopping the branch/merge environment and forced ourselves into a single trunk, so everyone was now responsible. We had discussions about how to coordinate dependencies, coordinate development of feature sets involving multiple teams, and how to deal with obstacles that affect many teams. As with everything we didn’t have an answer for, we designed experiments and tried them. This led us to create the idea of having a representative from each team form another Daily Scrum after each team conducted their own to coordinate and deal with cross-team topics. This eventually became known as the Scrum of Scrums. It also led to solving the issue of having 10 product owners learning to coordinate their decision-making by establishing a chief product owner role.
We created the idea of an integration Scrum team focused on testing integrations with other products in our portfolio, as well as third-party integrations. They also did continuous performance testing. We carved out fixed days/times for functional meetings so that directors of development, testing, documentation, etc. could spend two to three hours developing their people and their disciplines. We had teams who organized around certain product areas, architecture, and database development, helping to keep everything coordinated. We kept working on the process to improve and expand it.
Once we had a good handle on our own work, we had all other organizations participate in Sprint Reviews so they could get access to the product being developed. We brought in end users from the very start and just kept getting more and more of them to participate, which really helped us to build a better product. They became increasingly engaged in helping us manage our portfolio and product backlogs. As we moved forward, we dealt with other challenges like having multiple chief product owners, all with their own products wanting to use the same Scrum teams, and learning to manage the flow of work. Later, we encountered the challenges of distributed development and forming Scrum teams in India and the Ukraine.
Through it all, we just kept doing the hard work of solving problems and not looking for the silver bullet as Ken Schwaber had taught us so well. The message is clear; agile development practices are simple by design; implementing them is hard. It requires people who want to improve their circumstances. They want to serve their customers better than everyone else. They are willing to use their smarts to design experiments that will help them get there. And they are willing to fail sometimes, but learn quickly.
So, Now What Do We Do?
The answers to large-scale agility do not lie in a book, or a set of slides, or a poster. Every project that has more than one team is a project at scale, and every environment is different. The answers will emerge when people are willing to put in the work. There are no shortcuts; seeking shortcuts will only result in change initiatives that will not survive the test of time. Stories like these can help spark ideas, but they are not to be followed like a recipe. Doing so only sets us up to repeat history. So, the first question is not which model to follow, its asking yourselves “What problem are we trying to solve?”
Guest post by Charlie Rudd of SolutionsIQ
We’re not in Kansas anymore.
Most organizational change initiatives are not called transformations. So how come agile change initiatives are? To answer this question, let’s first review some examples of organizational change as well as the impact they have on the people in the organization.
Note in the above table how the magnitude of change deepens as you move from the top to the bottom of the table. At the top of the table, the change has little impact on the day-to-day work of most individuals. However, at the bottom, the impact of change can be quite profound. For example, changing the corporate culture uproots deeply embedded behavior and necessarily changes long-standing beliefs and assumptions.
Working with this principle, we can identify three levels of organization change magnitude:
Superficial org change
This type of org change has little impact on your day-to-day responsibilities and activities. Many corporate re-orgs are actually superficial. For example, your company may hire a new VP, but that doesn’t necessarily affect the project you’re working on, the work you perform on it, or the people you work with.
Significant org change
This type of org change has a greater impact on you. Your job or your work environment is affected, but usually not your role or job description. For example, some work procedures may change, and you may receive training or new software tools as a result. You may even have to join a new team or someone new joins your team. Perhaps you have to move to an office in a different building. Whatever the case, when your organization undergoes a significant org change, you are definitely affected even if the effect is rather minimal.
Transformational org change
Often, after a transformational org change, you have a new role that you have never performed before. Your job responsibilities change radically. So do your supervisors and their responsibilities. You have to approach your work in an entirely novel way, learning completely new skills, and often a new vocabulary. The unwritten rules that used to guide how you act and what you do no longer apply. Your work world is completely new. It’s surprising. It’s refreshing. It’s strange.
Let’s now consider where agile transformation fits within this org change magnitude framework:
Agile org change
In an agile transformation initiative, some of the change is superficial – some more significant – but when successful, the bulk is transformational. Learning new practices and tools are needed, but not sufficient for lasting success. Change must go deeper, in many cases down to the roots of corporate values, and what had been unquestioned management principles. It must encompass a new way of thinking about work and your place in this new world. Long-standing assumptions and unwritten rules go out the window as you discover new ways to work together with your colleagues, every day. This is why it’s called an agile transformation: you, your job, your responsibilities, your management, and your organization are transformed into something new.
So are we in Kansas anymore? In a word: nope. We’re not in Kansas. Agile transforms your world. It’s surprising. It’s refreshing. It’s strange. Whatever you think agile may be, there’s one thing it’s not: business as usual.
Guest post by AgileBill Krebs of Agile Dimensions
Some teams – such as sustaining engineering teams – are fine with Kanban. This method shows work on a taskboard as it progresses from waiting, to doing, to done, with an eye toward cycle time and focusing on a few things at once.
Some teams are fine with traditional Project Management Body of Knowledge (PMBOK – from the PMI) – as in special client engagements. This covers key project aspects such as cost, procurement, communications, and may use a Gantt chart to plan jobs of known but varying sizes. Unlike most of our agile projects, this will assume there is little likelihood of change.
Some teams are fine with Scrum development. Two-week iterations and sprints give vital visibility into progress, and also windows for change. Teams learn empirically and use these iteration windows to tune and adjust their product and procedures. Extreme Programming (XP) plans in a similar fashion, but adds some technical practice to build quality in.
These teams often have nine or fewer people, with three to six months for work. But what if the project or product you deliver has 40 people? 100 people? 300 people?
Projects like these would require scaling up your agile. Authors such as Jutta Eckstein, Scott Ambler, Kenny Rubin, and Dean Leffingwell have all described ways to do this.
Using such concepts in practice with dozens of teams has shown six key areas:
1) Roll-out – does management and the teams know agile at scale is different? Are they committed to doing it, and have they had some training on multi-team agile? Do you have someone prepared to program manage a team of teams?
2) Common language – one team can use whatever terms they wish. But when team of teams (aka, Scrum of Scrums) forms, it quickly becomes a mess where some say ‘Feature’ and some say ‘Epic.’ Pick a scaled agile methodology and vocabulary, and make that your organization’s common language.
3) Features – it helps organize larger projects to use the ‘parent’ of a story. Let’s call this a ‘Feature’ (like Dean Leffingwell’s Scaled Agile Framework® or SAFe™). While we still use small Stories, it becomes more important to plan ahead using larger Features so other teams can know when to depend on our output. This also helps stakeholders gain a picture of our product even as the number of Stories multiples as the team grows in size.
4) Align the business – with larger projects, it becomes even more important for business-facing parts of your organization to connect with your scaled agile process. Planning at higher levels such as portfolio (multiple products) and program (multiple teams) becomes more integral to how we work. But working with our market experts is harder if they do not understand our terminology and approaches to delivering at scale. Other areas such as accounting and your project management office may need to understand your scaled approach as well.
5) Kick off each release – spend a little more time before each release to look for dependencies between high-level features. Let teams know what’s coming, and have them discuss how they will deliver together.
6) More than a dozen teams – it makes sense to forge four or even 10 teams into a group that delivers a product. But if you product requires more than a dozen teams, that will be big enough to demand another sub organization with its own program manager.
Agile development has been used in many projects, large and small. Keeping these six factors in mind will help with your enterprise-strength projects. Taskboards may be sufficient with smaller projects, but larger projects benefit from tools designed to see things at more levels – portfolio, program, and team.
What steps can your project take to work smoothly between teams?
“AgileBill” Krebs has over 20 years of programming, performance, project management, and training in the IT industry at 5 IBM labs, banking, telecom, and healthcare. He has used agile since 2001, and taught it to over 2,000 people worldwide. He has presented at agile conferences, IBM Research, and conferences on education. Bill’s certifications and groups include SPC, PMI-ACP, CSP, ICE-AC, and others. He hosts the Distributed Agile Study Group and is a member of ALN, the Scrum and Agile Alliances, ACM, AERA, PMI, and more. He is pursuing a graduate degree in education technology, while working as an enterprise agile coach in the healthcare IT industry.
Scaled Agile Framework is a registered trademark and SAFe is a trademark of Scaled Agile, Inc.
Many common organizational problems can be traced down to management of Priorities and WIP (work in progress). Doing this well at all levels in an organization can make a huge difference! I’ve experimented quite a lot with this, here are some practical guidelines:WIP = Work In Progress = stuff that we have started and not yet finished, stuff that takes up our bandwidth, blocks up resources, etc.. Even things that are blocked or waiting are WIP.
- WIP is what it is, regardless of priorities (priorities are what we should be focusing on, WIP is what we are actually doing. They sometimes match…)
- It’s almost always a good idea to visualize WIP, whether it is at a team level or company level or whatever. Invisible WIP is hard to discuss, hard to challenge, and hard to limit. And hence, invisible WIP tends to grow and slow us down.
- Make WIP in-your-face-Visible! Ideally on the wall, since people will see it (and hence discuss it) without having to actually find and open a document. If it’s not on the wall, it tends to be ignored or forgotten. Analog visualization (stickynotes etc) usually works best, but showing a digital visualization on a screen works too.
- Use a “noise threshold” to avoid micromanagement. Avoid cluttering the visualization with hundreds of tiny things. For example, the noise threshold for a team-level visualization could be “if it’s less than 2 hours of work, just do it, don’t bother putting up a sticky”. At a department level the noise threshold could be “things that involve more than one team for more than a week”. Items smaller than that are allowed to “fly under the radar” (which has the added bonus of provided an incentive to break work down into small chunks).
- If there’s lots of noise, aggregate and visualize the noise (so that it too can be discussed/challenged/limited). For example “# of currently open Jira tickets” instead of displaying each individual ticket.
- The goal is to visualize all significant WIP that is burdening this team or department or project or whatever, and to do it in a way that doesn’t involve managing hundreds of individual notes on a board.
- It’s almost always a good idea to define WIP limits. The WIP limit is just “how much stuff can we have in progress before we start getting bogged down with multitasking and coordination overhead”. Start high and gradually reduce it, it’s an awesome way to drive out waste! This is one of the key principles in Kanban.
- Current WIP will sometimes be higher than the WIP limit! That’s OK. It’s an alerting system. Current WIP is simply our current reality, while WIP limit is our desired reality. Visualizing both makes the problem explicit. As long as we’re over the limit, our main focus is finishing things (or canceling them) and we are super-restrictive about starting new things.
Here’s an interesting study that shows how WIP limits dramatically benefit quality and speed “The Impact of Agile – Quantified”
Priorities are something different.
- Priorities are a guidelines to help us decide what new WIP to take on (when our WIP limits allow it), and what things to reject or postpone. Without clear priorites, we risk unaligned autonomy and suboptimization.
- Priorities also help us resolve resource conflicts within our current WIP (“Joe is needed for both of these tickets, which should he focus on first?” or “Let’s help Team X first, Team Y’s stuff is lower prio”)
- Priorities should be limited, too! Something like 1-3 items is usually sufficient. Because if everything is important, nothing is important! And if the list is too long, no one will read it or remember it.
- Priorites can be fluffy ( “our current priorities are 1) repay technical debt, and 2) improve the backoffice UX”.)
- …. or specific (“our current priorities are 1) Deliver feature X, and 2) Prototype feature Y, and 3) Install the new build tool”)
- Priorities may correspond directly to the WIP items (“these 3 WIP items are top priority”, or “the WIP items on the board are stack-ranked in priority order”). But they don’t have to be that specific.
- The test for useful priorties is:
- 1) “This list of priorities helps us decide what to do today, and what NOT to do today!”
- 2) “This list of priorities is so short and clear that everyone involved knows it by heart!”.
- 3) “We all understand why these priorities make sense for the company”
- Priorites are not exhaustive. We may have lots of things going on that are not directly related to our top 3 priorities. That’s OK, but:
- Non-priority work should by default not conflict with priority work. There are of course exceptions (“the server just crashed, bring it up again NOW!”), use common sense and talk about it.
- Guiding principle:
- 1) Can you contribute to a high-prio item today (directly or indirectly)? If so, do it! Not sure? Ask!
- 2) If you can’t contribute to a high-prio item, then work on something lower prio, but don’t let it conflict with people working on high prio work.
- 3) Be explicit about your choice and why.
- Priorities are cascading (or hierarchical, if you prefer, I just tried to find a less ominous-sounding word)
- Your team has priorities. So does your department. So does the whole company. Higher level priorities trump lower level priorities, and are essential for alignment. That means:
- 1) Lower level priorities should, at best, be aligned with higher level priorities (ex: “Department’s priority is Y, Team’s priority is Y”, or “Department’s priority is Y, team’s priority is X which contributes to Y”)
- 2) Lower level priorties should, at least, not conflict with higher level priortities (ex: “Department’s priority is Y, but that involves mostly other teams, our team can’t really contribute, so we’ll instead prioritize X, and make sure we don’t take time from anyone working on Y”).
- Your team has priorities. So does your department. So does the whole company. Higher level priorities trump lower level priorities, and are essential for alignment. That means:
- Avoid individual priorties. That tends to kill teamwork. Better to share priorities at a slightly higher level, such a team or workstream or project.
- Priorities change (of course!)
- It’s useful to have a recurring prioritization meetings to reevaluate priorities (every sprint for a team, every 6 weeks for a department, or whatever).
- … but priorities can also change at any time in between!
- Higher level priorities shouldn’t change as often, as they have ripple effects on lower level priorities and WIP. Causes confusion. The frequency of prioritization meetings should correspond roughly to how often we expect priorities to need to change.
- Long-lived and short-lived priorities can be on the same list!
- For example “our priorities are 1) customer support, 2) project X, 3) tech debt”. Project X might be short-lived and soon to be replaced by Project Y, while “customer support” might stay top priority for years!
- When a priority list has more than one item, be clear about what this really means.
- Ex: If our top priorities are “Project A and Project B”, what does it mean? Is A more important then B? Or are they equally important, but more important than other projects? Should we try to work exclusively on A if possible, or should we balance our time between both A and B?
- No exact rules needed, just some guiding principles.
If used appropriately, cascading priorities and WIP visualization and WIP limits can really help your organization be focused and fast!
This is an alternative to the Prime Directive for opening a retrospective. It isn’t a directive, and it needn’t be primary, just something you may like to reflect on with your fellow workers.
We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?
originally posted on AgileAnarchy in 2010
“Even imperfect answers can improve decision making.” – Donald Reinertson
When I read this from Reinertson’s book on flow, I realized that I had found the reason that people have so much trouble with story points. It’s a matter of overcoming their fear of inaccuracy. They are under the misguided belief in the accuracy of using hours or days to estimate work on projects. They’re basically afraid of being wrong (aren’t we all?) and that is the source of a lot of resistance to change. Being wrong sucks. I get that. Nevertheless, I’m wrong a lot.
Fortunately, wrong isn’t always boolean (unless you happen to step in front of a swiftly moving bus). There are shades of wrong. You can be just a little wrong, your aim just a little off, and still be headed in the right direction. Or you can be a lot wrong (the bus). That’s where frequently re-examining your decisions can help you catch the stuff that’s a lot wrong and fix it. What about the stuff that’s a little wrong? Don’t sweat it.
In the software world, a little wrong is still pretty useful. There is a tremendous amount of error and missing information. Compared to that, being slightly wrong isn’t so bad. Being slightly wrong gets you started – at least in mostly the right direction. You’re going to fine tune it anyway, so there’s really no need for decision making precision. That will come later, when you know more.
To me, the ability to overcome our fear of being wrong stems from an all-or-nothing mindset. We can’t allow ourselves to be even a little wrong for fear of failure. As Reinertson rightly points out, there is a time and a place for precision in decision making, but it’s not ALL the time.
Filed under: Agile, Process Tagged: error, estimation, Planning, sizing
From what I have been able to decipher in my career businesses are around to make money. The way they make money is by offering goods and services to people willing to pay for them. Each business has their idea of the best way to deliver these goods and services they believe in some way sets them apart. Most businesses I have come across have come to settle on an approach that allows them to work on individual separately managed projects resulting in an increment of business value being delivered. Something similar to this:
- Organize around projects
- Present the work that needs to be done in “clearly defined” requirements
- Staff the project appropriately according to the initial understanding of the scope and demand of the project
- Work hard on this project until it is completed and delivered to the market
In my experience some risks for delivering these projects on time and on budget might be identified by a project manager early on in the initial inception phase of the project and might be reviewed at the end of each project, but not much attention is paid to the risks during the life of the project.
I understand that the following might not be a revolutionary brand new concept, but I wanted to work on exploring the intricacies of this idea with you while I continue to work through this myself.Staying with a “Known Loser”
By not reassessing the risk throughout the life of the project we miss out on some great information to help us determine if the work can be completed on time (or at all for that matter) until the project is actually released.
We will continue to sink money into the project until it is “finished” even if everyone understands that there is no way to recoup our money through the sales of the eventual end result. I believe a big reason for staying with a “known loser” is that we become emotionally invested in these projects and stop looking at them objectively.
What if we were to stop looking at projects as work that needs to be done, and reframed them into a bucket of risk that needs to be removed.Shifting Focus
By shifting the focus to reduce risk it allows us to have a different conversation about the work we are evaluating. If we are performing a lot of work without reducing our risk, we are simply pushing out the inevitable delay of a project thus causing us to spend even more money. However, if we were to focus on removing the risk associated with the funded work we can determine if it is still worth pursuing or if the money earmarked for this project would be better suited spent somewhere else.
I have recently begun to realize that the project progress drivers I used to focus on and track are actually not very helpful to measuring the likelihood of a project being completed on time.Buckets of Risk
I believe that reframing our projects as a reduction in our exposed risk will allow us to focus our conversations on how valuable this investment is as opposed to how much money we might possibly make. If we continue this theory as we get more granular with the work and identify specific “buckets” of risk that are threatening to derail our progress we can more accurately predict if we will be able to deliver our work on time. The buckets I have used to date are Technical, Business, Verification & Validation, Organization and Dependencies. Let’s see some of the questions I’ve asked for each of these risk drivers and then you can decide if you think that these drivers will help you track the progress of your project.
- Do we have the technology in house already?
- Is this going to impact our current architecture?
- Do we have the appropriate skill set for the needed technology?
- Do we have clarity of scope?
- Do we understand the target market?
- Can we deliver on the intended business value?
Verification & Validation
- Do we know how we are going to test this work?
- Do we have sufficient information to be able to know when we should address this risk?
- Are the teams that need to work on this risk stable and fully staffed?
- Do we have the appropriate environments available to properly develop and test our work?
- Is there anything that must be done outside of this team in order to deliver this work?
- If there is work required by others, do we know their lead times?
Answering these questions will provide us the information necessary to truly understand our progress and make key decisions around the work we are evaluating.
Why are 59-Minute Scrums cool and what are they good for?The 59 Minute Scrum has been a popular training exercise for years in the Scrum community. The team gets a problem to solve, and goes through a "simulated" sprint to solve the problem. You get to experience real Scrum in a safe environment.
Fifty-nine minute sprints are an excellent learning tool because so much happens in such a short time. Everything that goes wrong in a real sprint can happen in a 59-minute sprint. They are great for problem solving!
In my classes, I usually simulate a 3-day sprint, using 5 minutes for each half of the Sprint Planning and the Sprint Review, 12 minutes for each day, and 4 minutes for each daily scrum. If you add it up, it comes to 59 minutes. Each Scrum Team has a Scrum Master, a Development Team and a Task Board. Depending on the context, there may be one Product Owner for all the teams in the room, or each team gets it's own PO. Note the 59 minutes does not include the Retrospective, which I handle separately in my courses. I usually don't too much about the length of the Sprint Review either.
I have found that if a team does three of these over three days, by the end of third iteration, they are really good at the basics of Scrum and ready to do it "in real life."
What is the difference between this being a Scrum simulation and a real-life "micro Sprint"? Well not much, except for the importance of the results you are producing. If you plan to throw away the results, it's a simulation. If plan to use them, it's a micro-sprint.
What would be an example of using micro-sprints? One area is to address organizational impediments. Imagine you have assembled in one room not just the Development Team, but also their management, important stakeholders, the operations group and other interested parties for the product. Ask them, "What are the biggest impediments to success of our project?" Have them write them on stickies and post them on the wall. Like in a retrospective, have their owners present them. The others can ask clarifying questions.
Finally you do some sort of dot-voting to identify the top issues. Exactly how you do this depends on many things, most importantly the number of people in the room. One way is to each table create a short list of two or three items, merge the lists to get about 10 to 15 items, then have everyone dot vote the this short list to prioritize the problems.
Now you are ready to use Scrum 59's to tackle your challenges. What could you do to solve the issues identified? Form teams around the top priority cards, usually one team per card and one team per table (did I mention, island seating with about 6 to 8 people per group?) Whoever wrote the top priority cards becomes Product Owner for those cards.
Iterate once or twice to come up with possible solutions for those impediments.
I have seen awesome results with this approach! Usually the people who are most surprised are the managers in the room, because they have never seen their staff working so creatively and with such energy. And the teams come up with good ideas that the managers never would have thought of. Oh, and they get really good at the mechanics of Scrum and ready to take on the challenges of their project using Scrum to help them.
Prepare to be amazed! And don't forget you can start implementing those solutions right away!
This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”.
The objective of a Scrum Master is to create a high performance team, which is in turn part of a high performance organization. So both team and Scrum Master must develop their skills moving forward. Just facilitating the Scrum meetings won't get you there.
The Scrum Alliance has defined the Certified Scrum Professional (CSP) program. This is the journeyman-level Scrum certification (think Apprentice -- Journeyman -- Master ). This certification is not achieved by passing a test, but rather by demonstrating a commitment to Scrum by doing Scrum and learning about Scrum.
How do you achieve the continuing education needed to achieve journeyman status? My answer is the Scrum Breakfast Club. The Scrum Breakfast Club is an inexpensive, recurring open-space format for solving problems related to Scrum and Scrum Projects (and learning advanced Scrum as you do). You bring your problems and find solutions, with me and with other people who face similar challenges. I also provide an opportunity for one-on-one coaching during this time.
Each Scrum Breakfast Club workshop earns you four Scrum Education Units. (If you are familiar with the PMI, these are like PDUs, and can also be used as PDUs).
From a career point of view, if you take a CSM Certified Scrum Master course, follow it up with a CSPO Certified Scrum Product Owner course 6 months later, and participate regularly in the Breakfast Club, after 2 years, you will have accumulated enough Scrum Education Units to qualify as a Certified Scrum Professional. And you have had plenty of opportunities to address the actual issues in your organization.
Here is a description of the Scrum Breakfast Club. How does this fit into your plans?
Is your team in need of a little improvement? Are they getting a little stale? Are you looking for a way to bring their performance “to the next level?” Well, maybe you should slow it down.
Oh I know, those other consultants will tell you that they can speed up your team. It’s the siren song of the wishful manager, “Speed my team up: faster!” But I’m here to tell you they’ve got it all wrong.
let me ask you this:When you get a flat tire in your car, do you speed up? No! If there is a burning smell coming from the oven, do you heat it up? No! So if you see your teams start to slow down, why on earth would you try to make them go faster?
Let’s face it, when teams slow down there is usually a damn good reason. So rather than speeding up, perhaps it’s time to slow down, pull over, and take a look under the hood.
How do you slow down? Nobody really teaches that. Everybody is so focused on speeding up they seem to have forgotten how to slow down. Here are my top 10 ways to slow down your team (and hopefully address your problem):
- Apply a WIP Limit
- 1 piece flow
- A more rigorous definition of done
- Pair programming
- Promiscuous programming
- Continuous Integration
- Continuous Delivery
- Acceptance Test Driven Development
- Spend more time on impediments
- Hack the org
Taking time to implement any one of these things is almost guaranteed to slow you down. That’s a good thing, because your team probably needs to pull over to the side of the metaphorical road and repair a few things.
Filed under: Agile Tagged: improvement, slowing down
Allison Pollard’s goal is “To Teach and Delight.” Her goal is to help people discover and develop their agile instincts. She enjoys mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. Allison blogs at over at To Teach and Delight.
After attending the Scrum Gathering in New Orleans, I’ve been pondering: What does it mean to be an agile coach? I heard a few things that reminded me of a presentation my client created a few months ago; the presentation outlined the agile roadmap for the organization, and one of the slides was about the agile coach role up to that point.Credit: Teddy Lambed
It showed cars in gridlock traffic, and one vehicle was labeled “agile coach.” I’ll give you a hint what that vehicle looked like:Photo by Steelman204
What does it mean for an agile coach to be an ambulance? To me, it implies that there’s something critical going on and that the agile coach is urgently needed. The team has injured themselves, and the coach is to come in and fix it. There’s a sense of a right way and a wrong way, and the coach must apply the right techniques before running off to the next emergency. And the agile coach is reactive rather than proactive.
The constant sirens and speeding through traffic and performing CPR on the scene…. being an ambulance is exhausting.
Let’s explore another perspective. What if we think of the agile coach as a muscle car?Photo by Abdullah AlBargan
Yeah… the coach has deep knowledge of agile and lean, so his engine is pretty powerful. Some folks ooh and ahh at the agile coach for his expertise confidence. They want to go for a ride with the coach and experience the power; others are afraid. They scoff and stick to their sensible cars. The muscle car could beat those cars in a race, but you’d have to get their interest first. The muscle car coach is more proactive than an ambulance coach. He can win over more people by dazzling them with agile knowledge and taking people for joy rides rather than emergency trips. But if the coach is a muscle car, what does that make everyone else?
With that thought, I’ve been exploring a different perspective: agile coach as bumper car.Photo by Glenn Beltz
If you’re on the track—coach, manager, team member, whoever—you’re in a bumper car. There’s movement and fun and spontaneity and safety on the track. And it’s pretty much guaranteed: you will be bumped. Everyone will be bumped—even the coach! Every car is equal, and we are on the track together. Everyone is safe and yet everyone will be pushed out of their comfort zone. Most of all, there is laughter.
I am the bumper car that provokes movement.
This post originally appeared on Allison’s blog at To Teach and Delight on 5/17/2012.
If you are organized as platform team, middleware, and front-end teams, you have a component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now.
If you have a program, you have many people in your teams. Your platform team might not be 7 people, but several teams, maybe 50 people, if you are large enough for a program. Your middleware teams could be another 100 people, and your front-end teams could be another 100 people. You have lots of people and lots of teams.
I bet you do not have an even ratio of platform, middleware, and front-end teams. You have experts, here, there, and everywhere. And, if you are anything like my clients, you have trouble releasing features in an agile program.
What are the problems?
- You have experts embedded in a wide variety of teams
- The experts need to multitask to serve a variety of projects, so you incur a cost of delay to multitasking and queues
- You are not releasing features. You have trouble when the components come together.
Even if the teams are agile, your program, the collection of projects is not agile.
What can you do?
You can ask the organization to try this as an experiment, for no longer than 2 weeks:
- The only measure of success is running tested features. And, no one, especially no manager, gets to compare teams. This is an experiment that the organization is going to learn from. Some teams will have small and easy features. Some teams will not. This is not a competition. If you start comparing teams, the teams will game this measure and the organization will lose the learning. It’s not about the number of features. It’s about learning how to manage the stream of features through feature teams.
- Ask three teams to volunteer: one platform, one middleware, and one front-end team. If more teams want to volunteer, fine. But you need three.
- Those teams stop multitasking. Those teams agree on one ranked backlog among the three teams. (I know, this might be the most difficult thing your organization has tried. I know you have experts. Ignore the fact you need experts everywhere. Agree on only one ranked backlog.)
- Ask these three teams to self-organize as feature teams for now. No changing managers. No changing desks. They get to decide how to organize. If you are a manager, no decreeing who is a feature team with whom. Let the teams decide who is on what team. This works best in one large room. However, I have seen geographically distributed teams who were desperate to release a feature do this over distance.
- Ask the Product Owner for these teams to make the stories as small as they can make them, preferably one or two team-days or less. This could be a huge challenge for the Product Owner. That’s okay. This is an experiment. I recommend a kanban board and limiting work in progress for this experiment.
- Tell the teams that if they don’t have the expert they need for a story, that’s okay. They can pair, swarm, or mob together to get the story done. But, they are not allowed to interrupt another team.
- The teams work on their backlog for this experiment (not any longer). They see what happens when everyone works in feature teams of their own making and no one multitasks, to get features to done. Remember, this is an experiment.
- Retrospect at the end of this experiment so they can see what happened.
- Decide what to do next. This is an experiment.
To sum: One self-organizing team, composed of platform, middleware, and front-end people. One backlog. One product owner. No longer than two weeks. Visualize the workflow. Limit work in progress. The only measure of success is running, tested features. No multitasking. Retrospect at the end. See what happens.
There are many things that can go wrong. But, there are many possibilities of learning here. This works best if the managers step back and don’t interfere. It works best with collocated teams. You can do this (and I have) with geographically distributed teams.
When I’ve facilitated this, the teams learn tons about how to work together and what they needed to do for their program. In several organizations, they wanted to do this again as an experiment.
Managers have to allow the teams to organize the way the product requires. Otherwise, you have Conway’s Law in spades.
When I have done this, I have had these results:
- Most of the time, the teams were able to finish some of the features in their backlog without too much trouble. These features required some of the team to work together, either discussing the feature, or pairing.
- They were able to finish most of the features in their backlog with a little trouble. These features required the entire team to work together.
- Some of their features were too large to finish in the timebox.
These results don’t surprise me. I bet they don’t surprise you.
Every so often, teams have trouble finishing any features. They learned that they did not have sufficient expertise to do anything on their features in their backlog. One team spiked a feature for a day, swarming on it. They had more questions than when they started. They needed an expert who was in another team.
If you put the focus on releasing running, tested features, that is what people will do. But you have to focus on it.
Component teams aren’t bad, per se. But component teams don’t get you running, tested features. This is one possibility. Based on your experiment and reflection, you could try something else.
In Part 1 of this four-part series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives. Each agile project developing a product or a solution has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management understanding and support, maturity of practices, challenges, culture, etc.
In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects: Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (see Tables 1-4 of Part 1 of this blog series). Each scaling agile parameter can assume one or more values from a range of values. Each organization or a large-scale project is likely to select a different combination of these 25 scaling agile parameters that are relevant; moreover, the value or range of values for each scaling agile parameter for a project or an organization is likely to be unique. However, “Scaling Agile Your Way” does not imply a license to optimize at the subsystem levels (teams or programs) at the expense of overall system-level optimization (portfolios and enterprise). Systems thinking is important for Scaling Agile Your Way.
In Part 1, I presented a brief overview of various popular Agile and Lean scaling frameworks: Scaled Agile Framework® (SAFe), LeSS, DAD and MAXOS. Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth. SAFe and MAXOS represent radically different approaches to scaling agile. Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.
Today, I will focus on the Sweet Spot, Challenge Zone and Unfit zone for SAFe and MAXOS:
- Indicates a good match between a scaling agile framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
- Implementation becomes easier, more efficient and effective
- Indicates a challenging match between a framework and a scaling agile parameter with a specific choice or range of choices selected for the parameter
- Requires more implementation effort compared to the Sweet Spot
- Indicates a poor match between a framework and a scaling agile parameter with a specific choice or range of choices for the parameter
- Poor match could happen for one of two reasons: (1) the parameter value chosen is not applicable, or (2) the parameter value chosen will not work well
Figure 1 illustrates the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presents similar information for MAXOS. These are organized by the six scaling aspects mentioned above. You will see four arrows in each Figure showing our recommendation for taking your large-scale agile projects closer to the Sweet Spot over a period of time. I urge you to carefully review all of the information presented in Figures 1 and 2. There is a lot of information, and it will take time to fully understand. You may find it helpful to discuss with other agilists within your company.
From the information in Figures 1 and 2, it is clear that SAFe and MAXOS offer mostly distinct Sweet Spots, Challenge Zones and Unfit Zones, although occasionally there may be some overlap. For example:
- As shown in Figure 1, cross-functional, self-organized teams with co-located or close-by time zoned team members working under low to moderate governance structure offer a Sweet Spot for SAFe. But in Figure 2, self-organized, developer-centric (not cross-functional) teams of co-located members with minimal governance overhead offer a Sweet Spot for MAXOS.
- In Figure 1, emerging user needs that must be discovered with sustained effort represent a Challenge Zone for SAFe; in Figure 2, the same scaling agile parameter value offers a Sweet Spot for MAXOS.
- In Figure 1, low to moderate product modularity represents a Challenge Zone for SAFe, while Figure 2 shows that low modularity (tight integration of all code) creates an Unfit Zone for MAXOS. On the other hand, a high degree of modularity in the product/solution architecture represents a Sweet Spot for both SAFe and MAXOS.
- In Figure 2, heavy and rigid governance, or heavy/life-critical regulatory regime represent an Unfit Zone for MAXOS. But in Figure 1, the same scaling parameter values offer a Challenge Zone for SAFe.
- In both of these, we see that, “Tightly coupled hardware product with embedded software and services (ex. appliances, cars, medical devices, smartphones, wearable computers, military gear, industrial equipment)” represent an Unfit Zone for both SAFe as well as MAXOS.
Get As Close to the Sweet Spot As Possible
If you decide to use SAFe in your enterprise (at least for some programs and portfolios), ideally you should try to get as close to the SAFe Sweet Spot as possible. I have similar advice if you decide to use MAXOS (get as close to the MAXOS Sweet Spot as possible). It is quite possible that your entire enterprise is not close to the Sweet Spot when you are just beginning your scaling agile transformation effort. In that situation, I suggest starting with a scaling agile pilot program of 5 to 10 teams; after their initial education on SAFe (or MAXOS) is over, have this pilot program start as close to the Sweet Spot as possible. This may require changes in some of your historical processes and practices, and development of SAFe (or MAXOS) with clear understanding and support for from your senior management.
For example, a pilot for SAFe may need to choose a relatively moderate domain complexity project, fairly modular architecture to minimize inter-team dependencies, co-located team members for most teams, a good deal of test automation and continuous integration (with prior training), a set of strong servant-leader ScrumMasters for each team, low to moderate governance overhead, low to moderate regulatory compliance regime, low to moderate impact of defects, etc. See the Sweet Spot for SAFe in Figure 1. If the pilot program teams are not close to the Sweet Spot yet, senior management will need to help them get there as the starting point for the pilot to make the scaling agile journey less painful. With the experience of one release cycle underway, more pilot programs can be started close to the Sweet Spot; in fact, while the first pilot is going on, one to four more pilot programs can be identified and necessary effort expended to bring them close to the Sweet Spot as a starting point for their upcoming SAFe (or MAXOS) pilots.
Dealing With the Unfit Zone
The other extreme of the Sweet Spot is, of course, the Unfit Zone. If a pilot team finds themselves in the Unfit Zone for at least one scaling agile aspect, the pilot will very likely fail. For example, if a SAFe pilot program must use contributions from the open source community, or a MAXOS pilot program must operate under a rigid or heavy governance structure, or work under a life-critical regulatory regime, it will most likely fail. Senior management must either take action to remove the issues creating the Unfit Zone, or select a different pilot program that does not find put the pilot in the Unfit Zone for any of the six scaling aspects.
Your Journey to the Sweet Spot is Your Tailored Journey
Your transition of your pilot program to the SAFe (or MAXOS) Sweet Spot will be your own customized plan and journey tailored to your situation. You need to consider where these pilot teams are now, the gap between their current status and the Sweet Spot, and the effort and time needed to bring them closer to the Sweet Spot. This effort will be dependent on each team’s situation, and is a very important aspect of “Scaling Agile Your Way.” How do you take a pilot program close to the Sweet Spot is going to be your own unique journey and cannot be copied from a recipe book. If a pilot program or a specific team within that program cannot reach the Sweet spot across all six scaling aspects, maybe it will come close to the Sweet Spot for four out of six scaling aspects, and stay in the Challenge Zone for the remaining two. When a pilot program is in the Challenge Zone with respect a scaling aspect, it does not mean that the pilot program cannot start or proceed; but it does mean that you need to be prepared to spend more effort and overcome difficult challenges if you are going to operate in the Challenge Zone.
For example, if a pilot program has one or more teams with their members in different locations with widely different time zones, the SAFe Release Train Planning (two-day event required by SAFe) may involve a lot of complicated logistics and travel time/expenses for remote people, for which senior management support might be hard to come by (after all, “this is a pilot” is likely to be the argument). If the pilot needs to operate under a traditional, hierarchical and rigid structure, it may create many organization impediments, complicating the challenges for the pilot program.
As shown in both Figures 1 and 2, your transition plan is to move as close to the Sweet Spot (the inner most rectangle area) as possible from the directions of Unfit Zone and Challenge Zone. This is illustrated by four broad arrows pointing toward the innermost rectangle in Figure 1 for SAFe and in Figure 2 for MAXOS. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The culprit is likely one of two things:
1. Internal to your own organization (its history, culture, current practices, etc.). This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate its understanding and commitment to the success of scaling agile.
2. Rooted in the market and business environment of your organization. These reasons cannot be removed by senior management (if you want to stay in the business). You will need to replace or augment the scaling agile framework practices with your own custom practices and retain the practices from the framework that are still applicable.
Table 11 below captures the Unfit Zone and Challenge Zone in its two rows, and the above two classes of reasons in its two columns. The cells in this table illustrate specific examples of an action plan.
Table 11: Reasons and Actions for Unfit and Challenge Zonewith Examples
The transition from Unfit or Challenge Zone to Sweet Spot will require planned, disciplined and concerted effort — and a good understanding and true commitment from your senior management. This journey will be uniquely yours, and cannot be copied from a cookbook. Over time, you will find that you are moving closer and closer to the Sweet Spot, but still have few areas in the Challenge Zone.
Customization Needs and Opportunities for Implementing Your Scaling Agile Framework
In addition to your unique and tailored journey toward the Sweet Spot of your scaling agile framework, a very important aspect of Scaling Agile Your Way is that each team, program or portfolio may need to implement key aspects of its framework in unique and customized ways. It seems that the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be used to implement a variety of process modules of SAFe in customized ways. Customization needs and opportunities for the MAXOS framework will come mostly in the context of implementing its advanced engineering practices of code contribution, automated testing, continuous integration, feature switches, continuous delivery, and making use of cloud computing facilities, etc. I will elaborate on this topic in Part 4 of this series.
Are you about to start your scaling agile journey? If so, do you have one or few pilot programs consisting of 5 to 10 teams in mind? How do you feel getting them started closer to the Sweet Spot of SAFe, MAXOS or any other framework of your choice (such as LeSS or DAD)? Have you run into the Unfit Zone for any scaling aspects? I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com) or on Twitter @smthatte.
Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly
Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS
Part 4: Scaling Agile Your Way: How to develop and implement your custom approach