3 Steps to Learn + Connect with Agile Experts via Social Media

Though books are a wonderful way to learn, beyond all the wonderful pages of information and writing, we have a new dimension available to us now – we have access to the actual people behind the words.

Thanks to social media, we can now personally learn from the experts, speakers, thought leaders and authors.

In my opinion, this is like having access to the most awesome library imaginable! It’s priceless, yet it’s available for free!

We can ask questions, debate and discuss theories, tools and techniques. If we read something that we don’t quite understand, we can go directly to the author to dig deeper, explore, dissect and innovate.

And what’s more, we can even become friends … not just superficial “virtual” friends, but form real-life connections based on shared interests and mutual respect.

Take any topic and you will most likely find others who have similar interests on LinkedIn, Facebook and Twitter.

If your interest is agile topics, there are hundreds of agile groups on LinkedIn, and agile pundits tweeting about everything agile. All you need to do is join in the conversation!

There is so much available, in fact, that it might seem overwhelming to know where to begin. Start with understanding your objectives. Are you trying to learn a particular methodology? A tool? Gain experience and knowledge to beef up your resume?

For those new to social media, I’d suggest these three phases of participation similar to the ShuHaRi model of mastery:

1. Read, Learn, Connect

2. Comment, Discuss, Share

3. Create, Write, Teach

1. Read, Learn, Connect

Start with finding social media related to the topics that interest you most. You can find blogs, LinkedIn Groups, forums, ebooks, courses, podcasts, SlideShare presentations, YouTube videos and other avenues to learn.

Many authors offer free ebooks in exchange for your subscription to their mailing list.

If you don’t have a LinkedIn account yet, get one and create a profile. LinkedIn is the best social media site for business and careers.

Then, whenever you read or learn from someone, request to connect to them via LinkedIn. Let them know in your request that you are interested in learning more about their topic and thank them for the blog post or whatever it was that led you to them.

Follow them on Twitter, subscribe to their blogs, and “friend” them on any social media that they advertise on their sites. If you find that you’re getting too much email, you can always unsubscribe, change your settings or set up an RSS feed.

However, by connecting to these experts, you will naturally be led to others as these connections post links or pass along information about similar agile circles and communities.

2. Comment, Discuss, Share

Bloggers love to get comments. Even if your comment is simply a “Thank you for your post,” your comment is appreciated and will help raise engagement on the blog.

Likewise, simple likes, re-tweets or sharing through various social media channels will not only help to establish you as someone who is interested in these topics, but will also help strengthen your connection with the authors.

Sharing a post or tweet is so easy, and it’s really a win-win. You are doing a service to others in the community by sharing information and the author feels happy for the recognition.

Taking this one step forward would be to add a longer comment with your own experience or ask a question. Once again, the authors will appreciate that you took the time to engage in discussion and will welcome respectful dialog.

This is another opportunity to form a connection with the thought leaders. If you are someone who comments on their material, they will recognize your name and you’ll gain some visibility as someone who is interested in learning and sharing.

LinkedIn Groups also give the opportunity to pose questions and engage in discussions with others with similar backgrounds and interests.

3. Create, Write, Teach

Finally, as you gain expertise, start your own blog or discussion forum. When I was laid off in 2009 and looking for a QA management job, I started a blog as a way to learn, network and gain some credibility, should anyone decide to “Google” me.

I started by blogging about everything I was learning from all these different social media avenues. Then I branched into interviewing other QA managers I’d connected with on LinkedIn, and started doing podcasts or Q&A sessions that I’d publish on my blog.

I remember writing about Cem Kaner – a well-known QA leader who I greatly respected and had once quoted in my master’s thesis on measuring software quality. Imagine how surprised and excited I was when he left a comment on MY blog!

I soon was getting other comments from QA and agile experts and feeling elated that these big-name experts and authors were communicating – some even on a personal level – with me … an unknown, unemployed blogger!

I became “real life friends” with Lisa Crispin, who I always admired, and who co-authored what I consider the most comprehensive and well-known books about agile testing.

My blog led to a job, but not the job I’d expected. I was offered a position as the site editor for, and soon was going to agile conferences, networking, interviewing and writing about agile development and software quality for a living.

Though I eventually went back to a QA management job, writing and networking with agile and QA professionals allowed me the best professional development I’ve ever had in my career.

What’s particularly thrilling for me is that many of the agile greats are now my Facebook friends, and I get to know them on a more personal level. Mike Cohn, with his humor and puns, is an absolute favorite.

Besides blogging, there are many other ways to share your knowledge and expertise with others. Volunteer to speak at user groups or events, host a podcast or YouTube channel, train, coach or mentor others who want to learn.

Social media is the ultimate tool in allowing us to learn and master any skill. However, beyond the written word, we have exposure to the minds of great leaders.

Take advantage of this treasure and you’ll soon find that not only will you grow your skills, you’ll also form life-long relationships.

Lessons Learned in Preparing for the PMI-ACP Exam

I happen to be a very good test-taker. When I was young, I thought it might be fun to have a job helping people who were preparing for standardized tests like the SATs.

Though I never had that particular job, now that I’m an agile coach teaching a course that helps people prepare for the PMI-ACP exam, it’s right up my alley. Of course, to qualify to teach that course, I had to first earn the PMI-ACP certification myself.

“No problem!” I thought. I’ve been totally immersed in “everything agile” for years, so it should be a piece of cake to get certified. I filled out the application and had the requisite experience and training, so now I simply needed to take the 120-question test.

The day before I was scheduled to take the test, I got my hands on a couple of sample exams. I’m embarrassed to say that I didn't do very well on them. Even though I thought I knew everything there was to know about agile, apparently I didn’t know how much I didn’t know!

Besides kicking myself for waiting until the day before the test to take the practice exam, I was also annoyed that I didn’t even agree with some of the answers on the practice tests, many of which I felt were really a matter of opinion.

For example, one of the questions on the sample exam was:

"A project retrospective is scheduled to last an entire day. One of the stakeholders asks if they can drop in and drop out throughout the day. What should the retrospective leader tell this stakeholder?

a) Tell the stakeholder full-time attendance is necessary because each part of the retrospective structure builds on the preceding portion.

b) Tell the stakeholder it's okay to drop in and drop out since their feedback is important.

c) Ask the stakeholder to still attend the retrospective and bring their other work with them to do in private.

d) Reschedule the retrospective until every participant's schedule allows for full-day attendance.”

Correct Response: D … Did you guess that?

“Drop-ins slow down the retrospective process; drop-outs send a different, often puzzling message. Set the expectation for full-time attendance as recommended in this answer choice.”
- Esther Derby and Diana Larsen, "Agile Retrospectives," Chapter 9

Wait a minute! Reschedule? Really? This is not a very realistic answer, since rescheduling to suit one stakeholder’s schedule will undoubtedly cause a problem for someone else. Waiting until everyone is available all day is likely to either be unrealistic or cause a long delay.

I had picked answer “A” and I still think that’s closer to “setting the expectation for full-time attendance.” Also, the question asks what the leader should tell the stakeholder, and “D” is the only answer that doesn't tell the stakeholder anything.

This is just one of many examples where the “right” answer was somewhat ambiguous.

I really didn’t have the time or ability to dig into all the answers I disagreed with, so I focused on learning unfamiliar material and memorizing all I could before the test.

Luckily, I passed the exam, which was easier than the sample tests, but still had a number of questions which I felt were not at all black and white. Agile suggests that we don’t assign black-and-white solutions to problems, but consider the context.

I thought many of the questions would be good for discussion, and that even the experts would have differing answers. It would be nice if we could have the answers as well as explanations on why a particular answer was considered “right,” but for now, I’m just happy to have passed despite my lack of preparedness.

PMI provides some tips and a reference list of materials to prepare for the test. They did allow feedback about the questions at the end of the exam.

Overall, I think it might be interesting to have a panel of agile experts (maybe all the people who wrote the books referenced) take the exam. Any question that gets different answers from the experts should be, in my opinion, eliminated or reworked.

In general, I’m not crazy about “certifications,” but I understand their purpose. This is not an easy one to earn and should instill credibility and respect for those who do earn it. On the other hand, I think the test questions need to be better vetted.

Lessons learned:

Don’t wait until the day before the exam to start preparing. There’s a lot more information in the agile reference books than I realized. Don’t depend on PMI-ACP practice exams as your sole resource for studying.

If I hadn’t passed, I’d be very curious to know which questions I’d missed and whether I’d have a chance to contest them. But luckily, I did pass. Taking the exam forced me to study and recognize that there was a lot I didn’t know.

Learning is always a good thing and for that reason, I’m happy to have had the experience. 

Have you taken the PMI-ACP exam? What are your thoughts on it? Let me know in the comments below.

Physical vs. Electronic Task Boards – Which Is Better?

I recently spent a few days on a coaching assignment with a small team that transitioned to agile about a year ago. We started with a retrospective of their agile practices, and I found it interesting that a task board they could physically touch was something the team liked best.

Obviously, agile practices promote the use of a physical task board for several reasons, and this team really was seeing the benefits. Here are some of the reasons they so enjoyed their task board:

-They have fun with it. For example, they each have their own Lego superhero figures, which reside on the cards they are working on. -The physical board is a great “information radiator,” providing visibility and transparency into what everyone is working on without the need to log into a tool. Because this is the only team practicing agile, the task board provides other teams with a little peek into how an agile team operates. -The physical board helps sort out what they're working on in the sprint without them digging through emails, spreadsheets or any other tools. They liked this low-tech approach, which, of course, is what agile methodologies promote.

I found this interesting because personally, I’ve had some issues maintaining a physical task board, and wondered if the very notion was going “out of style.” I’ve often thought electronic boards were preferable because:

-You don’t have to be physically present to see the status of the board (especially useful if you have remote team members or anyone who works from home). -Electronic boards will calculate velocity, burn down and other metrics for you. -You have documentation that will store data about the user stories, which is handy for traceability if similar stories or questions come up. -If you have both physical and electronic boards, you have two different records, which is usually a mistake because of the potential for maintenance and consistency issues.

Because this team chose not to use burn down or burn up charts, they did not have the cumbersome task of manually calculating these numbers or keeping both a physical and electronic board in sync.

Though the team felt good about their physical task board, they weren’t crazy about their stand-up meetings. Because their task board is in a hallway, having the stand-up meeting near it created disruption for others in that area, so they had their stand-ups without the benefit of their task board. 

Also, team members were allowed one weekly work-from-home day, and they chose not to call into their stand-up meeting during those days. Stand-ups often started late and went long. For these reasons, the stand-up meeting rated low in their assessment of the usefulness of their agile practices.

So here’s the solution that was created: In order to keep the benefits of their task board, and address the concerns of their stand-up meeting, the team decided to hold stand-ups by the task board, promising the people sitting close by they would minimize the noise and limit their meetings to 15 minutes.

This change also provided incentive to keep the stand-ups short and focused. If someone is working from home, they answer the stand-up questions via email and have a delegate make the updates on the task board.

The textbooks recommend a physical task board. And the team I highlighted today certainly realized the benefits of it. But, there were definite issues in the stand-up meetings due to not having the task board available. It was rewarding to see the team discuss the different issues and come up with a solution that worked best for them.

Do you prefer physical or electronic task boards? Let me know in the comments below.

Learn from the Agile Skeptics

When I’m teaching a class on agile basics, I like to play a game where I give points to the people who challenge what I’m saying or give examples of when what I’m saying might not always be true.

Not only does it encourage class engagement, it gives people an opportunity to safely disagree.

I embrace those who are skeptical about agile development and encourage them to tell me more. Once they see that I will not become defensive, and in many cases, even agree with their concerns, they are much more open to working at coming up with solutions or at least, a common understanding.

This technique of using opposition to your advantage is one change management pattern that Linda Rising and Mary Lynn Manns describe in their book, "Fearless Change: Patterns for Introducing New Ideas."

When I encounter people who “don’t like agile,” and I ask them why, I would say there are two categories of answers.

The first category has to do with what I’ll call “hype” (i.e., it’s sold as a silver bullet) and the second category has to do with “process” (i.e., we need more planning up front).

Let’s talk first about complaints that fall into the first category – the hype. In the post: How do you convince an agile skeptic? by agile coach Daniel Markham, he says these are the reasons why people are against agile:

Fake success stories Trainers who can't do the work Inflexibility on the part of adherents "Feel good" agile Magic Bullet syndrome Reversal of team dominance Cargo Cult agile Non-answers to questions Conflicting advice Scamsters It's the same, only different Little Gold Star syndrome

Markham does an excellent job of describing these negative perceptions of agile, followed by some basic descriptions and definitions of iterative development, incremental development, Scrum and agile.

In the case of “hype”-like complaints, I think the skeptics make a good point!

The best way to address this type of complaint is with good education and training on Scrum (agile’s most common methodology) and agile (a set of principles and mindset, rather than a prescriptive methodology).

As for “process complaints,” I contend that those complaints are more likely aimed against a poor implementation of Scrum vs. a complaint against agile.

Agile (and Scrum, for that matter) promote the practice of “inspecting and adapting.” So if you have a problem with a process, bring it up, and work as a team to try and improve that process.

A link to a more recent blog post from a skeptic was sent to me the other day on how agile is the new Waterfall. Actually, I’d say the author of this post is more negative than a typical agile skeptic.

He appears to be an “agile hater,” claiming that “agile has become everything that Waterfall was to developers and worse. It is a sheep in wolf’s clothing and I’m going to expose it here today.”

I won’t go through the entire post (which would result in a virtual field day for those of us who like to “learn from the skeptics”) but filter out what appear to be some of the “process concerns”:

“The reality of agile is that you still have immutable decisions made by business people with no real understanding of technology. Those decisions are then forced on to developers.” “Unfortunately, with little or no documentation, now the developer is accountable for the outcome while having little or no authority to create a winning one. This responsibility without authority makes agile even more toxic than Waterfall.” “The addition of the daily “scrum” ensures that anyone who is perceived to be working too slowly (whether this is true or not) is immediately highlighted. This type of “boiler room” atmosphere may work great for a few, but for most it is a source of significant stress and ultimately lower productivity.”

Again, these issues are more likely due to a new Scrum implementation. This author seems to be using “agile” and “Scrum” interchangeably, as many people do, which certainly adds to the confusion.

In fact, the post ends with a suggestion of starting over with minimum process, which the author admits is agile, but says it’s with “a lowercase a agile, not uppercase a agile.”

(Note there is currently no standard on the use of lowercase agile vs. uppercase agile. As a writer, this is frustrating for me, but I digress.)

The author has come up with what he feels are solutions to the above problems, which is great. However, I would suggest that these problems are not experienced by most Scrum teams and his solutions are not appropriate for everyone.

I’d also suggest that when a team is experiencing process issues, they stop, reflect and adapt. It’s not clear whether or not the problems this author experienced were discussed in a retrospective, but had they been, the team may have been able to resolve these issues and continue to improve.

Neither Scrum nor “agile” (upper or lowercase) are going to be perfect or make software development easy. If someone tells you that, challenge them.

Whatever processes you use, the team is bound to encounter problems. Listen to those problems and work as a team to resolve them.

Healthy skepticism is a good thing. Listen to and enlist help from the skeptics in finding solutions in order for your team to continue to learn and grow.

Agile ShuHaRi

ShuHaRi, a term that originated from Japanese martial arts, is often used in agile classes to describe a learning model.

Shu represents the first stage when the student imitates techniques.

Ha represents the second stage when the student understands the underlying principles and theories, and feels comfortable making modifications, keeping the principles and theories in tact.

Ri represents the final and the most innovative stage. The student is creating his own approaches and adapting what he’s learned to his unique circumstances.

When I’m teaching students who are new to agile, I use a cooking analogy, both to describe ShuHaRi and to describe the difference between what it means to “be agile” versus following a methodology, such as Scrum.

I tell the class that agile is like cooking and Scrum is more like a recipe. Agile gives us the manifesto and the 12 principles, but does not provide a step-by-step “cookbook” approach to either project management or developing software.

When we are new cooks, we need to follow a recipe. This is the “Shu” stage of learning to cook.

As we become more familiar with different flavors, we reach the “Ha” stage, feeling comfortable modifying the ingredients to our taste.

Finally, as we become chefs (“Ri”), we create new recipes or maybe write a cookbook ourselves, striving to create a unique and innovative set of recipes or approach to cooking.

If we compare this to agile, when we are new, it’s best to use the more prescriptive approach to following a methodology, such as Scrum. In other words, we need to “follow the recipe” at this stage.

Though agile promotes adaptability and flexibility, when a team is new and still in the “Shu” stage of learning, they are probably better off starting with the recommended “best practices” provided by the experts.

Too many people feel that they will be more agile by not following a recipe or rule book, but that really depends on how experienced the team is.

If you have a bunch of people who are inexperienced cooks who throw a bunch of ingredients together without really understanding the concepts behind cooking, the chances are that your resulting dish is not going to taste that good.

Similarly, inexperienced agile practitioners who pick and choose different agile techniques to follow may end up with a methodology that doesn’t work too well.

It’s really better to at least start with that recipe. However, having the benefit of gathering feedback and constantly adapting and improving allows the team to develop the skills to move to that next learning stage.

Whether it’s cooking, music, art, software development or project management, when we are new, we start the learning process by imitating others.

Over time, we gain the skills to make modifications, and at the highest levels, we create something entirely new.

Agile: Not Just for Software Developers

“Let’s create a backlog for all the things you want to do,” I tell my friend, Joe, trying to convince him to give Scrum a try in helping to manage his ever-growing personal to-do list. “Then we’ll pick the highest priority things and you can focus on those for the next two weeks.”

At the end of those two weeks, Joe had started on a bunch of things, but hadn’t finished much. “I think your ‘stories’ need to be smaller and you need to limit your WIP,” I advise. “Finish some of these before you start on anything new.”

After breaking down some of his bigger stories into more manageable chunks, the next two weeks showed much more progress – and some of the projects that had been on his to-do list for months were finally done! He was an agile convert!

Agile, No Matter What the Situation

There’s something about checking off an item as complete that really gets your endorphins flowing. That was a comment from a student in an Agile Boot Camp I recently taught for a bunch of engineers that were not software developers.

At first, they were very skeptical about using agile, feeling like the concepts really wouldn’t apply (because in their field, they needed to know the entire design up front).

However, the more I described various techniques for creating smaller stories and continually checking in for feedback, the more head nods I got from the class that showed that they could see advantages of working in a more agile manner.

There are certain concepts, such as working collaboratively with customers, breaking tasks up into manageable pieces and continually “inspecting and adapting” that make sense no matter what domain you work in.

I recently wrote an article about personal Scrum giving examples of ways Scrum is being used outside of software development and was especially impressed with the creative use of Scrum in wedding planning by Hannah Kane and Julia Smith in their business venture, Scrum Your Wedding.

The article I wrote generated comments including a reference to the book, "Agile Kids," which promotes the use of agile techniques to empower kids to be in control of their tasks while still respecting parental authority.

The Tools to Manage Anything

Agile concepts and techniques are proven project management and leadership practices that work well both in business and in personal life, regardless of your profession.

You don’t have to be a software developer or techie to jump on the bandwagon. Start by learning some of the terminology and concepts, and then if you want to get some experience, try using the concepts to manage your personal to-do list.

Elicit a friend and work together on some of the tasks. Spend some time after each iteration to host a retrospective so you can “inspect and adapt.”

Mike Cohn describes how he uses Scrum in his personal life using tools like Things and Asana. I’ve used Trello, a free, easy tool that provides a task board that will help you visualize your workflow.

Don’t get too caught up in tools if you’re new to agile, though. Simply using a pen and paper or even notecards or sticky notes is fine and even encouraged in agile circles.

Undoubtedly, as agile techniques continue to become trendy in everyday life, people will start to refer to their “backlog” or suggest they should “time box” an activity or “limit their WIP.” So, why not get ahead of the game?

Do you use agile techniques in your personal life or to manage your own to-do list? What are creative ways you’ve seen agile used outside of software development?

Large-Scale Agile: SAFe and DAD More Friends Than Competitors

One criticism of agile has been that it’s tough to scale. In answer to that, new methodologies and frameworks have cropped up designed to better handle enterprise, large-scale projects, taking into account agile principles.

I recently took a Scaled Agile Framework (SAFe) class and earned my SAFe Program Consultant (SPC) certification from Dean Leffingwell himself! It turns out, Mark Lines, co-author with Scott Ambler of the "Disciplined Agile Delivery" (DAD) book was also in the class. What an awesome opportunity it was for the class to learn about these two frameworks from the true experts!

Both Dean (on the right in the picture) and Mark (on the left) acknowledged that SAFe and DAD were not competitors. SAFe is more prescriptive and primarily uses Scrum at the team level, and extends the framework to outline roles, ceremonies and artifacts at the program and portfolio levels using a variety of lean and agile concepts.

DAD is described more as a process framework that helps users determine a methodology that might be right for their situation. I reached out to Scott Ambler via email, and he described the difference this way:

“In many ways SAFe is an instance of DA. Where disciplined agile provides choices, SAFe instead makes a collection of choices for you and shows how that subset of DA works together. As long as you’re in a situation where those choices make sense, then SAFe can work for you. If your context is different, then you need to make a different collection of choices. If your organization has adopted SAFe, then it should take a very close look at disciplined agile for tailoring advice to help you to evolve SAFe into something that will fit well in your environment.”

Both SAFe and DA use many techniques that originated from various methodologies. In fact, so many agile methodologies mix and match techniques that most people don’t even know where they originated. I only learned recently that user stories originated with XP. I’ve seen them used so often in Scrum that I assumed they originated there; but, in fact, the Scrum Guide doesn’t even mention user stories.

Though many people act as though the various methodologies are in competition with one another, they actually are quite complementary. Even waterfall and agile can play nicely together!

Scrum has become such a popular agile methodology, that many people use the terms agile and Scrum as synonyms. This happens when one brand seems to have cornered the market. When I worked at IBM, management warned us that we were not to use the term “Xerox” when making a copy because IBM made a copier, too. And I’m sure Microsoft is not crazy that people suggest “Googling” rather than “Binging.”

So while Scrum is not the only agile methodology, its popularity is so prevalent that it’s a good starting ground for those new to agile. Certainly, learning the terminology and concepts associated with Scrum will provide a good basis for any agile training.

True, learning agile can be a bit overwhelming because there are a variety of methodologies and techniques that fall under the agile umbrella. These are not competitors in which an organization must choose one right way of operating, but more a toolkit with choices.

Though Scrum started by addressing the needs of small cross-functional teams, it can be extended, and frameworks such as SAFe and DAD are emerging that help further the agile toolkit for the enterprise.

Should The Product Owner Attend The Retrospective?

One question I get asked a lot is:

Should the product owner attend the retrospective at the end of the sprint?

The word “should” makes this a multi-dimensional question, so first, I want to address a slightly different question.

Can the product owner attend the retrospective?

This one is easier to answer, because according to the Scrum Guide:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

Since the Scrum Guide also states that the Scrum team = product owner + Scrum Master + development team, we can deduce that (officially at least) the product owner is allowed to attend the retrospective.

Now whether they should attend is not as easy. Having worked with many many Scrum teams and seen many, many retrospectives, I have noticed two patterns:

The best Scrum teams tend to have their product owner attend their retrospectives The worst Scrum teams tend to have their product owner attend their retrospectives

What I have determined from these two patterns is that the product owner attending a retrospective tends to have a big impact on the development team in one way or another. In the positive examples, it is a very clear symbol of everyone acting as one team, working together collaboratively to improve the overall situation with true transparency and respect.

In the other cases, I see teams avoiding issues, scared to speak up and customers looking for individual SMART goals for improvement and targets for velocity growth.

Going back to the Scrum Guide, the Scrum Master is responsible for “removing impediments to the Development Team’s progress,” and if the product owner being present at the retrospective is proving to be an impediment to the team feeling comfortable and exploring their situation, reflecting upon it and identifying ways to improve their process, then you could argue that the Scrum Master should remove that impediment.

As a coach, the Scrum Master would most likely coach the product owner in the impact they are having on the team, and how that is ultimately affecting the results they are receiving from the development team. This is because, in an ideal world, having the product owner present at the retrospective has got to be better than not having them there.

As the Scrum Guide points out, the retrospective is for the Scrum team, and any decisions that are made in order to improve the Scrum team’s process will inevitably impact the product owner. Making decisions is an important part of our THEMED structure of facilitating retrospectives:

Topics to help everyone focus in on a specific area
Hooks to engage all attendees as soon as the meeting starts
Events of the last sprint or iteration using interactive exercises
Meanings behind the events
Else - exploring variations on the exercises or considering alternative perspectives or things they might be missing
Decisions they need to make as a team to move forward

You can find out more about this structure and get some ready-to-use templates for retrospectives in my newest course with agile coach Paul Goddard -- the "THEMED Retrospective Handbook" -- here.