A Way of Working

This list is not meant to be in a specific order of process, it is just a list of things we do. And, this is an evolving list.

1. We change the way we are working as needed.
2. We don’t need to ask for permission to fix something in our products.
3. A core team, sr. developer and product owner/product manager/analyst meet with the business/customer/user together to discuss problems and/or stories. This is even more agile when the business/customer/user can be with the developers(makers) directly while the thing is being made.
4. We get training immediately as needed.
5. We experiment and learn with everything we do.
6. We story map from user experience or expected way of working with the user whenever possible.
7. We leave stories as stories until they are priority to be built. We don’t spend time refining and detailing everything in a story to have it sit in a giant to do list backlog.
8. We split stories when the story has multiple stories in it. We don’t split stories into more stories to build the story, those are tasks or sub-tasks of work to make the story work.
9. We don’t have refinement meetings to build out the backlog, we meet to discuss what is next to build, understand it, and then start building it.
10. We don’t estimate, we just count stories and make projections based on cycle time.
11. We keep the backlog lean and mean, things older than 6 months are removed since too much has changed since the story was created (we want it at 2 months max, but getting it to 6 months from 3 years is improvement).
12. We meet together to work through questions and issues, we don’t send emails or comment on Jira tickets and wait for someone to see it.
13. We build a little bit of a story, show it to the user and ask if we are on the right path and continue this until the story is done. We do not build everything, even with shared understanding, and hope it is right.
14. We practice TDD. Some of us write the code, write the test, revert the code, see test fail, correct the code, see test pass. This is mostly for domain knowledge and getting used to and how to work with TDD.
15. We don’t throw things over the wall between BA/DEV/QA. We pair program at minimum and mob program whenever possible. This tends to remove the need for code reviews since we wrote it together.

I was evolving this list and came across a much better list that people should read. Allen has a much better way with words. My list above is some of the things the teams I currently work with are doing. Allen’s list I think hits more to the core of what working in an agile way is about.

https://holub.com/heuristics/