Carina Silfverduk

agility coach

Author: carina (page 2 of 2)

In Gratitude

As a young, single mother of twins, I embarked on my software engineering journey really because I considered myself to be “good with computers,” and because I was searching for a way to provide for my children. I set out at the local community college to study Computer Information Systems, and Programming more specifically, thinking this could be a good career move for my family’s sake.

On a different day, I might characterize my long journey as one I made alone, because in some respects, I truly did. No one advised me to graduate early from high school, that was my decision. It only worked because I had worked so very hard to be a good student throughout my three years in high school. With two children, I needed a way to support them and I decided getting on to college was paramount. No one but me, felt the weight of full time school and full time entry level work that first year. I pushed myself to stretch, early and often to move ahead and provide. I transferred beyond community college. I made a pitstop in an Associates of Arts. I continued my education over many years, even when I think some people might have given up. I pushed myself for more responsibility, more difficult work, more challenges, and only I could make that journey for myself.

But today, and more often as I get older, I remember the people who have made my success more possible in the opportunities they provided. I would never have given up, but without those helping hands the road would have been much longer, much lonelier, and I wouldn’t be where I am today.

I was only a few classes into college when a professor recommended I apply for my first job in software engineering, and honestly I might not have applied if she wasn’t so insistent that I should make the attempt. Quite frankly, I was surprised she recommended me since I had a habit of falling asleep in her class. It was an early morning class, of a long day of classes for me, and I had two babies at home, and at night I worked as a waitress. For at least half of the year, I also worked part time in a tuxedo shop measuring men for tuxes and processing orders. I was lucky to live at home at the time and my mother was especially a big help for me. Ultimately though, there was never enough time for sleep, and that early morning class on IBM mainframe programming spent an awful lot of time on programming basics that I had already mastered. Long hours working and caring for two bright children and boredom in the classroom, well sleep was nearly inevitable.

Still I was a top student, and I enjoyed the assignments and working in the lab. I worked hard and my answers on tests were often used as class examples. Maybe I could do this as a career, right then, as my professor suggested but I was skeptical.

I was surprised when I was called for an interview, and I felt I did well under the scrutiny of the many people I interviewed with. I later learned there was some concern whether I would make a good hire, being so young, and a parent, and only having achieving the title of “waitress.” I am forever grateful I got the opportunity I did to become a part of the working family processing collections data at my first software engineering position.

I was hired as a student programmer, but within the first few months was promoted to programmer/analyst. I was a part of the Y2K project for our company and was ever encouraged forward by my first great manager, of which I have been so fortunate to have had many. Working there was truly like being part of a family. I’ve not had a position since that has really measured up to that feeling of belonging, but I can say my current role is very close.

Today, I remember the director of the software department that was a big part of that first opportunity. He’s lost his battle with cancer, like so many I’ve known in the last few years. I want to acknowledge, without that first step, I would not be where I am today.

All along the way, there were people willing to let me take a shot at many a wonderful opportunity, who encouraged me to stretch myself, and many of whom are still a strong part of my life today. I made lifelong friends who still always believe in me, always have my back, and I feel so fortunate to have had all of these opportunities, to have worked with so many bright and brilliant people, and to count myself among them.

It took me 17 years to finish my degree. By the time I was done, I had learned so much more in the professional world than I could ever learn in a classroom. I had moved from student programmer, to programmer analyst, to software engineer to Scrum Master, consultant and coach. I had seen the difference for myself and the teams I worked on, between big upfront planning and nimble agile development. Putting people first made sense. Taking incremental risks was safer, smarter and delivered software sooner.

If I look at my career closely, that all comes down to my first opportunity. I was given the chance to take risks, to prove theories, and to explore a better way forward. My first months, I pair-programmed with two developers who are still some of my best friends. Working together, two sets of eyes were better than one. They taught me what they knew, and (I hope) I offered a fresh analytical perspective. I’ve always been a problem solver, but my career in software engineering gave me a license to do it nearly anywhere it was needed.

The problems I tackle today may be bigger, and more complex, and perhaps involve more people, but I believe that at my foundation, are lessons learned at that first job before Agile was an official methodology.

There were later roles that gained me experience in Extreme Programming and Test Driven Development, so early in the Agile movement that I can barely believe I got such a fantastic opportunity to do things that today I am teaching others how to do. There are so many managers, mentors and coworkers that I want to thank.

Ultimately it comes down to this, though. Take chances and encourage young talent. It goes such a long way to building careers than you can ever imagine, and I am living proof. No doubt, one of many, as I have taken these lessons and encouraged other young and bright programmers on in their fledgling careers and hoped that they will someday arrive at this same place I am today: in gratitude to all those who took chances on and encouraged me.

Retrospectives for Everyone – CodeMash 2016 – Resources


Slides: Retrospectives for Everyone

Photos from Session

The Path to Nirvana 1: Now

Where your team is now

The Path to Nirvana 2: Next Step

What’s the very next step you can take towards the ideal state

The Path to Nirvana 3: Ideal State

The perfect team environment

The Flying High Technique

Identifying challenges within the team’s control and challenges at the organizational level




  • Agile Retrospectives: Making Good Teams Great by Esther Derby and Diane Larson
  • Fifty Quick Ideas to Improve Your Retrospectives by Ben Williams and Tom Roden
  • Fun Retrospectives by Taina Caetano and Paulo Caroli
  • Gamestorming: A Playbook for Innovators, Rule Breakers and Change Makers by Dave Gray
  • Getting Value out of Retrospectives by Luis Goncalves and Ben Linders
  • The Retrospective Handbook by Patrick Kua
  • Retrospectives for Organizational Change by Jutta Eckstein

Materials from “Yes, It’s Alive” CodeMash KidzMash Presentation

For those of you who were interested in my daughter and I’s presentation on Fermentation for KidzMash and wanted more information, we put this post together for you.

Kombucha Recipe

Materials Needed

  • Sugar (Refined white sugar ferments faster than organic and less quickly minimally refined sugar)
  • Organic Tea
  • SCOBY (optional)
  • Distilled Water
  • Clean Jar
  • Coffee Filter
  • Rubberband

Note: We prepared organic sweet tea ahead of time for this demonstration. To make it at home, brew the tea and add about 1 cup of sugar per gallon of tea while still hot. Allow to cool COMPLETELY. Kombucha SCOBY is sensitive to heat and putting the SCOBY in while the tea is hot can damage or kill it.


  1. Gather your necessary materials (Jar, Coffee Filter, Rubber Band, Tea, SCOBY)
  2. Pour the tea into your jar.
  3. Put the SCOBY into your jar.
  4. Place the lid onto your jar
  5. When you get home replace the lid with the rubber band and coffee filter and let ferment for 7-14 days.

Taking Care of you Ferment at Home

  1. Find a place for your ferment to live.

Whether it be on the kitchen counter or in the pantry, your ferment needs a home that is away from direct sunlight. A ferment’s ideal home is in a warm, dark and dry environment, however your ferment can adapt to living on the kitchen counter just fine as long as it gets a little bit more love and attention.

  1. Switch your ferments lid with a coffee filter and rubber band.

Your ferment is an aerobic organism and needs oxygen to survive.

  1. Check on Your Ferment

Check on your ferment regularly to see if it needs an extra sugar.

If you are starting a ferment without a SCOBY stirring is usually necessary.

  1. Determine if Your Ferment is Done

Determine if your ferment is done by taste testing along the way. Once your ferment is to your desired taste you are ready to bottle or jar it for “long term” storage.

Bottling and Finishing your Finished Ferment

If your ferment is kimchi or another vegetable ferment simply store the ferment in the fridge for up to 3 months.

If your ferment is a vinegar, kombucha, or any other liquid based ferment then follow the following steps below:

  1. Filter your Ferment

Filter out your SCOBY (and save it to make a new ferment), any chunks of fruit, herbs or anything else you might have used to flavor your ferment by pouring it through a strainer.

  1. Transfer your Ferment to its Desired Container

Whether it be a fancy bottle or back in to the jar you used to ferment your culture, you are going to need to give you finalized ferment a home. If you are flavoring it be sure to leave space to add the materials to flavor.

  1. Start a Secondary Ferment (Optional)

To flavor your Kombucha (or add an extra something to vinegar) you will need to decide how to flavor it. I recommend mint leaves or ginger but you can also add in organic fruit juice. Once you have decided, add the required ingredients to your culture and let it ferment for 24 hours out of the fridge or 2-3 days in the fridge with the lid on.

  1. Put a lid on your ferment and store in fridge (for up to 3 months)


If you notice mold on your ferment, throw it out and try again.

If you notice your SCOBY has turned BLACK it has died and you’ll need to wild ferment to create a new one or ask your parent’s to help you find someone in your town who can give you a mother (Kombucha makers love to share).

Kimchi Recipe

This is a modified version from here, modified to emphasize necessary steps for successful ferment, there are additional options listed at the website above.

Materials Needed

Cutting board, knife
Large bowl, large plate that can cover it and can of vegetables or paper weight
Food safe gloves (non powdered)
Small bowl
Clean swing top/flip top lid jar
Bowl or plate to place under jar

1 organic cabbage
1/4 cup sea salt – MUST have only ingredient as salt (no iodine, anticaking or preservative ingredients – will inhibit probiotic growth)
distilled water
grated organic garlic to taste
grated organic ginger to taste
1 tsp sugar
1 tsp salt (for sauce)
2 to 3 tablespoons seafood flavor – kelp powder, fish sauce from an international market with no preservatives, shrimp paste with only salt in it – CHECK INGREDIENTS for preservatives
1 to 5 tablespoons Korean red pepper flakes – you can find at an international market
(optional) Daikon radish cut into small pieces – you can find at an international market


  1. Slice the cabbage into 2-inch-wide strips.
  2. Salt the cabbage: Place the cabbage and salt (sea salt without anti-caking or preservative ingredients) in a large bowl. Using your hands, massage the salt into the cabbage until it starts to soften a bit, then add distilled water to cover the cabbage. Put a plate on top and weigh it down with something heavy, like a jar or can of beans. Let stand for 1 to 2 hours.
  3. Rinse and drain the cabbage: Rinse the cabbage under cold water (from the tap) 3 times and drain in a colander for 15 to 20 minutes. Rinse and dry the bowl you used for salting, and set it aside to use in step 5.
  4. Make the paste: Meanwhile, combine the garlic, ginger, sugar, and seafood flavor (or 3 tablespoons water) in a small bowl and mix to form a smooth paste. Mix in the Korean red pepper, using 1 tablespoon for mild and up to 5 tablespoons for spicy.
  5. Combine the vegetables and paste: Gently squeeze any remaining water from the cabbage and return it to the bowl along with the radish, scallions, and seasoning paste.
  6. Mix thoroughly: Using your hands, gloves recommended, gently work the paste into the vegetables until they are thoroughly coated.
  7. Pack the kimchi into the jar: Pack the kimchi into the jar, pressing down on it until the brine rises to cover the vegetables. Leave at least 1 inch of headspace.
  8. Add water if needed so that vegetables are submerged.
  9. Seal the jar with the lid.
  10. Let it ferment: Let the jar stand at room temperature for 1 to 5 days. You may see bubbles inside the jar and brine may seep out of the lid; place a bowl or plate under the jar to help catch any overflow.
  11. Check it daily and refrigerate when ready: Check the kimchi once a day, pressing down on the vegetables with a clean finger or spoon to keep them submerged under the brine. (This also releases gases produced during fermentation.) Taste a little at this point, too! When the kimchi tastes ripe enough for your liking, transfer the jar to the refrigerator. You may eat it right away, but it’s best after another week or two.

Attached are the presentation materials created by Tayler.

Yes It’s Alive Presentation (currently unavailable)

Yes Its Alive Take Home (currently unavailable)

For more information:

Do Agile Right

There’s no right way to do Agile but there are plenty of wrong ones. Chet Rong, the world’s worst Agile Coach (via Atlassian) offers some examples of the wrong way to do Agile that never cease to give me some chuckles (follow him on Twitter) .

The main focus in adopting Agile for an organization is to adhere to practices which encourage a learning and improving organization. Keep the Agile practices you try out that bring value, and discard the ones that do not.

Ken Schwaber, in speaking to the Path to Agility in 2012 said that the Agile founders never intended there to be only a few flavors or variations of the Agile Framework. Instead, Schwaber said they envisioned Agile in practice would be as individual as a company or organization. No two implementations would be the same. In my experience, this is true. Each organization has their own challenges and unique needs that mean their implementation of Agile must account for them.

Differences in your organization or your implementation should not be used as an excuse to ignore core principles. If Agile isn’t working for your team, it’s essential to ask yourself why:

  • Did we start with the right practices and derive through experience which are valuable and which are not as valuable, or did we eliminate some core practices before trying them? Eliminating core practices, or the conditions necessary to make these core practices working is a common misstep.
  • Are we putting the proper value on the Agile principles? The Agile tenets?
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

(That is while there is value on the items on the right, we value the items on the left more)

  • Are we skipping things because they are inconvenient, difficult, confusing or otherwise HARD?
    • Just because Agile is simple, doesn’t mean it’s easy.
    • Just because Agile is adaptive, doesn’t mean core principles are optional.
    • Just because Agile is collaborative, doesn’t mean your implementation of Agile is.
  • Are we making proper use of LEARNING? Are we looking at what’s working, what’s not and what we can do about it?
    • Are taking time to improve every sprint?
    • Are we asking ourselves the hard questions on how we can do and be better?
    • Are we utilizing the fastest feedback we have at our disposal? Could we have faster feedback? How?

This is just a start. A truly Agile organization is always seeking to improve and ever evolving. In order to do this you use retrospectives and introspection to understand what is working and what is not. You make incremental improvements and you continue to observe how things are going every day.

This makes Agile a moving target, and truly, it is. Agile is not your end destination, it’s your journey.

If you are looking for a more concrete way to find out if you are doing it right… well, Henrik Kniberg, in the Scrum Checklist offers a concentrated list to determine this – do these and you are essentially doing it right:

  1. Releasable, working and tested software every sprint.
  2. Delivering the highest business value.
  3. Ever improving process.


The Importance of Done

A team I have been working with recently has reached a milestone. When I first started working with this team, most work would get to “development complete” but would linger in QA for multiple sprints or would not pass Product Owner approval so the work never got to “done.”

This particular team had experienced a lot of turnover and strife. I don’t know all of the details, but I can say that even just having people move in and out of a team can create enough instability to make holding to the team’s Definition of Done (DoD) difficult.

I think most people on the team understood what their Definition of Done was, even if it wasn’t something they said out loud or had written on the wall somewhere (but you can do such an activity in a retrospective, and I highly recommend it).

This team was writing automated tests, code reviewing check-ins, ensuring new work passed the test suite and built successfully. Everyone seemed to understand in concept that QA had to test their work and bless it, and ultimately the work needed Product Owner approval, but that’s not what was being measured.

The act of measuring something impacts your results.  People naturally start to key on what you measure. This team was being measured on how much work they could get to development complete when I first started working with them. I knew instantly we needed to adjust it, but getting to shift the team towards the right measurements couldn’t happen overnight. I needed to better understand why this was happening, and then determine what to do to move towards what should be happening.

For any Agile team, the Definition of Done (DoD) is very important. It becomes how you know you’ve met your sprint goals and commitments and it gives a guideline for what the team considers to be completed work. It’s also how you measure the team and the work at a high level, for sprint planning purposes and at retrospective time to understand what trends the team experiences and why.

Every team’s DoD may differ, but generally, done does not mean “development complete.” It’s rare to be development complete and have fully releasable software on the first try. When development work is passed on for testing and quality checks, there are inevitably bugs/defects to fix or improvements to be made in the work. The Product Owner or Stakeholder may request tweaks or changes before approving the work, or alternately may accept this iteration’s pass at functionality while requesting tweaks in the next iteration.

Done usually means the work in question has met a level of quality the team has agreed on. Quality Assurance, Business Analysts and Product Owner(s)/Stakeholder(s) have approved the work. Acceptance criteria are met, and automated testing and/or checks (performance/load etc) have passed.

Generally, done for Agile teams should mean the work is releasable. Releasable, but not necessarily released. Meaning if you were to stop work after a given sprint, the product you have developed so far would be able to be pushed live and provide value. Some teams release small improvements often. Some teams group development work into releases containing multiple sprints worth of work. Regardless when you release, at sprint end, your work is ready for real world use.

Definition of Done can be skewed when there are things happening that [someone or the team] is trying to address- for example none of the work involved in getting to QA or Pending Product Owner Approval counts as completed (in terms of moving up the field). If you have enough work that lingers like that just shy of done that leaves a team demotivated because no one acknowledges their hard work. Or someone isn’t addressing the concerns coming from the Quality Analyst or Product Owner. Or someone isn’t protecting the process. This is a process problem AND a people problem. Sometimes it’s people not understanding the process. Sometimes it’s absence of process.

On teams where work is frequently not meeting the definition of done, Scrum Masters / Agile Coaches must be looking at why and working together with the team to find solutions.

Your very first step when encountering a team that isn’t performing the way you think it should, is to start looking at what’s going on with an open mind. Find out what they consider as their DoD – either formally, through a retrospective, or informally, through observation and casual discussion.

Observe. Take notes. If possible, talk to the team about what you are seeing. Inevitably, there are reasons why the team is where they are, and as in the Retrospective Prime Directive- that’s a result of everyone’s actions and inaction – they were doing the best they could at the time. No need to start blaming anyone. Just start addressing the problem in a constructive and adaptive way.

Ask questions to discover what may be preventing the team from getting to done.

  • Is the definition of done too difficult to meet? Too ambiguous?
  • Is the team spending enough time discussing the work and how to approach it in sprint planning?
  • Are stories fully defined or do various roles have to track down information during what should be development or testing time?
  • Are acceptance criteria too ambiguous, resulting in confusion over whether the work is complete, or whether the work passes the expectations of it.
  • Does the stakeholder/product owner understand incremental software development and accept working software (a few most valuable features that work well rather than pressing to get all of the features that barely function)?
  • Does the team have all of the skills and experience needed to complete work? Does the team have the right balance of skills?
  • Is there a workflow problem? Are the right people involved at the right agile ceremonies to keep work moving (especially review of defects and work failing testing as well as product demo and stakeholder approval).
  • Is the team overloading the sprint?
  • Where does the work tend to get stuck, and why?
  • Are team members remaining blocked without hope of help getting unblocked?
  • Does the team fully grasp the agile sprint lifecycle?
  • Is someone protecting the agile process?

This is just an example list. Remember, look at what’s going on with an open mind. After asking questions, start looking for solutions. It’s easy to complain, but it’s much harder to take problems and start finding solutions. It may help to use a Retrospective Method such as Known Issues, AFTER clarifying the Definition of Done (DoD), to collaborate as a team in finding ways to solve the problem for the team.

As an example, for one team I worked with not too long ago, we identified one main reason they didn’t reach DoD was the work was not fully defined. People doing the development had to spend time tracking down and clarifying with Stakeholders what was desired. People testing the work had to spend time walking through with the developers what the heck the software was supposed to be doing. Stakeholders didn’t understand that the work could be further improved in a future sprint and didn’t want to release before everything was perfect. All of these things left work just shy of done at the end of the sprint.

When problem solving how to address the DoD issue with this team, there was one root cause and 3 resulting problems to consider. The first thing they decided was they wanted to write more robust acceptance criteria. The second, that they would not begin work without clear acceptance criteria and they would consult these acceptance criteria in determining whether the work was complete. The third was that QA would use this criteria to evaluate the work. And lastly, they had to, over time, help their Stakeholders become more comfortable with the idea that the software was ever evolving and improving.

Every team is different but getting to done is the general goal of an agile team during the sprint. If your team is struggling with this, it’s time to examine why.

Don’t Be a Jerk

From 2008 to 2010, I had the unique experience of working overseas in Sweden. It was a fantastic opportunity, and I learned a lot about how cultural norms can differ. Workplace norms are not the same everywhere in the world – and this was surprising to me.

I had assumed that working in IT would be nearly the same. Programming in Sweden was very similar to programming in USA- all of the programs were in a language I knew (English), and the technologies I used were familiar. My keyboard had some extra keys on it, and surprisingly, this threw me off for the first month or so. I kept accidentally pressing the wrong keys, and that led to slower coding.

The cultures in the various offices I worked in were vastly different. From the moment I entered my first interview, this was clear. Instead of focusing on my career highlights and my strengths and weaknesses, hiring managers wanted to know was I fully rounded individual? What did I like to do in my spare time?

The norm in USA of talking up your experience and skills was not acceptable in the humble company of Swedes either. This might have been the hardest adjustment for me. To me, finding a job and standing out against other candidates meant aggressively selling what I could do. To the Swedes, this seemed like the boasts of someone who liked themselves a little too much. I had never looked at myself as being someone who was full of themselves, but to survive in Sweden’s job market, I needed to tone it down.

Another thing that struck me, again and again, was the power of shared expectations. In Sweden you were expected to follow certain cultural norms, and everyone I met did things to help you know what was expected of you. On the bus, someone would helpfully remind a gentleman to give up his seat for the elderly, or else every occupant would turn an angry eye to the man who did not give up his seat for an elderly woman. That peer pressure was powerful.

People said what they meant. If a friend said let’s get coffee, they actually meant it. We better be getting coffee!

In one office, we had coffee break or fika, every day in the mid afternoon. I can verge on workaholism, so my teammates would subtly stop by my desk just before to encourage my attendance.

Even living in Sweden, the government encourages you to understand the country and fit in. I am a Swedish citizen, but I was not fluent enough in Swedish and was encouraged to attend a free class to learn the language and culture better. For this small nation, gentle cultural guidance helped those not used to the expectations to fit in.

In the same way, Agile teams can use their defined cultural norms to help new members onboard, and to encourage each other to be better team members. This can be done in many ways, but the retrospective is one of my go-tos.

I may not have posted about this here yet, but in my daily life, I say all the time that one should vary retrospective methods. It is truly the most powerful tool in the scrum master’s toolbox, and using the same method every time is like using a hammer for every job around the house. You might get some things nailed in, but you’re likely to get some dented walls and fixtures too.

One method I like using in retrospectives with new teams, or with teams in which it seems like discord appears to be growing, is to define our team’s working relationships with “That Guy, This Guy.

With this method, after reminding the team about the Retrospective Prime Directive, the team works to define the kind of team member that is difficult to work with (Don’t Be That Guy) and the kind of team member they love to work with (This Guy Rocks!).

I did this retro with a team I worked with in the last year. The That Guy, This Guy artifact became their playbook for their team. Take a look at some of the qualities that That Guy has versus This Guy.


“That Guy” passes the buck, isn’t accountable and closes new ideas down. The phrase, Don’t Be That Guy takes on special meaning when we define the behaviors that make it hard to work with someone.


On the other hand, look at the qualities this team defined for the sort of person everyone enjoys working with – proactive, helpful, and willing to pitch in. Everyone wants to work with “This Guy.”

Agile is all about raising accountability for all team members and pushing the team, and the individuals in it, to be their best selves. As human beings we like examples of what that means. For each team, this may look a little different. It depends on your business, the products you work with, and your processes.

A similar retrospective method I’ve used is called Ground Rules, which is especially appropriate to use in the formation of a new team. The premise is similar – how do we work together best – what rules do we agree on and what new ones should we consider? These rules then can be passed on to any new team member to give an example of how the team expects members to behave.

In summary, these retrospective methods really boil down to the team defining how not to be a jerk. They arm the team with a way of calling out what their preferred behaviors are, and a playful way of saying, hey- This Guy Rocks!

This is super important in agile teams where the team dynamic has more potential than ever to slow down productivity if people don’t play by the rules, or conversely, produce more than ever as the team gets better at working together.

Fail Early

On the subject of fail early – I had a great lesson in this in the fall of 2013.

I went to a shooting range for a social event. I participated in 3 rounds at three different locations. It was the first time I had ever held a gun let alone shot one, and I was really intimidated at the first station. We were grouped in teams, and each person got two shots per turn at clay pigeons that came from varying locations. Then the teams would switch.

At the first station I received minimal instruction and minimal feedback. I would take aim and fire, but only ended up hitting one over the entire series.

At the second station, each person still took a turn to shoot, with a rotating launcher for the pigeons that might send your target out in any direction, but this time only one shot per turn. The feedback was very detailed. I got feedback after each shot. I shot maybe two total in the series.

At the third station, in the same location, we then shot each person, each turn, and I being the only lady in the group, got to call when to release the pigeons. I shot and hit every one.

For me, being able to participate and get immediate feedback on every shot without pause between to wait for others taking their turn was essential for my success. I needed the experience of taking the shot, every time for all the feedback I had received to really work. You could have spent all night talking to me about how I needed to aim higher or to the left, or not to pause when I got the target in my sights, but none of that could substitute for the actual experience of aiming, shooting, then repeating the whole thing again.

Developers need that experience in their work as well. Taking aim at a target, attempting to complete it, and learning from that experience. The most important part of this equation is learning!

Eric Ries, author of The Lean Startup was rumored to release up to 100 times a day for his product IMVU. The product was released after 6 months. It was buggy, but it got out and into use with the people who were interested in it, allowing improvement and refinement of the product to the customer’s needs.

He compares the release of IMVU and it’s buggy performance so bad it didn’t perform half of the time when presenting to venture capitalists to the release of another perfectly planned over the span of 3 years that failed miserably.

The difference is that they didn’t try to predict what was wanted or needed in 3 years, they tried to figure out what was wanted / needed now, and got fast and early feedback from customers to quickly iterate over the product to make it more and more into the ideal.

We should take these lessons to heart. Getting early and often feedback is important. Making mistakes is essential to improving and innovating. Finding out about these mistakes early has a much lesser cost to fix than finding out about mistakes late.

Fail early, fail often – otherwise you aren’t stepping out of your comfort zone into what is possible and stretching your potential. Otherwise you are playing it so safe you never take a risk at all. That might be comfortable, but it also probably won’t get us very far in the long run. The problems we have today will be the same problems we talk about in one year or two years.

Take a risk and try something new. Maybe even consider the possibility that we may want to start something radical – like the new management of the Toyota plant Nummi – taking the roughest union workers and turning them into team players by treating everyone as valuable, allowing anyone to stop the production line when there was an issue, using a pull workflow, and problem solving together.

This goes beyond methodology and into practice. What do we want our work environment to be like? Do we want to look forward to working together as a team, and value all contributions? Do we want to raise the level of accountability to the products we work on and to our teammates? Do we want to encourage innovation and measured risk taking? Do we want to look forward to the possibilities new technologies may offer us and experiment with what they might be able to give us?

Change is a scary but necessary and expected part of technology work. Expecting things not to change is like expecting it to rain and to not get wet.

Rather than avoid change- let’s embrace it, and the learning potential it brings with it, whenever we can.

I’m Just Getting Started

I’m in the process of migrating my professional information here from a variety of locations. Thanks for your patience on this journey to establish a central web presence!

Newer posts »

© 2019 Carina Silfverduk

Theme by Anders NorenUp ↑