1 / 6

Being Brave

Being Brave. Notes on Requirement Driven Development and the Agile Space. What do we mean by being brave. Being prepared to ring the changes within the code base without the need for explicit permission

evania
Download Presentation

Being Brave

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Being Brave Notes on Requirement Driven Development and the Agile Space

  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

More Related