LitheSpeed recently launched a new continuing education offering called Your Agile Path, which gives you access to our training classes, career mentoring and a new quarterly workshop series. Agile Outside of IT, coming in June, will explore how methods like Scrum and Kanban have been applied to everything from marketing and HR to real estate, education and running the household. Here are a few targeted points to wet your appetite.
Let’s introduce a framework for “jargon-free agility” that is meant to help folks understand the patterns behind the methods in a manner applicable outside of the world of software development. The core concepts of jargon-free agility are: Understand Value; Think Big, Build Small; Focus on Feedback; Work Together, and Keep Work Visible.
Understand Value
Value is defined by how effectively a given solution addresses a given problem. The mistake many make is jumping to solutions before the problem has been fully grasped, with a solid audience defined and validated. Luckily, agile methods like Scrum are meant not solely for delivery, but also for exploration and learning.
Since we’re eliminating typical analysis phases, we must use the time within sprints for learning and research as well as building. Insufficient preparation and forethought, typically led by roles such as the Product Owner, have led to many rudderless teams and failed sprints. Think of agile delivery cycles as a chance to probe, test and explore.
Getting started: Ask yourself what assumptions you’re making about your audience and their problems, then have your teams use simple prototypes, simulations and research techniques to test these assumptions. Adjust your plans, goals and expectations as appropriate based on this new knowledge.
Think Big, Build Small
Agile teams tend to build things in small chunks, generally delivering something tangible every few days or so at most. There are many good reasons to decompose work; small things are easier to discuss, analyze, build, test, document and (critically) change. It is easier to collaborate around something focused and tangible than around something large and ill-defined. Finally, the feeling of closure and accomplishment from getting something done arrives much more often.
However, one can get lost in these small bits, and often it takes many of them working in harmony to truly fulfill our customer’s end goals, so an oscillation between big picture planning and detailed elaboration is critical.
Getting started: Sketch out your user’s end goals, then map out journeys you will create or improve for them to reach these goals using sticky notes in simple rows on the wall. Plan the simplest experience that meets the goal for an initial release, and flesh it out in subsequent releases.
Focus on Feedback
If we’re going to move fast, then we have to start fast. Many projects get mired before they even begin in the muck of analysis paralysis. This is when nobody knows the answer, but none will admit it. The rationale is fear; if we make a mistake, punishments may ensue, so it seems safer to remain perpetually undecided.
The solution is to lower the cost of failure, and hence make rapid experimentation safe and palatable. Quick, direct feedback loops are one of the best ways to do this. Agile methods primarily adapt through two perspectives; product feedback and process feedback. The Sprint Review in Scrum is an example of product feedback, while the Retrospective focuses on team and process improvement.
Getting started: For product feedback, ensure that as you build things, you test them in meaningful ways with real users and customers (not just internal stakeholders). Use the feedback from these tests to plan further deliveries. For process feedback, let your team improve one thing of their choice every sprint, and ensure that there’s an easy escalation path when they hit process impediments they can’t resolve alone.
Work Together
One major grievance the Agile community holds against the waterfall method is its strict delineation of the development process into separate phases and roles. Are analysis, design, development and testing really activities that should happen in serialized isolation from one another, with separate owners and executors? As it so happens, Scrum’s name was borrowed from a Harvard Business Review article that established just the opposite, The New New Product Development Game; put simply, the more that activities and roles overlapped, the more innovative and successful teams and projects tended to be.
In practice, the many activities that comprise building a new product or service are deeply interrelated, and it’s tough to manage dependencies with only a single hand-off point. Also, overlapping roles help team members work together fluidly and share common goals, instead of blaming one another when handoffs go wrong.
Getting started: Establish common goals for your entire team every sprint, as opposed to defining deliverables by activity completion. Try to make currently serialized processes more concurrent, so that cycles like writing and editing or building and testing happen frequently on small bits of work. Encourage team members to pair up and learn about one another’s skillsets while working.
Keep Work Visible
An easily defensible truism is “out of sight, out of mind.” When we can’t see our work, we forget about it. It lurks in the back of our minds, generating subconscious stresses that drain our energy. Customers also get nervous when they can’t see the state of their requests, and begin asking for more reports and meetings. The result is a subtle but draining morass of distrust, lack of focus, wasted time and fatigued despondency. The solution is focused transparency.
Agile teams frequently use “information radiators” like big, visible charts to make projects largely self-reporting. Having tools on the wall makes them more likely to be used directly by the whole team, not just a project manager. Also, it’s easier for groups to work in concert on complex problems when they can quickly write, rewrite, sort, group and sequence the pieces of the problem in some tangible manner, such as with sticky notes on a whiteboard. For instance, Scrum teams use sprint task boards for tracking their work and burn-up charts for forecasting deliveries.
Getting started: Write simple cards that detail out your current deliverables, and note the key states through which they travel (e.g. not started, doing, testing, done). Put this in some readily visible location, and have planning activities such as the daily scrum happen at that location. Also note the key questions that stakeholders will likely ask about the project (e.g. when will it be done?) and create simple charts that sketch the team’s delivery trends to date; this empirical knowledge of the past will help you create forecasts of the near future.
What’s Next?
I hope these ideas help to make some of the core concepts of agility more accessible and applicable to your own work. To learn more about specific applications within domains such as education or disciplines such as human resources, sign up for my Agile Outside of IT workshop in Your Agile Path today!
Look for my book “The Leader’s Guide to Agility in HR and People Operations” coming soon.
