1. Do not talk about Kanban
2. Do not talk about Coolban
3. Every rule can and should be challenged
4. A story is ready to Code when the acceptance tests are done
5. A story is ready to Test when the acceptance tests are green on QA environments
6. A story is in Build after being preapproved
7. A story is Done after being demoed on an integration environment
8. Every story has a sponsor, if you are the sponsor, you should pave the story's way to Done
The fact that I published this proves how valuable is "The Passionate Programmer" by Chad Fowler. I am applying his advice of "Let your voice be heard" from the chapter "Marketing... Not just for suits". I already do roughly 80% of the things recommended in the book to guide you in a path of a great career. But what makes it unique is the fact that I agree with 100% of what it's saying and it pushes me to do some of that 20% I keep chickening out of doing.
If you already have a great career you would read this book at a Dreyfus level of Expert. In such case I can't really tell how the expert to expert transfer of knowledge goes. You might enjoy the anecdotes, especially when they lead to metaphors back and forth between music and programming. It helped me do retrospectives on misbehaviors like in "Learn to love maintenance", so you might map errors in early years like when I desperately wanted to leave my team in 2008 to escape from legacy code.
The book is the second edition of "My job went to India: 52 Ways to save your job" and it was refactored to read more like 52 advices to make your software development career shine. It still has a lot of references to India since the author lived and worked there. For instance, the warning about "The South Indian monkey trap" is an eastern version of the boiling frog from "The Pragmatic Programmer". I do think however that it's more cruel because they actually do that to monkeys.
The book closes with the advice to "Have Fun". "Software development is both challenging and rewarding. It's creative like an art-form, but (unlike art) it provides concrete, measurable value". If you've chosen to become a software developer this book reassures you why you should feel lucky and offers advice on how to steer you career.
I didn't choose to be a software developer, I am a natural born programmer. I am not a geek, I just happen to have natural inclination to think in terms of programmable algorithms. That is what I enjoy the most and it feels as creative and cool as to be a rock n' roll guitar player. This book is about how to make it to the big gigs and perform at the highest level in your profession. To become a rock start doing what you love, programming.
The first rule of Coolban is "you do not talk about Kanban". The second rule of Coolban is "you do not talk about Coolban". We are not about labels and fashions. We are not about process fondness an methodology zealotry. We want to be highly profitable for the enterprise, professionally accomplished as individuals and harmonically gelled as a group.
Blindly following anything is a recipe for disaster. Every agile methodology warns about adapting principles and practices to your context. We are lucky to have a mix of experienced agilists with energetic journeymen. That's why having a custom process was a no-brainer. We are taking any idea that seems to help us achieve our goals, experimenting, reflecting and adapting it accordingly.
Coolban is an experiment inspired on Kanban and bounded by Enterprise Scrum rules. Lean is meant to reach the whole enterprise but it's also common to have Scrumban as a transitional step. Our biggest impedance with the system so far has been on the strategy/business side. It could be due to the inherent lack of time to build trust by a newborn team along with human resistance to changes.
These impedances provide context and opportunity for adaptations. For instance, we plan and estimate biweekly. During these sessions we also write high level acceptance tests. The POs are not actively involved in the generation of the tests or in the pull mechanics of Coolban. They just want to see the story follow the workflow in Jira like every other team does.
We put the sprint stories on the story cloud on top of the Coolban with the estimate on them. Once a slot becomes available on the Ready stage the story can enter the stream. After all the planned stories are pulled from the cloud we request to bring a story into the sprint. However the PO might consider we have too much WIP and not feel comfortable with a safe sprint completion. At that point we simply pull from the prioritized backlog without officially being committed by Scrum rules.
The flow rules are also synchronized with Jira's workflow. We set the story to In Process before it's moved into Code, to In Build before the Build stage and to the done spike after is Closed in Jira. The tasks for dependencies are tracked with stickers. And we are also planning on attaching a picture of the team member Assigned To the story.
Secretly yes, we want to influence the enterprise. We are set to propagate and participate on initiatives to continuously improve the system as a whole. We invite you to do the same within your bounded context while keeping the harmony in the system. Welcome to Coolban, if you are not content with the status quo, you have to fight.
Posts
All Comments
