Finding meaning in the Agile Manifesto

Whenever I'm starting with a new group, whether they are currently using Agile practices or whether they are looking to move in an Agile direction, one of the first things I do with them is a review of the Agile Manifesto. The purpose of this exercise is to understand how much of an Agile Mindset has been incorporated or already exists in the group or whether they've just adopted some practices without a good understanding of why.

Utilizing concepts and techniques popularized by by Sharon Bowman in her book: Training from the Back of the Room, I start by showing the group the Agile Manifesto. I read out loud each item but don't explain the meaning. Next I then have the group self-organize into four even sized teams giving each team poster paper and colored markers.  

The teams start by each writing one of the Manifesto items across the top. Then each team creates a definition of what they think it means, giving examples of how it applies to their work. Finally they give a rating on a scale of 1-10 on how well their group currently meets this definition (1 = not at all, 10 = we live and die by this).  

This usually takes about 20 minutes to complete, as the teams are creating their posters I move between room helping to guide and asking probing questions. A typical question I often get from teams is "is it X vs. Y?" Use this as an opportunity to discuss situations where Y can still provide value to their team, but how X can help their team achieve even greater Agility.

As the teams finish, I have them tape their posters up on the wall and choose a spokesperson. The teams will now present their posters to the rest of the group with a facilitated discussion on what the team has created. The audience is given a chance to make changes if needed and give their take on the correct rating.  

Using this technique, I am be able to engage teams in a more meaningful discussion of where a group's Agile Mindset is strong and where it needs improvement. This creates a great lead-in to a discussion of the team's pain points and how to help them address them using Agile principles. 

If you get the opportunity to use this exercise with your team, be sure to reach out and let me know.

Does what your team value match your Agile practices?

Agile has become a crowded field and one that grows more and more confusing by the day. There are so many different approaches coming from so many different directions, it’s hard to have any hope of figuring out what “being Agile” will mean to your team. 

Will you adopt Scrum, SAFe, Kanban, or LeSS? Should you incorporate XP, Mob Programming, or TDD? Can one team use Scrum while another in the same company uses Kanban and can they both then scale up to DaD? With the overwhelming number of options and even more opinions, how do you begin to create an action plan?

The problem is, despite what some may tell you, there is no one right approach for every team. One of the first things you need to do with your team is to decide what matters most to your team and your company. What are your core values and how do those inform your goals and ways of working?

Each team is unique and is influenced by their environment, requirements, expectations, skill sets, and goals. For example, take a team that is working on a 7th generation product that allows users to file their annual US taxes, let's take a look at 12 core areas to help determine where to focus.

Cycle Medium, Hard – Product is on an annual release cycle that cannot change

New Features Low to Medium – Product must remain current with US tax code

Reliability High – Users expect few to no errors

Innovation Low – Users expect to be able to use the product in a similar way each year

Users Non-technical – Although some users may be technical, a majority are not.  Usage must be obvious and documented in easy to understand language.

Regulation High – Company must comply with federal and financial regulations

Team - Experienced – Team has been together for several years with strong product knowledge

Integration Medium to High – Product must be able to import from and export to banking, accounting, stock broker, and government systems as well as their own bookkeeping and planning products.

Market Low to Medium – Although highly competitive, competition is stable year over year with few new entrants or innovations.  Customers tend to stick with programs they are familiar with.

Team Structure Multi-team – Product is made up of 7 segmented teams (4 dev, 1 QA, 1 UX/UI, 1 Product) with separate sales, marketing, and management. Standard turnover/replacement.

Corporate Culture – Diverse, stable – Workforce is a mix from recent college grads to long-term employees who are interested in more secure, large corporations with reasonable work/life balance.  A 9 to 5 workday is common for many employees.

Agile ExperienceLittle – A couple teams on another product implemented Scrum initiated by their Product Manager to moderate success.

Now let’s take a look at a mobile dating app team who are busily iterating after their initial release.

Cycle Short, flexible – App can be updated on demand through app stores.  New features are only announced at time of release.

New FeaturesMedium to High – User’s expect a product that consistently provides new ways to connect with each other.

Reliability Medium – Reliability is important, but users tolerate the occasional crash or slowdown

Innovation High – User’s need to feel they are using the latest and greatest

Users Tech Savvy, Young – Marketed to younger users who are comfortable with apps and don’t tend to reference documentation or tutorials

Regulation Low – Must comply with App store rules

Team Inexperienced, but skilled – Although typically younger with less experience, team members are skilled individuals attracted by high risk/high reward start up culture

Integration Low – App is stand alone and is the sole product of company

Market Volatile – New competitors appear almost weekly, users have very little loyalty and will often use multiple competitors at the same time.

Team StructureSingle team – A single cross functional team of 13 people.  Looking to double within the next year.

Corporate CultureHigh energy, high stress – Teams are under pressure to rapidly deliver new features before competitors.  Motivation consist of a “us against the world” mentality and the potential of pre-IPO stock grants.

Agile ExperienceSome – Founder launched using Lean Start-up principles he read about.  Work is done loosely in sprints/iterations and the team uses a form of User Stories with either To Do or Done status.

So what is the likelihood that an identical approach to software development will serve each team equally well? Although both teams could apply Scrum with potential success, are there other approaches or additional practices that can help the team reach their goals?

By identifying your team’s values using the 12 core areas, you can start to identify and create the best possible approach to guide your team to becoming Agile rather than just using a one size fits all methodology.