A feeling has been rising in me over the last year about how agilists choose to speak and behave. At Path to Agility in 2017, it became overwhelming in a moment when a conversation I was a part of took an unexpected turn.
If I had not seen Tim Ottinger‘s opening keynote on aggressive curiosity, it might have taken much longer for me to identify this feeling.
The Curiosity Manifesto
Ottinger spoke of embracing curiosity, and closed his talk with the curiosity manifesto:
By thinking and helping others to think, we have come to value:
Instead of judgment, curiosity
Instead of later, now
Instead of guilt, permission
That is, while things on the right have value, things on the left just seem to get in the way.
I took these words to heart. When I felt the urge to judge a mistake in a tweet I posted, I paused, and said instead, “How interesting!” Throughout the two days, I postponed judgment. I tried to remain as open minded as I could.
I’d like to think that this is easier for me because I am incredibly empathetic. I can easily put myself in the other’s shoes.
Even in the conversation in question, I could see the temptation to make a flippant comment. I could see wanting to get some laughs, grow a sort of insider agilist camaraderie. But I could also see fresh faces just newly embracing agile participating in the conversation with me. And I thought, what a mistake it would be to close conversation off to possibility for a laugh. What harm we could do by turning a person off pursuing something better for themselves or for the workplace they might take this conversation back to. In the moment, I felt concern for how those taking part could misinterpret the words that were said.
As the conference came to a close, and now, it seems more and more often… I am struck by how our words and deeds either express our values as a community, or betray them.
As a community, I see agilists as smart, adaptive folks who believe in treating human beings with respect. We invite everyone to the table to participate. We are inclusive.
As a person, the values of inspect and adapt are central to who I am. Explaining what I do to a long time friend I hadn’t seen in some time, she exclaimed- oh that makes perfect sense, that’s who you are.
I want us as a community and as individuals to get better at doing no harm. I’d like to see us get better at constructive disagreement and listening to context before we speak. What we say and do can harm as much as help, depending on how we choose to respond.
Maybe, you too, see where I am going here. Maybe you too see sweeping statements filled with judgment and feel uncomfortable. When we say, don’t do ____. Or that’s not ____. Or we make a flippant comment about a buzzword and it is taken out of context. When we tell a client, “you shouldn’t need a [role] for longer than [ a time period]” without understanding the client needs.
What about when decisions rely on our words? What responsibility do we have to individuals? What about when organizations make decisions based on our advice? We can do great damage.
Do No Harm
The way I see it, as agilists it’s our responsibility to open up the conversation. Perhaps agilists should have the equivalent of a Hippocratic oath. We may not be operating on human bodies but organizations are living things- we are working to improve the health of organizations. There is great weight with this responsibility.
I set a personal goal of reading 50 books this year and finished double my goal.
Included in my list were fiction, non-fiction, personal and work related books, as well as things I just wanted to learn more about.
How I did it:
I set a goal in Goodreads and tracked my progress there.
Set a reading cadence goal:
to read some each week, or each day depending on what my schedule looked like at the time.
Liberal use of all tools available to me:
library (physical checkouts and online resources such as eBooks and audiobooks)
Always reading a few books at any given time. This is important for me, because sometimes I just do not feel like reading that non-fiction book on work stuff, or I’m really focused on a problem I want to solve and I don’t want to spend time on fiction.
This also helped when I was trudging through a work of classic fiction I really wanted to finish, but needed a break from the language or themes for a while.
Used multiple formats
I often got more than one format of a book so that I could listen to it, read it, and highlight/take notes. This was especially helpful for dense content that doesn’t lend itself to audio.
Always had a book with me:
If I was stuck in traffic, it was no big deal because I had a audiobook to keep me company.
If I was waiting a long time in line, or at the doctor’s office, I saw it as a bonus to get some reading time in.
Used digital and hard copy notes to track information I knew I would need / use again.
Scanned relevant dense pages I wanted to come back to so that I could take notes with a PDF app and Apple Pencil on my iPad.
I listened to audiobooks while driving, exercising, doing housework, or other tasks. Some I download if it’s possible to do so through Overdrive or Audible. Some I get form the library on CD.
I often have an audiobook on CD in my car, and one or two loaded on my phone.
Cast a wide net:
The Columbus Library is absolutely awesome. Whenever I have been away from Columbus, I have missed this great library. So I use it to the max. This is something I’ve done most of my adult life.
I search the library for books on a topic I want to learn.
Within checkout limits, I check out every book on the topic.
I often request additional book purchases from the library as the most recent are not yet purchased by them.
I also check networked libraries to see if I can request a copy through this route.
I group the books based on aspect (at times I group by size, subtopic, or whether they seem like they will be easier or harder to discern if I want to read them).
I weed through each book to determine which would be helpful, which are redundant or not useful and which I might want to have my own copy of for reference.
Then I read them.
Joined a book club:
I joined a book club that met regularly with other readers. Our book club list contained diverse books to expand my reading experience.
Some interesting things happened as a result of my reading that I did not anticipate.
For books I read on work topics, I wanted to share them with coworkers- but I know not everyone has the time or interest to dedicate. I could recommend whole books, or certain chapters or pages.
I realized that for some books, I just could not digest them in audio format. This has not happened often for me, but if the subject is particularly complicated, or the narrator is (for whatever reason) difficult to listen to, I switched format from audiobook to physical or digital book.
For non-fiction books, I found myself finishing a book, and then skimming through it again to take notes if I didn’t take notes as I read it the first time. This definitely contributed to a stronger understanding of the book’s content.
For 2018 I set my goal to 75 150 books and am working towards it every day.
At it’s simplest the backlog is a list of work we want to do. There are several types:
Sprint Backlog: The work team(s) have committed to do in a sprint, or the work that is prioritized to start first in Lean / Kanban.
Product Backlog: All of the work that has been requested to do for a product or suite of products.
Impediment Backlog: The work to remove or reduce the impact of impediments and blockers for the team(s).
Any high performing team should be familiar with this kind of work. There are a few ways to view what this backlog is to contain. Some describe it as a backlog for the Scrum Master / Agile Coach. Some describe it as a kanban style list of things to improve in the agile implementation for the individuals, teams, departments, even organization as a whole. I suggest the following definition:
Impediment Backlog: a list of impediments for the team(s). With support from the Agile team(s), the Scrum Master / Agile Coach works throughout every sprint to try to remove or reduce the impact of impediments.
Consider that these items in the Impediments backlog should be informed through team interaction during a sprint (or throughout work in Kanban) and solidified and prioritized to work in the Retrospective.
Who is the Product Owner of the Impediment Backlog?
Unblocking the team is not just a job for the Scrum Master / Agile Coach. So, the impediment backlog is not just a backlog for Scrum Master / Agile Coach, it is a backlog for the team.
A high performing team is one who can work together with the Scrum Master / Agile Coach to unblock itself. The Scrum Master / Agile Coach is often the person leading this effort.
The Product Owner of the Impediment Backlog is the team itself.
I often hear about poorly run retrospectives. Below, I’ll describe a few different common problems and some ways I have addressed them. Beyond what I list below, you may want to learn more abut how good facilitation can help any team.
Common Challenge #1: Skipping The Retrospective
The most common challenge for the practice of retrospectives is pretty simple: many agile teams just don’t do them. It can be tempting to skip the retrospective, or allow teams to cancel because “there are no issues to discuss.”
I’m no longer surprised when teams I start working with aren’t holding this ceremony. It takes time, is challenging, and good facilitation of any meeting takes skill. So the retrospective is frequently the first thing to be dropped.
However, in agile, continuous improvement is really important. The difference between a good team and a high performing one lies in retros. You won’t see the kinds of amazing things high performing teams can deliver if you don’t take the time as a team to evaluate what’s working, and what you might try differently.
Teams not seeing much benefit in agile practices need the retrospective to find out why. Good teams need it to become great. Great teams need the retro to stay great.
Hold regular retrospectives for the same reason you take your car to the mechanic. You don’t just take your car to be looked at when it isn’t running at all; you also take it when you realize something might not be working as well as you’d like, and for regular maintenance to keep it running well.
I’ve been asked many times by people new to agile, “When can the team stop having retros?” The answer is when you are perfect. (In other words, from my perspective, never.)
On rare occasions I have worked with teams that proactively address issues throughout the sprint and therefore rely on retros less. However, even mature teams need time set aside to respond to change and improve process together.
To avoid skipping this valuable ceremony, whenever possible, schedule it ahead during a time slot when all team members can be present and emphasize the importance of attending.
Common Challenge #2: Too Short
It’s almost worse than skipping the retro if you aren’t setting aside enough time for discussion. One scrum master I had the pleasure of listening speak on this topic called these PDQ retros: Pretty Damn Quick.
Through the hundreds of retrospectives I’ve facilitated, I’ve found anything shorter than 1.5 hours doesn’t allow the group to dig deep enough. Your experience may be different – and certainly the length needed varies by the team.
Too short of a retro gives you the illusion that you are tackling all team issues while allowing some issues to remain unaired. It takes time for some challenges to be discovered and fully understood, and sometimes the most impactful topics are the most difficult to raise, or aren’t surfaced until the easier and more visible challenges are out of the way.
There’s a few recommended ways to determine the length of time needed for retros that you’ll find if you Google it: from 2 hours per week in the sprint, to 20% of the sprint length. This is never a palatable amount of time for teams or businesses to spend when first adopting agile. Underestimating the value of retrospective practice costs teams much more than the time required for this meeting, but some people and some organizations may need convincing.
One thing you can do if you have pressure outside, or even inside the team to keep this meeting short is ask to try it for the duration you believe best for a few sprints and re-evaluate after. Remember the goal isn’t perfect, it’s just better, so after a few sprints, ask if the parties pressuring for shorter retros still have concerns and work together to find a way forward that everyone feels good about.
Another approach is to schedule them for shorter time slots and limit discussion to a few topics. Set a timer so you leave enough time to wrap the meeting with action items. Work your way into longer retrospectives by proving their value through action item follow up and resulting measurable improvements.
Common Challenge #3: Lack of Constructive Discussion
Another common scenario is lack of constructive discussion.
I see this most when running the retrospective without setting guidelines for appropriate discussion. It’s so important to set the expectation of constructive discourse and ban blaming, shaming, and naming.
The Lean practices of Kaizen and Hansei are one way to approach this. Kaizen is the idea of change for the better – often referred to in the concept of continuous improvement. Big results come from many small changes accumulated over time. This means everyone making small changes and improvements, and involves introspection to discover what you yourself could do better (or are good at and can build on).
This goes hand and hand with Hansei- the idea of acknowledging your mistakes or weaknesses and offering ideas of ways you can improve. Encourage individuals calling out their own faults or issues and things they could do better next time. Other participants must listen objectively and keep feedback positive.
It’s much less threatening for a team member to acknowledge their own shortcomings than it is for other team members to call it out. If your retro takes a turn in the direction of personal attacks redirect. Remind participants, that we’re all in this together. If you can reword comments in a constructive manner and remind participants of the expectations for discussion.
I try to start retros with the Retrospective Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. In other words, we did the best we could. It can help to note that if we could do better we would like to, and that’s what this meeting is about, improving.
Emphasize that we, as a team, through action or inaction, are all responsible for the outcome of a significant event, a sprint, release or project. It is an art to guide discussion to protect individuals but allow the sort of introspection that helps to improve teams. Once you allow one blamer, shamer or namer, the rest come out of the woodwork, often in a defensive posture to scapegoating.
Discussing things from a team responsibility perspective allows the team as a whole to discover ways to address problems and opportunities. It is a powerful feeling to see an opportunity to improve and identify how you might contribute to that, by choice, by building on your strengths, or by trying something new.
Common Challenge #4: Participants Don’t Feel Safe
Lack of trust sets up retrospectives to fail. Missing trust can happen in the beginning stages of a team, when action items are not followed up on, when management or leadership uses feedback discovered in the retro against the team or as a result of numerous poor retrospectives involving lack of constructive feedback that have made discussion feel unsafe.
You can help with trust issues by telling the team the retrospective discussion is private, feedback is anonymous and asking what teams are comfortable sharing outside of the meeting and then following through, every time.
You can gauge the trust in a group by running a Safety Check and addressing the issues preventing safe discussion through a Creating Safety retrospective.
It is essential to address issues of safety before holding a true retrospective as the team will not discuss openly when they do not feel safe to do so.
Common Challenge #5: No Action Items or Action Items Are Agreed Upon and Forgotten
One of the goals of the retro is to agree upon action items and then act on them. Strive for 1-3 action items that the team has agreed to try. If you find your teams ending retros without action items consistently, or agreeing on action items that go no where, that’s a problem!
Ensure action items result from the retro by reserving time for action item discussion in the agenda. Set a timer or have a time keeper help.
After gathering data and generating insights, use filtering techniques to decide what to do.
Ensure action items are acted upon by creating cards, estimating them and tracking them on the agile board, just as you would any other work your team does. Set aside a percentage of every sprint for team improvement work.
You can use a checkout activity like Who What When (found in the Fun Retrospectives by Paulo Caroli and Taina Caetano) to garner ownership of these action items within the team.
Just as important is following up at the next retro on what you did and asking the team, did it make a difference? You could set aside the first 5-10 minutes of retro discussion to review your action items and gather feedback from the team.
Common Challenge #6: Repeating Themes
Repeating themes are a call to action. Issues that come up again and again could mean you haven’t tackled the issue fully, the issue a bigger problem than the team and requires escalation or that the team doesn’t have the tools it needs to address it.
In the case of repeating themes, consider a retro focused entirely on this persistent issue. Preface the session with a description of the problem and what you have tried and ask the team to brainstorm for ideas they haven’t tried yet.
The repeating issue may be one that the team doesn’t think they have influence over. Try using the Circles and Soup technique to reveal what the team does have influence over.
One team I worked with had the same issues come up every retrospective that were organizational issues needing a manager to escalate them in order to solve them. Sometimes the things you can’t change are the easiest to want to change.
You want your team showing up for retrospectives ready to discuss whatever issues, concerns and opportunities that may come out of open exchange. You want your participants engaged.
If you are using the same retrospective method every time (what did we do well, what could improve is one common example), your attendees know what you are going to ask of them each time and you may not be getting the chance to spark creative solutions. Sometimes participants have pre-rehearsed answers, even pre-written post-its that can disrupt the flow of natural discussion and discovery.
It is important to keep the discussion alive and interesting. This can be done by varying check-in and check-out activities as well as the main retrospective itself. Asking the question of how we can improve in a different way can help the team think about it’s challenges differently.
Some team members may feel uncomfortable with varying technique, so you can give participants an idea of what’s to come with an agenda prior to the meeting as well as labeled sections on the white board (or large stickies) in the meeting room so they know the general areas we you cover.
Spend time planning activities and have everything set up in the meeting room ahead of time.
Consider the team’s disposition (generally, and at the time of the retro). Some teams love to do something creative like a quick drawing as a check in / set the stage portion of the retro. Some teams don’t like this kind of activity at all.
I track of everything I have tried in retrospectives I’ve facilitated and which things are good for different desired outcomes. When planning a good retro, my focus remains on what success, challenge, or conflict I am seeing in the team, and what issues remain unsolved to help decide on a retro technique to try.
For yourself, create a library of techniques that you can pull from. Good sources include Derby and Larsen’s book Agile Retrospectives: Making Good Teams Great, the Retro-Mat website (Corinna Baldauf) and Fun Retrospectives (book or website) by Paulo Caroli and Taina Caetano among many. One Scrum Master I know uses Pinterest as a source of inspiration. You can also alter techniques to get different effects, and or try something brand new.
Consider a 5 stage or 7 stage agenda to surface team challenges and find your way to action items.
There are different methods to spark discussion on different topics, to build the team, and to discuss team goals. It’s a good idea with a new team to try techniques that encourage the discussion of working agreements, role expectations, the behaviors or attributes of a model team member versus the behaviors or attributes of team members that are not easy to work with. Discussing future desired state is a great idea as well.
There’s More: Resources to Read More
This is just a starting list. Others have written about common ailments and ways to tackle them. If you think you’re retros could go better, you’re probably right.
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.
2016-01-06 / carina / Comments Off on 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.
Sugar (Refined white sugar ferments faster than organic and less quickly minimally refined sugar)
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.
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
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.
Switch your ferments lid with a coffee filter and rubber band.
Your ferment is an aerobic organism and needs oxygen to survive.
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.
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:
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.
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.
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.
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).
This is a modified version from here, modified to emphasize necessary steps for successful ferment, there are additional options listed at the website above.
Cutting board, knife
Large bowl, large plate that can cover it and can of vegetables or paper weight
Food safe gloves (non powdered)
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)
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
Slice the cabbage into 2-inch-wide strips.
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.
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.
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.
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.
Mix thoroughly: Using your hands, gloves recommended, gently work the paste into the vegetables until they are thoroughly coated.
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.
Add water if needed so that vegetables are submerged.
Seal the jar with the lid.
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.
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.
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.
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:
Releasable, working and tested software every sprint.
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.