Posted By Meghan Robinson,
Tuesday, August 2, 2016
Updated: Tuesday, August 2, 2016
| Comments (0)
AUTHOR: LAURI PIISPANEN
A video interview can be a daunting experience. Talking to a computer is nothing like speaking with a live person. This, coupled with the fact that, even in today’s age of selfies, few of us are used to seeing a recording of ourselves, can make the whole interview session seem like a harrowing ordeal. That’s why I decided put together a list of a few things to focus on that can make the whole interview a much more pleasant experience.
It’s good to also bear in mind why video interviews are used: professional recruiters can receive a greater amount of applications and, at peak times, scheduling face-to-face meetings can require a significant amount of work. Video interviews allow the recruiter to kick-start the recruitment pipeline process. This means that if you’ve received an invite to a video interview, you can already pat yourself on the back – obviously the recruiter is interested in hearing more about you! Now all you need to do is remember these five tips for how to nail a video interview, and you’re sure to make a good impression!
1. Check your gear
Before starting, take a quick glance over your shoulder: how will those dirty dishes behind you contribute to your overall appearance? It should be pretty easy to find a solid-colored wall in any ordinary home or office – use that as backdrop instead. Next, make sure there’s enough light in the space you’re recording. Turn on as many lights as necessary to achieve good overall lighting.
Once you’re satisfied with the visuals, record a short test clip with your computer or smartphone. Is the audio okay? Adjust levels if necessary, or find a different room if there’s too much echo or background noise. It is imperative that your speech is intelligible. If you’re experiencing any technical issues at this point, make sure to contact your recruiter. They’ll help you sort out any issues or suggest a workaround.
2. Relax, take it nice and slow
A live broadcast can be extremely difficult, even for seasoned veterans. Thankfully, all video interview platforms allow an unlimited amount of retakes. A good technique is to first listen all the way through the question, then draft your answer using pen and paper or a text editor. Pick three or four key points to highlight. This’ll help you focus and stick to the point in your answer. It’s a good idea to place your notes next to the webcam while recording, so you’re not relying on memory alone.
3. Keep it concise
At this point, it should already be quite clear to you what you’re going to say. Go ahead, press that red button and record your answer! This shouldn’t take more than 1 to 2 minutes. If you’re way past this length, double-check your answers with an eye for detail. Are all the details relevant in conveying your message? It only takes six words to tell a story, so there’s really no reason you can’t get your point across in fewer words as well!
4. Do a retake if needed
Now take a good look at the video you just recorded. Forgot what you were trying to say? A sudden cough took you by surprise? No problem, you can always do as many retakes as you like. This really is the best feature of video interviews, and you should take full advantage of it.
5. Don’t forget to smile
While it’s never a good idea to flat-out lie to your interviewer, you can certainly do that to yourself. Focus on having good posture, and flex those cheek muscles! This is a way of telling your body you’re enjoying the situation, and that’s something that will definitely come across in your video. Let’s make this an enjoyable experience together!
Don’t forget to bring your own personality into play. Even though this isn’t Comedy Central, there’s no reason to be too serious. I’ve seen my share of juggling, guitar wizardry, cats and Rubik speedcubing, and they always manage to put a smile on my face!
With these five tips, you should now be ready for your video interview. Once again, you’ve already made your way past that first step. Now focus on your presentation, and the position is yours!
This article was originally published on Reaktor.
Posted By Meghan Robinson,
Tuesday, July 19, 2016
| Comments (0)
AUTHOR: GEZ SMITH, Lead Agile Coach at HSBC
It’s been an interesting 15 years since the Agile Alliance met in Snowbird, Utah to write the Agile Manifesto. Agile, and its frameworks like Scrum, have gone from being the niche interest of a few software development teams to the highly sought tool of the business mainstream.
All over the world, companies use Agile to respond to change, build collaboration, drive up quality, and create happier employees. Many more companies are beginning to realize that their market environment is changing so rapidly that they need to find a new Agile way of working in order to keep up.
However, one element of the working world hasn’t kept pace — the realm of hiring and recruitment. When it comes to Agile, recruiters often just don’t know what’s involved in the roles they’re hiring for. That’s a shame, as the more they know about the roles they’re hiring for, the better they can find the right candidates for those roles. It’s not unusual, though, as it’s hard to be a specialist in every department or type of work.
There is another aspect of Agile recruitment that is more troubling. Agile is a whole new way of working, a whole new way of seeing the world of work. What if you just can’t recruit into Agile roles the same way you would for more traditional working environments?
Earlier this year, I noticed that recruitment consultants in the UK really didn’t understand Agile and its frameworks. They’d write “AGILE” instead of Agile, or “SCRUM” instead of Scrum, as if these words were acronyms like that other project delivery stalwart, PRINCE2. Moreover, they didn’t know what the different Agile certifications meant, or didn’t bat an eyelid at hiring a Scrum Master for a Scrum team of 15+ people.
I thought I’d see if anyone else was noticing these problems, and set up a simple website with two online surveys: one for recruiters, and one for Agile practitioners. The surveys asked the following questions:
Whether people thought there was a problem in this area;
Whether Agile practitioners were happy with the current state of Agile recruitment; and
What recruiters needed to learn to make things better.
The results were emphatic, as 90 percent of Agile practitioners said a lack of understanding of Agile and its frameworks amongst recruiters and HR professionals was a problem. On top of this, nearly two-thirds of the practitioners said they had been dissatisfied or very dissatisfied with their experience of using a recruiter to find a job in Agile.
Interestingly, 29 percent of recruiters said their Agile knowledge was good or excellent, while only 3 percent of practitioners rated their recruiters’ knowledge as good, and none of the practitioners who responded rated it as excellent. At the other end of the scale, only 10 percent of recruiters said they had no Agile knowledge, while 41 percent of practitioners said their recruiter had no knowledge. Perhaps recruiters just don’t know what they don’t know?
On the other hand, perhaps this problem has its roots in the fact that recruiters don’t specialize in Agile hiring alone, making them generalists rather than specialists? Only 12 percent of recruiters who responded said they only hire into Agile roles, and 83 percent said they hire for both Agile and non-Agile roles. How can they be expected to understand Agile in depth when it’s only a part of their daily hiring work?
However, these are just statistics. What problems do these stats actually cause? Practitioners were free to write openly in response to the survey about the problems and knowledge gaps amongst recruiters, and they didn’t hold back. Some felt that the roles being advertised would never work if someone was hired into them. One practitioner noted that “[t]here are a lot of Agile project manager roles I see advertised. [S]ome of these are Scrum Master roles, some are Project Manager roles, some are weird hybrids which make no sense at all.”
More fundamentally, practitioners felt that a lack of Agile knowledge amongst recruiters made it difficult for them to assess the different candidates’ skills and experience. As one practitioner put it, “They don't understand the skills required in a good Agile coach. They look for years of experience regardless of Agile knowledge.” Another practitioner observed: “Just because someone has a ScrumMaster certification, it doesn’t make them a coach.”
It also doesn’t help that it is hard to show certain aspects of Agile on a resume. For example, Agile needs servant leadership, but how do you demonstrate servant leadership when resumes are about what you have delivered, not what you have helped others to deliver by acting as their servant.
Some acknowledge that these problems happen further up the line with the person who has the vacancy to fill, but as one practitioner explained, “Their clients often don't understand, so recruiters compound the problem instead of fixing it.”
Context and environment is hugely important in Agile, and one practitioner felt this was often missing from the recruitment process: “Agile is seen as a thing people do rather than a cultural mindset...so many ScrumMaster job descriptions are cut-and-paste jobs, where the nuances of what is required in that specific context are not mentioned.”
Other practitioners backed up my original hypothesis: that hiring for Agile roles may need to be very different from the way hiring has traditionally been run, writing that “Recruiters think Agile is a process like any other SDLC process, which [it] is not, and that is the problem,” and that “[Agile] is more cultural and human than a functional process. Finding cultural fit and empathetic individuals is important. You can't recruit for these roles in the same way as you would (for example) in traditional project management.”
So what are the problems with all of this? Practitioners noted many, but the most worrying issue concerned recruiters putting the wrong people into roles. This role mismatch leads to the failure of Agile transformations and alienates the best candidates. One practitioner even admitted that they like it when some recruiters write “SCRUM” and “AGILE,” as it’s a clear sign they don't know what they’re talking about, warning the practitioner to avoid applying for that role. Fundamentally, a recruiter’s lack of Agile knowledge will harm the company’s bottom line.
So, I’ve taken all of this feedback and data, and used it to create a potential solution to the problem. Recruiters clearly need training in Agile, but they stated clearly that they work in a fast-paced, pressurized industry with little spare time, and that they didn’t want to share their knowledge gaps with potential competitors.
I’ve put together a comprehensive online training course that offers a solid grounding in Agile — one that’s been tailored specifically for recruiters and hiring managers.
To learn more and get started, visit www.agileforrecruiters.com.
This post has not been tagged.
Posted By Meghan Robinson,
Monday, July 18, 2016
| Comments (0)
So, you're thinking about an Agile career path, but aren't sure if it's right for you? How does a position on an Agile team really differ from any other position?
The Agile mindset has many benefits, but it’s not for everyone. Here are seven important considerations when exploring your options.
#1 Shared Values
When you work with other people in the Agile community, you share a core set of values with them. This shared belief system typically results in Agilists working well together. Agilists:
Put the Customer First The highest priority in Agile is to satisfy the customer. If you are someone who wants to produce great things that provide customer value, Agile is a good fit.
Collaborate, Collaborate, Collaborate Agile practitioners also values collaboration. If you are someone who prefers to work alone, this framework may align with your sensibilities . However, if you enjoy teamwork and eliminating hierarchy in organizations, you will find great satisfaction within an Agile role.
Communicate to Innovate If you are someone who enjoys face-to-face communication and problem-solving, you've come to the right place. If you prefer sitting behind your desk and having someone tell you what to do, then Agile is not the way for you.
Act on Fast Feedback Are you someone who enjoys continually improving and hearing real-time feedback? If yes, you think like an Agilist. If you prefer to do things how they have always been done, then a career on an Agile team will be a misfit.
Be More Scrum You'll also find a commonality between Agile values and the Scrum values of focus, courage, openness, commitment and respect. Agilists feel strongly about working this way.
Agile frameworks are designed for creative people, who enjoys continuous improvement. No matter what your role is, Agile is all about creative problem- solving. You will constantly strive to find new ways of working and creating a better product. If you don't enjoy working through a product’s development creatively, then you may want to think this whole Agile thing through.
Are you sick of being told what to do and how to do it? Then you will love working in Agile. Most Agile organizations trust the team to do the right thing, and they empower people at the team level (not the manager level) to make important decisions.
An April 2014 a study of 1,562 adults conducted by theAmerican Psychological Association found that when employees felt valued by their employers:
92% felt satisfied in their roles.
91% said they were motivated to do their best.
#4 Personal Growth
In Agile, transparency is critical. You must be okay showing your work at all points along the way, even if it's not done. If you're an open book, you will thrive in an Agile role. Agile is great for having team members tell you where you need to improve and helping you get there.
#5 A Professional Network
The Agile community is not only very active, but extremely supportive. Most practitioners share Scrum Alliance's mission of "Transforming the World of Work" and will put that above all else.
In addition, there are tons of books, blogs, user groups, gatherings, and collaborative discussions happening virtually and in person. These will help you connect with other Agile practitioners.
#6 More Moolah
Who doesn't like a little more moolah? As an Agile professional, you can pursue specialized certifications such as the Certified ScrumMaster (CSM) certification. CSMs have a specialized skillset that's in high demand. As more and more companies are transitioning to Agile, that demand is only going to increase.
According to Indeed, the U.S. national average salary for a ScrumMaster is $103,000 annually, compared to $89,000 for a project manager.
According to happinessworks.com, a catalyst for organizational culture change, "Happiness is a worthwhile investment. Decades of compelling evidence shows that improving happiness in the
workplace delivers significant increases in profit, productivity and innovation, and substantial savings in costs. Happier workers are healthier, more effective in teams, and provide better customer service. Happier businesses attract top talent, and are more able to retain their best workers."
Happinessworks.com states that happiness leads to 30 percent greater productivity, 54 percent better staff retention and 3X higher creativity.
In Agile, we value the happiness of the team members and the team as a whole. In fact, one of the biggest jobs of a ScrumMaster is to ensure team happiness.
If you enjoy producing great products, collaborating with a team, creative problems solving, empowerment, personal growth, a great professional network, a good salary, and a happy lifestyle, take the first step and create an account on AgileCareers.com.
Then, take it a step further by posting your resume; let Agile employers find you on the the only job board dedicated to Agile careers and professionals.
AgileCareers is powered by Scrum Alliance®, the largest, most established and influential professional certification organization in the Agile community with more than 500,000 practitioners worldwide.
AgileCareers.com is built on best-in-class, enterprise-grade job board technology and connects Agile organizations with strong Scrum and Agile talent. Explore AgileCareers today!
This post has not been tagged.
Posted By Meghan Robinson,
Thursday, June 30, 2016
Updated: Tuesday, June 28, 2016
| Comments (0)
AUTHOR: JEREMY JARRELL
If you’ve experimented with scrum, you’re likely familiar with the Scrum Master and Product Owner roles. But just in case you’re not, here’s a quick breakdown: The Scrum Master is responsible for ensuring that the team follows the Scrum process, while the Product Owner ensures that the team spends time building things that bring the most value to the organization. These roles sound so deceivingly simple that sometimes a single person will try tackling both.
This can happen in a ground-up implementation of scrum when a Product Owner is never officially assigned to the team, leaving the Scrum Master to fill these responsibilities. It can also happen when the team’s Scrum Master is also an individual contributor, and simply too overwhelmed to focus on the scrum process. In these cases the Product Owner may try to step up to lead the process, in addition to their own responsibilities.Regardless of the reason, when a team attempts to combine all responsibilities into a single role, it almost never ends well. Let’s look at some of the ways this can go awry, and how to fix it.
Scenario 1: Scrum Master acts as Product Owner
Most commonly, when these roles are combined, it results in the Scrum Master also wearing the hat of Product Owner. While it sounds logical, the Scrum Master may not have access to the customers to gather valuable feedback. Without actionable feedback, the team simply breaks an un-validated product down into smaller and smaller pieces delivering each incrementally. While incremental delivery is an improvement over a single large delivery, the reality is that it’s really just a more efficient way to deliver the wrong product.
When the Scrum Master acts as Product Owner, it’s easy to miss out on a coherent vision for the team, resulting in the delivery of low-value work. This can happen when the Scrum Master, lacking customer access or a true vision for the product, simply stacks the backlog with the items they find most interesting or familiar. This results in the team dusting the app by making minor enhancements to existing features or cleaning up low-priority bugs, but not accomplishing any meaningful work. In this case, low-value shouldn’t be confused with low-quality: While the team may be producing high-quality work, it doesn’t mean it’s making a meaningful impact on the product.
Scenario 2: Product Owner acts as Scrum Master
Product Ownership is a full-time job. This means that it’s easy for responsibilities outside of this role to slip. When the Product Owner acts as a Scrum Master we usually see the less tangible pieces of the scrum process slowly start to wane. Retrospectives are often the first casualty, as their outcomes can (incorrectly) seem less relevant to a busy Product Owner. While the Product Owner may not officially cancel a Retrospective, they may view it as most relevant to the development team and, therefore, leave the scheduling to them. These meetings appear unimportant to the organization and eventually die out.
Alternatively, the symptom may not be as blatant as a missed meeting. In some cases, regular meetings will still occur but you’ll start to notice that their focus subtly changes. For instance, daily standups still occur but rather than acting as a chance for the team to plan their work for the day, they slowly morph into a status meeting in which each team member reports their progress to the Product Owner. Likewise, sprint-planning meetings will still occur, but rather than the team arriving at estimates and a sprint plan together, they may find themselves bullied into uncomfortable commitments as the result of an overzealous Product Owner.
How to fix it
Both Scrum Master and Product Owner, for the most part, are full-time jobs. When the same person attempts to fill both roles disaster almost always ensues. In the cases where the Scrum Master is filling the Product Owner’s responsibilities, the simplest solution can be to free the individual of their Scrum Master responsibilities, allowing them to focus on the Product Owner role entirely. Many Scrum Masters eventually gravitate toward the Product Owner role and, as of late, this has become a very popular career progression for those with a taste for Product Management.
Keep in mind, however, that your team still needs a Scrum Master. This is your opportunity to identify a team member who’s up for the challenge, and coach them into their new role. If successful, you’ll have a new, dedicated Scrum Master, brought up from within the team, and a new dedicated Product Owner with a background in the scrum process. That’s a pretty big win.
In situations where the Product Owner acts as Scrum Master, the solution is to find a new Scrum Master who can dedicate time to the role. Not only does this free the Product Owner from managing the Scrum process, but it also helps create healthy tension between Scrum Masters and Product Owners. Ideally, the Scrum Master and Product Owner act as opposing forces. While the Product Owner represents the interest of the customers, the Scrum Master represents the interests of the team. When a single person tries to fill both roles, this healthy tension is lost and the fulcrum inevitably tips too far in one direction.
This is often seen when the Product Owner attempts both roles, as the fulcrum may tip toward bigger feature sets and a rush to market, which not only sacrifices the team’s investment in quality, but can also take a toll on their overall well-being. Freeing the Product Owner to focus entirely on product ownership, while allowing a completely different individual to focus on the scrum process, helps restore balance and better serves the end result.
There are exceptions to every rule, and it is possible for one person to serve both roles successfully. Just keep in mind that this isn’t the norm, nor should it be a long-term solution. To give your organization the best chance for success when using scrum, allow two distinct individuals to serve these roles. Even if you’re struggling to find those with the right aptitude, you’ll be better off with two people who have a passion to grow into their respective roles, rather than one exceptional individual struggling to balance both.
Want to learn more about how agile really works? Check out Jeremy’s course, Agile in the Real World, for concrete strategies on making the best agile techniques work for your team.
This article was originally posted on PLURALSIGHT.
Posted By Meghan Robinson,
Tuesday, June 28, 2016
| Comments (0)
AUTHOR: ADAM MYHR
When looking for information on Agile, software development is the most common industry represented. Within those results more often than not Scrum is used as the implementation. Many articles that try to talk about Agile in a generic sense use terminology from Scrum. A common side effect of this is that many people associate Agile and Scrum on a 1 to 1 level. This is a problem.
Agile is flexible.
In learning about Agile I have come to realize that one of the main concepts is that we do not know what we do not know. As we go through a project there will be new information. In being Agile we admit that up front. We start the project when we have the least information needed. We often take breaks to see what we have learned along with what that changes along the way. Most importantly, we allow those changes to occur whether they are to the project or our process.
Scrum is well-defined.
To be considered Scrum there are very specific rules that must be adhered to. If any of them are missing Scrum is not truly taking place. If any of them are in place in name only then at best “Scrum-but” is taking place. The entirety of what is required for Scrum to happen can be condensed into a 16 page guide or a 20 page primer. Nothing more and nothing less is required to be Scrum.
Agile guides decision
The heart of Agile is a set of values. Drilling down to the next level of Agile as defined for software development are a set of guiding principles. In none of the values or principles is an edict for activity made. They are all ideals to keep at the forefront of decision-making. They are meant to shape how a project is approached, not dictate the method used for accomplishing work.
Scrum dictates process structure.
The heart of scrum is a set of roles, events, and artifacts. The roles people play on a project team are consolidated to one of three named positions. There are specific meetings that must take place every iteration. Work must be structured and queued in a certain way. Inside of this defined shell is Scrum. Outside of it is something else.
Agile is a way of thinking.
Agile thinking can benefit any project. Agile thinking is also something that can be done in many different working environments. An Emergency Room can be run as an Agile project using a method such as Kanban. Agile thinking is open thinking. Open to change. Open to improvement. Open to modifications. Agile thinking allows for bonds to be as broad as practical.
Scrum is a framework for getting work done.
Scrum is specific to product development, specifically software development. Scrum allows for flexibility, but only inside of the framework. Anything that is outside of the framework is an addition to scrum. It is allowed, but only if it does not undermine the framework itself. Anything removed from the framework means Scrum is no longer happening.
Scrum is Agile but Agile is not Scrum.
Just as all Fords are vehicles but not all vehicles are Fords Scrum is Agile but Agile is not Scrum. Scrum is something that, when used properly, is Agile. It allows for constant, short feedback cycles. It allows for continuous improvement. It gives transparency to the people who need it. Agile allows for more. Agile allows the framework to change as needed to best deliver value to the customer. Agile allows people to be placed in front of defined roles.
Scrum is a good place to start an Agile journey. It is simple on paper and in concept. It is widespread and shows a lot of success over the last decade. It is well understood and the benefits can easily be explained to the organization at large. The structure for Scrum can be mapped out and placed in an organization in a very short time frame. As an Agile Coach I would default to Scrum for most software development environments at the outset. In the end though, Agile needs to be more important than Scrum. Scrum is going to work. It might even be the best solution. Once a team trends towards high-performing the framework of Scrum must not be a limiting factor in improving the product and performance of that team. For this reason, even though I would start as Scrum, as an Agile Coach I would be open Scrum-but over Pure Scrum in more cases than I would be blatantly against it.
This article was originally posted on Our Agile Journey.