Setting up an Agile based environment for any work group or business

Overview:

An agile environment organizes the resources of an organization in a more adaptive and disciplined way. Short-term adaptability and rapid response strengthen long-term planning. Using the concept of controlled chaos it is possible to increase efficiency and innovation. Through new roles and a few rules any organization or group can become more agile.

Philosophy:

Although agile is originally a methodology developed by software programmers. It is  at heart a new philosophical approach to project management. Consider this statement of values from the original authors of the agile manifesto (Beedle, et al; 2001):

The philosophy of agile has a number of important ideas, such as: self-organizing groups, knowledge sharing cultures, participatory environments, individual empowerment, responsible stewardship, collaboration and open communications.

In this sense, agile is more a way to create a new culture than simply a way to write software or manage a project. For this reason, it is adaptable to almost any workflow or operational situation. In essence, agile blends the simple credo: “act – analyze – adjust” with the life affirming principle of “people first”. The result is a more effective organization. This is why agile is such an important part of management 3.0.

Psychology:

The psychological importance of the agile method

Before we get into the practice of agile management let’s take a quick look at the generative grammar behind it. This gives us a sense of the purpose and underlying dynamics of the agile components. (We will learn more about these concepts in the next section.)

Agile Concept	Generative Grammar (an underlying dynamic)
User stories	We think clearly and adapt quickly to customer/market needs (aka reality)
Estimates	We collaborate realistically to project time and difficulty of projects
Sprints	We work in more meaningful and adaptive units of time
Standups	We share our status quickly, usefully, and stay focused and aware of where others are at
Velocity	We have a realistic view of our capabilities
Iterative Pivots and Releases	We adapt quickly and effectively to changes in the market

Practice:

Putting the pieces of agile to work in your organization

Getting started in agile takes planning and discussion. You start with your organizational vision (see: How to create a vision log). Once you have a dynamic approach to your future, you begin looking at the specific experiences that your potential customers are after; these are your User Stories. An example might be, “ As a business owner I want a to-do list that follows me on all my digital devices and is easy to use.” And so on…

You then prioritize your user stories and estimate the difficulty of completing them using story points. This is important because it involves all the core members responsible for bringing your project to life. Estimating has significant psychological value because it improves communication, knowledge sharing, and over time establishes realistic production capacities.

You then plan your first release. This will be a four-month interval that aims at completing a deployable or demonstrable version of your product or service that you will test in the marketplace. Inside of this release period will be a series of sprints, possibly 4 four-week work sessions. These sprints will be iterative in nature, meaning you produce results that you test and evaluate in some way. The result of the testing or evaluating then influences the next sprint.

Here are some of the roles and rules to consider in developing an agile culture…

Roles:

A Scrum Master (aka: show runner, team leader/captain, director, general contractor) is familiar with the dynamics and process of an agile environment and will act as the mentor and team wrangler. The SM helps support workflow balance, removes obstacles and helps make sure everyone is implementing all the agile practices. The group agrees to view the Scrum Master as team captain, responsible for morale and discipline. (You can find more info on this role here and here.)

A Product Owner (aka: producer, general manager, architect…) represents the interests of the principle stakeholders, i.e., the business, the customers or the end users. The PO guides the team towards building the product or in lean business modeling parlance, continually proves or disproves the current business hypothesis. The product owner is also responsible for understanding and communicating the company’s Vision Log – the evolving but long-term vision or road map for the organization

Product owners do this in part through the product backlog, which is a prioritized features list for the product or service.

The product owner is commonly someone with a solid understanding of users, the market place, the competition, and of future trends for the product, service, or type of system being developed.

Small groups of say 2 or 3 members, not part of a larger operation, can share and/or rotate the roles of Scrum Master and Product Owner.

Core Team Members are everyone else directly responsible for bringing the project to life; or, in a going concern, meeting the quarterly release objectives. They work collaboratively and develop themselves in an interdisciplinary way. This means simultaneously mentoring and learning from other members of the group. They will also  take part in the organization’s knowledge sharing system. And of course they must participate in the daily stand ups.

Rules

The Product Backlog is the laundry list of all the things you need to do to bring your product or service to life. For a software or internet company it can include things like product features, bugs to resolve, technical work to complete, etc… For a service organization it could be a list of client issues, research projects, analysis, client calls, etc… For a marketing department it could be sales calls, market analysis, SEO, SMM, vendor meetings, write copy, etc… (Here is a good article on agile marketing.)

The rule to creating a product backlog is not to list outcomes. Outcomes are the results of actions and not directly under any individual’s control. This includes sales volume, client acquisition, or basically any “goals” that are not made up of concrete action steps. A product backlog is a list of actions or activities waiting for your team members.

User Stories are an effective way to build your product backlog. To write user stories, simply state your product or service requirements from the perspective of an end-user. For example, the goal of creating a video promotion for your service would be: “as a potential customer I want to see a video of what your product does and how it will help me.”  The basic framework for a user story is, “As a <user>, I want <a goal> so that <a reason>.”  A story that is too broad or general gets broken down into sub-stories. Examples of sub-stories could be, “As the director and editor of the video I want storyboards to work from”.  And another would be, “ as the storyboard artist I need a script to work from.”

Writing organizational or operational goals as user stories has a psychological benefit. It helps give everyone involved in the development process, adopt a customer-focused perspective. User stories also help develop empathy, which can increase innovation. Additionally, stating requirements as end-user-needs can help reduce certain cognitive biases.

As the list of user stories grows, the stories or product backlog are sometimes logged in specially designed software (e.g. scrumy.com, Agilo for Scrum, XPlanner, and perhaps Mingle).  We are currently testing out AgileWrap. [I’ll update with our team’s opinion over time]. You can also keep it real and use index cards or sticky notes. They use of analog cards allows you to place them on the wall and use a kanban system of lean workflow (more on that later). If you stick with the wall system, you will still need to input the stories, estimates, and completion rate into a spread sheet to track your velocity.

To make user stories, or anything on your product backlog list more effective, it is important to include all the team members and stakeholders that will influence the product or service. For example, if you are building an iPhone application or new website, the user experience is as important (sometimes more important) than the capabilities. Therefore, it is important to involve your UX/AI person when you develop your product backlog.

Whatever your product or service is, it is a good idea to bring your design and user experience team in from the beginning. Thinking about how end-users will see and experience your service or product will force potential problems and issues out earlier and not later. Including the designer(s) in the early stages can help bridge the gap between end-user and the development team.

A Sprint is a predetermined length of time (one week to four weeks) during which the team will work to complete the tasks agreed upon in the sprint-planning meeting.

A Sprint-Planning Meeting will include the product owner, Scrum Master, and the rest of the team. Unlike the product backlog development process, which can involve multiple stakeholders/clients, end users, etc…-sprint planning is usually restricted to the core team in charge of building or creating the product or business.

The goals of the sprint-planning meeting are:

• Describe the highest priority actions or user stories
• Analyze and question the more general user stories and requirements and turn them into the detailed tasks of the sprint backlog (different from the product backlog.)
• Estimate the amount of time each story or requirement will take to complete. This is a crucial piece of the agile-sprint methodology. In the early stages it is difficult but as the sprints progress you will get better and better at it. Part of the secret to good estimates is to predict the effort, not the calendar time that a project will take. One trick is to convert tasks into points rather than time. Points can take into account more than just time such as complexity or simplicity.
• As you complete sprints, you can track the percentage of actual tasks completed and chart that number as your sprint Velocity. To predict your next iteration’s velocity, add the estimates of the stories completed in the previous iteration.
• Define the basic goal of the sprint based on the sprint backlog. This is a short sentence or phrase that sums up the purpose of the sprint.

Daily Standups are meetings attended by the entire team (everyone committed to the project’s completion). These meetings are strictly limited to 15 minutes and no sitting. Ideally they occur at the same time and place everyday. Team members that are working from other locations can meet through Skype or Google hangouts.

Limit standup meetings to the following three questions: (answered by each member)

1. What did you do yesterday?
2. What will you do today?
3. What obstacles are you facing?

If you have the meeting at the end of the day the first two questions become: “What did you do today?” and “What will you do tomorrow?”

The daily stand up is not the age-old status report meeting where management collects info on who is falling behind. Instead it is a session where members make commitments to each other about what they will complete.

If impediments surface, the Scrum Master (as well as other team members)  can help to resolve them as quickly as possible. If the obstacle cannot be handled in the meeting it is the Scrum Master’s responsibility to resolve it as soon after the meeting as possible.

It can also be useful to hold your daily meeting in front of the board showing the sprint backlog; aka the sprint or scrum task board.

Celebrate the Milestones – it is important to take time out to chill and reward the team at the end of each sprint with a celebration of work done.

Post Mortems are conducted at the end of each campaign to review and record what you learned as a team; sort of like a retrospective of all that occurred from beginning to end.

A Quick Reference Glossary of Key Agile Concepts

Vision Log – The vision log is a monthly, quarterly, or semi-annual revisit and revision of your organization’s objectives. Here instead of a static mission statement you will create a shifting growing journal, chronicling the purpose of your entity’s existence.

Project – Usually a project is a specific product or perhaps a big event. If no specific finished product is the goal either because it is complete, and you are in sales mode or because that is not the nature of the business (like a service business), then make each quarter a project. Note that your quarterly objectives or user stories will come from your Organizational Vision Log.

Product Backlog – a list of all the user stories (objectives/requirement) required for your project. You will use story points to estimate the difficulty of each user story.

Story points – these are estimating values that show the difficulty of each story when compared to other stories on your list (backlog). The members of the core team estimate the point value of a story by taking into account the time, complexity, and potential pitfalls. Points begin with best guess value such as an ideal workday. Stories are then evaluated in comparison to other stories in the project. So if a story that is fairly easy to complete is a 1, then something that is twice as difficult is a 2. If the next story is twice as difficult as the 2 was, then make it a 4 and not just a 3. Do this to help avoid cognitive biases.

It is better not to use a 1, 2, 3, 4, 5, 6, sequence for estimating. This tends to lead to bad estimates. It is a better idea to use a logarithmic sequence like (1, 3, 5, 7, 11, 13,) or a tetranacci sequence like (1, 2, 4, 8, 15, 29).  Also, don’t overthink it when you are first starting out. Over time your organization will get better and better at estimating user stories.

User Stories – begin with a description: “As a <user>, I want <a goal> so that <a reason/benefit>.”

From there it expands into three elements:

1. A description of how it brings value to the end-user.
2. Discussion of details as well as the understanding and expectations of the people affected by the story (from developers, to clients, to end users).
3. Clear criteria are used for determining if a user story is complete and acceptable.

A useful acronym to check user stories is INVEST.
I – Independent: is it a thing in itself? Or does it depend on many other factors to work?
N – Negotiable: Is there room for improvement, flexibility, adaptability?
V – Valuable: does it give value to the end-user
E – Estimable: can your team come up with a ball park estimate?
S – Simple: is it small enough to fit in a sprint? If not, can it be broken down and stay independent?
T – Testable: develop a means of testing or assessing any user story.
(Thanks to Bill Wake for this well received idea.)

Releases – these are milestones and usually the product of multiple sprints (but not always). They represent a working version or component of a project. It could be an event or a presentation in a sales and marketing context. It could be a demo or prototype of design work. In a service context it could be a monthly report. Basically, a release is the demonstrable or deployable results of multiple sprints. Sometimes, a sprint and a release coincide. For example the last sprint of a release could be known as the release sprint. It is also possible for a release to only require one sprint.

Sprints – A sprint is a fixed amount of time a team uses to complete an agreed upon set of user stories. Larger user stories (aka epics) get taken apart and become smaller stories (aka child user stories). These are user stories  that you and your team estimate will be possible to complete within a specific time; say,1 day to 6 weeks (though 1 to 4 weeks is most common.)

Tasks are the discrete actions generated by the user stories in any given sprint. Estimate tasks  in hours.

Defects – when you get feed back from users or testers that something in your product, service, or process isn’t working and the solution is not a quick fix then you can list the problem as a defect. It will be in the backlog ready for scheduling (i.e. attached to a sprint or a release.

The Sprint Task Board is a visual display of how stories or requirements are progressing through the sprint. This can help alert the team to bottlenecks or mis-estimating.

Here is an example of a task board mocked up by Mike Cohn of Mountain Goat Software:

A Sprint Review Meeting is held at the end of each sprint. This is both a concise presentation of everything accomplished during the sprint and a review of the team’s velocity, i.e what the team accomplished versus what they estimated.

Sprint reviews are informal, simple, and need limited amount of preparation time, so as to not distract from productivity. Participants may include the sprint team as well as clients, consultants, and end users.

Sprint Retrospectives are held after the sprint and are also short and limited to the sprint team. They focus on what they learned from the completed sprint and give valuable insights for the next sprint-planning meeting. I like agile coach Mike Cohn’s recommendation of focusing on three issues: What should we:

1. Start doing?
2. Stop doing?
3. Continue doing?

Burndown Charts are how the Scrum Master or Product Owner keep track of the team progress by graphing the amount of estimated work remaining over the course of the sprints. The sprint burndown chart gives the team a visual record of their progress.

The chart typically presents 2 lines going from the top left section of the chart towards the bottom right.  While the first line presents an estimate of work delivered over time, the second line shows the real values. As such, the Burn Down Chart helps predict  when work scheduled for the current release or sprint will finish. The Y axis is units of time or story points estimated and the X axis represents units of calendar time or the number of sprints.

Velocity is the distance covered in each sprint as measured by story points. This is a relative number; you are comparing output from sprint to sprint based on your teams estimates. If your team guessed you they would finish 20 story points worth of work but only completed 18 then their velocity is 18. Over time keeping track of velocity will help make better estimations.  Velocity is not a tool for measuring productivity; it is just a tool to improve estimates. Here is a good article on velocity by Michael Lant.

Graphical Overview – the different levels of an agile environment

Graphical Review – the agile process in action

 Please post your comments and feedback. I would love to hear from you. 

(credit for the team in a circle illustration at the top of the article goes to Bob Commander)