The first in a series about Caxy’s implementation of Agile. Ben Rathbone, a Caxy ScrumMaster, discusses implementing agile in an agency setting.
What is Agile Development anyway?
Agile Development is a project management process for software development. At Caxy we’ve seen agile used to plan a wedding, remodel a house, organize a party, and plan a benefit. Agile provides a way to get complex projects done while working with a multi-disciplined, collaborative team. Have you ever had an IT project (or any project) go spinning out of control? Or have you are tried to get the most out of a team, then Agile may be for you.
I have worn the hat of ScrumMaster for several months now, and in this capacity I’ve facilitated planning meetings, held pointing parties, maintained ticket boards with swim lanes, and played the role of “information radiator.” In my experience, many companies pay lip service to Agile, implement some elements of it, or implement it 'whole hog' only to see it sputter and eventually set aside. At Caxy, we made several attempts at implementation over a five year period. In May of 2014, our efforts gained significant traction.
At the beginning of 2015, we have a solid Agile practice driving all our major, multi-person projects. The basics and details of Agile and Scrum are covered elsewhere.These are my tips on getting the rubber to meet the road with Agile in your organization.
1-Think in terms of principles - rise above the concretes.
Don’t let the rituals distract from the larger goals of an Agile practice.
Agile principles embody a specific approach to dealing with the deployment of resources. There are a variety of rituals, props, products, and ways of "doing Agile.” Stay focused on the larger goals of compressing the cycle of completing work, receiving feedback, and planning the next iteration, and delivering value in tighter alignment with the client’s needs and wants. The rituals and props are just means to that end.
2-Think in terms of goals not tools.
Don’t get hung up on a tool. Stay focused on agility.
Evaluate your tools in terms of how they help meet the larger goals of agile. Keeping your process and principles ahead of your tools and rituals helps prevent the limits of the tool from limiting your process. Any tool has limits: do not have your entire Agile process depend on any one tool. At Caxy, we tried a variety of tools including Pivotal, BaseCamp, Trello, home-grown solutions, and CodeBase. Recently, we settled on Atlassian’s JIRA and Confluence, paired with manually updated physical KanBan boards. We are still experimenting with various details, but our process is not tied to a single tool. Our props evolve, our process stays on target.
3-Get Creative
Staying focused on the principles allows for creative implementations. Implementation can be tuned to the needs of your organization and production process. At Caxy, we’ve created issue-cards for our Kanban boards with a variety of styles. We found it was useful to have more sprint details on the wall, besides issue-cards, so we print calendars and sprint summaries to post on the wall. We like JIRA but we’ve been dissatisfied with its means of printing issues. So, we rolled our own system to render printable tickets via API calls. Don't be afraid to try different ways of enabling or enhancing your own Agile processes and rituals.
4-Just Do it, embrace ‘Creeping’ Agile
Thinking that planning and Agile work as two separate activities is a trap. Your Agile work is your planning. To begin, jump in. Sometimes, one has to "just do" to get going. If you “just do ” and start thinking and talking in Agile terms, the concepts can still creep their way into your organization's operating system. An easy place to start is to start talking about work in terms of sprints. A sprint is chunk of work and most any project can be broken down into chunks of work. In short, you don't have to implement everything at once, but you can implement parts of the process at a time.
5-Bolt down the definition of done.
For process to gain traction, when previous attempts have failed, the problem may be that the specific end-point or goal needs to be defined in a manner more clearly and concretely than before. A clear definition of done is important to be able to work backwards and plan accordingly. Once the definition is pinned down, it will be critical to get the team’s input on the viability of the plans to meet deadlines, and get the rest of the planning process in motion. “Very specifically defined” may mean down to explicit, tangible, and own-able steps.
An example of “done” used at Caxy
- The Product Owner has completed sprint planning when a plan document is complete
- The plan document is delivered to the ScrumMaster listing all the user stories and subtasks.
- The ScrumMaster has completed sprint planning when all the stories listed in the doc are created as issues in JIRA and include updated stories, subtasks, and points.
It is equally important for deliverables for the client to be defined in clear and explicit ways. For example, with software development, it is important to agree with the client on when a particular sprint is complete. Is it complete when the code has been committed? Tests written? QA’ed? Deployed? Or deployed and bugs fixed.
