team management

5 Important Agile Interview Questions

Posted on by

5-important-agile-interview-questionsIf you are looking to recruit someone new in your company whether it’s for a new Agile implementation, or to replace someone who left, it’s important to get specific Agile interview questions asked up front during the recruitment and selection process.

Below we’ve outlined some basic yet relevant questions that you can ask a potential candidate, and gauge whether or not they are going to be a good fit for your department, team, or organization. That is not to say that your candidate should answer all of them correctly to be considered the perfect member to add to your team, but they should be within some level of understanding on why these questions are being asked.

1 – What does Agile mean to you?

For this question,  you should be looking for closely related Agile principles and values. It’s important to see how close your candidate can get to mentioning and explaining those values of:

A. Check whether your candidate is referring to how they like to interact in groups, looking to share ideas and solutions while promoting team building and servant leadership. If they tend to emphasize the processes and tools, this might not be such a bad thing but you should try to steer them into more group dynamic and group transparency based topics. If they don’t respond or get sidetracked to following orders and making sure everyone in their surrounding work environment must conform to process, this might be a less suitable candidate. However this is not the only basis on which to make your decision.

B. Many who try to impress in an interview, tend to throw ideas out of which documentation they would create and use throughout an agile project. It’s important to see if your candidate sees the value of delivering a working product. If they are the type of person that is trying to make sure everything works around the product except for the actual delivery of the product as necessary, it’s important to see if they are making this distinction.

C. If your candidate is more concerned about how many contracts they can get out of the customer, they might not understand the importance of the other aspect of Agile values which is to try to gain as much customer collaboration as possible. You wouldn’t want interactions with the client to be about how to draft a new contract every step of the way. Remember it’s the soft stuff (people skills) that’s the hard stuff, so your candidate should be able to demonstrate how they are able to engage the customer into problem solving discussions and come to mutually beneficial agreements.

D. If your candidate seems to be more concerned about project plans and gantt charts, they may be stuck in a waterfall mindset. These plans in an Agile setting are a distraction to actually executing the process of developing actual product. For this you should be trying to see if your candidate is looking solely to write-up a plan and make sure everyone follows it (command-and-control) vs. being able to point out the inherent importance of having a team self-manage and create a product based on prioritized features that a market is ruling as important for ROI.

2 – What types of Agile processes have you implemented before?

With this question, you should be able to get the candidate to point out if they’ve actually implemented Agile methodologies whether they are Scrum, XP, Lean, etc.. Key words that you can look for are those found from the beginning to end of the cycles. Words like Sprint Planning, Kanban Board, Burndown Charts, Retrospectives, etc.. You should be able to check and see whether they have an understanding of the ceremonies and events that occur through iterative cycles. More importantly, they should be able to point out why those processes exist and how they fit together to make a fully Agile environment possible.

3 – What is your idea of an Agile mindset?

The character and personality of your candidate fundamentally must be a good match to the agile mindset if they are to practice Agile. Common sense, right? however you might come across some who think they know what it means to be Agile but portray a completely different mindset. You may want to have a look at our other related articles that shed some light on what qualities an Agile Mindset has (or does not):

4 – How often must Agile be practiced during a project?

The answer to this one is simple: at ALL times! If your candidate starts to mention which aspects of agile should or shouldn’t be implemented, as if to compare switching it on or off like a light switch, this person may not actually understand the importance of synergies built over time through agile principles. This question is best answered in a holistic overall “outside the box” sense. Agility is not to be pulled apart and peeled only for certain parts and principles. This leads us to our next question.

5 – Can Agile be tailored?

This is a very important question as the candidate should be able to read between the lines. In practice it’s well-known that you should not be tailoring Agile right from the start unless you have many years of Agile experience. Many of the reasons why Agile fails, is because it is tailored to fit another mold, i.e. trying to fit Agile into Waterfall, and this is where false beliefs about the effectiveness of agile come in to play. Your candidate should be able to respond with a “yes, but…” type of answer. From there they should be able to point out that tailoring is not ideal, and that it would take place perhaps after multiple iterations and sprints, where the agile team notices certain events or processes that aren’t working well for them. This would usually be coming from the Sprint Retrospectives and observed in each successive retrospective to see whether they’re continuously improving or not. This makes the tailoring process more safe and tuned to the team’s needs.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

 

7 Reasons Why Some Corporations Hate Agile Methodologies

Posted on by

7-reasons-why-some-corporations-hate-agile-methodologiesConventional business wisdom will tell us that we should tell our shareholders what they want to hear so that the price of company stock will rise. This displaces the value that corporations will aim for toward the shareholder and not necessarily toward the customer. This is where Agile methodologies conflict as the goals of a conventional vs. agile mindset are not the same.

Below we will outline how conventional corporate mindset thinking conflicts with that of an agile mindset:

1- Focus on customers over shareholders

As a company you would likely be trying to appeal to both the shareholders and customers, however it’s usually shareholders that will come first and customers second. Based on agile principles and agile mindsets, the priority undeniably reverts to customers first! Everything in the agile value mindset reflects a goal toward delighting the customer and the accepted agile methodologies and processes show much evidence to conclude this is always the case.

2- Perceived Loss of control

The thought that there could be teams that are self-organized and self-managed leaves a sense of control loss by management at any level. Management may argue that if the teams are self-managing, then what is the use for management in the first place. Unfortunately this is a false perception, since management would likely still be needed for areas of business operations that are not covered by the day-to-day of agile processes. 

3- Perceived loss of authoritative rank and power

Most conventional businesses will follow the militaristic approach as the known command-and-control approach to business structure and organization. Companies with a highly vertical (hierarchical) structure being at one extreme and the more flat (horizontal) type of organization at the other end. Those with a heavy emphasis on a vertical structure tend to harbor many of the anti-patterns of an agile approach. Be it either from lack of trust or lack of willingness to let go of authoritative power, many companies that have a top-heavy structure will not be easily capable of converting or adopting agile.

4- Focus on delivering immediate customer value over immediate revenue

As many have noticed the periodic reporting of large businesses, especially those whose stocks are on the market exchange, the revenues that were forecasted must hold up in the later quarters or else face the consequences of lost share prices and market share overall. This places emphasis on how soon work can be done and made billable rather than concentrating on the actual scope and process of work to be done. The best interest of the customer is left behind as resources are stuffed into the work processes, rather than allowing agile methodologies to take their course.

5- Too much learning and too much change

Most who have reached a respectable level within their company whether it be in management or non-management (technical) levels, may tend to sit on their laurels all too often. Although we seem to hope that society is a meritocracy, let’s face it, some people just get to the higher positions based on years of experience rather than actual willingness to continue learning and changing. To this point, there are some who live up to their titles, but others who don’t and wouldn’t care to collaborate with their fellow colleagues either because they have underdeveloped people skills, lack of extensive knowledge, or because it’s seen as too much work to learn and share.

6- Customer value is cumulative while overall benefits only come if done properly in the long run

If there is anything we can’t promise is what will happen in the future. It is highly unlikely that an executive management team will wait to see if there will be continued commitment and support from their existing customers. Since much of what builds up customer satisfaction retention accumulates over time, most companies do not factor that in and will take the shortest path to generating revenue. Building quick untested solutions for the sake of having something billable does not look after the best interest of the client. This extends further to the disappointment of employees who are being told what to do, without buy-in. Some companies would rather sacrifice growth of their existing team synergies to result in high turnovers from unmotivated employees, rather than keep them on-board. This is why at the first sign of lost profits, most companies will take the immediate route of terminating their employees. The reason? It’s the quickest and easiest way to lower costs. However in the long-term it proves detrimental, and usually leads to further “voluntary” fallout where employees lose sense of purpose from the previous setback of layoffs. This affects customer relationships as the level of expertise and direct customer engagement from employees diminish.

7- Increased level of transparency perceived as very risky

Most companies do not share at many levels for fear that the truth may  reveal too much for many to be comfortable with. High levels of transparency bring about a sense of fear that the information provided can be way too sensitive or used against the company. Although transparency may reveal positive and negative aspects of a company and its operations, most companies tend to err on the side of non-transparency to avoid the risk at all costs. This approach of course lowers the level of trust and therefore the level of engagement from customers as they find out from latent communications throughout the project life-cycle.

[Image courtesy of cooldesign at FreeDigitalPhotos.net]

 

10 Negative Sounding Terms Used in Agile Working Settings (But are not!)

Posted on by

10-negative-terms-in-agile-working-settingsSome level of confusion may occur with the use of certain terminologies, likely when a relatively new-to-agile member joins an agile working team. Let’s face it, we are living in a society that requires us to know expressions, abbreviations, or acronyms on what everyone is talking about as common knowledge. It’s certainly always best to ask the question up front, but for those worried about terms that typically come up in the context of agile projects, we’ve outlined some below.

Those joining an agile project will naturally learn quickly about every day agile terms that are not usually used in any other project context such as: scrum, sprint, retrospective, standup, etc., but what about the mention of some less familiar terms? Some might come up only a few times within a sprint or throughout the entire agile project.

Here’s a few examples of terms, that could raise some eyebrows upon first hearing them. You can rest assured most have a positive context despite their seemingly negative sounding words:

Burn-Down

The instance from which we use the term Burn-Down is with the Burn-Down Chart. This term has very little to do with burning anything down, at least not from the context of lighting something up with a flame or fire. The Burn-Down Chart, as an agile tool, gives a graphical representation of how much work is left to do in the sprint. The main component that is being represented is the amount of scope or story points completed, while giving a visual cue of agile team velocity.

Peer Pressure

Many of us started to hear the term Peer Pressure in our high school days. This brought about times of being pressured to fit in with the crowd by doing acts of stupidity, substance use, or criminal activity. Performing any of the acts would reassure acceptance for that member, but if not they would face possible rejection, bullying or humiliation. Peer pressure in agile working environments comes about more from the high level of transparency and visibility, than actual pressure from the agile team. The occurrence of peer pressure comes about when the individual reports their own performance and realizes that they may be stalling or slowing the rest of the team down. This could be a result of over committing, or just simply under-performing within the group. This typically would require the individual review with the agile business coach or scrum master role to see where or why they may not be a fit for the current team.

Burn-Up

Similar to Burn-Down, this term is also used when referring to an agile information radiator called the Burn-Up Chart. This chart can viewed side-by-side with the Burn-Down chart, but today most software applications can show them both superimposed for better understanding of progress. While the Burn-Down Chart will show how much scope or points being completed. the Burn-Up Chart shows how many hours are being used to complete the tasks. Both charts together will confirm whether or not estimates that we set in the sprint planning are on track or not.

Servant

For those who have taken on the Scrum Master role, they may learn eventually that their preferred form of leadership is that of “servant-leadership.” This in no way means being a servant in the traditional sense, but rather one of the most effective ways to lead by example. So the idea that a servant as a slave is very far from the intent. Servant-Leadership in principle is meant to serve others so that others can grow and become self-organized, rather than the opposite “command-and-control” approach to leadership that creates drone-like behavior from others.

Playing Games

Much of agile training and learning can come about from playing agile games. Typically when you think of playing games, it is thought that people are just horsing around, not being productive or wasting time. In the context of agile teams, it is very much encouraged to play games to get familiar with agile workflows, planning, iterative development, and team building activities. There are numerous and still new and innovative ways that agile practitioners play games to learn while adopting an agile mindset and principles.

Disruptive

When we think of the term disruptive on a day-to-day context, we tend to think of disturbance or distraction. In an agile context and mainly technological circles, disruptive commonly refers to innovation. To be part of an agile team that has created a disruptive technology or invention means that there has been a major advancement, so much so, that it actually brings the previous function, or use of the previously existing technology to obsoletion.

Pigs and Chickens

While working on an agile project, you may come across some farm animal terminology, specifically Pigs and/or Chickens. These terms are perhaps used less and less recently, but they came about from an anecdote that demonstrates the level of commitment of certain members of the team. The story refers to a chicken asking a pig to start a restaurant together called “Ham and Eggs.” The Pig answers “no thanks” since the Pig would need to be committed (since Pig has to be killed to make Ham), whereas the chicken would only be involved. This basically gives an idea of the different levels that certain stakeholders and agile team roles have in a project and how they should participate in sprint events such as the daily standup.

Pirate Metrics

For what is now being used as a part of agile metrics, you might think this has something to do with piracy. The term pirate metrics comes from the mnemonic term AARRR (the pirate rant) to remember the 5 key metrics to measure increasing revenue: Acquisition, Activation, Retention, Referral, and Revenue.

Fail-Fast

This concept about failing fast may confuse early agile practitioners since most people are told early and for most of their lives that failure is the opposite of success. Certainly this term can raise a sense of fear of failure and cause some resistance at first. The concept of Fail-Fast is a principal agile concept coming from inspecting and adapting. It is an approach to encourage early detection of failure, to be able to learn or fix quickly before sunk costs are incurred. In principle you would want to know if a project or product feature would fail at the beginning instead of reaching the end to find out it is a failure.

Empiricism

We’re not referring to empires and conquests with this term, although we can certainly get carried away and think that the project may take on that type of personality. Empiricism is mainly a scientific approach that requires a process to be observed and tested so that it can be considered universally effective.

Learning and Understanding Terms for Better Communication

There are certainly more of these types of terms that are used in Agile, but note that the best way to start learning, to keep learning, and to contribute to the discussions that come up in an agile project is by communicating with same type of vocabulary. There are already many factors that increase the risk of breakdown in the communication process, so we may as well get on the same page and know up front what common terms everyone may use use in the project.

[Image courtesy of photostock at FreeDigitalPhotos.net]

 

Top 5 Agile Myths and Misconceptions

Posted on by

If you are planning on becoming agile at your workplace, you’ll most definitely come across some colleagues that have a negative outlook about what’s coming. The thing to consider is that everyone wants the benefits of being agile but they are not likely to be committed to actually making the changes to become fully agile. This is where myths and misconceptions come into play to justify potential failure down the road. Keep in mind this failure would not be from implementing agile itself, but rather the lack of actually implementing agile to its fullest potential.

Here are the top myths and misconceptions that must be dispelled or at least brought up in situations leading to disappointing results:

1 – Agile is Chaotic – It certainly isn’t easy, but when implemented properly and with many trained and experienced practitioners, agile can be very organized and structured. There is a lot more planning that goes into agile projects when compared to waterfall. In fact planning is done at the beginning of every sprint, but it doesn’t stop there.

2 – Agile is just a recent trend – Believe it or not agile has been around for many years, and it has taken on many forms over time. The term “Agile” is perhaps more recent in terms of use, but the methodologies that were around previous to what are now encompassed by what we’ve deemed as agile, have been around for many years, and still continue to be used.

3 – Agile needs a lot of training – You need to start somewhere, but experience is valued more than training. Being on an agile project while being open to learning about it, can give you all the training you need. Certainly that comes with asking questions, reading a few books or attending a couple of seminars of agile courses along the way, but there’s no more training than any other process in today’s workplace.

4 – Agile is for small teams – Many people who have worked on large projects might see that agile and sticking only to the basic agile team roles is unattainable, at least in the strictest sense. However, an agile working team can be scaled and works very well with the proper structure put in place. Beyond that, keep in mind agile isn’t purely about the processes it imposes, but also relies heavily on the people and collective emotional intelligence of the agile team adopting it.

5 – Agile doesn’t require testing – For those accustomed to waterfall vs agile projects, most would be expecting to find or look for the QA testing schedule. The one that typically comes at the end of every waterfall structured project. With agile the testing takes place simultaneously throughout the project and is done in a more seamless process, usually facilitated by tools like jira. The testing (inspection) goes on from beginning to end and is part of every sprint.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]