At SEP, we have very diverse teams, clients, and projects. With all of that variety and diversity, comes a lot of variation in how projects are run. Almost every project, in my experience, has used different processes and techniques.
I was recently inspired by one of my coworkers, Jennifer, by a letter that she wrote to herself describing her ideal job.
Given that we experience so much variety, I decided to try and describe my ideal project. I was not able to describe my ideal project, but I was able to come up with a list of my beliefs and things that I value.
Below, in no particular order, are the values of my ideal project.
My ideal project and team values…
…Flow versus Sprints:
- I believe that a sprint boundary is disruptive, and we should instead optimize on the flow of work through our process.
- I believe that each commit to master should be potentially ship-able within component/system boundary.
- I believe that waiting for a sprint boundary to create a ship-able increment introduces waste and overhead into the process.
- I believe thatHeroic efforts are not sustainable, and in my experience sprints require heroes to work.
…periodic Retrospectives versus project Postmortems:
- I believe thatretrospectives drastically improve the team and the processes and foster an environment where we all learn and improve.
- I believe thatKaizen learning, or intentional learning, should happen early and often.
- I believe that only having a postmortem (after the project is done) is not nearly as valuable to the team as having periodic retrospectives.
…Discovery Sessions versus Up-Front-Requirements:
- I believe that up-front-requirements will prevent us from solving the right problems, and instead focus us on implementing the single solution.
- I believe that discovery sessions position us to validate early and generate the appropriate stories.
- I believe that acceptance-tests for each story should be agreed to, and written, before the story is implemented. (Bonus points if these tests are later automated.)
…Validated-Learning with users versus Over-The-Wall with releases:
- I believe that coders and testers are not equivalent to real users and customers.
- I believe that the real value of having usability studies and validation efforts during the project are infinitely better than having the studies and validation after the project is complete.
- I believe that the delays between completing a story and validating a story introduce risk, make changes more difficult, and increase the likelihood of injecting defects.
…rough Story Sizes versus low-level Detailed Estimates:
- I believe that detailed estimates are rarely correct because we, humans, are naturally bad at estimating.
- I believe that metrics like cycle time and velocity are more meaningful than round-tripping estimates.
- I believe that detailed estimates are more threatening than they are helpful.
…Architecture versus Incremental-Patches:
- I believe that a good architecture that caters to test-first, like Ports And Adapters, helps us do our best work.
- I believe that defects are injected, and delays are introduced, when we simply build by continuously patching new features in.
…Test-First versus Dev-First:
- I believe that unit-tests and TDD improve quality drastically.
- I believe that automated tests allow coders to move quickly and confidently.
- I believe that our testers are not able to focus on more important tests without coders practicing Test-First.
I imagine that many people have differing backgrounds, experiences, and beliefs from me; and therefore, I imagine that many people will have different values from me as well.
What does your ideal project look like?
Any values that you would add to this list?
Do you disagree with any of my values?
Let me know in the comments below!
