This lecture focuses on the music streaming service called Spotify. The organisation changed its culture to create a less rigid form of Agility that focuses on agile principles rather than Scrum practices. The lightweight framework is adopted by engineering disciplines and more focused empirical teams.
Big Picture
Xp Basics
Extreme Programming was created by Kent Beck one of the original group that formed the Agile Manifesto. He worked on an Agile concept to develop fast paced framework to create high-quality software that was based on engineering disciplines for Chrysler payroll project. Its focus was based on fast feedback and customer centric approach makes it suitable for ever changing businesses with a view to have a quick turnaround and improve productivity. The term 'Extreme' is to imply taking disciplines to the extreme.
XP is thought to be best suited to high-risk projects where the requirements or demands are likely to be unstable, and push the XP mindset towards success and delivery. What makes XP more intriguing is that many Agile frameworks are adopting some of its practices to improve the quality of the deliverables, practices like Pair programming and Continous Delivery.
The objective for Extreme Programming was to evolve displines created by developers for developers. XP is broken in to 3 main parts, Values, Principles and Practices.
XP Core Values
The mindset for an XP developer is slightly different from that of a scrum developer. XP can work in chaos and stabilise and improve the quality of the product, this mindset is set very early on and the values sit on top of this thinking. There are 6 simple values:
For most businesses delivering the solution based on what was asked rather than what was inferred in the conversation requires a value in Simplicity. To create features that gives the Customer exactly what they need and nothing more is vital. Embedding Simplicity into the XP mindset drives increased productivity with less waste.
This is taken from the Agile principles in terms of encouraging face to face conversation. Encouraging communication at all levels with the commitment to deliver the business value / requirements etc. To work closely with the customer communicating the requirements quickly with transparency for the work.
XP encourages rapid feedback loops. It advocates the process of feedback mechanisms when dealing with the customer to ensure commitment and confidence in the product feature under development. Listening is really important in the aspect for feedback particularly when trying to understand the needs of the customer. The objective for feedback is to reduce the costs of change and time investment in the delivery, partcularly reduction of bugs etc.
This requires honesty and integrity as a member of the team as well as the whole team. To not compromise quality of what is being delivered and to be open and transparent to any failings and to admit mistakes without the blame culture. To learn and move on.
There are no ego's in XP. Mutual respect of all team members is a foundation to encourage the sense of the 'Whole Team'. Empowerment to make decisions defines a level of respect that is attained to that principle. Team members are fully motivated and committed to achieve the goals.
XP Principles
The key principles in Xp allows teams to align towards one team goal embracing some key components to the XP model. The high-level principles are illustrated below:
This is a key XP principle learn from the system and its surrounding, once learning gathered it should be fed back straight in to the system. The feedback and learning respective should be immediate, in both the shape of requirements and delivery.
Simplicity is a key mindset, not to look for over complex solutions that may require reverse engineering, the development approach is to build from a simple or basic foundation to what is exactly needed, nothing more or nothing less. Layers of complexity can be added as the detail unfolds but the code if simple should be able to adapt to change.
Build small pieces not big, incrementally building from firm foundations allows the Xp team to build functionality that has greater value in small increments rather than big ones. Each feature will be easier to build and test and will show more transparency on what is being delivered to the whole team.
Teams that embrace change allow a stronger product to be developed based on the options presented. Having only one single design option can result in rigidity in approach, embracing change and ideas allows more opportunist approach to be taken to the design or build.
In XP quality is never compromised the whole team works towards the quality milestones set by the team. The team is proud for the product created and there is enough metric to support the benchmarks defined for quality.
XP Roles and Responsibilites
Typically there are four main roles in XP - Customer, the developer, Coach and the Manager or Tracker. There are a maximum number of upto 12 members in a team.
XP Customer
XP Developer
XP Coach
XP Tracker
The Customer works within the XP team as an requirements provider on behalf of the business. The idea behind the customer is to get the developers working very close to the requirements and if they raise any questions or issues they will be able liaise closely and effectively to the Customer and vice versa.
The customer forms the integral part of the team, they are the direct link with the business and owners for the requirments that arrive at the team and there could possible be more than one customer. In terms of shaping the requirements, the also write the non functional and functional test cases.
The stories are shaped in the form of user-stories and are displayed on Program boards for the team to see. The customer does not estimate any part of the user-story.
The development is a cross functional, self organised empirical team. Every role in the Development team is a developer, the architects, the analysts, the coder and testers fall under the same role, there is no differentiation in their importance and all bear an equal accountability in their position within the team. The developer is code-centric in fact the code sits at the heart of Xp, developers will be focused on the code output delivery as a measure of test and progress.
The developer will take requirements from the Customer and turn these requirement or user-stories into deliverables such as function or a feature, this would be estimated by the developer and tested separately by the developer.
The XP coach is a servant leader who is empowered to support the team on their XP practices. To ensure they can harness the core values and practices of XP and allow teams to build knowledge and reflection on the quality of the work. They are not leaders or facilitators, they are there as a guide to provide their agile experience to the wider team.
The XP coach can run workshops to optimise the teams techniques using observations, the learnings are then made to the wider team. They can also be used to provide support and encouragement to the XP team when work demands are high or challenges are occuring. They have a key pivotal role in the agility of XP in team.
The Xp manager main roles revolve around the release planning and iteration planning meetings for the Xp team. They will be responsible and accountable that the whole team understand the planning game as well as ensure there is transparency in the process. The Manager will ensure the team is committed to the delivery and the team is on track with the milestones.
The manager is also responsible to ensure that estimation and prioritisation of the user stories are occuring, and will work closely with both the Customer and the developers to ensure the accuracy of those estimations based on the relevant experience of previous iterations.
They will also have tracker duties to be able to monitor and track progress of the team in terms of deliverables and quality of product, these metrics will be collated quantitively from the team.
XP Practices
The 'doing' part of XP are the distinct practices, these are key enablers for the Xp framework. These disciplines are commonly used in Agile practises, but in Xp these stem towards greater focus/practice and rigidity.
1. One Team
The whole team concept is around the essence of what we mean by Team? The team is a whole where everyone is equal and accountable for the delivery as a whole. The Customer is an integral part of the team where requirements are given and timescales and delivery plans are tracked. The Coach is the servant leader providing guidance in the team to improve their level of agility. All developer, QA and analysts roles are tagged as Developers.
2. Pair Programming
Two developers work alongside each other, one is the coder the other is the reviewer. The objective is to collaborate in the development for the coding, they then change places where the other is the reviewer and one the coder. This will considerably improve the quality of the code and allows coding to be written from a testing perspective.
The objective for this is to improve the quality and collaboration of the team members, particularly helping to assist to standards and techniques. There is also reduced amount of skill dependency so if someone is away there is always a standby.
3. Planning Game
This is a meeting ceremony that occurs once in a iteration or sprint, it is similar to the Sprint Planning meeting in a scrum. The meeting focuses on two planning activities Release Planning and Iteration Planning
4. Release planning
Here the customer goes through the features that are to be developed into the future iterations, a very high level estimate is given around the feature items, the objectives and deliverable are recorded on a feature board and the increment plan is updated to record the timescales. During the estimation the development team analyse the requirements determining the work and complexity required for each as well as any risks or impediments. Once the estimations are completed the feature is added to the product plan or roadmap.
5. Iteration planning
This meeting plans the activities to be carried out in the upcoming sprint - this is a development team task (without Customer). Customer prioritises the features that will be developed during the Iteration and the development team will do a deep dive estimation on the features and these is then placed into the Iteration plan. The developers will then create all activities and tasks associated to the features and these are then committed to the Sprint.
6. Test First Development
Test-First Development or Test-driven Development is a concept which is different to unit test, In Unit testing feature logic is added and the functionality would then be developed finally the tests would begin. In Test Driven Development the Test is created before the coding logic is started.
The back to front approach to development in very short cycles, ensures the developer is focused towards the core requirements of the feature by writing the tests to begin with. It helps and focuses the developer what needs to be conceptualised before the development begins. This ensures the code written is of higher quality standard, and makes tests re-usable and testable. By writing the tests explicitly beforehand also offers a lean documentation for the feature.
Its important to emphasise the code created will be re-written or Refactored to continously add additional functionality as the requirements are being built.
Continous Integration
