Many organizations follow some flavor of “Agile” development with varying results. This document describes how we have successfully developed software for years at ÆLOGICA and what you can expect if you engage us.
At ÆLOGICA, we seek to maximize the sustainable pace of value delivery for our clients and businesses. This overriding value must be embraced by every member of a team, including client stakeholders and the Product Owner. We judge all practices against this criteria.
We follow heuristics. Heuristics are practices we have learned from experience. I hesitate to use the word “rules”, because people treat rules like commandments. These heuristics may or may not be optimal. They may or may not resemble techniques you have used elsewhere in an “Agile” setting. They do work 98% of the time and that is good enough. When employed by all members of a team, they will lead to a consistently high velocity.
There are reasons to dispense with any given practice from time to time. Do so consciously. Use your best judgement. Learn from your mistakes. Inform others if you depart from the norms.
Agile Heuristics for the Whole Team
1. Prepare for a marathon, not a sprint.
In a sprint, you run flat out at an unsustainable pace to beat a field of opponents across a well-defined finish line. This hardly describes most software development — even software development in competative entreprenuerial markets. The finish line keeps moving. An unstainable pace cannot be kept up for very long. The winner is the organization that learns how to best serve the customer fastest, not the one that writes the most code.
The word “sprint” creates a false sense of urgency. Making everything urgent implies nothing is urgent. Fatigue from perpetual crisis-mode will burn out even a strong team. We seek sustainable and consistent high-velocity rather than erratic and unpredictable crunch and crash.
2. Minimize cognitive work and communication.
Do not create extra work for others.
A software team is a multi-brain network that works together to solve complicated problems. Busywork, redundancy, information-hoarding and organizational politics all detract from the performance of the team as a unit.
Every member of the team, including those on the business or product side as well as each developer has a responsibility to minimize the amount of total cognitive work and communication performed by the whole team.
If you know something that someone else will need to know to perform their role, provide the information in the right context, in the right form, at the right time. Do not wait to be asked.
If you have thought something through, record your thoughts in the relevant place where the person who will next encounter it or need it can see it. For example, place necessary comments in an issue tracker where they can be searched, use comments in the code if you are communicating something to a future developer, etc.
On the other hand, no one can do your thinking for you. Take initiative and responsibility to do whatever you can do.
3. Teach others how to work with you.
Do not assume that everyone knows these heuristics even if they have read them. When something seems out of whack because someone is not performing as expected, gently explain the heuristic or rule to follow and why. Use the “When you do X, it causes me to do Y.” conversational pattern. Make your expectations clear without implying ignorance in the other party. Assume your teammates are skilled professionals trying to do their best. Your job is always to help your teammates do their best because you are not an island and you cannot succeed alone.
4. Every team is a learning team.
Practices must be questioned and modified periodically. Do not assume you already know how to do things best, even if you have years of experience doing things one way or certifications in a methodology or practice. Be ready to learn from your teammates. We are pragmatic, not dogmatic. We do what works.
5. Use the best tool for the job.
Most of our non-programming-related tooling pertains to communication. All members should be familiar with and know when to use the proper communication tools.
Use the agreed upon project tracking system for communication about the project and for holding requirements in a suitable form for team-internal consumption and processing. Use the tracking system to organize and identify any task that will consume more than a few minutes of a team-member’s time. If you begin working on something not in the tracking system and it takes more than a few minutes, add the item to the tracking system and decide where it fits within your other priorities.
Avoid using email for project-related communication.
Use email for out-of-band signaling to call attention to issues of concern to management that are not related to specific features or development and which are not urgent in nature. Do not write long emails unless absolutely necessary. Use Reply instead of Reply-All whenever possible. (See Rules for Better Email)
If someone sends you an email related to a story or bug, copy-paste it into the item in the tracking system or create a new item for it.
- Use chat and/or team chat for frequent intermittent communication and coordination with team members where small delays are tolerable.
Avoid excessive unnecessary banter in group chats.
If coordination is too slow when chatting, call the other party on Skype or by phone to speed things up.
Use documents outside the project tracking system only for consumption by members outside of the team.
Attach documents to the relevant features within the tracking system.
- Use a simple spreadsheet or database only when appropriate.
If you must maintain a large amount of structured data that is not suitable for inclusion inside the project tracking system you may use a spreadsheet. Do not use a spreadsheet or database for information consumed by the team internally that has a proper place in the project tracking system. For example, do not start to build spreadsheets of bugs or features.
You may use a spreadsheet or database to input or track a large amount of automatically generated test case variants or test data or to supply test cases for use by the developers in automated testing.
6. When it comes to deadlines, let the backlog speak for itself.
Do not commit to arbitrary deadlines picked by others.
These deadlines are not grounded in reality. They are almost always wildly optimistic and highly-political in nature. We seek to shield software teams from organizational politics and focus on the work to be done.
Valid estimates of completion dates can be arrived at through:
Applying a type of rigorous estimation that is almost never seen in practice because it incurs heavy up-front analysis costs or
Using an agile project tracking tool with a well-ordered and completely estimated backlog used by a team with several weeks of track record of having items accepted.
Needless to say, we use #2. It is a bottom-up method of analysis grounded in reality. If a completion date appears too far off for some stakeholder, let them decide to change priorities, remove items from the backlog or adjust their dates. These are the only realistic options.
7. Agree that “done” means Accepted.
Do not use the term “done” casually. Always refer to the status of the story or epic in the project tracking system.
Nobody is finished with a story until it has been Accepted by the Product Owner in the acceptance environment and merged to the appropriate branch. The above heuristics apply to all team members, regardless of role or function.
The Developer role applies to anyone who makes commits to the code base and writes or edits code. Generally a single team will contain between 2 and 6 developers and a single Product Owner.
1. Follow the default Order of Work:
- Production issues – Only if there is a financial impact
- Rejected items – Focus on fixing and redelivering
- Previously started items – Focus on delivering; help someone else on the team deliver their items if you can
- Select new items from the top of the backlog that you feel most qualified or interested to work on or which you think you can deliver quickly.
- Assist with grooming the feature backlog by improving features, estimating features, correcting labeling or other organizing tasks.
- Plan work for the next day.
2. Improve the quality of the user stories or bugs prior to working on them.
- Fix the title of the user story or bug if it is misnamed or unclear. (See guide)
- Subdivide the story if you think it will take more than a full day to deliver.
- Request any additional information or clarification required before starting.
- Add any information you have that will assist the people working on the story.
- When clarifying verbally a complex set of instructions or steps, repeat the entire set as you understand it and ask for confirmation. Then update your notes in the description of the user story.
3. Test everything in the delivery/acceptance environment prior to delivering a feature in the tracking system.
Agree to how much manual “smoke testing” you will do, eg. multi-browser or multi-device. Avoid the “worked on my machine” situation. You are responsible for seeing the features you worked on tested, accepted and moved successfully into production.
4. Provide any information required to accept the feature.
Examples include instructions for manual testing, caveats or known cases that should not be tested, and links to documentation. It is especially good practice to include a screenshot of the feature you have delivered. This helps eliminate confusion and if the acceptance environment changes between the time you deliver the feature and when the feature is tested for acceptance, it will be clear to the person doing the testing.
5. Speak with the Product Owner or client representative daily at the appointed time for the “standup” using voice or video or in person if possible.
Keep it short. Be prepared for the call. Ask for things or call attention to requests you have made for information or to items that have not been accepted. Do not review what you have done — that should be obvious from the tracking system and some people are prone to exaggerate or go on and on about whatever they did while wasting everyone’s time. Stay focused on delivering value. Simply state what you are working on and what you are going to do next and anything you might need from the other party in order to do that. Postpone any followup conversation for a 1-on-1 after the standup. Volunteer to help with accepting any difficult features.
6. Clean up the Current column of the project tracker after delivering a feature.
Group items in a similar state together according to the priority in Developer Heuristic #1, Order of Work. This makes it easier for everyone to see what needs to be done. Do not wait for someone else to organize your mess.
7. If the inventory of unaccepted items is large, stop and help the Product Owner to accept the items before working on more stories.
The goal is always to maintain a “just in time” inventory of delivered features. Do not batch up a week’s worth of work or more for acceptance.
8. Groom the backlog.
Estimate any unestimated item/s as soon as you have free moment or need to take a break from programming. We mention this twice because it is very important that developers also take shared responsibility for the quality of the backlog or work queue.
9.Clean as You Go
When you are working on a user story, if you encounter code that needs cleanup or refactoring, use your best judgement.
Try to execute cleanup chores while you are delivering related value in the form of a user story or feature. This is part of the “true cost” of the feature. In general, do not hide the cost or “pay it later.” Always doing the expedient thing will create an unpayable technical debt.
If you choose to postpone the cleanup work, make a chore in the Icebox and tag it appropriately.
Paying as you go keeps technical debt from growing too quickly to an unmanagable size. Little bits of effort exerted continually over time add up quickly and even a large technical debt can be paid down this way. Use your best judgement. Do not ask permission. Just do it if it needs to be done and you know you can do it in a reasonable amount of time. Postpone if you are unsure. If you ask, it may never get done. Start with small clean up tasks that will not introduce problems until you are comfortable and confident enough in the codebase to handle larger refactoring.
Product Owner Heuristics
The Product Owner manages both the input and the output of the development team. He or she may have any title but we refer to the role as Product Owner. Generally this will be filled by a Product Manager, a “Project Manager”, an Engineering or Development Manager or a Producer of some kind. Occasionally, this will be the founder or CEO of a small startup.
Whoever fills this role must:
1. Proactively handle communications outside the team.
You are the focal point and conduit for information to management and other stakeholders. Do not let others request items or derail the team with ad-hoc requests. If something urgent comes in for the team, add it to the backlog and prioritize it accordingly.
2. Use the agile project tracking system to organize development. (See Guide)
When used properly, you will be able to give other stakeholders visibility into when things will be done and your team’s production will likely never be questioned. Keep it well ordered and organized and you will be able to provide high-level information and effectively manage expectations. This is your primary power-tool. Resolve to learn and use it well.
3. Manage expectations about delivery timelines using information derived from actual team performance over several iterations.
Do not make promises about what you think is possible before you have the track record and all the information required. Avoid making promises if at all possible. Endeavor to provide visibility into your team’s performance and progress through a well-ordered backlog in your agile project tracking system.
4. Make yourself available to the team via voice, video or in-person daily at the appointed time.
5. Remain accessible in a chat for some agreed upon period afterward.
6. Schedule or request extensive coordination sessions ahead of time.
You may need the team’s assistance in accepting complex features or to help estimate and clarify items in the backlog or icebox. You may need to arrange meetings with other teams. Keep this to a minimum however as these tend to be time-wasters. If at all possible, be the conduit.
7. Allocate time each day for acceptance testing.
Plan to spend the first hour of your day or a regular period of equivalent duration to perform acceptance testing on delivered stories. If your timezone situation allows, try to do this prior to the start of the developer’s day. Allocate more time if you have more than 2 developers on your team at a rate of 1 hour per developer-pair.
8. Allocate time each day for improving your backlog.
Plan to spend the second hour of your day or a regular period of equivalent duration to organizing the backlog for greater clarity, better prioritization, better labelling, or structuring epics and milestones. Allocate more time if you have more than 2 developers on your team at a rate of 1 hour per developer-pair.
9. Provide all information necessary for the developers in the agile project tracking system.
If you need to reference an external document, attach it to the feature or provide a link. Include instructions for replicating a bug, a screenshot demonstrating a problem and any information regarding the browser used or urls accessed.
10. Do not reopen or change stories after accepting them.
Create a new story with any changes that come up after a story has been accepted.
11. Understand that quality begins with the inputs.
You are responsible for organizing the inputs. Study the guide for how to do this well. At ÆLOGICA, we provide agile coaching to help get a project started well or to correct course if a project is off-track or experiencing a crisis.