Best known for being a global leader in navigation and mapping products, TomTom is also the mapping provider for Apple Maps, and the maps and traffic data provider for Uber drivers in over 300 cities worldwide.
An interesting thing about TomTom’s SAFe adoption is that it started in 2012, which gives us a view into a fast-growing company that has worked within the Framework over a five-year period. There were some early wins (see quote below), as well as challenges and learnings, which they summarize in detail as the “Good,” the Bad,” and the “Ugly.”
“There is no doubt in my mind that without SAFe and Rally we would not have launched this in only 140 days. It is also our best new product ever.”
Re: TomTom GO500 sold in 45 countries
Before adopting SAFe, TomTom’s challenges had a familiar ring:
- Organized as waterfall projects
- Many projects working in all parts of the code with minimal module or component ownership
- Many releases are months-quarters late
- Multiple code lines and branches
- Negligible automated testing & no continuous integration
- “downstream” teams spend 3,4,5 months accepting the code and often changing it
- Poor visibility and facts-based decision-making
Once they decided to adopt the Framework they got it right from the start, providing SAFe training for their CTO, SVPs, and 50 CSMs and CPOs. Today, SAFe is practiced by all of TomTom’s large product teams representing navigation software, online services, map creation and sports software. That represents approximately 750 FTEs, with 200+ trained and certified in SAFe.
Some of the things I do on a regular basis is to facilitate workshops and events of different kinds - open space being one of them. I'd like to share with you a small trick-of-the-trade I have evolved while facilitating those: the Idea Mingle.
I really like the energy the open space format brings to the discussions. People are familiar with the format of participating in a discussion, and also shy or introvert people are given room to participate in a comfortable way.
However I have sometimes found that the initial part can be a little bit slow, the part where you pitch topics for discussion. This is seldom a problem with groups that are used to open space. Everybody involved understands what "level of ambition" is needed for posting a topic - acknowledging the fact that the really interesting part will be the discussion that unfolds around the topic. However, with groups unused to open space I have found that people can get shy. Posting a subject might seem pretentious: "what have I that everybody else should find interesting". So, when asked at point blanc "what do you think should be discussed", their mind goes blank.
To give the "pitching phase" of open space a soft start I do a "Idea Mingle" that gives people a chance to evolve their interests into discussion topics before it is time to post them. It is a "mingle party" with the purpose of distilling ideas for discussion, thus "Idea Mingle".
The instructions I give are simple:
- Look around the room and lock eye contact with someone you have not yet spoken to today.
- On my call, pair up
- Introduce yourself by saying "Hi, my name is …" to each other
- Continue by saying "I think it would be interesting to discuss something around …" and fill in a field. It does not need to be specific, it can be broad or vague, e g "something about testing".
- Have a short discussion digging a little bit into each others interests
- After two minutes I will break the discussion
The basic idea is that the one-on-one-format is a more comfortable format for talking about an idea than to do it in public. Speaking to a stranger is still an uncomfortable situation for a lot of people, me included. However, the short format and the very focused scope makes it managable - as opposed to the usual mingle setting "find a stranger, talk to him/her, and be nice and interesting for an undefined period of time". Just the thought gives me creeps.
Now, after the first one-on-one, all participants have bounced one of their interests on another participant. Almost certainly they have received acknowledgment that "it is an interesting field" and most have probably got feedback of the form "testing is interesting; I myself is interesting in how to use automation to make it easier".
OK, so people have now got a slightly refined idea about an interesting discussion. But, for most of them it is not yet ready to publish as a open-space-discussion-subject.
Allow me a slight detour.
At a workshop class with Lyssa Adkins and Leslie Stein there was a small knowledge-sharing exercise. During that exercise I was given the task to explain "sprint retrospective" to a few of the other participants. I was given literally no time to prepare, and my presentation time was limited to five minutes (if I remember correctly). It was really awkward.
Immediately after the first group of listeners, I was sent a second group of a few class-mates, and had to explain to them. This time it was less awkward. A third group was sent to me, and this time I basically knew what I should say or not. The fourth time, the explanation went smooth. So, in four iteration a very awkward rambling refined into a pretty crisp micro-presentation.
Back to open space and Idea Mingle.
The next instruction for Idea Mingle is: Now, lock eye-contact with someone else. And, we do the same thing once again.
At the end of this second one-on-one the idea might have evolved to "automation in testing, and the trouble with databases".
And then we repeat the one-on-one a total of four times.
At this point of time, many of the participants have received acknowledgement that they are interested in a field others also are interested in. And, a lot of them have refined an initial rough idea into something that is a more specific topic, e g "How to involve DBAs in test automation" - a topic ready for discussion.
And we are ready to form a queue for pitching topics to discuss.
Also, everyone is a little bit frustrated over that each one-on-one was interrupted just when they were getting started. So, all participants are eager to start the open space discussions.
Sometimes you find yourself in a weird predicament. A third party application that you’ve slapped nginx in front of insists on using internal IP addresses or ports despite your reverse proxy passing all the correct headers and other pieces required. Or maybe you’ve found yourself in the situation I found myself in last week where you have a third party internal application wanting to reference a file on a CDN. As luck would have it, that CDN has been deprecated and changing it requires rebuilding a jar where the script path is hardcoded and then repackaging the internal application that uses it. Long story short, we’ll soon be doing some yak shaving that could possibly take all day so how about we just use sub_filter instead and take a nap?Use It
Thankfully most stock builds of nginx include ngx_http_sub_module by default. Using it is actually simple enough, just slap the following directive under your location or server directive in nginx.conf.
And that’s it! You can also use regular expression here as well. sub_filter_once indicates whether nginx should apply the replacement once or repeatedly. One gotcha you might have is that by default this only works with mime types of text/html. If you want to modify the mime-types that subfilter executes on set `sub_filter_types` to the desired type.Give It a Try
I’ve put together a very simple demonstration of using subfilter for text replacement on Github.
An Exercise in Estimation: How many times can you fold a piece of paper in half & half again...
I do this exercise when beginning scrum teams start story estimation or task estimation. While this exercise has a unique twist that is very different than task estimation or story estimation - very few people foresee this aspect of the exercise, so it adds to the ah-ha moment.
Start by giving everyone a sheet of typical paper (8.5 x 11 in the USA - although the size just doesn't matter). Then tell them the exercise but ask that no one do any thing yet. First we will estimate. The task is to estimate how many times you could fold the paper in half and then again in half and repeat... without doing it what's your estimate of the number of folds?
Ask people to call out their estimate, write then on a board in no particular order or fashion.
Typical groups come up with estimate in the range of 5 - 20 folds.
If you want to do math... calculate an average estimate... or just circle the mean value.
Next have the group fold the paper in half and half again up to 4 times - then STOP and estimate again. Same as last time - call out the estimates and write them down on the board.
Next - fold the paper until you are done. How many folds did you get?
Now the debrief: What did you learn in this exercise? What happened to the estimates - why did this happen? What generalizations of estimating can we learn from this example? So when do we practice this re-estimation technique in Scrum?
For BONUS points - how many times do you need to fold paper to get to the Moon?
How Folding Paper Can Get You to the Moon
MythBusters episode: Folding a large piece of Paper in Half - What's the Limit
Moon Scoops - Buzz Aldrin on the things you do not know about the Moon Landings - Late Night
I regularly get questions on agile retrospectives, which I'm more than happy to answer. In this blog post I'll discuss the question that I got from someone who attended one of my workshops on valuable agile retrospectives. He was planning a retrospective with a new team, and wanted my advice on which exercise to use and how to facilitate the retrospective. Continue reading →
I’m a new contributor to the TechBeacon site. I have an article up, called Small-world networks: a lightweight alternative to SAFe for scaling agile.
Hope you enjoy the article.
Legacy is planting seeds in a garden you will never see grow. – Hamilton, The Musical
For those of us who are practicing Agile coaches, you know the truth in this quote. We are often gifted with a short window of time to be a catalyst for change and create enough of a spark to cause a meaningful transformation to the DNA of an organization. No pressure!
With so much riding on our ability to catalyze transformation, how do we know if we’re really having an impact? How do we assess if we’re making enough of a difference to cause positive and lasting change? How do we know if the seeds being planted will flourish and grow long after we are gone?
A coach on a sports team will have a real-time scoreboard and a win and loss record, measuring the impact of an Agile coach is often subjective. A while back, I mentioned how measuring team agility is like measuring how in love you are and assessing a coach feels quite the same.
So we know this isn’t going to be easy but let’s give it a try. Here are a few ways I have been personally assessing my own impact (and a means to identify areas to develop and grow.)
“Proud Parent” moments (also known as “Mr. Myagi” moments). A couple weeks ago while coaching an Agile transformation team, I was standing in the back of the room observing an update on the progress the team was making in crafting their new framework with others in the company. As the conversation continued, the questions from the group became harder and harder. I was mentally preparing my answers for the time the team would ask for help…but it never happened.
They were rock-stars and their responses were better than I could have ever delivered. I glanced over to the other coach in the room and I’m sure we both had the same smile. Something similar to Mr. Myagi when Daniel won the tournament in the movie “The Karate Kid.” I live for these moments!
These “moments” should be happening at least once a week. Keep a log of how often they occur for you. As an example, here is a recent page from my journal when I captured the experience described above.
In my opinion, the impact of an Agile coach should FIRST be measured by the growth in confidence of the people in the community they are working with and how soon they are able to stand on their own.
Language change. Similarly, I will often create a mental count of the number of times words such as “flow,” “pull,” “co-creation,” “responsiveness,” “trust,” “speed,” “collaboration,” and “customer-focused” (or other words aligned to the values and principles of the framework being designed) are being used in everyday conversations. On the contrary, I would listen for the reduction of phrases like “we always do things this way” or “this is the [insert company name] way of doing things and it will never change.”
The level of optimism and excitement for the future should be increasing during any transformation and language will always reveal this. When language changes the culture changes. This is especially true for those in leadership positions.
Shortest possible cycle-time. How fast are new ideas getting from incubation and into the hands of customers or end-users? Many coaches and coaching organizations will attempt to use an Agile Capability or Maturity Matrix to gauge the success of an overall Agile transformation but I’m beginning to believe keeping track of how frequent customers or end-users are experiencing fresh working product is a strong enough measure to identify coaching opportunities. If an agile team has been sprinting without a deployment to customers/users in months, an agile coach should be very concerned.
Quality. While speed is important, it isn’t everything. Teaching and coaching principles of craftsmanship at all times should be a priority. For coaches working with a team for just a short period of time this will be tricky but monitoring the number of unhappy users because of defects or shoddy work would be the best measure here along with your speed measurements. Test automation coverage may also apply.
Ability to self-heal. I believe a measure of success for a coach is their ability to instill self-awareness, bravery, and the necessary skills to be in control of their own destiny. Are the teams you are working with able to identify unhealthy behaviors or activities and repair them without the input of a coach or leader? Are they able to identify and remove impediments without assistance? Are they able to have the crucial conversations to remove anything infecting their new way of working? Keep track of the times they are showing this new-found capability.
Formal meeting reduction. When a member of an Agile team states, “My day is full of meetings!” unrelated to the work of the team, something smells. I see this quite often with product owners but can be prevalent throughout an organization. As much as possible, an Agile coach should be guiding their teams to solve things in real-time with people present (both virtually and physically). Waiting for a meeting to resolve something or make a decision restricts flow (speed) and adds friction. I’m not saying this should be reduced to zero but we need to focus on creating space for co-creation to emerge and for people to experience life together.
Concept advancements. The next step beyond a “proud parent” moment is assessing when the organization (or team) is taking initial training, ideas or an approach and making it their own. Some call this “Shu-Ha-Ri” based on how martial arts is often taught.
How do we know when they are bending the rules or creating their own? This is a tough one to measure but they should be questioning everything and exploring ruthlessly. They are asking what is the simplest thing we could do, and what would be the hardest thing we could do while still aligning with the principles of agile and lean. I will often measure this by how much of my original concept sharing has been crossed off and replaced. :)
Coaching tree. The presence of an Agile coach must trigger the growth of people and you must be a springboard for them to achieve greater things on their own. As your portfolio of coaching engagements grow, it’s nice to take a moment every so often to observe those you have worked with years ago and see how they are brightly shining now.
This reminded me of the coaching tree for Bill Walsh, the former coach of the San Francisco 49ers. While he passed away in 2007, I’m hoping he looked at his coaching tree at some point and had more than a few “proud parent” moments thinking about the seeds he planted.
This also aligns nicely with Robert Greenleaf’s description of how to measure servant leadership. “The best test, and difficult to administer, is this: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?”
I have been able to watch with pride how many of the people I have been blessed to worked with have developed and grown into amazing agilists, change agents and servant leaders. And yes, l’ve had many Mr. Miyagi smiles thinking about my time with them.
Feel free to share your own ways you are assessing coaching impact…please add your thoughts below.Becoming a Catalyst - Scrum Master Edition
To understand the culture you’re attempting to change in your organization, you need to measure (or sense) the current state and then map that state to a model.
- Collaboration – a culture of working together
- Control – a culture of predictability and staying in control
- Competence – we’re the best at what we do
- Cultivation – a culture of learning and growth focused on a vision
These attributes are mapped on two axes: Horizontal – People vs. Company oriented; Vertical – Reality vs. Possibility oriented.
Each organization will have a primary and secondary culture. Agile and Scrum are primarily collaborative, with a secondary focus on cultivation .
To sense where your organization fits in, you can either use a questionnaire (sample via Survey Monkey) or run a culture discovery workshop in conjunction with the questionnaire. My own experience, and that of Michael Sahota in “An Agile Adoption and Transformation Survival Guide”, suggests that using a workshop is more effective at creating a consensus around the results of the survey.Case Study
For the past six months, WorldsSmallestOnlineBookStore has had trouble with customers leaving us or abandoning their shopping carts mid-purchase. We’ve figured out the technical sources of our problems, but nothing has been resolved. The executive team have been discussing them for months, and there is even some grumbling that Agile was “supposed to fix” the quality problem.
Of course, one of the bigger challenges that the teams perceive is that, while Scrum is being used at the team level, nothing is happening at the organizational level to support the changes that are needed. This doesn’t leave them with much faith overall.
In the above Case Study, a day-long workshop was held where attendees (a mix of Executives, Middle Management and Team Members) placed aspects of the current organizational structure, behaviours, practices and slogans on the Schneider model. The notes they added included:
- We share knowledge with other teams
- The team ships, not the individual
- We welcome new ideas
- Our Scrum Teams are stable
- We need Red, Yellow, Green Reports to retain control
- Hierarchy matters – talk to your manager before going outside their span of control
- Annual Performance Reviews are important
- We use Stack Ranking and Rank and Yank to eliminate underperformers
- Ship features now
- We use a skills matrix to identify strengths and weaknesses in the team. We use this information to help individuals learn.
- We hold lunch and learns
- We’ve created a community of practice to share new ideas. Example: http://www.infoq.com/articles/levison-TDD-adoption-strategy
- Nothing in this section as they don’t currently put emphasis on Competence.
From this picture we can see that Scrum has truly taken hold at the team level, creating a culture of collaboration and cultivation. However the organizational structure remains stuck with a focus on control. If nothing changes, the control focus of the organization could destroy the collaborative culture the teams have built.From Reengineering Alternative: A Plan to Make Your Current Culture Work (1994), William Schneider
 See: Michael Sahota’s excellent summary here: http://www.methodsandtools.com/archive/agileculture.php
 Thanks to Michael Spayd for his research in this area
First image attribution: Agile Pain Relief Consulting
Agile brings about a change in mindset and mechanics, which affects both employees and customers. Whereas change can create new opportunities, it will also be met with resistance. Agile change really isn’t any different than any other culture change, ergo the resistance will have similar patterns. There are many reasons for resistance. Here are some of the patterns:
Here we go again! It is comforting when things remain the same. Employees have seen change efforts come and go without any true commitment and may attempt to wait the new ones out.
- What can you do? The commitment to change must be clearly stated. The change initiate must be treated as a program, with clear motivations and rewards for change.
Fear of the unknown. Change is often defined by a journey into the unknown and it natural to resist what we don’t understand. For most, it is unclear what the change will entail.
- What can you do? Leaders should provide a vision of what the new world will look like
Lack of communication.Employees need to know what is occurring to them. As information trickles down from the top, the message can be lost.
- What can you do? Plan for continuous communications at all levels is important. Include various communication channels and messages from as many champions as possible.
Change in roles.Some employees like to retain the status quo and do not want to see their roles changed. When roles are vague, some don't know where they fit in the new culture, making them feel excluded. When they have no say in their new roles, they can feel alienated.
- What can you do? Discuss the role changes with employees. Give them time to adapt to the roles or give them time to try new roles.
Competing initiatives.Introducing an agile initiative when there are already multiple initiatives occurring can lead to employees feeling overwhelmed, causing them to resist. Hardly an auspicious start!
- What can you do? It is important for management to prioritize initiatives and focus on the higher priority ones.
Change for people, not leaders. When asked “Who wants change?”, everyone raises their hands. But when asked, “Who wants to change?”, no one’s hand goes up. This can be particularly true with leaders. Leaders want change to occur within their teams but are not particularly interested in changing themselves and this may be been prevalent in past change initiatives.
- What can you do? Acknowledge the change that the leaders must make and convey the leaders’ commitment to change.
New management's need to change something. New leaders often feel they must show they are action-oriented. They may reason that the change that worked in their previous company should work here. Some know their term is short, so they are not interested in long-term change. Some are unaware of what it takes to affect culture. Employees who are used to this scenario may resist.
- What can you do? Avoid what may appear to be random changes. Ensure the Agile change is aligned with better business outcomes and not just to do Agile.
It will not always be possible to identify and manage all types of resistance. However, it must be treated as a real and tangible activity. It is better to start addressing resistance to change in a pro-active manner. The more you review and enact the "What can you do?" tips, the more likely you will increase your changes of a successful Agile change (or any culture change).
Satya posted his mental model for Digital Transformation:
I like the simplicity.
What I like is that there are four clear pillars or areas to look at for driving Digital Transformation:
Collectively, these four Digital Transformation pillars set the stage for transforming your business model.
What I also like is that this matches what I learned while driving Digital Business Transformation with our field with customers, and as part of Satya’s innovation team.
Effectively, to generate new sources of revenue, organizations re-imagine their customer experience along their value chain. As they connect and engage with their customers in new ways, this transforms their employee experience, and their operations. As they gain new insight into their customers behavior and needs, they transform their products and services.
In a world of infinite compute and infinite storage…how would you re-imagine your business for a mobile-first, cloud-first world?You Might Also Like
Just last month I receive a congratulatory letter from REI MasterCard - 10 years of a mutually beneficial business relationship .... until .... chaos ensued (thank you Mr. Mayhem). So I accepted the opportunity to communicate with my business lender on an incident that may me very dissatisfied with their policies.
Subject: Re: Congratulations on your REI World MasterCard anniversary! Thank you Robert,
Just to let you know - I’m sure this will interest you - I will shortly be canceling my 10 year relationship with REI MasterCard, because of the quality of service you have just required me to deal with. I’ve got a great payment history and have been using our card to pay bills on line and automagically for years. Recently through my oversight, I forgot to pay my bill on time. So in response to this great customer who always pays his bills and once in 10 years paid late, your organization saw fit to block all payments, causing further confusion and customer / client dissections with your service level. When I called in to rectify the situation your senior rep. could not do anything to help - your policy prevented customer satisfaction. Said policy created even more denied automatic payments for my accounts, creating a snowball of unpaid bills. All from a company that is in the business of extending credit. This is unacceptable. So I will be canceling my relationship and moving to VISA. David Koontz, very unhappy customer.Here is the response I received from the Office of the President, US BANK Cardmember Service
One technique for losing customers is to make the very nature of your core business proposition an oxymoronic meme. Let's use this US Bank - REI Credit Card issue as a case study.
The back story: I've been a REI Credit Card user for around 10 years, I've built up a very good customer relationship, paying bills on time for those year, sure there may have been a slip through the cracks from time to time, yet my credit score reflects that I'm a very sound risk for credit.
So when a job transition happened in the sprint of 2016 there was much confusion with cash flow and various credit cards transition from one service vendor to another (seems as if Master Card is losing clients to VISA) and Costco moved away from Am Ex. Lots of changes in the card industry. These had various impacts upon my personal fincianal life...
Some few years ago I started moving auto pay bills to my REI card (US BANK) we loved the cash back rewards at one of our favorite shopping stores, REI. So by 2016 almost every bill I get, from water bills to Amazon to Apple App Store to Netflix etc. is on the card.
Now in March, I missed the $30 min. payment to US BANK. So in silence they blocked all debits and transaction to the card. There was no communication to me about such a significant event. However, I get plenty of alerts of various natures, such as payment due, minimal balances, large transactions, etc. But, for unknown reasons explained by the Office of the President, they are just unable to communicate with customers about this type of event.
I've canceled the card. Kinda hate to lose the REI relationship, but they have not responded to any inquiries either. In today's credit industry there are plenty of reward programs to choose from and I've made other arrangements - did all the work to transition payments away from US BANK's card to a USAA Signature card. Maybe I'll probe that system and see how they respond to a missed payment.
So what would US BANK needed to have done to keep a 10 year customer? A simple alert - your account has been frozen because of late payment. AND then been able to recognize a good customer and rectify the issue over the phone - by extending credit and reinstating the account with the promise of the check is in the mail. After all their core business proposition is extending credit.
Agile Pain Relief is once again proud to support Agile Coach Camp Canada. As the major sponsor for both Coach Camp Canada East and Coach Camp Canada West, we encourage you to attend these invaluable “unconference” annual events if you ever have the opportunity.
Let’s have a conversation about what it means to be an agile coach, why it matters, and where we are headed.
The annual gathering at Agile Coach Camp creates opportunities for our Agile community to share our successes, our learning, our questions and our unresolved dilemmas – all in an energizing and supportive environment.
The Open Space Technology, Unconference format, encourages participants to join the conversation.
Each of us can make a contribution to the art and science of helping people and teams be their best as they deliver valuable software. Share your stories, observations, and enquiries. Discuss challenges you have overcome or those you are still wrestling with today. Describe opportunities you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others.
Agile Coach Camp Canada East, June 3-5 in Cornwall ON, is already sold out, but you can add your name to the waiting list. Agile Coach Camp Canada West, June 17-19 in Vancouver BC, still has open registration.
Image used with permission from Agile Coach Camp Canada
Van 25-29 april is er de jaarlijkse Retrospectives Facilitators Gathering. Voor mij de gelegenheid bij uitstek om mijn vaardigheden als trainer, coach en facilitator van Agile Retrospectives verder te verbeteren. Wil jij ook meer waarde halen uit retrospectives? Bestel dan voor 1 mei de paperback Waardevolle Agile Retrospectives op bol.com bij Ben Linders Publishing en je ontvangt de Nederlandstalige eBook editie gratis. Continue reading →
The post Gratis eBook editie bij Paperback Waardevolle Agile Retrospectives appeared first on Ben Linders.
I learned this technique from the facilitators of Language Hunting and Where Are Your Keys, they term the technique How Fascinating and practice it quite a few times each game.
The purpose of the technique is to invert the physiology of failure into a learning moment to reflect upon what just went wrong and instead of cringing and curling up into a safe ball, we open up the body and the mind to learning and the experience of reflecting and allowing the universe to teach us something.
Try it a few times...
The Failure bow -DeepFUN by Matt Smith
Go Ahead, Take a Failure Bow by Beth Kanter at HBR
TED Talk: The unexpected benefit of celebrating failure
"Great dreams aren't just visions," says Astro Teller, "They're visions coupled to strategies for making them real." The head of X (formerly Google X), Teller takes us inside the "moonshot factory," as it's called, where his team seeks to solve the world's biggest problems through experimental projects like balloon-powered Internet and wind turbines that sail through the air. Find out X's secret to creating an organization where people feel comfortable working on big, risky projects and exploring audacious ideas.
Well I thought I'd try to open the kimono to see if it helps me...
I've studied Psychometric assessments and some I find useful, some I feel are just a step to the left from astrology charting. Yet might not be harmful for self reflection. I've also found that it takes an expert to explain the tools and reports such that a layperson can understand and make positive use of the assessment and it's report. And while I've been "certified" is some of these tools/technique I do not practice them enough to be competent - and my pitch is akin to a snake-oil salesman.
Here is my DiSC Classic profile:
DiSC Classic by WileyHere is my Trimetric assessment (DiSC, EQ, Motivation) by Abelson Group
DiSC WheelMotivators Wheel
Emotional Quotient Wheel
Here is my Myers Briggs Type Indicator - Level II assessment:
MBTI Level OneMBTI Level II reports
Here is my EQ 2.0 - Emotional Intelligence:
EQ 2.0 by
TalentSmart, Inc. Here is my Action & Influence report:
Here is my Personalysis assessment:
Personalisis assessment ReviewedMBTI Level II assessment Reviewed
Psychometric testing resources
British Psychological Society’s Psychological Testing Centre (PTC) provides information and services relating to standards in tests and testing for test takers, test users, test developers and members of the public.
National Cultural Studies - assessments at the meta level - the personality and behaviors of nations.
In an earlier post, we described an abridged version of the SAFe Lean Agile Principles that we have been working on. They have now been reviewed and updated a bit, so I just posted them as a summary under the main Principles page. That way they won’t just be floating around in blog land, and instead, take their place as first class citizens of SAFe, where they really belong.
By the way, that “Introduction to the Scaled Agile Framework V4.0” whitepaper that we have been working on is about ready for prime time. Richard is doing some final edits, and he’ll post it soon.
–Dean and Team
Here is my updated drawing showing how Culture is the core of your organization – how it binds everything together. “Organizational Culture” = the wibbly, wobbly thing that connect everything. In this model, there are two important dimensions of culture: Consciousness = intangible way of being that reflects how we are as human beings. Inner world. Structure […]
Below is a list of 10 of them from my experience and a brief description of proven solutions.
1. Fixed scope, schedule & cost
It’s OK to have a fixed schedule for games, but when you fix the scope as well, you’re asking for problems. Forget about being able to plan enough to eliminate that uncertainty by remembering Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Solution: Scope is the best and most flexible tool. Use a prioritized scope, develop from that and derive your schedule.
We often build up a "debt" of work during development that is unpredictable, grows like financial debt and has to be paid back at the end through extended crunch. There are different flavors of debt:
2. Technical debt in the form of bugs and late optimization.
Solution: address debt as soon as possible through an iterative approach that frequently delivers potentially shippable builds. There are a number such approaches; test-driven development is a popular one.
3. Content debt in the form of a minimum required set of polished assets that have to be produced after the mechanics are created, to tell a story or provide a minimum gameplay experience.
Solution: Build increasing fidelity prototypes and tests of assets during preproduction to measure and extrapolate the cost and schedule for full production.
4. Design debt in the form of waiting until all the technology and assets are in place before discovering whether the experience is fun enough for a full good game.
Solution: Use iterative development is used to explore gameplay and to “find the fun” early.
5. Feature creep
We all know that the scope we ship is never what we initially planned and that feature creep is inevitable, but if there is a lot of debt being carried, it's hard to measure true progress. This makes it hard to gauge the impact of additional features requested. We end up backloading the game with even more "90% complete" features and therefore even more debt.
Solution: Address debt first, so that the true cost of features can be measured. Then prioritize the feature list so that you can have conversations about where additional features can be added and what features are demoted as a result. As long as it's understood that the feature list is not a promised set of features, but a prioritized one, where the lowest priority features can be dropped, feature creep can be managed.
6. Lack of courage
Middle management has made promises to stakeholders that can’t be kept and enforces extended crunch on development in an attempt to hide it.
Solution: Upper management needs to create a culture of transparency and not punishing those who deliver the bad news.
7. Risk adversity
Avoiding the areas of greatest uncertainty, such as unproven mechanics or new hardware in the hopes that it won't manifest. When the risk triggers, it’s too late to do anything smart about it.
Solution: Embrace risk and prioritize work to mitigate it as early as possible.
8. Team ability
The inability of the team to make the game envisioned, due to missing skill-sets or a lack of experience.
Solution: For the short term, a risk-prioritized approach, will inform you early that the team existing cannot make the game hoped for (see courage). For the long term grow your people through mentoring and training.
9. Ignorance of the limited benefit of crunch
For a many decades, businesses have known that crunch isn't effective past a few weeks. The data is clear. Sure, some extra time now and again isn't bad. At times I've had to drag myself away from the keyboard after marathon sessions, but that doesn't mean we can or should do it for months.
Solution: As a manager who was guilty of this, I had to measure what was making it into the game, rather than just measuring how many hours people were at work. That demonstrated the loss of value we faced with extended crunch. That was the last time I enforced it.
10. Lack of empathy/respect
The attitude that game developers are fungible, that crunch is part of the territory if you want to make games and that they are to blame for a bad process.
Solution: Quit and work someplace that respects you.
What is missing? What are solutions have you seen? Let me know and I'll add it to the list (with credit to you).