Goals Principles & Rules
Many people come and visit our software development department. In one such visit Mitch Lacey pointed out some items on the walls that were particularly interesting. We have tons of retrospectives, timelines etc... usually fashioned out of flip charts and sticky notes, but some things we have gone through the trouble of making them a little more permanent than that. Of course we can change these when ever it makes sense, but the following are some items we noticed change less often for us...
Software Development Department Guiding Principle
Our lofty goals were actually defined before our guiding principle. Over a time it was brought to my attention that the lofty goals were 12 items. We needed something more concise and higher level. That is when I asked for feedback on many principles until this one stuck.
Exploring the unexplored potential
This principle embodies our desire to continuously experiment and never grow comfortable with just a good way of doing things. Always seeking to improve and learn to get ourselves to the next level. We accomplish this through regular retrospectives, learning sessions, and experimentation. We find areas that have potential and explore that potential to our satisfaction. The result is a team that can release multiple times a day, have psychological safety, and continuously improve.
If you are leading a team, I highly recommend defining your guiding principle and bring it up when ever you have new processes to define. Your every day work will move toward this point. Be sure to re-evaluate its effectiveness for you as well.
Lofty Goals
This document was created from feedback of many team members and even people on twitter and other contacts we have. The idea was to guide the team on 4 key concepts. Each of these concepts have 3 main values.
How do we INTERACT?
We wanted to define how our interpersonal communication is revealed to others within the organization. To enable this we said we value the following:
Kindness, Consideration, Respect
This one was defined for the team by Woody Zuill. When I first started at Hunter he was making sure that everyone on the team was willing to agree to treat each other with Kindness Consideration and Respect as a core working agreement. Today we keep this alive as a request to all new developers who join the team.
Be Vulnerable, Hold Trust, Show Appreciation
This one came from feedback from twitter. We really liked the addition to the above 3 as a way to accelerate our ability to work well together.
Psychological Safety
Finally, Psychological Safety has been shown to be important from Amy Edmondson's research. We have agreed as a team to put these findings into practice and work diligently to increase Psychological Safety within the team.
How do we CODE?
The way we write code is guided by the following:
No one between code and production
We accomplish this though continuous integration. We first heard this from Yahoo! back in the day to describe their goals around release management.
Clean code
We utilize the Clean Code book in our code. This one also was brought to the team originally by Woody.
Zarro Boogs
This is like the #BugsZero movement. Zarro Boogs is an acknowledgement that was mean "zero know bugs" The term comes from the Bugzilla software when you run out of bugs.
How do we do BUSINESS?
The way we do business as a department is guided by the following:
Deliver valuable working software to customers daily
This one guides us toward continuous delivery and measurement of outcomes in the work that gets done.
Anyone can take a vacation at any time: Zero Silos
I have been in too many environments in the past where turn over or on boarding was too difficult and painful. One of the benefits we get from mob programming is the ability to keep code moving forward no matter who on the team is there that day.
Effective Interdepartmental Communication
To guide our interactions, interdepartmental communication is preferable face to face. If face to face is not available then do remote video, then phone, then pager etc.. :)
How do we INNOVATE?
We are constantly innovating and working to create something better and new. The following items guide our innovative spirit.
Continuously develop lofty goals and practices
This one is here to remind us to review this document on a regular basis and consider changing it.
Experiment Frequently
Without experimentation, a system will stagnate or reach its most performant local optimum. We have identified that a culture of experimentation is valuable in keeping up with the cutting edge.
Develop Software Community
Not only to help the community understand the value of the experiments and insights but to improve our chances of finding people that share our beliefs to come work with us we work hard to develop the software community. From conference talks to blogs to 8th graders programming with us for a few hours, we work toward bettering not only ourselves but those around us.
Software Development Principles and Team Rules
This one is posted in our break area/ kitchen and usually gets the most attention from visitors. I will elaborate a little on each of the sections a bit.
We do not give estimates
Due to the Software Estimation Paradox, we believe it is more important to properly automate QA, and repetitive work. This means we believe estimates only encourage bad behaviors on a team doing software development. (repetition without automation) These principles are a reflection of that concept.
All software created at the highest quality possible
This principle reflect our aversion to the waste that comes with keeping a bug list. We write code with automated tests and high level of quality. This means we implement clean code and automated testing in order to keep a known bug count of 0. Rework in lean is on of the 7 deadly wastes and it is no different in software development.
There are two types of code we work on
First priority is bug fixes until they are gone permanently (i.e. automated tests proving they never come back). Second priority is Feature work with the understanding that we will use our core development process to ensure continuous refactoring.
Team Rules
- We do not give estimates
- We treat each other with Kindness Consideration, and Respect.
- We retrospect often and adapt to action items that result
- We adhere to the agile manifesto and principles.
Agile Manifesto
Hopefully this one does not need an introduction. The agile manifesto is something we look to in order to provide grounding of our ideas in the experiences of others.
Agile Manifesto Principles
The 12 principles are a little less known but I encourage you to review them if you get the chance!
Manifesto for Software Craftsmanship
Finally we have a poster up of the Manifesto for Software Craftsmanship This one is important to clarify our focus on quality to the team. This document is also less known than the agile manifesto but is just as important to us.
Leave questions in the comments of ping me on twitter. I like to blog out the replies!
0 comments:
Post a Comment