diff --git a/TheATeam.asciidoc b/TheATeam.asciidoc index 68339ed..e4a5aac 100644 --- a/TheATeam.asciidoc +++ b/TheATeam.asciidoc @@ -2,7 +2,7 @@ In general, we need to ensure we have coverage of the 5 main sections referred to in Error! Reference source not found., therefore, the project team should look like the following: -* **Prepper**: This is the analyst who will liaise with the customer, populate the initial product backlog, and ideally be able be able to put together wireframes, information architecture, formulate the backlog in a typical project. They will also be hands on during the project delivery and help ensure the quality of the solution delivered that it matches the requirements. +* **Prepper**: This is the analyst who will liaise with the customer and gather the detailed requirements, populate the initial product backlog, and ideally be able be able to put together wireframes, information architecture, formulate the backlog in a typical project. They will also be hands on during the project delivery and help ensure the quality of the solution delivered that it matches the requirements. * **Designer**: Dependent on the stage of the project, and type of project, you may need Solution Designers (Architects), UX/UI Designers, Data Designers (Architects/Scientists). It’s quite possible that in a smaller team the Solution Designer also has the skillset to act as the Prepper as well. * **Engineer**: This person will be responsible for implementing and building the solution according to the product backlog. You will have Dev Engineers (or software engineers) as well as Op Engineers (operations) and Release Engineers, the latter may or may not be fulltime on the project. You could also categorize your engineers as Junior and Senior/Lead. The release engineer is responsible for maintenance of the branches, ensuring successful build and releases and creating release notes. * **Test pilot**: They should be involved throughout the delivery of the project. They put together the test plans from the product backlog and carry out testing (manual and automated if possible) of features as they are delivered. On average you should have at least 1 test pilot full time for every 4 Dev Engineers. @@ -20,11 +20,17 @@ The T-Minus-15 methodology encourages the following values within a team: // Review these - e.g. our values in Karma -* **Be transparency**: You’ll read in the course of this book how everything is very open. The product owner (customer) has open access to your backlog, developer comments, and the Team collaboration area. Even a large part of the estimate process is done with the client. -* Be accountability: We also assign responsibilities to specific people. Initiatives and Master Features are owned by the Architect, whereas the Features and User stories are owned by the Engineer to deliver. -* Recognise success: It’s important that team members are recognised for their good work. We introduce the Karma points awarding method. -* Solve problems: Being a member of the team, you should be a problem solver. You should be pushing things from left to right. At whatever level, whether that’s fixing Bugs, Delivering Features, Delivering Initiatives, or alike, you are overcoming challenges and solving things, not passing the buck for someone else to figure out. This is a “get it done” mentality and certainly not a “finger pointing” culture. -* Deliver high-quality high-value (HQHV): Deliver solutions to the business that are of high-quality and high-value using the principle of little-and-often. Our target here is not “lines of code”, it’s tested, working, solutions. Make sure the business know about the hard work you are delivering. + +* **We are passionate**: Each team member should be passionate about the work that they are responsible for. Passion is the key value to delivering a quality solution. Engineers must be passionate about learning new things and updating themselves with the latest technologies and new features. Solution designers must be passionate about building robust solutions and delivering high value to the customer. Scrum master must be passionate about process maintenance and customer happiness and team building, whereas Quality analysts must be passionate about maintaining high-quality products by raising bugs. +* **We are creative**: Everyone must be creative and add unique value to the team. Each day team is going to face new challenges and it is important that one should find a creative and reliable solution to the problem. +* **We are knowledgeable**: Team members must have a good knowledge of the requirements, Agile process, and technology using which we are going to implement the software. Knowledge is the important key to delivering the solution successfully. +* **We are transparent**: You’ll read in the course of this book how everything is very open. The product owner (customer) has open access to your backlog, developer comments, and the Team collaboration area. Even a large part of the estimate process is done with the client. +* **We are accountable**: We also assign responsibilities to specific people. Initiatives and Master Features are owned by the Architect, whereas the Features and User Stories are owned by the Engineer to deliver. The Scrum master is responsible for the whole delivery process and managing customer’s expectations and resolving team’s blockers. QA is responsible for maintaining the quality of the software we handover to the customer. +* **We are together**: We will never be able to deliver a solution if we are not together. A **passionate** team with **creative** ideas and good **knowledge** will only be able to **accomplish** a project with record success with the customer. +* **We are agile**: We are dynamic and flexible to deal with any challenges during the spring or project life cycle. In the Agile process where we gather intermittent feedback from customers and review our work during the spring, we expect our team to be flexible and continuously improve based on the feedback. +* **We recognise success**: It’s important that team members are recognized for their good work. We introduce the Karma points awarding method. We can also provide a bounty for exceptionally challenging work to the team which will keep the team motivated. +* **We solve problems**: Being a member of the team, you should be a problem solver. You should be pushing things from left to right. At whatever level, whether that’s fixing Bugs, Delivering Features, Delivering Initiatives, or alike, you are overcoming challenges and solving things, not passing the buck for someone else to figure out. This is a “get it done” mentality and certainly not a “finger pointing” culture. +* **We deliver high-quality high-value (HQHV)**: Deliver solutions to the business that are of high-quality and high-value using the principle of little-and-often. Our target here is not “lines of code”, it’s tested, working, solutions. Make sure the business know about the hard work you are delivering. Engineers, don’t just “throw” functionality over the fence to the Test Pilot(s). Test Pilots, don’t just feedback “it’s broken” without giving clarity to what exactly went wrong with clear steps to reproduce and perhaps even doing some research into what might have caused the failure. Preppers, make sure you have a nicely organised backlog with clear requirements and acceptance criteria. Scrum masters, don’t just play the “management” role with a pointy stick to make your team work faster - get involved into resolving blocking points and reducing unnecessary workload for the team. Product owners, turn-up to meetings, help clarify your needs, help prioritize workload and don’t just say “I MUST HAVE everything”.