Get the latest news on AgileCareers!
AgileCareers.com is dedicated to connecting Scrum and Agile organizations with qualified, passionate Agile professionals. We strive to Transform the World of Work by offering a platform that has the resources and technology to help build those professional synergies.
Posted By Gez Smith ,
Wednesday, December 21, 2016
Updated: Tuesday, December 20, 2016
Agile recruiting is much different from traditional recruiting. In part one of this five-part video series, Gez Smith introduces the idea of Agile recruiting and talks about the topics he'll discuss in upcoming videos.
Gez Smith is an agile coach, certified scrum master, and one of fewer than 150 certified scrum professionals in the UK, with over 10 years experience in Agile and Scrum. Through a varied career encompassing software sales, development, rollout and maintenance, he has delivered projects in all stages of the SDLC, in roles including developer, product owner and scrum master.
Gez is an active member of the UK Agile community, regularly attending and speaking at conferences and user group meetups. Having completed a research thesis on Agile as part of an MSc in Strategy, Change and Leadership, achieving a distinction grade. He has also published two books on Agile in the context of digital communications and is now seeking new opportunities to apply his Agile mindset and Scrum knowledge to various projects.
Posted By AgileCareers ,
Wednesday, October 12, 2016
In 2016, you would be hard-pressed to walk into a local coffee shop or library and not find every person within the confines of the space in possession of a smartphone, laptop, or tablet (and in some cases, all three).
As mobile devices become increasingly commonplace, growing numbers of professionals are turning online for everything from research to record-keeping, to seeking out new career opportunities.
One of the fastest growing segments of the online recruiting world are Virtual Career Fairs. Much like an Onsite Career Fair, these events attract exhibiting employers and jobseekers in an environment where they can connect and engage in conversations, although in an online event this all occurs without the need for travel.
The absence of travel costs is just the tip of the iceberg in terms of the many reasons why Online Career Fairs have gained such immense popularity in the past several years. Along with the ease of use of online platforms, there is an incredible efficiency in recruiting at a Virtual Fair that just can’t be duplicated elsewhere.
As a recruiter, you’ll have the ability to interview highly qualified candidates in your niche without having to leave your desk. You can pre-qualify candidates in your virtual line, view resumes while chatting with jobseekers, hold multiple one-on-one chats simultaneously, conduct follow-ups both during and after the event, and rate and take personal notes of each candidate you speak with. You’ll have access to a history page where all of their conversations, ratings, and notes are saved, and in the course of three hours you can have several dozen first touch interviews!
Come join us for the AgileCareers Virtual Career Fair on November 3, 2016 and connect with job seekers. The Virtual Career Fair adds value for hiring companies.
Employers may purchase booths and develop company profiles prior to the fair
Conduct up to dozens of first-round interviews with qualified candidates during the fair
Up to four recruiters may showcase open positions in the customized virtual booth
A rating system is in place for employers to score interactions and record notes
All conversations will take place from the comfort of attendees’ home or office – no suit or travel necessary! The event will take place on November 3, 2016 from 1 – 4 p.m. EST. To register, please visit the AgileCareers website at http://www.agilecareers.com/ and click on the banner at the top of the page. We look forward to seeing you there!
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
Everyone participating already had Agile training and experience. They knew what they were getting into and why they were doing it.
Everyone was encouraged to participate through the way the meeting was facilitated. No one felt like their opinion was ignored.
The meeting was long, but also time boxed. It wasn’t an open-ended discussion that could go forever.
It was in-person!!! Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
It was honest: tough things were discussed including potential personality conflicts. This open discussion required expert facilitation.
Management was not involved in the decision-making during the meeting.
The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group. Is it for a specific Program? If so, what is the objective of the program from a business perspective? It should not just be a one-time communication. This should come from the business Real Agility Coach.
The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations. These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.
TEAM CREATION EVENT AGENDA
The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
Management stakeholders make their presentations to ensure that participants have a clear vision.
The business Real Agility Coach summarizes the vision presented by the management stakeholders.
The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
People who want to work on that particular team’s goal (if such is set).
Everyone must be on a team.
Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
Everyone starts self-organizing! Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams. These optimization opportunities should always be offered as suggestions rather than being directive.
As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
The people/process Real Agility Coach closes the meeting. It is critical to record the final results of who is on which team. It may be easiest to get the teams themselves to do this before leaving the meeting.
The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone. Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.
Have you experienced an event like this? Did it work? What was different from what I described?
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.
Posted By Meghan Robinson - Scrum,
Friday, March 4, 2016
Updated: Thursday, March 3, 2016
Agile teams are structurally different than their waterfall counterparts. Agile teams focus on the team itself, whereas waterfall teams often follow the structure of the organization. In traditional waterfall development, scheduling is often “top down,” meaning management sets the pace and schedule. In agile, the team is self organizing, and sets its own schedule and destiny within the larger organization. As I was learning scrum, one of the questions that kept coming to mind was, “How do development managers and scrum masters share responsibilities in the team?” Let’s explore the answer to this question.
Waterfall teams vs. scrum teams
Most waterfall teams are manager centric. They look to the the manager to set priorities, track progress, and evaluate performance. Agile teams are self-organizing.They work with a product owner (not usually in the team’s management chain) who sets the vision for what should be built. The team, through a series of sprints, drives how the product should be built.
Self-organizing teams own their destiny. In sprint planning, they decide how much work to commit to the sprint, and because of that, their level of ownership in the success of the program remains high. Engineers who own their own schedules build products of higher quality more consistently because they own their schedules. Engineers want to build high quality products on time. Everyone in the organization has the same goal. As a company we all want to succeed. Tuckman’s stages of group development outlines how teams form and thrive. Agile, self-organizing teams are no exception.
Mutual trust and candor are essential to well-performing agile teams. Management that continually focuses on hiring the right team is able to trust the team to get the job done. The need to then micromanage every detail of the team’s work doesn’t exist. The scrum master and the development manager protect the team from outside distractions such as feature creep, waterfall anti-patterns, cross functional thrash, or side projects that will compromise the integrity of the sprint.
Role 1: scrum masters
Scrum masters are the project leaders in agile teams who focus on optimizing performance of the scrum process. They work between the product owner and the team ensuring consistent, successful sprints by running stand-ups, and working to reduce blocking issues for the team. Cross-functional thrashing can be costly for teams, so successful scrum masters own cross-team coordination so the core team can focus on product development. This practice keeps everyone efficient and on the same page.
“Scrum masters are leaders in agile teams who focus on optimizing performance of the scrum process.”
The scrum master coordinates most of the inputs and outputs required for an agile program. He or she drives the sprint kickoff, daily stand-ups, sprint review, and sprint retrospective. The scrum master is also an agile coach, helping the team to adopt and own agile practices throughout the product life cycle: story point estimation, sprint planning, and continuous delivery. The coaching aspect of the scrum master’s job is critical as they not only help the team to be agile, but advocate for agile development throughout the organization, and spread the good word about why agile development is right for the project and for the company. Often times, when agile methodologies are new at a company, the advisers and stakeholders outside of the team need agile coaching as well.
The scrum master works with the team and the development manager to estimate items in the backlog. At first, the team will need some guidance from the scrum master and development manager. As the team is forming, it builds shared knowledge of the program through successful sprint planning. As the team moves into a performing stage, the scrum master focuses less on estimation and more on optimizing the velocity of delivery.
Role 2: development managers
There’s a lot of uncertainty for engineering managers when their team adopts agile – an Admiral Stockdale moment, if you will. But despite the fact that agile development teams don’t rely on their manager for estimation and prioritization, managers still play a vital role.
The most important thing a development manager does is hire. Why spend so much time on hiring the right candidate? Team changes are expensive on two levels:
Searching for candidates takes focus away from building great product.
When new employees join, the existing team needs to spend time onboarding them. Teams will experience a drop in velocity over a few sprints as each new person integrates into the team.
“The most important thing a development manager does is hire.”
When a team is truly self organizing and performing well, everyone in the organization sees it through the product quality and delivery. No one has more impact here than the development manager.
One of the big differences between agile and waterfall teams is that the development manager is a partner in the estimation process. In a waterfall team, a conversation like this wouldn’t be unheard of:
“Hey, how long is it going to take to deliver this feature?” – manager
“It’s going to take six weeks. We need to do A, B, C to get the feature to market.” – engineer
“Hmm. That makes sense, however, you need to find a way to get it done in four weeks.” – manager
But an agile development manager knows to hire great people, then trust them. A fundamental tenet of the agile process is that those closest to the work are best able to scope and deliver. The team sets the schedule. The development manager adds unique value in inquiring and vetting assumptions made in the estimation exercise – partnering in the process, rather than dictating it.
“A tenet of the agile process: those closest to the work are best able to scope and deliver.”
While scrum masters focus on team velocity, development managers build up team members’ velocity by coaching individuals one on one. Development managers curate and inspire great talent in their organizations. Great managers are adept at the fundamentals of management: one on ones, giving feedback, and coaching their teams. Successful development managers mentor engineers to bring greatness to the table: ideas, code, tests, and culture. Great development managers partner with their teams. At times, the team will struggle or come to an impasse with architecture design decisions. Adept development managers know when to intervene to break the impasse or let the team continue to struggle to grow the team. The scrum master may not be as technical as the rest of the team so the development manager lends valuable context between the scrum master and the team when there is a clear knowledge gap.
In addition, they also partner with the senior developers in the company to set the development culture. They’re often influential in the technology choice for the program, and continue to own responsibility for the quality of the product from the code architecture to the end-user experience. Development managers engage in code reviews to ensure team members are contributing code that meets the short and long term goals of the program. They also set context internally for the team and in the larger organization.
To learn more
We’ve spent a fair amount of time looking at what makes a great manager in an agile culture and now we’d love to know: how does your team practice the agile methodology? Drop us a line in the comments!