2. What do we mean by being brave
• Being prepared to ring the changes within the code base without the
need for explicit permission
• Being prepared to speak up about process , tooling or environment or
team with out fear of recrimination
• Being prepared to code at risk and then roll back the code rather than
push a bad position
• Do use Emergent Architecture rather than being spoon feed architecture
you have no ability to change
• Taking personal responsibility for project and team success
3. Empowering people to be brave
• Make people feel safe if they feel safe then people will be more inclined to be brave
• Make the team members feel trusted
• Make bigger decisions as a team
• Do hold retrospectives and do encourage people to take actions and make changes
• Make it clear that this is a collectively owned code base and process pallet
• Encourage team working, collaboration and most importantly trust
playing team games
holding team nights out / lunches
• Dissolve any specialization
Cross train the team in all elements of the SDLC
Cross train team in all elements of the technology stack
Implement Technology champions go to people, who people can get advise on certain technologies
from
4. Implement systems that make
people brave
• Source control
Small checkin’s
Its ok to roll back
Its ok to have to merge
• Requirement management systems including visible story walls
Make requirements small
Make requirements atomic
Make story cards light weight so they become a starter for a discussion
Do perform iteration / sprint planning with the whole team
• Implement CI
Fast feed back cycles
• Do Test Drive all your code and your functional path way’s
5. Standards
• Have set coding standards that the whole team agrees to
Don’t neglect principals like SOLID
• Have a defined process in terms of lifecycle management
Have a Project process ie. Scum , XP , Lean
Have a Application lifecycle process
Have a full release process
Have a process for feedback
• Have and use the concept of technical debt
Make sure you pay off technical debt regularly
Make sure as a team you hold sessions to review technical debt, some of it might
have been fixed by consequence
• Do perform ‘Positive ‘ code reviews or pair
• Do have a wiki, do encourage the whole team to make use of it
6. This has been Katie Jaye Martin
Http://www.cloud-coder.co.uk/BLog
Email: Katie@cloudcoder.onmicrosoft.com
