Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Being brave


Published on

  • Be the first to comment

  • Be the first to like this

Being brave

  1. 1. Being BraveNotes on Requirement Driven Development and the Agile Space
  2. 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. 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. 4. Implement systems that makepeople 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. 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. 6. This has been Katie Jaye MartinHttp://