Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. You see, if you specified things enough, and structured things enough, everything would all work out.
I thought I was the only idiot that structure and specification didn’t work for. Why did I have to iterate and increment?
At my first job, we had design reviews and code reviews. I learned a lot. I worked on a government contract, and the government mandated those reviews. They were useful, and they were supposed to be a silver bullet. Because we implemented features (yes, back in the ’70s, we implemented features), the reviews were helpful in the small.
But, I worked on a program. There is just so much design by contract can do for a program. I was in Boston. I had questions for my counterpart in New Mexico. I was not allowed to talk to that person. (To this day, I don’t know who that person was. That person was part of another subcontractor.) I had to send my questions up through the project management layers to the program team and down the other side. My questions never did get answered. I left that company before I knew if my code worked with the entire system.
I transitioned into project management, program management and people management. I have seen my share of fads, bullets, and fixes for the software departments.
As a director in the early ’90’s I got sent to TQM school (Total Quality Management). My company thought it would change the way we managed, and revolutionize our organization. It would be our “silver bullet.” I’m pretty sure those were somebody’s words. They weren’t mine.
I got a certificate for my five days of intensive training (powerpoint and calculations). I might still have it somewhere.
I became excellent at calculating many costs: the cost of quality, the cost of not doing things right, the cost of technical debt, even what we might consider the cost of delay. I dutifully explained these costs to my senior management. Was I able to persuade my company of the cost of not doing the right thing, even though I was a middle manager, a program manager, and had been TQM’d?
No. My management was too concerned that doing things “right” would prevent us from making money. I had data—yes, data—that proved them wrong. But their belief systems overcame my data.
Later, after I started my consulting business, many of my clients fell into the ISO 9000 and the CMM/CMMI quick fix/silver bullet traps. The ISO joke made the rounds: “You could specify a cement life jacket with ISO, as long as you define the right process for creating it.” Well, no. But the jokes still persisted. (Many people find value in ISO. Some do not.)
And, with the CMM/CMMI? Oh, my clients had binders full of documentation, but they weren’t releasing software. They hired me on the side, because their silver bullet of CMM/CMMI process wasn’t working. Somehow, my approaches of timeboxes and increments, and iterations, and thinking about their projects was. (Many people find value in using CMM/CMMI. Some do not.)
We have no silver bullets in software.
We have difficult problems to solve. We must think about our approaches, each and every time. We must consider our context. That why I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because every single project is unique. That’s why I’m writing Agile and Lean Program Management: Collaborating Across the Organization. That book is a principle-based approach to program management, to scaling agile past one or two teams. Not a one-size fits all approach to program management.
And, because we have no silver bullets in software, and because we have no quick fixes, my management myth this month is We Need a Quick Fix or a Silver Bullet.
It’s very tempting to think that transitioning to agile might be a quick fix or a silver bullet. Transitioning to agile or lean might help you. It won’t be quick.
Any transition is a change. Change takes time. Change is learning. Developing software is learning. You can help yourself learn faster with some approaches: make value obvious instead of tasks, get feedback often, visualize your work, etc. For many of you starting your agile journey, these are cultural changes.
The more you challenge the culture, the longer the change takes because people need to learn what to do and how to work. Cultural change is not a silver bullet. It is certainly not a quick fix.
Have you heard the story of the Brave Little Taylor? Here’s a refresher:
So one day this little guy kills 7 flies with one mighty blow. He crafts for himself a belt with “7 in One Blow” sewn into it. He then proceeds through various feats of cleverness to intimidate or subdue giants, soldiers, kings and princesses. Each one, in their own ignorance, misinterpreting what “7 in One Blow” actually refers to. It’s a classic for a number of reasons:
- It’s a story about mis-communication: Not one single adversary has the wit to ask just what he means by killing “7 in one blow”
- It’s also a story about using one’s cleverness to achieve great things. You have to love the ingenuity of the little guy as he makes his way adroitly past each obstacle.
- It’s a story about blowing things way out of proportion. Each of the tailor’s adversaries manages to magnify the capabilities of the tailor to extraordinary, even supernatural levels.
I’m thinking I might have to get a belt like that and wear it around the office. A nice pair of kahkis, a button down shirt, and a big belt with the words, “7 in One Blow”. Given how prone we all tend to be to each of the foibles above, I’m sure it would be a riot.
A QA guy might see my belt and say, “Wow! He killed 7 bugs in one blow!”
Maybe a project manager might see it and think, “This guy is so good he finished 7 projects all at once!” Or maybe the HR rep says, “Did he really fire 7 people in one day?” Or the Scrum Master who thinks, “That’s a lot of impediments to clear out at once!”
The point is that we make up these stories all the time. We have stories in our heads about our team mates, “Did you hear about Joe?” our managers, and their managers. Sometimes it seems as though we all have these distorted visions of each other. And perhaps we do. We need to get better at questioning those stories. We need to cultivate more of a sense of curiosity about the incomplete knowledge that we have of each other. That belt would be my reminder. I might have to buy one for each member of my team.
Of course the other thing that the belt can remind us of, is to use our own innate cleverness to help get what we need. When we are wrestling with the corporate challenges, we all too often tend to try and brute force our problems and obstacles. We need to be a bit more like the Little Tailor and manipulate the world around us with some cleverness. We all have it to one degree or another, and Lord knows we need all the cleverness we can get. Good work is full of challenges and you don’t want to take them all head on or you will end up like an NFL linebacker – brain damaged. Instead, we need to approach some things with subtlety. There is just as much value in not being in the path of a problem as there is in tackling things head on. Like the Tailor, we need to recruit others to achieve our objectives.
Finally, we really must stop blowing things out of proportion. Nobody cares about our methodology. You want to know what my favorite kind of pairing is? Lunch! We need to lighten up a bit. Working your way through the dark corporate forest, you can either play with what ever it brings and gracefully dodge the risks, or…you can get stepped on.
Filed under: Agile, Coaching, impediment, Process, Teams Tagged: cleverness, fool, Process, Teams, wit
In Part 1 of this four-part blog 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:
3. Agile Methods and Environments
6. Value Chain (see Tables 1 through 4 of Part 1 of this blog series)
Each scaling agile parameter can assume one or more values from a range of values. This comprehensive (but by no means, complete or exhaustive) list of 25 scaling agile parameters suggests that the agile scaling space is complex and rich with many choices. Each organization or 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, in Part 1, I also clarified that “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 radically different from MAXOS. In this part of the series, I will compare and contrast SAFe vs. MAXOS in some depth.
Briefly, here are the key highlights of SAFe. Details can be found at Scaled Agile Framework:
- SAFe requires a “Portfolio, Program and Teams” hierarchy for a large-scale agile project.
- Each team must be a cross-functional Scrum team and may follow many XP practices.
- Epics at portfolio levels are managed as a Lean/Kanban flow. Epics are broken down into features that can be completed in a single release cycle at the program level; each feature is broken down into stories that can be completed in a single sprint at the team level.
- All teams in a release train of a program must follow the same lock-step sprint cadence (typically two weeks).
- Release train planning requires all team members (typically up to 150) from all teams in a program to hold two-day-long release planning meetings in person, which entails a substantial effort and complex logistics.
- Release cycles are typically eight to 12 weeks long.
- Software is developed on sprint cadence, and released on demand (but cannot be released faster than the sprint cadence).
- Considerable time and effort is spent in various ceremonies: sprint planning, sprint review and sprint retrospectives, release train planning across multiple teams, release review and release retrospectives, etc.
Briefly, here are the highlights of MAXOS. Details can be found in Andy Singleton’s Agile 2014 presentation.
- MAXOS is the scaling approach for “Continuous Agile.” Continuous Agile combines Kanban Agile task management with continuous delivery code management.
- MAXOS requires a number of (almost) independent service teams.
- Services have well-defined APIs, are loosely coupled, and have minimal dependencies among them.
- Each team operates with Lean flow. Applications are rapidly composed of a group or a network of services.
- Each team is developer-centric (not cross-functional) and highly empowered.
- Code is continually integrated in a single code base across all teams.
- Code is continually tested with automated tests (unit, acceptance, regression, etc.) by firing off as many virtual machines as needed in a cloud-based environment.
- Any dependency issues across teams are immediately resolved via rapid team-to-team communication. For rapid team-to-team or member-to-member communication, tool support is essential. VersionOne provides excellent communication and collaboration among team members.
- The typical ratio of developers to testers tends to be 10:1, as teams are developer-centric and developers do most automated testing. There are no separate QA teams. QA testers are called as needed for their expertise by developer-centric teams.
- Each empowered, developer-centric team decides when to release its code (not decided by QA testers or product managers!). MAXOS claims that this policy rationally aligns the interests of developers with consequences of their release decision; poorly written, poorly reviewed, or inadequately tested code may mean “no weekends” or “No Friday evening beer” for developers!
- All features or stories have switches (togglers) that the product owner (called story owner) decides to turn on (unblock) or turn off (block) based on the market needs.
- Code released in production is extensively supported by automated user feedback collection, measurements and analysis that result in actionable reports for product management.
- Automated feedback from production environment is also used directly by developers to immediately fix problems.
- Meeting time is minimized by “automating away” management meetings, and removing or reducing other Scrum ceremonies. For example, sprint and release retrospectives are replaced by periodic “Happiness Surveys” and taking actions based on those surveys.
Because of these fundamental differences between SAFe and MAXOS, they represent radically different approaches to scaling agile. The contrast between SAFe and MAXOS is breathtaking, and its implications are worth understanding. Tables 5-10 present the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.
These six tables (Tables 5-10 below) follow a specific color legend described below:
Are your agile projects closer to the SAFe Sweet Spot or the MAXOS Sweet Spot?
Or are your projects closer to the SAFe Challenge Zone or the MAXOS Challenge Zone? Or are you in a situation where neither SAFe nor MAXOS will serve you unique agile scaling needs? If you are exploring the use of LeSS or DAD framework, I would encourage you to use the list of 25 scaling agile parameters to identify the Sweet Spot, Challenge Zone and Unfit Zone for LeSS or DAD (as I have done in Tables 5-10 for SAFe and MAXOS). Then determine if your projects are closer to the Sweet Spot or Challenge Zone of LeSS or DAD.
Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly
Stay tuned for these future parts of this series:
Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS
Part 4: Scaling Agile Your Way – How to develop and implement your custom approach
Why did I stay so long? – 13 years. Because I loved working with that team. It was a rare thing – A real team who each day learn’t from each other, continuously supporting one another.
But there was something I couldn’t change – We grew into each other and lost touch with the outside. I wanted to open us up, expose us to the diverse and rapidly changing world, to alternative perspectives and views. I failed, hierarchy or fear got in the way, I’m not sure.
And then I got a taste of what I’d been missing – Working directly with a client who I could sit down with, we’d discuss each others needs with no proxy. We built a supportive relationship, and learn’t from each other and built some software that surprised everyone, there was no going back
And I realised that there is a bigger team out there – So I’m off freelancing, to find the freedom to work with different people each day, and learn from different people each day. Developers, Designers and most importantly opened minded people with needs that I can meet. A team that continually changes, diversifies and grows.
Self-organisation without the boundaries – how’s that going to work out?
Making the first steps in setting up a scaled framework with agile teams in a complex environment does not always allow to set up teams by the book. Rather than dragging people from their current activities and having everybody dislike agile, before we have even really started using and living it, I try to make compromises.
By working in very short sprints of one week, I allow team members to switch between teams with every start of a new sprint. For the one sprint however, they commit to be fully engaged in the sprint backlog and team activities of the one single team. Product owners can plan with the team members’ knowledge for some sprints. The team can make the experience i.e. every other sprint what they are capable of on their own and build confidence and see where they still need more knowledge transfer and help. Multi skilled team members can learn step by step to let go their „baby“ and still be engaged in the field of the product.
An alternative in the same situation might be:
If there is a huge overlap in skills needed for one and the other team or part of the product, try putting the teams to either being one team. Build rather large teams in the beginning covering two backlogs (should not be more). Creating a team backlog rather than a product backlog allows the others to learn about the other parts of the product by just being in the team and does not force team members to leave one or the other part of the product without their experience and knowledge.
Forcing the teams into a decision for one or the other might lead to the opposite – double work by only making one part transparent or frustrated „left alone teams“ and multi skilled team members with feelings of guilt.
What else have you tried?
- Sprint Planning with geographically dispersed teams located in different timezones
- Scrum Teams – No Part Time!
- How internationally distributed Teams can improve their Sprint Planning 2
“Going against men, I have heard at times a deep harmony
thrumming in the mixture, and when they ask me what
I say I don’t know. It is not the only or the easiest
way to come to the truth. It is one way.” – Wendell Berry
I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right.
We sat down and had a talk. It turns out he’s tired and cranky and seen this all before. I told him I can relate. We agreed that we’ve both done enough stupid to last a couple of lifetimes. No arguments there. He knows what he doesn’t like – me too! After a little debate, we both agreed we don’t give a damn what you think.
So we decided it was time to write a manifesto. That is
We grumps have come to value:
Speaking our mind over listening to whiners
Working hard over talking about it
Getting shit done over following a plan
Disagreeing with you over getting along
That is, while the items are the right are a total waste of time, the stuff on the left is much more gratifying.
Filed under: Coaching, Humor, Scrum Tagged: bad attitude, grumpy, Humor, Scrum, Scrum Master
A Burn-Up graph is simply a stack graph showing the total amount of work the team has in their product backlog over a number of Sprints. I’ve used a variety of different Agile Burn-Up graphs over the years. Here’s one of my favourites:
I created this with Excel while working with an insurance company based in Mayfield, Ohio. In this article I’ll show you how to create something similar using Google docs.Understanding the Burn-up Graph
This graph (above) shows the total amount of work in the product backlog (top line of the graph), the amount of work completed (yellow) and the amount of work remaining (red and blue). The amount of work remaining is divided into estimated work (red) and un-estimated work (blue) which we guessed at using a very course scale. At the start you can see the total amount of work on the backlog increase until the fourth Sprint as indicated by the rising top-line of the graph.
After the fourth Sprint the team decided that they needed to start breaking down the un-estimated work into small User Stories and so you can see an increase in the red area of the graph and a decline in the blue. We continued to complete work, so the yellow area continued to grow.
By Sprint 12 we had completely broken down all the large bodies of work and had a well refined backlog.Creating the Graph in Google Spreadsheets
The Google graph that I’ve created is a little bit simpler than the graph above. It shows the total amount of work in the product, the total amount of work added to the product backlog, and the total amount of work completed. You can get the Google Spreadsheet document to create this graph here.
This is what it looks like:
The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. To start using this graph,
- Make a copy of the Google Spreadsheet
- Enter the total of the teams estimates in the product backlog into the first column of Series A.
- There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
- The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.
You can get the Google Spreadsheet document to create this graph here.
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 Skalierenden mächtig schiefgehen kann, 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
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.
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
Some sample pics below: