Agile management




Agile Project Management

When it comes to agile project management roles, most agile processes — Scrum in particular — do not include a project manager. Agile “project manager” roles and responsibilities are shared among others on the project, namely the team, Scrum Master and product owner.

How are agile projects managed?

Within agile development, Scrum has the most to say about exactly what is agile project management. So let’s use Scrum as our model for answering this question. On a Scrum project, there are three roles: product owner, ScrumMaster and team.

The product owner is responsible for the business aspects of the project, including ensuring the right product is being built and in the right order. A good product owner can balance competing priorities, is available to the team, and is empowered to make decisions about the product.

The Scrum Master serves as the team’s coach, helping team members work together in the most effective manner possible. A good Scrum Master views the role as one of providing a service to the team, removing impediments to progress, facilitating meetings and discussions, and performing typical project management duties such as tracking progress and issues.

The team itself assumes agile project management roles when determining how to best achieve the product goals (as established by the product owner). Team members will collaboratively decide which person should work on which tasks, which technical practices are necessary to achieve stated quality goals, and so on.

So, what is “agile” about this process? Agile project management divides responsibility among more than one team member. In the case of Scrum, it’s a project’s product owner, ScrumMaster and the rest of the team.

Where does the Scrum Master fit in agile project manager roles and responsibilities?

In agile project management, the world may come to view the Scrum Master as a 21st century version of the project manager. But unlike a traditional project manager, the Scrum Master is not viewed as the person to credit (or blame) for the success (or failure) of the project.

The Scrum Master’s authority extends only to the process. The Scrum Master is an expert on the process, and on using it to get a team to perform to its highest level. But, a Scrum Master does not have many of the traditional responsibilities – scope, cost, personnel, risk management – that a project manager does.

Who handles conventional project manager duties in agile development?

Traditional project managers usually take on a great deal of responsibility. They are responsible for managing scope, cost, quality, personnel, communication, risk, procurement and more.

Agile project management often puts the traditional project manager in a difficult position. He or she is told, for example, to make scope/schedule tradeoff decisions knowing that a product manager or customer might second-guess those decisions if the project goes poorly.

Agile acknowledges this difficult position, and distributes the traditional project manager’s responsibilities. What is agile about this new paradigm is that many of these duties, such as task assignment and day-to-day project decisions revert back to the team where they rightfully belong.

Responsibility for scope and schedule tradeoff goes to the product owner. Quality management becomes a responsibility shared among the team, a product owner and Scrum Master. Other traditional tasks are distributed as well among a team’s agile project management roles.

Do agile projects scale with agile project management?

Agile processes like Scrum are definitely scalable. While the typical agile project has between five and 20 people across one to three teams, agile implementation has been successful on projects with 200 to 500 – even 1,000 people.

As you might expect, projects of that size must introduce more points of coordination and agile project management than small-scale implementation.

To coordinate the work of many teams, larger projects sometimes include a role called “project manager.” While involving someone on the project with this title or background can be very helpful, we need to be careful of the baggage associated with the project manager title.

Even on a very large agile project, the team will still do much of the project management. For example, teams decide how to allocate tasks, not a project manager; so the project manager role becomes more of a project coordinator.

Duties would include allocating and tracking the budget; communicating with outside stakeholders, contractors and others; maintaining the risk census with guidance from the teams, Scrum Masters and product owners; and so on. This is a true agile project management role.

Management agile

Le management agile peut être vu comme une organisation de type holistique et humaniste basée essentiellement sur la motivation rationnelle des ressources humaines. Son émergence, au début des années 1990, a été portée par la vague des nouvelles technologies (NTIC).

Ses valeurs et principes combinent des aspects sociologiques et technologiques à une approche industrielle [ 1 ] . Le management Agile s’oppose aux fondements du taylorisme : parcellisation du travail, déresponsabilisation globale ainsi que d’autres principes de productivité individuelle dont la mise en œuvre devient difficilement défendable dans les pays industrialisés, compte tenu du coût des ressources humaines [ 2 ] .

Le management agile s’applique au niveau de l’organisation et les Méthodes Agiles, si elles s’en réfèrent, ne représentent qu’un secteur de l’application des diverses formes d’agilité managériale se référant au (Lean). Les formes actuelles du Lean sont : Lean office, Lean services, Lean industriel, Lean Product Development et plus récemment, issu des méthodes Agiles appliquées au développement des systèmes d’information, le Lean IT (pour Information Technologie).

Le management agile est indissociable de l’auto-organisation qui induit adaptabilité, résilience et autonomie des équipes. D’où l’importance de critères et de schémas d’organisation du travail qui favorisent l’émergence et le développement de l’auto-organisation et de l’intelligence collective.

Sommaire

Fondements théoriques Modifier

L’agilité ne serait pas seulement une simple réaction au changement ou un mouvement limité aux développement des systèmes d’informations, mais représenterait la composante majeure d’un large mouvement d’auto-management [ 3 ] , où la résolution de la complexité de détail est confiée à la compétence et à la motivation rationnelle du personnel d’exécution. Cette exigence implique la constitution d’un Patrimoine immatériel formalisé de savoir-faire, ainsi que l’acceptation consensuelle des ressources humaines impliquées dans cette évolution.

Dissociation agilité et flexibilité Modifier

Agilité et flexibilité sont des concepts pouvant paraître proches en théorie (Lean). Pourtant ces deux approches présentent des différences notables dans la réalité de leur mise en œuvre et, cela aussi bien sur le plan philosophique, que sur celui des relations humaines sous-jacentes, ou que des pratiques réelles d’implémentation. Si la flexibilité est souvent assimilée à la Réactivité industrielle, il n’en est pas de même pour l’Agilité qui a naturellement émergé d’une recherche d’Amélioration continue du développement applicatif directement issue de l’Intelligence collective des équipes qui le pratiquaient.

Une entreprise est fonctionnellement agile lorsque ses composants opérationnels collaborent en synergie formelle à anticiper ou à capter le changement, aux fins de le compenser dynamiquement, puis de l’intégrer. En pratique, l’agilité se matérialise par une orientation « services » et s’instrumente par la conjonction de trois vecteurs :

La vision agile implique aussi une forme proactive de veille technologique basée sur la théorie de l’anticipation rationnelle. L’instrumentation opérationnelle de cette technique et son acquisition par l’ensemble des ressources humaines de l’organisation sont déterminantes dans l’évolution des trois vecteurs qui permettent d’assurer l’Agilité d’organisation.

Premier vecteur : l’intelligence collective Modifier

Les systèmes d’organisation d’aujourd’hui, à l’instar du vivant, sont complexes et parfois volontairement et insidieusement compliqués. À défaut de les simplifier immédiatement, ce qui n’est pourtant pas une utopie, il faut, pour les maîtriser, utiliser le pouvoir de l’intelligence collective [ 7 ] . Le principe tire sa force de la connaissance pratique des employés du bas de la « pyramide » dont la participation volontariste à une recherche systématique d’améliorations est suscitée. L’organisation dispose alors d’un fantastique outil de résolution de la « complexité de détail » [ 8 ] . Ceci engendre des évolutions dans la façon de concevoir le management, avec une évolution de la fonction de manager en servant leader [ 9 ] .

Deuxième vecteur : l’usage optimal des nouvelles technologies Modifier

Les nouvelles technologies permettent économiquement la personnalisation de masse des produits et services ainsi que la réduction des délais de mise en marché (time-to-market). Couplée à une vision Agile de leur usage, les NTIC proposent un des instruments de réponse à des besoins toujours plus complexes, mixant produits novateurs et services à forte valeur ajoutée. En revanche, l’innovation en matière de SI et de NTIC, lorsqu’elle atteint un certain degré, affecte fondamentalement le cœur du métier et déclenche naturellement la mise en œuvre d’une reconfiguration des processus. L’organisation fait alors face simultanément à la nécessité de plusieurs projets de changement. Un système d’information agile permet de fournir une réponse à l’évolution de l’organisation qu’il instrumente à certaines conditions :

  • D’une part, une granularité trop grosse doit être compensée par une charge additionnelle appliquée aux ressources humaines.
  • D’autre part, des adaptations trop fréquentes du système d’information représentent, non seulement un coût prohibitif en fonction du retour sur investissement possible, mais souvent un facteur de déstabilisation.

Troisième vecteur : la maîtrise formalisée de processus améliorés en continu Modifier

Les projets d’optimisation continue des processus représentent de puissants moyens d’obtention d’avantages concurrentiels au meilleur coût. Bien déployée, cette technique permet d’optimiser tous les secteurs de l’entreprise. Dans cette quête de productivité, lorsque les règles d’optimisation continue basées sur l’usage de l’intelligence collective sont réellement et complètement implémentées elles deviennent un puissant outil d’optimisation de la qualité [ 10 ] . La détection et la résolution des problèmes peuvent alors s’appliquer à une multitude de dysfonctionnements mineurs qui pourraient échapper aux échelons supérieurs compte tenu de leur faible visibilité.

Les paragraphes suivants ont pour objectif de mettre en évidence l’intérêt de nombreux acteurs de notre société pour le mouvement agile. L’ordre est totalement aléatoire.

Déclarations et citations Modifier

Pour IBM, l’agilité est considérée comme une capacité « technique » de procéder aux changements harmonieux et continus indispensables à la survie de l’entreprise et à son succès. La mise en place d’une infrastructure agile repose alors sur trois éléments : l’agilité de l’architecture, les effets des technologies et l’organisation des tâches critiques. IBM, après avoir pris le contrôle de Rational (leader des outils méthodologiques), produit un rapport intitulé The Agile CFO et propose maintenant Succeed with Agility at Scale: Increase your flexibility and responsiveness with Agile Development. Rien de surprenant : Scott W. Ambler, le fondateur de l’Agile Alliance, est aussi le Leader en matière de pratiques Agile de IBM Corp. ».

Pour Microsoft, l’agilité se présente sous la forme du principe que toute chose se trouve à une seconde d’une autre : « Aujourd’hui la technologie permet de rendre les entreprises plus agiles.» Microsoft, toujours conquérant dans l’apport de solutions en phase avec les attentes du marché, s’oriente vers « l’Internet Agile », édite son propre magazine Entreprises agiles puis annonce July 2007 — Microsoft releases tools to bring Agile development to the masses.

Pour Michel Guérin, professeur associé à l’université Paris-Nord, « l’entreprise agile est un modèle de développement où la politique, la stratégie et les opérations sont pilotées en continu ».

Bernard Galambaud Professeur à ESCP Europe « Devenir flexible, être flexible, telle est l’exigence du temps. La flexibilité est une exigence, et à ce titre, elle n’a pas à être discutée, elle s’impose, elle va de soi. » Pour Frédéric Fréry, lui aussi Professeur à ESCP Europe, « l’agilité serait la capacité à maintenir la compétitivité des entreprises alors que la turbulence de leur environnement dépasse leur vitesse d’adaptation traditionnelle. ».

Patrick Besson, également professeur à ESCP Europe, déclare : « en situation incertaine, volatile ou ambiguë, diriger suppose une agilité et des attitudes à bien des égards en rupture avec celles de la posture classique du dirigeant actuel. » Ou, pour résumer cette pensée en quatre points, le management agile nécessite le sens : de l’auto-évaluation permanente à l’une de mesures externes ; du dialogue dans la recherche d’une vérité partagée ; de la coopération et du maillage en réseaux de l’action collective ; de l’expérimentation privilégiant l’apprentissage progressif.

Allan Afuah, dans Innovation Management: Strategies, Implementation, and Profits « pour gérer et développer au mieux son capital humain, l’entreprise agile doit maîtriser quatre processus prioritaires : l’identification des écarts entre les compétences stratégiques et l’état actuel de ses ressources ; le développement de son portefeuille de compétences actuelles, en combinant les différents leviers existants (formation, gestion des connaissances, coaching, etc.) ; l’optimisation de l’utilisation des ressources et leur mobilisation au sein d’unités d’appartenance forte ; l’utilisation des outils de rétribution et de préservation des ressources critiques.

Selon les analystes du Gartner Group, les huit ingrédients de base qui justifient l’évolution des technologies de l’information et de la conduite des affaires durant la décennie à venir, se matérialisent en un impératif : l’agilité : « saura-t-on transformer à temps l’héritage de décennies d’informatique pour évoluer avec agilité, c’est-à-dire avec réactivité et capacité d’évoluer, en accord avec ces tendances de fond ? »

Dans une vision plus généraliste de l’importance de l’agilité en matière de SI, Geneviève Feraud, professeur au Theseus International Management Institute, fait état d’un profond changement des schémas d’entreprise portant sur la prépondérance de l’innovation appliquée au concept de service global. L’Agilité découlerait ainsi de l’architecture changeante des équipes formées pour chaque projet. Elle permettrait de s’adapter plus rapidement à l’évolution des conditions du marché. »

Éric Monnoyer, dans une intervention sur l’ingénierie du savoir au service de la compétitivité : « la définition des modèles métiers, l’amélioration dynamique de la qualité, l’optimisation de la performance sont les bases mises en œuvre par les entreprises agiles. Il y a aujourd’hui suffisamment de cas réels d’entreprises agiles qui permettent de passer en revue les principaux éléments de cette nouvelle compétitivité fondée sur l’usage des technologies de l’information, l’intelligence économique et l’ingénierie du savoir, le développement des talents et de la culture d’entreprise. »

Dans une perspective entrepreneuriale, Jean-Loup Richet (Chercheur Associé à l’ESSEC — Institute for Strategic Innovation & Services) met en avant l’intérêt de l’agilité de l’organisation dans des contextes innovants et incertains (start-up, business unit en électron libre, ou encore filiale en rupture). L’avantage de cette approche est qu’elle permet une mise sur le marché d’un produit innovant de façon plus rapide et plus efficace : orientation ‘besoin client’, optimisation des coûts et du temps, pas de gaspillage, et finalement une meilleure performance financière par rapport à une méthode traditionnelle de développement de produit.

Pour Olivier Badot (Professeur à ESCP Europe) dans son livre Théorie de l’entreprise Agile : « les hommes et les femmes de l’entreprise agile sont, par leur connaissance intime des clients et de l’environnement, par leurs savoir-faire en permanence affûté, par leur imagination et par les initiatives qu’ils sont autorisés à prendre pour satisfaire de façon originale le client. Ils deviennent alors la principale source de différenciation et de performance commerciale de l’entreprise. La recherche d’agilité, pourra alors atteindre le niveau le plus élevé d’implication des ressources: l’intrapreunariat ».

Pour Olivier d’Herbemont, le management agile est un mode de management fondé sur le développement de la capacité de l’organisation managée à se focaliser sur la valeur produite. L’agilité vient de la capacité du manager à transmettre un désir de plus de valeur collective. « Il va falloir de nouveau agir collectivement de manière solidaire et altruiste » (Booster l’Intelligence collective, Armand Colin, 2012, p.339)

Pour Jérôme Barrand (Institut d’agilité des organisations de Grenoble École de management), auteur de Le Manager agile, Dunod, 2006, prix Mutations et Travail 2007, l’agilité n’est surtout pas la simple flexibilité. L’agilité est la capacité à bouger (non pas simplement innover car de vieilles recettes peuvent redevenir pertinentes) en permanence, avec la bonne intensité, au bon moment, et de manière coordonnées tant en interne qu’en externe. L’agilité exige la mise en application de 8 principes tant au niveau stratégique, d’organisation, managérial, qu’individuel : l’anticipation des ruptures comme des conséquences de nos décisions, la « proopération » visant à travailler pour l’autre plus qu’avec l’autre, la «justinnovation» pour ne changer que ce qui doit l’être dans le seul but de réellement créer de la valeur, l’« effissens » (néologisme de Karim Benameur) pour signifier l’efficacité et l’efficience par le partage du sens, l’offre globale c’est-à-dire une offre de produit et de service mais aussi de l’image, de la prescription, de l’information et surtout de la relation, la réciprocité client pour exprimer que la notion de fournisseur s’efface en faveur d’une logique de troc d’offres globales entre des acteurs qui sont clients les uns pour les autres et réciproquement, la réduction de la complexité pour revenir à une complexité humaine pour chaque acteur du système pouvant ainsi porter totalement sa responsabilité, et enfin une culture agile [ 11 ] du changement pour cesser de manager le changement, perte de temps et d’argent dans un environnement où le changement est omniprésent.

Pour Olivier Reaud, un expert en intelligence économique « l’agilité ne se décrète pas, elle se suscite de l’intérieur de l’organisation. Pour réussir cette transformation, il faut créer les conditions, susciter les opportunités, et faire se développer sur celles-ci des dynamiques d’intelligence collaborative. [. ] Le comportement agile alors se pratique, se vit, se propage. Projet agile après projet agile, entité après entité, transversalité après transversalité, c’est progressivement toute l’organisation qui devient agile.»

Selon Jean-Pierre Vickoff, impliqué depuis 1989 dans l’évolution de l’agilité d’organisation : « L’agilité devrait devenir pour les sociétés avancées ce que le taylorisme a été à la révolution industrielle. Son émergence découle du plus vaste mouvement d’échanges dérégulés jamais initié : la mondialisation. Lors de cette révolution, les premières sociétés à s’assurer de la maîtrise opérationnelle du paradigme Agile gagneront la bataille des systèmes d’informations et, par là même, la guerre économique.»

Faits Modifier

En 2007,Oracle (base de données) fait l’acquisition de Agile Software pour disposer de son offre de gestion intégrée du cycle de développement applicatif Agile’s Product Lifecycle Management Solutions.

En 2005, EDS (Electronic Data Systems) a lancé un ambitieux programme Agile Enterprise Platform (1,2 milliard de dollars affectés sur trois ans). Le projet se décline sur deux axes majeurs : d’une part la standardisation et l’industrialisation des modes de fournitures des services (bonnes pratiques), et d’autre part la standardisation des plates-formes techniques.

AGILE PROJECT MANAGEMENT

Embrace change. Deliver results for your most ambitious projects.

What is Agile Project Management?

Broadly defined, Agile Project Management is an iterative process that focuses on customer value first, team interaction over tasks, and adapting to current business reality rather than following a prescribed plan. Agile Project Management is based on the same organizational practices and key principles found in the Agile Manifesto.

Agile Project Management is how you deliver high value and technical quality within your time and budget constraints. However, the principles go beyond software development. It’s a mindset for people who need a management approach that builds consensus quickly in a fast-paced environment.

Discover the problem that your business is trying to solve.

Agile Project Management uses facilitated work sessions with business and IT to get to a shared understanding of the problem, the solution and the plan. Outputs such as low-fidelity prototypes and story maps help you move quickly to a solution.

Evolve quickly, respond, and adapt.

You don’t often get it right the first time. Agile Project Management helps you find the source of the problem quickly through frequent testing. And even better, it gives you to the tools to solve it because you have involved the right stakeholders continuously.

It’s a new way of thinking.

We love spiking, story walls and team charters as much as the next person, but at the end of the day, Agile Project Management is about embracing a servant leadership mindset. It’s about understanding self-organizing teams and the interaction between all the roles contributing to the development process. And it’s about encouraging collaboration and discovering innovative solutions, unleashing the power of agile thinking.

Agile Project Management

Agile Project Management Done Right!

Whether you have just wondered about agile project management, or actually dipped one toe in, you would probably agree: the role of the Project Manager can seem impossible. Customers expect quality software on time and on budget. But wait! The requirements just changed. Again.

Sound familiar? We get it. Many of today’€™s smart software organizations have ditched unforgiving waterfall project management for an agile approach. Agile project management allows Project Managers to hit key milestones and provide executives with fast, accurate project status even when the deliverable is a moving target. By having greater visibility and continuous feedback, agile PMOs can react very quickly to change and bottlenecks in the development process, delivering better software, faster. Think you might want to try agile? Or tried it but didn€™t see value? We can help.

What is Agile Project Management?

“But we do daily stand ups. We’re Agile.”

Not so fast. Before you can say your team is agile, it€™s important to have a good understanding of €œWhat is agile?€ and €œWhat are some of the agile roles?€ Agile project management is a value-driven approach that allows Project Managers to deliver high-priority, high-quality work €“ and look like rock stars to their stakeholders. It€™s nothing like the plodding, costly and error-prone approach to project management, which has delivered inconsistent results for years.

Software projects change constantly. When customers are expected to finalize requirements before they can test-drive the prototypes, overhead and long delays often cripple the project. Agile Project Management is about embracing change, even late in the development stage. It€™s about delivering the features with the greatest business value first, and having the real-time information to tightly manage cost, time and scope.

Agile Project Management reduces complexity by breaking down the many-months-long cycle of building requirements for the whole project, building the entire product and then testing to find hundreds of product flaws. Instead small, usable segments of the software product are specified, developed and tested in manageable, two- to four-week cycles.

Have you heard about agile project management with scrum?

In traditional waterfall project management, the Project Manager is burdened with balancing project scope, cost, quality, personnel, reporting, risk, and adapting as requirements change. Agile project management divides these overwhelming responsibilities among three agile roles:

  • The Product Owner handles setting project goals, handling the tradeoff of schedule versus scope, adapting to changing project requirements and setting priorities for product features.
  • The ScrumMaster guides the team to prioritize their tasks and removes impediments to handling their tasks. Agile project management with scrum is an entirely new world!
  • The Team Members directly handle most of the task assignment, daily detail management, progress reporting and quality control for the product.

The Beginner’s Guide To Scrum And Agile Project Management

What can help you build a car, save your marriage, code software, write a book, or even renovate a house?

A whiteboard and a pad of sticky notes (the analog OR digital kind!).

Well, and the knowledge of how to use them, of course.

If you work in tech (or spend any amount of time with engineers), you’ve probably heard about “Scrum” and “Agile.” It’s a system mentioned in reverent tones by tech types and seems to have its own strange language. Terms like “planning poker,” “stand-ups,” and “sprints” are thrown about by its proponents.

It can all be a bit intimidating to the uninitiated.

I know because I’ve been there. During my first week working at a tech company I was introduced to Scrum through our software development team, and I was instantly hooked. The way they were able to take complex problems, prioritize them into individual tasks, then delegate those tasks to the team member best suited to solve each one was incredible.

But was this just for engineers? Could us non-code-wizards really benefit from something like Scrum? If so, how do you even get started?

Buckle up, because we’re about to “sprint” through an intro to Scrum (you’ll get that joke by the end of this article, I promise).

What is Scrum and Agile?

Things can get a bit confusing to newcomers in regards to nomenclature. “Scrum” and “Agile” seem to be used interchangeably when you first enter this world, but there is an important distinction.

Agile refers to a set of “methods and practices based on the values and principles expressed in the Agile Manifesto ,” which includes things like collaboration, self-organization, and cross functionality of teams.

A good analogy would be the difference between a recipe and a diet. A vegetarian diet is a set of methods and practices based on principles and values. A recipe for chickpea tacos would be a framework you can use to implement your vegetarian diet.

This is similar to the relationship between Agile (the diet) and Scrum (the recipe you follow).

Agile was born out of the techniques utilized by innovative Japanese companies in the 70’s and 80’s (companies like Toyota, Fuji, and Honda).

In the mid-90’s, a man by the name of Jeff Sutherland found himself frustrated by companies who were continually plagued by projects that were behind schedule and over budget. He sought to find a better way.

His research brought him to these Japanese companies and their Agile methods. Basing his work on this, Sutherland created the Scrum framework. After a series of successes using his new methods, Scrum began to quickly spread throughout the product development world.

Who Can Benefit From Scrum?

You could be forgiven for thinking Scrum was something limited to engineers or developers. But the framework can be beneficial for other types of projects too.

“Scrum can be used for any sort of complex project, the caveat is that it works best when there’s a concrete product being produced,” says David Matthew , a Certified Scrum Master for Incentive Technology Group , “If you work in marketing and need to write copy for a project, it could definitely be beneficial for your team.”

Scrum has been used by everyone from the FBI , to marketing agencies , to construction crews. Any time you’re producing some sort of product, be it software or an email campaign, Scrum can help you organize your team and get more work done in less time.

The People and Parts of Scrum

To understand Scrum, you’ve got to know the people and parts of the framework. The good news is, you don’t need any special experience or certifications to start.

“You don’t need much to get started with Scrum,” says Matthew, “You really just need a place to organize your thoughts, or your Backlog . That could be software like Trello, or even just a whiteboard. You need the different roles, like the Product Owner and the Scrum Master . The actual tools you need are not as big as the roles involved.”

Let’s break down the pieces and parts that make Scrum happen:

  • Scrum starts with a Product Owner. This is the person who represents the final user’s best interest, and has the authority to say what goes into the final product.
  • That Product Owner is in charge of making the Backlog, a list of tasks and requirements the final product needs. Here’s an important part: The backlog MUST be prioritized . That’s the job of the Product Owner.
    • If I were using Scrum to design a car, items like “Must have an engine” would be near the top of my prioritized list, because the car can’t work without it. “Must be painted red” would be lower on my priority list; it might still be important to me, but it’s not a requirement for the car to run.
  • Next up is the Sprint. A Sprint is a predetermined timeframe within which the team completes sets of tasks from the Backlog. The length of time depends on the needs of the team, but two weeks is pretty typical.
  • Teams meet every day to give progress updates in the Daily Scrum . Many people also call these “Daily Stand-Ups.”
  • Each Sprint ends with a review, or Retrospective, where the team reviews their work and discusses ways to improve the next Sprint.

As you can see, there’s not really any special equipment or training you need to get started. The hardest part is learning the lingo, and staying true to the rules and guidelines that make Scrum work.

“Scrum is kind of like poker; you can learn the rules in 10 minutes, but it takes a long time to get great at it.”

Starting a Basic Scrum Framework

If you’re tired of your current methods of project management, why not give Scrum a shot?

Since you don’t need special training to get started, it’s really just a matter of learning the ropes on your own. Sutherland and his co-creator, Ken Schwaber, make this super easy by making the official guide freely available on ScrumGuides.org .

Learning the basics of getting started is easy. Mastering the technique is the hard part.

Here’s Scrum Master David Matthew again:

“Scrum is kind of like poker; you can learn the rules in 10 minutes, but it takes a long time to get great at it.”

Still, don’t let that deter you. One need not be a master to start making their work lives happier and more productive.

Here are some basic steps to get started:

  1. Download and print the PDF version of the officialScrum Guide : Read it on your commute or during your lunch break with a highlighter in hand. Highlight the phrases and roles that are new to you and start working on memorizing what each one means.
  • Pick your roles: You need a Product Owner (speaks for the user, final say in what the project needs), a Scrum Master (helps the team move along based on the principles of Scrum), and team members. Remember, there’s no room for egos in Scrum. Scrum runs on a “servant leader” model.
  • Create your product Backlog: The Backlog is where you list out everything the project needs, ordered by importance. Keep in mind that the Backlog is never complete. As the project takes shape and new needs emerge, you will add to this. The Product Owner takes primarily responsible for this.
  • Plan your Sprint: Next, it’s time to pick tasks from the backlog to be completed in your first Sprint. Sprint’s are time-limited. You can decide a time length that works for you, but they are always less than one month. During the Spring Planning, the team decides what tasks to include in this Sprint and who will be responsible for them.
  • Get to work! Time to start working on that Sprint! Team members work on their tasks, and everybody checks in on their progress at the Daily Scrum Meeting. This meeting lasts no more than 15-minutes and answers three questions: What did you work on yesterday? What will you work on today? Is there anything blocking your work today that you need help with?
  • Review your work: At the end of the Sprint, the team reviews the work accomplished and presents their completed tasks.
  • Review your process: During the Retrospective meeting, you’ll review how the actual work process went and plan ways you can improve your work and be more efficient next time.
  • Repeat! With your first Sprint complete, it’s time to start over again. Pick more tasks from the Backlog and repeat the process.

Making It All Visual

An important principle in Scrum is the idea of transparency. All team members involved should be aware of what everyone else is working on, progress being made, and what the team is trying to accomplish.

That’s why making things visible for all to see is so important.

A big piece of this is the Scrum Board . This is a place where you can organize your Backlog, as well as tasks that are being worked on in the current sprint and their progress.

Scrum Boards can be as simple as a whiteboard with sticky notes for each task, or as complicated as specialized software, with charts and task tracking features.

For my personal Scrum Board, I use Trello.

My Trello Scrum Board is broken up into seven lists (inspired by this blog post ), representing the workflow of my tasks.

  • Resources: In this list, I keep all tasks that are recurring. That way I don’t have to make a new card every time I need to build a landing page for a webinar. Just move that card out from the Resources list.
  • Backlog : Here’s where I keep my Backlog of tasks to be worked on. When my boss tells me he has something he needs help with, I add it to my Backlog list.
  • To Do : When I plan my Sprint, I pull tasks from the Backlog to this list. This is the current Sprint I’m working on.
  • Doing: When a task has been started, it gets moved here.
  • QC: Quality check. As tasks are completed, they get moved to “QC.” At the end of the week, I review this list to make sure everything is up to snuff.
  • Done: Passed quality check, ready to be shipped! No more edits or reviews necessary, it’s scheduled and ready for action.
  • Blocked: When something is preventing me from completing a task (maybe I need to purchase something first and need approval from my boss), I move it to “Blocked”, along with a comment about what the blocker is.

Trello is an effective tool for this, because I can throw my board onto a monitor that’s visible for anyone to see, share access with my entire team, and put every detail needed on each and every task in the form of comments, checklists, due dates, and attachments.

I can assign different team members to these tasks and integrate it with our marketing Slack channel , too. That way, when a team member moves a task from “Doing” to “QC,” I know they’re ready to move onto the next task.

My end goal here is that anyone assigned a task should have everything they need to complete it on that card. There should be no reason they need to come to me with questions, or wait for me to give them something. When tasks are clearly outlined before assignment, work moves significantly faster.

The Importance of Iteration and Improvement

One of the core features of Scrum, and what makes it so potentially powerful, is the idea of iteration and improvement. This is in regards to both the product being worked on, and the efficiency of the team itself.

At the end of each Sprint, the work delivered should be ready to deliver to a client. This does not mean that it’s a finished, complete project. Far from it. Rather, it means that the work should be complete enough to show some sort of Minimum Viable Product (MVP, in startup parlance).

If it were a car, you should be able to drive it. Maybe it doesn’t have a radio or A/C, but it can drive.

Why is this so important?

Because it lets you collect feedback from users early on, helping guide development of the product to ensure a good fit with the user.

I think everyone has experienced those moments in life where you worked for hours on a project, only to find out the person you’re delivering it to had something else in mind completely.

Imagine spending thousands of dollars and many months developing a product, only to find out it doesn’t actually solve the user’s problem.

Going back to our car analogy, if we deliver the car to the user in small, iterative chunks, it’s not such a big deal when they say “Gee, you know what? After driving it around a bit, I think I want it to be a convertible instead.” Learning this after the final product is delivered would be a huge problem.

Scrum is built on iterative deliveries of your product. Rather than waiting until the project is 100% complete to deliver it to the user, you deliver useable chunks of the project over time. This helps avoid wasted efforts when needs change or things get lost in communication.

But beyond the importance of iterations and improvements for the product, Scrum also focuses on improving the process with each new cycle.

During the Retrospective meeting, team members discuss areas where their efficiency could be improved. Maybe it’s a tech limitation holding them back. Maybe one team member is overloaded with tasks. The team decides how to fix these problems, with the intent of improving their efficiency in the next Sprint. Theoretically, the team should be more efficient and produce more work with each new cycle.

Wait a Minute. MORE WORK?!

When I first started looking at Scrum, there was something that scared me a bit: this whole idea of completing more work.

More work? I’m overworked already!

But the idea behind Scrum is not to “do more work,” it’s to work smarter and thus accomplish more.

Sutherland has a great quote about this in his book Scrum: The Art of Doing Twice the Work in Half the Time:

“Think about your job. How much of your time is wasted while you’re waiting for someone else to finish their work, or for information to be delivered, or because you’re trying to do too many things at once? Maybe you would rather be at work all day — me , I’d rather be surfing.”

Scrum doesn’t measure you by the hours you logged, but by the tasks you accomplished. Who cares how long a task took if the result is the same?

With Scrum, you’re not creating more work for yourself; you’re being more efficient with your time so that you can spend less of it at the office and more time with the people and things you love.

How’s that for work-life balance?

More Resources

Scrum is hard to fit into a single blog post, so I highly recommend doing some further reading on the topic if it interests you:

  • Scrum: The Art of Doing Twice the Work in Half The Time, by Jeff Sutherland — This book was my first deep dive into Scrum. Everything is laid out in an entertaining manner, with stories to back each and every aspect of the framework. A great read.
  • Our Agency’s Epic 200% Productivity Secret, by Adam Steele — I came across this blog after watching the developers at my company work with Scrum and wondering if any marketers are using it. The answer? Yes, and in a big way.
  • The Scrum Guide , by Jeff Sutherland and Ken Schwaber — The basic guide you need to get started.
  • Scrum Glossary , from the Scrum Alliance — Definitions of all the people and pieces in Scrum
  • Scrum Certifications, from the Scrum Alliance — If you want to dive deeper into Scrum, check out some of these certification courses.