Despite my best efforts, I couldn’t help but get involved in Lean Kanban Central Europe again this year, and have even taken on more of a role by helping co-chair the Kanban track. Its always a great event (one of my favourites) because the people and content are such high calibre. This year looks to be no different.
This year I’m also running a workshop (as previously announced). I hope to see you there!
Wenn wir von Skalierung sprechen, denken wir häufig an Umbrüche, Neuorganisation und Transformationen. Wir haben große Schemata und Organigramme im Kopf. Ein schönes Lehrstück darüber, wie solche Skalierungen mächtig schiefgehen können, beschreibt David Robertson in seinem Buch “Brick by Brick”. Es erzählt die Geschichte der dänischen Lego-Gruppe.
Besonders spannend sind zwei Augenblicke in der Firmengeschichte: Zum einen ist da die frühe Firmengeschichte in der Nachkriegszeit, als Lego sich vom Hersteller von Holzspielzeugen zum Fabrikant modularer Plastikbausteine mauserte. Damals, im Jahr 1946, investierte Lego mehr als den zweifachen Jahresgewinn zum Erwerb einer enzigen Spritzgussmaschine für Kunststoff. Den Erfolg dieser Entscheidung kennen wir alle.Verlorener Fokus
Weniger bekannt ist, dass Lego um die Jahrtausendwende kurz vor der Insolvenz stand. Wie konnte es so weit kommen? Lego hatte in den 1990er Jahren erlebt, wie sich das Spielverhalten von Kindern und Jugendlichen veränderte. In Zeiten von Gameboy und XBox erschien das Aufeinandertürmen von Spielklötzen zur Erschaffung eigener Welten plötzlich veraltet. Lego reagierte, indem es sich in einer Reihe von Geschäftsfeldern wie Computerspielen, Lifestyle-Produkte, Themenparks und Lernkonzepten versuchte. Dabei geriet das, was Lego immer schon stark gemacht hatte, aus dem Fokus. An Stelle des klaren und einfachen Designs, in dem Kinder ihre eigenen Erlebeniswelten nachbauen konnten, traten abstrakte Action- und Sci-Fi-Figuren. Die bei Kleinkindern beliebte Duplo-Linie wurde durch ein längst schon wieder abgeschafftes System namens Lego Explore ersetzt, das sich an den Spielzeugen des Konkurrenten Fisher-Price orientierte. Lego war in viele Richtungen gewachsen, aber diese Diversifizierung brach dem Unternehmen fast das Genick.
Eine interne Untersuchung ergab im Jahr 2004, dass 94% der Lego-Baukästen unprofitabel waren. Neben der misslungenen Diversifizierung war dies auch auf eine misslungene Systemarchitektur zurückzuführen. Zwischen 1997 und 2004 war die Nummer an Einzelbausteinen von 6.000 auf über 14.000 explodiert. Die Farbvarianten der Bausteine stiegen von ursprünglich sechs auf über 50 an. Jeder Einkäufer, jeder Logistiker kann sich vorstellen, wie viel Mehraufwand es für Produktion, Lager und Versand bedeutet, wenn neue Elemente nur für ein Baukasten-Set verwendbar sind. Aber auch die Integrität der Marken litt darunter: Plötzlich gab es nicht ein, sondern gleich acht Polizeimännchen mit minimalen Unterschieden in der Konfiguration. Für Produktlinien wurden eigene Minifiguren geschaffen, die zum Teil den Gesichtern ihrer Designer nachempfunden waren. Die Tradition war, im wörtlichsten Sinn (tra-dere – hinüber-geben) verloren gegangen. Erwachsene fanden das Lego ihrer Kindheit nicht wieder – und Kinder konnten mit den schönen neuen Welten wenig anfangen.Rückbesinnung auf die Stärken
Der Weg zurück zur Profitabilität war ebenso einfach wie genial. Robertson erzählt, wie bei dem frisch ernannten CEO Jørgen Vig Knudstorp, damals Mitte 30, der Groschen fiel:
“For children and their parents, the benefits of a play system were obvious: combining bricks in almost any way they wanted fired kid’s creativity and imagination and delivered a singularly unique building experience. But for Knudstorp, his eureka moment came when he realized the Lego System is not just a play system, it’s also a business system. (…) Instead of following the industry norm of striving to come up with one-hit wonders, LEGO should create a coherent, expandable universe of toys. A Lego system of toys (…) would build familiarity and a sense of community around Lego.”
Diese Erkenntnis führte beispielsweise dazu, dass künftig mindestens 70% aller Bauteile aus bisherigem Bestand sein mussten. Oder dass die erfahrensten Designer und Entwickler wieder die Autorität bekamen, den Entwicklungsprozess von Anfang an mitzubestimmen. Oder dass die interne Softwareentwicklung mangels Erfahrung aufgegeben wurde und stattdessen Kooperationen eingegangen wurden.
Die Lego-Story ist ein Lehrstück in Skalierung. Kurz vor dem eigenen Untergang hat Lego erkannt, dass wirkliches Wachstum nur in Feldern geschehen kann, in denen das Unternehmen stark ist. In den neunziger Jahren versuchte Lego, Zeittrends hinterher zu laufen, die mit seiner eigenen Identität wenig zu tun hatten. Entsprechend hilflos agierte Lego dann auch. Bis es schließlich erkannte, welche Stärken es schon immer gehabt hatte. Dann hat Lego angefangen, konsequent auf diese Stärken zu fokussieren. Dort, im geschlossenen Ökoystem der Bausteinwelten, ist das Wachstum gelungen. Das Ergebnis kann sich mittlerweile auch finanziell sehen lassen: Im vergangenen Jahr meldete die Lego-Gruppe eine Umsatzrendite von 34% bei 3,1 Milliarden Euro Umsatz.
- 1 Euro wer zu spät kommt | Daily Scrum | Bärenherz
- Die Kraft der Begeisterung
- Mehr wissen! Moderationstraining
When I talk to folks about Scrum, one of the points I make sure to cover is the holy trinity, the three basic roles in Scrum: Product Owner, Scrum Master, and Team. I’m starting to think I must be doing it wrong because when I talk about roles, somehow that role manifests itself as a job. Let me back up a step and see if I can explain what I mean. To me, a role is a transitory responsibility that anyone can take on. It’s akin to what actors do. Actors take different roles all the time. But when an actor takes a role, say as a teacher, they act in every way like a teacher, without actually being a teacher. They do it and then leave it behind and move on to the next role. They may perform the role so well that you can’t tell the difference between the actor and the teacher, but to the actor teaching is still just a role.
Now there are people for whom teaching is a job. A job is very different from a role. You are hired for a job. A job is something that you identify with and are assigned to. A job, at least for some, becomes something that they identify strongly with (i.e. “I am a teacher.” or “Teaching is what I do.”). A job is a very different thing than a role. A job comes with identity, some feeling of authenticity and permanence. Typically we hire people to perform jobs.
According to this definition, jobs and roles are very different beasts. However, people have a hard time keeping this distinction in mind. We tend to take roles and turn them into jobs. That’s unfortunate, because a role is meant to be something transitory, something that is filled temporarily. It is meant to be worn like a costume and then passed on to the next wearer. When you turn a role into a job, you risk perverting it’s purpose. When you turn a role into a job, you make it very difficult for others to share it – it’s hard to swap back and forth. When you make a role into a job, people get surprisingly defensive about it. It becomes something that they identify with very closely. If you try and tell them that anybody can do it, they tend to get all fussy and upset. They start to try and protect their job with clever artifacts like certifications – they’ll do anything to make themselves unique enough to keep that job. It’s an identity trap.
Here is how I see this problem manifest itself with Scrum teams: You sell them on scrum and teach them how it works. Every team has a Scrum Master and a Product Owner. So what do they do? They run out and hire themselves some people to fill the jobs of Scrum Masters and Product Owners. They get their teams sprinting and start delivering quickly – hey, now they’re agile! Only they’re not really. You see, as you face the challenge and complexity of modern day business, the team often needs to change. That person you hired as the Scrum Master? You may be best served to swap that role with somebody else. Maybe a developer or QA on the team. The ability to move that role around to different actors could be very useful. But you can’t do that now because it’s no longer a role, it’s somebody’s job. And you can’t mess with their job without seriously upsetting somebody. The end result is that your organization effectively can’t change. You limit your agility.
The bottom line is that I believe that the roles in Scrum were never intended to be jobs. To make those roles into jobs risks limiting your agility.
Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, agility, jobs, roles, Scrum
With Bill Tozier, I’m working on re-basing XProgramming.com from WordPress to Ruby/Sinatra etc. We tweeted a bit about an issue we ran into today. It goes like this:
The image we had of the new site is that each article would be stored in a folder named to match the WordPress “slug” for the article such as “…/articles/xprognew-todays-problem/”. We’re planning to keep the article, its metadata, and any other assets, such as images, right in the article.
Writing will be in Markdown. So I’d expect to write an article that looks like this:Some Title
Here's a paragraph of text. Assume it runs on and on ...
Markdown assumes that the construct above specifies a picture in the same folder as the article. It will generate, roughly, <img src='picture7.png/>.
This would clearly be the easiest way to specify the picture, and it seems to us to make sense to keep the pictures and metadata with the article. And the folder name matching the slug makes converting the existing site much easier. (Existing images will not have that kind of link, but are all in a WordPress images folder together somewhere. We’ve not looked yet at what to do about that. We’re trying to make new articles easier and if the conversion is tricky so be it.)
We are using Sinatra and kramdown. The Markdown above does generate the image statement shown. However, somewhere inside or above Sinatra, there is a built-in assumption that assets like images will be in a folder named “public”, and the article is rendered as if it, itself, were in public, so that the image call looks into public.
We tried navigating out of public with things like “../articles/myslug/” but this just doesn’t work. I’m told by Z Spencer that Rackup or whatever its name is, keeps you in public as a security measure. Good for it.
The result, though, is that we see few options:
- Put all images in public. This will work, and is not unlike WordPress, but we don’t like it.
- Put images in a subfolder of public, and type the folder name into the image call. This ties the article contents to the name of its slug and we don’t like that.
- Put images in a subfolder of public, and do an on-the-fly substitution of the file name as we render the file. This requires a search and replace on the article and we don’t like that either.
There are probably other options but we see none that we like. And we see, today, no way to override where public points, except somewhere else under public.
Anyway, that’s the problem I’ve been tweeting about.
In my continued playing around with meetup data I wanted to plot the number of members who join the Neo4j group over time.
I started off with the variable ‘byWeek’ which shows how many members joined the group each week:
> head(byWeek) Source: local data frame [6 x 2] week n 1 2011-06-02 8 2 2011-06-09 4 3 2011-06-30 2 4 2011-07-14 1 5 2011-07-21 1 6 2011-08-18 1
I wanted to plot the actual count alongside a rolling average for which I created the following data frame:
library(zoo) joinsByWeek = data.frame(actual = byWeek$n, week = byWeek$week, rolling = rollmean(byWeek$n, 4, fill = NA, align=c("right")))
> head(joinsByWeek, 10) actual week rolling 1 8 2011-06-02 NA 2 4 2011-06-09 NA 3 2 2011-06-30 NA 4 1 2011-07-14 3.75 5 1 2011-07-21 2.00 6 1 2011-08-18 1.25 7 1 2011-10-13 1.00 8 2 2011-11-24 1.25 9 1 2012-01-05 1.25 10 3 2012-01-12 1.75
The next step was to work out how to plot both ‘rolling’ and ‘actual’ on the same line chart. The easiest way is to make two calls to ‘geom_line’, like so:
ggplot(joinsByWeek, aes(x = week)) + geom_line(aes(y = rolling), colour="blue") + geom_line(aes(y = actual), colour = "grey") + ylab(label="Number of new members") + xlab("Week")
Alternatively we can make use of the ‘melt’ function from the reshape library…
library(reshape) meltedJoinsByWeek = melt(joinsByWeek, id = 'week')
> head(meltedJoinsByWeek, 20) week variable value 1 1 actual 8 2 2 actual 4 3 3 actual 2 4 4 actual 1 5 5 actual 1 6 6 actual 1 7 7 actual 1 8 8 actual 2 9 9 actual 1 10 10 actual 3 11 11 actual 1 12 12 actual 2 13 13 actual 4 14 14 actual 2 15 15 actual 3 16 16 actual 5 17 17 actual 1 18 18 actual 2 19 19 actual 1 20 20 actual 2
…which then means we can plot the chart with a single call to geom_line:
ggplot(meltedJoinsByWeek, aes(x = week, y = value, colour = variable)) + geom_line() + ylab(label="Number of new members") + xlab("Week Number") + scale_colour_manual(values=c("grey", "blue"))
One of the things I do, as a patterns and practices kind of guy, is research and share success patterns.
One of my more interesting bodies of work is my set of patterns and practices for successful executive thinking.
A while back, I interviewed several Microsoft executives to get their take on how to think like an effective executive.
While the styles vary, what I enjoyed is the different mindset that each executive uses as they approach the challenge of how to change the world in a meaningful way.5 Key Questions to Share Proven Practices for Executive Thinking
My approach was pretty simple. I tried to think of a simple way to capture and distill the essence. I originally went the path of identifying key thinking scenarios (changing perspective, creating ideas, evaluating ideas, making decisions, making meaning, prioritizing ideas, and solving problems) ... and the path of identifying key thinking techniques (blue ocean/strategic profile, PMI, Six Thinking Hats, PQ/PA, BusinessThink, Five Whys, ... etc.) -- but I think just a simple set of 5 key questions was more effective.
These are the five questions I ended up using:
- What frame do you mostly use to evaluate ideas? (for example, one frame is: who's the customer? what's the problem? what's the competition doing? what does success look like?)
- How do you think differently, than other people might, that helps you get a better perspective on the problem?
- How do you think differently, than other people might, that helps you make a better decision?
- What are the top 3 questions you ask yourself the most each day that make the most difference?
- How do you get in your best state of mind or frame of mind for your best thinking?
The insights and lessons learned could fill books, but I thought I would share three of the responses that I tend to use and draw from on a regular basis …Microsoft Executive #1
1) The dominant framework I like to use for decisions is: how can we best help the customer? Prioritizing the customer is nearly always the right way to make good decisions for the long term. While one has to have awareness of the competition and the like, it usually fails to “follow taillights” excessively. The best lens through which to view the competition is, “how are they helping their customers, and is there anything we can learn from them about how to help our own customers?”
2) I don’t think that there is anything magical about executive thinking. The one thing we hopefully have is a greater breadth and depth of experience on key decisions. We use this experience to discern patterns, and those patterns often help us make good decisions on relatively little data.
3) Same answer as #2.
4) How can we help our customers more? Are we being realistic in our assessments of ourselves, our offerings and the needs of our customers? How can we best execute on delivering customer value?
5) It is key to keep some discretionary time for connecting with customers, studying the competition and the marketplace and “white space thinking.” It is too easy to get caught up on being reactionary to lots of short-term details and therefore lose the time to think about the long term.Microsoft Executive #2
There are three things that I think about as it relates to leading organizations: Vision, People and Results. Some of the principles in each of these components will apply to any organization, whether the organization's goal is to make profit, achieve strategic objectives, or make non-profit social impact.
In setting the vision and top level objectives, it is very important to pick the right priorities. I like to focus on the big rocks instead of small rocks at the vision-setting stage. In today's world of information overload, it is really easy to get bombarded with too many things needing attention. This can dilute your focus across too many objectives. The negative effect of not having a clear concentrated focus multiplies rapidly across many people when you are running a large organization. So, you need to first ask yourself what are the few ultimate results that are the objectives of your organization and then stay disciplined to focus on those objectives. The ultimate goal might be a single objective or a few, but should not be a laundry list. It is alright to have multiple metrics that are aligned to drive each objective, but the overall objectives themselves should be crisp and focused.
The next step in running an organization is to make sure you have the right people in the right jobs. This starts with first identifying the needs of the business to achieve the vision set out above. Then, I try to figure out what types of roles are needed to meet those needs. What will the organization structure look like? What kind of competencies, that is, attributes, skills, and behaviors, are needed in those roles to meet expected results? If there is a mismatch between the role and the person, it can set up both the employee and the business for failure. So, this is a crucial step in making sure you've a well running organization.
Once you have the right people in the right jobs, I try to make sure that the work environment encourages people to do their best. Selfless leadership, where the leaders have a sense of humility and are committed to the success of the business over their own self, is essential. An inclusive environment where everyone is encouraged to contribute is also a must. People's experience with the organization is for the most part shaped by their interaction with their immediate manager. Therefore, it is very important that a lot of care goes into selecting, encouraging and rewarding people managers who can create a positive environment for their employees.
Finally, the organization needs to produce results towards achieving the vision and the objectives you set out. Do not confuse results with actions. You need to make sure you reward people based on performance towards producing results instead of actions. When setting commitments for people, you need to be thoughtful about what metrics you choose so that you incent the right behavior. This again helps build an environment that encourages people to do their best. Producing results also requires that you've a compelling strategy for the organization. Thus, you need to stay on top of where the market and customers are. This will help you focus your organization's efforts on anticipating customer needs, and proactively taking steps to delight customers. This is necessary to ensure that organization's resources are prioritized towards those efforts that will produce the highest return on investment.Microsoft Executive #3
- Different situations call for different pivots. That said, I most often start with the customer, as technology is just a tool; ultimately, people are trying to solve problems. I should note, however, that “customer” does not always mean the person who licenses or uses our products and/or services. While they may be the focus, my true “customer” is sometimes the business itself (and its management), a business group, or a government (addressing a policy issue). Often, the problem presented has to be solved in a multi-disciplinary way (e.g., a mixture of policy changes, education, technological innovation, and business process refinements). Think, for example, about protecting children on-line. While technology may help, any comprehensive solution may also involve government laws, parental and child education, a change in website business practices, etc.
- As noted above, the key is thinking in a multi-disciplinary way. People gravitate to what they know; thus the old adage that “if you have a hammer, everything you see is a nail.” Think more broadly about an issue, and a more interesting solution to the customer’s problem may present itself. (Scenario focused engineering works this way too.)
- It is partially about thinking differently (as discussed above), but also about seeking the right counsel. There is an interesting truth about hard Presidential decisions. The more sensitive an issue, the fewer the number of people consulted (because of the sensitivity) and the less informed the decision. Obtaining good counsel – while avoiding the pitfall of paralysis (either because you have yet to speak to everyone on the planet or because there was not universal consensus on what to do next) is the key.
- (1) What is the right thing to do? (This may be harder than it looks because the different customers described above may have different interests. For example, a costly solution may be good for customers but bad for shareholders. A regulatory solution might be convenient for governments but stifle technological innovation.) (2) What unintended consequences might occur? (The best laid plans….). (3) Will the solution be achievable?
- I need quiet time; time to think deeply.
The big things that really stand out for me are using the customer as the North Star, balancing with multi-disciplinary perspectives, evaluating multiple, cascading ramifications, and leading with vision.You Might Also Like
Early on in my Program Management career, I ran into challenges around cutting scope.
The schedule said the project was done by next week, but scope said the project would be done a few months from now.
On the Microsoft patterns & practices team, we optimized around “fix time, flex scope.” This ensured we were on time, on budget. This helped constrain risk. Plus, as soon as you start chasing scope, you become a victim of scope creep, and create a runaway train. It’s better to get smart people shipping on a cadence, and focus on creating incremental value. If the trains leave the station on time, then if you miss a train, you know you can count on the next train. Plus, this builds a reputation for shipping and execution excellence.
And so I would have to cut scope, and feel the pains of impact ripple across multiple dependencies.
Without a simple chunking mechanism, it was a game of trying to cut features and trying to figure out which requirements could be completed and still be useful within a given time frame.
This is where User Stories and System Stories helped.
Stories created a simple way to chunk up value. Stories help us put requirements into a context and a testable outcome, share what good looks like, and estimate our work. So paring stories down is fine, and a good thing, as long as we can still achieve those basic goals.
Stories help us create Cuttable Scope.
They make it easier to deliver value in incremental chunks.
A healthy project start includes a baseline set of stories that help define a Minimum Credible Release, and additional stories that would add additional, incremental value.
It helps create a lot of confidence in your project when there is a clear vision for what your solution will do, along with a healthy path of execution that includes a baseline release, along with a healthy pipeline of additional value, chunked up in the form of user stories that your stakeholders and user community can relate to.You Might Also Like
Organizations like to have clear role definitions, clear processes outlined and clear documentation templates. It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect. ScrumMasters should be anti-bureaucracy. Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.
To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.
- None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).
- Obstacles or impediments “backlog” - a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing. These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
- Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
- Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams. Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed. Outsiders are not welcome to the retrospective.
- Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks. This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
- State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).
NOT RECOMMENDED (BUT SOMETIMES NEEDED):
- minutes of Scrum meetings
- process compliance audit reports
- project administrative documents (e.g. status reports, time sheets)
- project charter (often recommended for the Product Owner, however)
- project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
- any sort of up-front technical or design documents
The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach. There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
- improving how the team uses Scrum
- helping the team to remove obstacles and impediments to getting their work done.
Delivery teams manage and deliver value supported by the tool user stories. These teams tell stories about who, what, why, and acceptability using standard form, “As a <persona>, I want <capability> so that <delivered value> occurs,” and behavior acceptance form, “Given < context>, when <action occurs>, then < consequence >.” These stories form the foundation of repeatable delivery and management of value.
While these forms support delivery team conversations well, they are inadequate to support the richer conversation needed by executives to manage investment and value. What forms the basis of these stories? How do we tell stories about delivering product value to our customers and delivering investment value to our organization?
Developing contextual story-telling focuses on the kinds of conversations the product managers, product owners, business owners, and executives have when they meet to operate and run the business. We listen to these stories and then use existing canvas templates to develop contextually relevant canvas designs. These canvases become the fabric used when beginning new stories, and continuing old stories regarding business strategy and tactics.
To develop the canvases, we need to listen to these conversations and stories and develop a sense for topics and content of the strategic and tactical conversations. These questions form the thinking needed to create a first draft tool that can be used to bookmark a conversation.
- What is the focus of each conversation?
- What are the conversational topics?
- What is the airtime of each topic?
- What is the passion level of each topic?
- In what order are the topics discussed?
These conversations may cover the following topics:Product Focus Areas
- Problem Space
- Solution Space
- Delivery Channels
We also discover that there are quite a few topics of conversations that don’t quite fit into the strategic bucket and sound more like high-level tactics. This turns out to be the work of the executive and product teams. Those topics of conversation may cover the following:
- Leader or Owner
- Big Picture
- Solution Details
The key is identifying the key conversations in meetings and formulating a canvas around those topics. A common mistake is to use an existing template and force the conversations to conform to that template. Although tempting, this mistake leads to disengagement and abandonment of the canvas and tools. The tools are there to support the way the team works, not to force conformity to industry luminary ideals. These canvas designs will evolve as the organization improves its prowess at portfolio management.
The following is an example of the conversations important to an executive strategy canvas we recently developed:
- Vision: Why pursue the strategy?
- Customers: Who wanted it achieved?
- Problem Space: What problems were they facing?
- Solution Space: What solutions would work?
- Value to the Customer: What epic stories would the customers tell?
- Metrics: What dials would move in the near future?
- Value to the Organization: How does the organization benefit?
These topics of conversation are arranged canvas style so that new conversations take place to create a new strategy or so that existing conversations can be continued to check in on existing conversations. You may notice that while the range of topics available, this group focused around the customer. This is very clear by the absence of cost and revenue as a significant part of their strategic conversation.
The executives also had conversations about investments they would make in the strategy. The topics of that conversation included the following areas:
- Goal: What is the desired outcome?
- Metrics: What are the measures of success?
- Customers: Who wants this?
- Big Picture: What is the big picture?
- Solution Details: What are possible solutions?
- Alignment: How does this align with the strategy canvas?
We also listened for how the executive team intended to use the tools to support their work. They decided to use the canvases in the following ways:
- 90 Day True North
- Investment Decision Filter
- Organizational Strategic Alignment
- Organizational Transparent
- Tactical deliverable investment designed to experiment with some part of the strategy
- Flow in a work system
- Regular discussions about discovery, validation, delivery, and evaluation
We have created a glimpse of a strategic and work alignment system focused on portfolio management. The system and artifacts was developed based on the context of the organization and the thought leadership in the industry. The key point to take away is that context matters when developing the artifacts executives use to manage their strategic and tactical portfolio work.
I have discovered the truth of this with Agile. The one time in my whole life I truly surrendered my attachment to Agile, it resulted in a beautiful transformation starting. But most of the time I was too attached to Agile to let it go.
This post is about how we may accidentally harm organizations with Agile and how we can let go so that we may succeed.Accidentally Harming Organizations
Here is the basic thinking:
- Agile is a good thing.
- We can help companies if they use Agile.
- Let’s do it!
Agile for me is basic common sense – this is how to get stuff done. BUT Agile does not work in most organizations due to culture. Sure there are some small pockets where Agile just works but this seems to be relatively rare – especially now that Agile has crossed the chasm.
Agile is a different culture from most companies, so the first trap is to accidentally introduce organizational conflict. That’s why I wrote “An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture” – to help people notice this trap and avoid it.
My suggestion was to look at two options:
- Adopt elements of Agile that fit with the culture.
- Transform the organizational culture.
For many, option 1 is like giving up on Agile since they key part of it is missing so many Agile folks don’t like that option.
Increasingly Agile experts go for option #2 instead: Transform the Organizational Culture. I sure did. I set out to learn how to change organizational culture. And I figured it out. But there was a problem. A big one.Trap #2 Attempt to Transform to Agile Culture
The core of the problem is that Agile is not an end in itself. It is means to an end. Some common goals (ends) are: a quality product, time to market or engaged staff. The problem is not that Agile doesn’t help with these goals (it certainly does), the problem is that people confuse Agile as the goal and often act in ways that undermine the real goal. We see Agile being used as a Whip or a Shield. That is why it’s a good idea to Stop Agile Initiatives. A better alternative to an Agile initiative is to have an initiative around the real goals. One way to get at the real goals is to run a workshop to clarify why people want Agile.
It is a good thing to change culture in service to what organizations really want for themselves. A specific culture is not a goal in itself, but a means to accomplishing something. We may seek a culture of engagement and innovation not for itself, but because we want our organization to thrive in a competitive landscape.
There are many many beautiful, productive organization cultures all over the world that have nothing to do with Agile. The implication is that there are many ways to get to a place where people love what they do. If we really want to help people, then the best move is to work with them to evolve a wonderful culture that is right for them. And for sure it will not be exactly “Agile Culture” (especially since this is not completely precise). If it is a progressive culture, it will likely be Agile-compatible and using Agile to get benefits will be very natural. It’s a win – win.
Agile Culture should never be a goal. If it is, we will likely just cause harm.Let Go of the Outcome to Find Success
Here is my secret to success: Let go of the outcome.
I wrote a couple of years about about how leaders have a choice between the red pill (deeper reality) and the blue pill (surface reality). I stated it like I gave people a choice. But I didn’t. The only choice I wanted was the red pill. I wanted so much to help the people in organizations I pushed for the red pill. The truth is I cared so much for the outcome which I assumed was best that I didn’t really give a open choice. In subtle and more obvious ways I was attempting to coerce leaders into taking the red pill. Ooops! Coercion is not any part of Agile, but here I was wanting my outcome for others. And it is not just me. I have talked to dozens of professional coaches and this is pandemic in the Agile community.
The solution is obvious. If we really want to stay true to Agile values, we can’t coerce. We have to let the people (especially management teams) make their own decisions and their own mistakes. We have to help them find and walk the path that they choose. This means letting go of the outcome. This means letting go of Agile.
This business of learning to let go is not new. In fact, letting go of attachment is a central message of Buddhism.
To close, the one time I fully let go of Agile it came back in such a beautiful sustainable and lasting way. Time to rinse and repeat.
“If you want Agile very, very badly, let it go free. If it comes back to you, it’s there forever. If it doesn’t, it was never meant to be.”
(Stay tuned for a follow-up post on Agile as a means of creating freedom by Olaf Lewitz.)My Apology
I helped a lot of people see Agile as a culture system and learn how to stop causing accidental conflict.
Unfortunately, I also energized a lot of people to seek culture change with the goal of growing Agile. As clarified in this blog post, this was a mistake. I am sorry.
What’s the alternative? For those who want real change, let’s help them meet their organizational goals with culture transformation and let Agile come willingly.
- Agile is NOT the Goal (Workshop) Here is how to run a one hour workshop turn...
- Guy Laurence – Culture Change Through Renovation Guy Lawrence – former CEO at Vodafone – tells of...
- Stop Agile Initiatives! I am sick to death of Agile Initiatives because they...
Related posts brought to you by Yet Another Related Posts Plugin.
Do you have projects where you can’t predict an end date? These tend to be a job search, a change project, and with a tip of the hat to Cesar Abeid, your life. I like to call these “emergent” projects.
You might prefer to call them “adaptable” projects, but to me, every project has to be adaptable. These projects are emergent. You need to plan, but not too much. You need to replan. You need to take advantage of serendipity.
My column this quarter for projectmanagement.com is Applying Agile to Emergent Projects. (Free registration required.)
At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article about it together with coach-colleague Kristian Lindwall.
Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.
„Aber ich habe ja so viele Dinge, die ich jeden Tag erledigen muss – da kann ich doch gar nicht ständig einen Zettel schreiben?“ So oder so ähnlich lauteten in einem Projekt die Kommentare, als wir begannen, ein Taskboard auf Management-Level einzuführen. Ich kann das gut nachvollziehen, meine Taskliste von heute sieht so aus:
- Kunde: Backlog mit N.N
- Kunde: Meetings mit N.N. und O.O.
- Kunde: Daily Scrum
- Kunde: JIRA Training – Setup
- Kunde: Arbeit an der Darstellung zur Meeting-Struktur
- Marketing: Review Pressemitteilung Agile Bodensee
- Blog: Brauchen wir noch Daily Standups?
- Blog: Die Generation Y – “Wir wollen unser Leben genießen”
- JIRA Playbook an alle geschickt
- Travel: Flüge für die nächsten drei Wochen gebucht
- Blog: Das Taskboard auf Management Ebene – Warum eigentlich ein Taskboard?
- Intern: HR-Backlog und Unklarheiten besprochen
- Sales: einen Kunden angerufen, und um Feedback gebeten
- Travel: Ersatzreisedokument am Flughafen Berlin besorgt
- Familie: Meine Frau vom Flughafen abholen
Soll ich da wirklich jedes Mal einen Zettel schreiben oder meine kleine 1h-Aufgabe in einem Tool wie JIRA oder Trello ablegen? Ihr könnt euch denken, dass ich vor mich hin schmunzle. Denn während ich das hier schreibe, habe ich ja gerade die Einträge für ein Taskboard erstellt. Das nun auf Klebezettel zu schreiben, oder vielleicht sogar in ein Tool wie JIRA einzutragen, ist sicher genauso möglich. Es ist ein wenig komplizierter, aber nicht sehr. Wer mehr dazu wissen will, wie man das effizient macht, dem sei Personal Kanban empfohlen. Und doch: Management-Teams wehren sich zunächst, diese wenigen Einträge zu machen. Also mache ich sie in meiner Rolle als ScrumMaster in der ersten Woche für das Management-Team. Auf diese Weise sehen sie auch, wie viele Dinge sie erledigt bekommen und wie viele Dinge sie abseits des Üblichen noch so machen.
Ist Euch das auch schon mal aufgefallen? Die meisten Manager machen unendlich viele ad-hoc-Aufgaben, sie stecken zu tief im Tagesgeschäft. Ständige Störungen, permanente Meetings und sie werden von E-Mails überflutet. Konzeptionelles Arbeiten oder gar Führen ist fast nicht möglich. Ich habe schon öfter geschrieben, dass Henry Mintzberg das schon vor Jahren festgestellt hatte:
“Folklore: The manager is a reflective, systematic planner. The evidence of this issue is overwhelming, but not a shred of it supports this statement.
Fact: Study after study has shown that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to action and dislike reflective activities. Consider this evidence: Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour. A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds. The work pace for both chief executives and foremen was unrelenting. The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work related, and ever-present subordinates seemed to usurp any free moment.“
Trotzdem es ist etwas anderes, das täglich in der Praxis zu sehen. Management-Teams haben also nicht wirklich Zeit, das große Ganze zu sehen. Sie kommen gar nicht dazu, sich um die vielen wichtigen Aspekte zu kümmern, denn sie sind total beschäftigt. Gesehen haben wir ein ähnliches Phänomen in der Vergangenheit bereits bei skalierten Scrum-Implementierungen. Dort mit den Product Ownern konzeptionell zu arbeiten, in Ruhe ein Backlog aufzubauen, vielleicht zwei Tage intensiv daran arbeiten, eine wirklich ausgearbeitete Story Map zu erstellen – das war aufgrund der vielen Störungen gar nicht möglich. In diesen Kontexten hatten wir aber die Schwierigkeiten auf die Komplexität der Produkte geschoben.
Was mir jetzt als ScrumMaster eines Management-Teams auffällt: Es fehlt die Priorisierung. Alles scheint gleich wichtig, als wäre es in einem größeren Unternehmen nicht auch möglich, sich zu fokussieren. Gleichzeitig ist das nicht so viel anders als das, was die Arbeit von vielen Entwicklungsteams in der Vergangenheit gezeigt hat.
Wie kann ich meinem Management-Team dabei helfen: Mit einem Taskboard. Es macht transparent, wie viele Dinge erledigt werden müssen. Damit kann man daran arbeiten, die wirklich wichtigen Dinge zu tun und sich gegenseitig zu helfen. Jetzt brauche ich nur noch Geduld – wie bei allen Teams dauert es ein wenig, bis die Idee des Taskboards angenommen wird.
Henry Mintzberg: The Manager’s Job: Folklore and Fact, HARVARD BUSINESS REVIEW: March/April 1990, p. 163 – 176
- 5 Minutes on Scrum | Transparency
- Prioritäten | Product Owners Tools
- Product Backlog | Templates | Scrum Tools
So you want your organization to change? Then you just might need a change artist. What is a change artist? A change artist is someone who leads change in an organization by sharing example and by influence using visualization. That is to say, a change artist will not mandate or coerce in order to introduce change, but rather they will begin with themselves and demonstrate their own change – thereby providing the example and the potential motivation for others to seek similar change in themselves. The visualizations help to share the story – you need the artist.
I think that people who are able to express their ideas through pictures are particularly well suited to creating the kinds of compelling visualizations that help convey what change might look like. They don’t have to be technically competent as an artist. Just good enough to draw stick figures and tell a story. Its really not that hard once you stop worrying about what people think.
Can we create people like this? Or are they born to it? I don’t think the hard part is the art. Anybody can do that. It’s how they approach change that matters most.
Perhaps there are organizations that would be more receptive to change initiatives that aggressively use visualization techniques. I can’t help imagine that visualization can add a compelling element to any transition engagement. I’ve not see much evidence of that sort of approach on agile transition engagements that I’ve been on. I’ve seen the power of what a simple drawing can do to draw people together and generate discussion. Using some sharpies and some butcher paper I can start a conversation that will continue long after I’m gone. I’ve seen it happen. There isn’t a text document in the world that can compete with a good picture. I’m not talking about Visio diagrams either. There is a quality to the hand drawn diagram that invites people to engage in a way that no sterile electronic diagram ever will. I’ve held two versions of the same diagram, one hand drawn and one electronic, side by side and the preference is almost always unanimous – the hand drawn version wins. I think the magic lies somewhere in the the errors and mistakes in the drawing. They must serve to remind us that we are human. Perfection isn’t necessary, and in fact may be counterproductive.
That’s who I want to help me change the world. Combine the passion for change and the art and I’ll give you a change artist.
Filed under: Agile, Coaching Tagged: Agile, artist, change, change artist, Transition
SAFe relies on transparency and objective metrics to measure and improve software development outcomes. And as we work exclusively at scale, tooling is, of course, required. Last week, Microsoft announced their support for SAFe in Team Foundation Server. As you can see in that post, TFS provides an at-a-glance interface that provides team metrics, measures capacity, and visually tracks progress in the context of SAFe best practices. InCycle’s Barry Paquet (a Scaled Agile Partner) provides a further description of how TFS and SAFe can be used at the team and program level:
“For example, at the program or feature level, we measure progress against what we have accepted or observed (think sprint review and system demo). Moreover, we can report against planned features and percent (%) complete. Given that TFS doesn’t provide this report OOTB, the team at InCycle developed a TFS report to illustrate what’s possible and demonstrate how TFS can be used to support scaled agile or SAFe. Below is a sample report we created to support our SAFe customers.”
You can read more about TFS and SAFe on Barry’s blog entry, “Scaling Agile and SAFe Metrics with TFS,” and read Microsoft’s post here. Thanks to Barry Paquet, Incycle Director, ALM Practice (West Region), for his contributions, and to the folks at Microsoft who authored this report, especially Gregg Boer, SPC, and the product owner for the Agile Management experience in TFS.
Some sample pics below:
Last week InfoQ published an interview that I gave with Katherine Kirk at Agile2014 in which we talked about the Kanban Canvas, why I came up with it, and how I use it. Unfortunately I can’t embed it here, so please use the following link to find it:
- Our target date is March 2015, the alternative is June, 2015.
- The open space will be held on a Friday and Saturday.
- We want to hold a Product Owner Masterclass, one or two days before the Open Space event.
- The audience is experienced Product Owners, Agile Product Managers and Lean Startup Practitioners. This is by practitioners for practitioners, not for beginners.
- The event is not profit oriented.
- We are going to get together on skype roughly once every to two weeks to take the event forward.
We have created a backlog to organize our work: Our first objective is the find a leader for the MasterClass, reserve some dates, and start working on the website. After that, priority will be the venue...
Several other people expressed an interest in helping to organize, we will welcome them as they confirm their participation :-)!
Are you interested in participating (or even helping out?) Join our google group to stay informed!