Welcome to the RattleBerry RoundUp. This is a weekly series where we select a topic of interest to our clients and panel members working in experience design, product management, marketing technology and digital transformation. We hope you enjoy it and we look forward to reading your feedback and comments! Let us know either way on LinkedIn.
Here at RattleBerry, we collaborate with large, multi-layed corporations operating in various sectors such as finance, aviation, media and retail. Our clients for quite some time now, adopt and invest more and more in the Agile project and software deliver method. But why are they doing this? Well, our view is they find the methods used very suitable for delivering front end products, website and apps. This is the intersection of user experience design and digital innovation, where we recruit exclusively. So, we thought a deeper dive into the make up of agile team, common terms you hear and more merited a round-up.
The rise in popular usage of Agile methods
First of all let’s point to a few articles that explain the rise in popularity of Agile and the difference between Agile and Waterfall. In a recent blog post we explained the pros and cons of both Agile and Waterfall. Waterfall model is the traditional design process that was and still is used by contractors from more than 45 years now and can be described as a sound method. It has it merits as it is a useful technique as regards documentation and can be a effective when the requirements of the product are evidently known, the product has a firm and stable definition and the technology that will be implemented is understood.
However, with this model is difficult to change something once the application is in the testing stage. It is “chunky” and nor is the best method for web, application and front end development. It is not flexible nor is user/customer-centric as the user is badly represented and does not allow feedback from users. Agile on the other hand, better suits user/customer-centric products as customers participate actively and have a say in each stage of the procedure. The product manager is closer to the user. Thus, perhaps this is one of the main reasons why enterprises adopt this way now. Moreover, Agile gives freedom to make the changes that are likely to occur in the development procedure and promotes communication among various partners.
Agile vs. Waterfall: A Side-by-Side Comparison post by Yoshitaka Shiotsu touches on this topic and provides relevant insights as well as links to relevant articles. She mentions that “Agile methodologies place an emphasis on teamwork, constant user feedback, continuous improvement, and the ability to adapt to changing requirements. Agile is a broad term that refers to any methodology that abides by the Agile Manifesto established on February 17, 2001″.
Agile team and stakeholders
Now, let’s breakdown the typical make up of an agile team with some links as well. How can someone be a part of an Agile team in a company? What is the typical (though by no means concrete) structure of a team? We see it as:
A typical agile team is composed by the following stakeholders and job titles: Business owner, Product owner, Scrum master, Business analyst, Frond end developer, Back end developer, UX manager or Architect, UX designer, UI designer, Quality analyst, Testers.
Terminology and glossary
What, however, do these terms denote and how do these professionals communicate between them? The best way to get your head around it and come to grips with how it can be used to deliver project is through breaking down the meaning of the terms used. Agile has its own language and syntax and relies on this to help people in the roles and responsibilities. However, coming from the outside in this can be dense and off-putting. So we though a run down of the most common language used is the most effective way to master the topic. Hence, our summarised Agile glossary:
According to this blog this term defines the “graphical representation of the work remaining to be done versus the time available. This can be a great motivator if the team makes steady progress and hence it should be shown prominently in the project management tool”.
According to SolutionsIQ “Business Owners are a small group of management stakeholders who have the primary efficacy, governance, and ROI responsibility for the value delivered by a specific release train. Business Owners play a key role throughout the flow of value, and have particularly critical roles during Release Planning, where they participate in the management review and problem solving meeting, approve plans, and assign Business”.
Daily stand-up meetings:
According to this dictionary this term denote “A short, daily all-hands meeting in which members of an Agile team address three key questions:
What did you get done since the last stand-up?
What will you do before the next stand-up?
What impediments stand in your way?
The meeting is held at the same time and in the same place every day, with team members standing in a small circle. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell, and the meeting is usually time boxed to no more than 15 minutes. The stand-up focuses on peer-to peer coordination through information exchange, and the meeting serves to raise the visibility of each person’s work and to ensure work integration. Only members of the development team participate, as many people as can comfortably stand in a small circle”.
Developers and testers:
According to SolutionsIQ “developers and testers make up the majority of an Agile Team. Developers write the code for the User Stories and conduct research, design, and prototyping with Spike stories. The developer’s responsibilities include collaborating with the Product Owner and testers to make sure the right code is being developed; pairing, writing the code, unit tests, and automated acceptance tests; and checking new code into the shared repository every day. Testers work collaboratively and in parallel with developers and Product Owners to define, write and execute acceptance tests, and maintain the test cases in a shared repository”.
“If something is going in the wrong direction, it is important to track and stop it as soon as possible, instead of investing more time and effort in it. This is one of main philosophies of lean development. Fail-fast refers to the ability of the system to report any failure or a condition that may lead to failure as soon as possible”. The term is defined in this blog post.
According to this website, Kanban is “a tool derived from Lean manufacturing and is associated with the branch of agile practices loosely referred to as Lean software development. Like a task board, Kanban visually represents the state of work in process. Unlike a task board, the Kanban constrains how much work in process is permitted to occur at the same time. The purpose of limiting work in process is to reduce bottlenecks and increase throughput by optimizing that segment of the value stream that is the subject of the Kanban. A principle difference between Kanban and Scrum is that Scrum limits work in process through timeboxing (i.e. the sprint) and Kanban limits work in process by limiting how much work may occur at one time (e.g. N tasks or N stories)”.
According to Taica Blog “A product owner is the primary business representative who also is the voice of customer to the development team. The product owner is responsible for communicating the product vision to the team, take decisions on official releases, monitoring project progress and ROI and leading the team. Due to this wide spectrum of responsibilities, bigger projects sometimes have more than on project owners – to take care of different functional areas”.
According to this dictionary, Scrum is “a framework for the iterative development of complex products, particularly software. Scrum is the most widely recognized Agile framework, and is compatible with other Agile practices like Extreme Programming and Test Driven Development”.
Scrum is comprised of a series of short iterations–called sprints in Scrum–each of which ends with the delivery of an increment of working software. The framework is further characterized by a set of roles (ScrumMaster, Product Owner, Team), time-boxed ceremonies (Daily Scrum, Sprint Planning Meeting, Sprint Review and Retrospective), and artifacts (burn down charts, product backlog).
A “scrum” or “daily scrum” is a 15 minute-long status meeting, one of the ceremonies of Scrum. Usage: Floyd, the new project manager, was invited to observe our daily scrum.
Tip: You will sometimes hear the term Scrum used interchangeably with the term Agile, but this is incorrect. Agile is not a framework, but a broader set of values and practices, while Scrum is a specific framework that fits comfortably under the Agile umbrella”.
This blog defines scrum master as “one the most important role (along with product owner) in a scrum based approach. Scrum master is responsible for daily standup meetings and tracking the overall progress. It is the duty of scrum master to make sure team is not blocked at any point of time due to external or internal issues. But, scrum master should not be thought as a task master – since in a pure agile approach the team assigns tasks to itself”.
Sprint or Iteration:
According to this dictionary, this term defines the “uninterrupted period of time during which an Agile development team performs work, most commonly one week to one month in length, at the end of which the team delivers “potentially shippable” product. This deliverable can be a new feature or feature set, or the improvement or expansion of an existing feature that was completed in an earlier iteration. In Agile, iterations typically begin with a planning meeting, and end with a retrospective”.
Based on this blog post, this term represents “the place where all the current tasks, along with their assignees are prominently displayed. Optionally task boards can also show the complete percentage or the state of the task (e.g. new, work in progress, ready to test, etc)”.
According to SolutionsIQ “while Agile Teams have the full responsibility for implementing the code, including the user interface (UI) elements, the User Experience designer works at the Program Level to provide cross-component and cross-program design guidance so as to provide a consistent user experience across the components and systems of the solution”.
According to this website Story (User) is “a requirement, feature and/or unit of business value that can be estimated and tested. Stories describe work that must be done to create and deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation between the Scrum Team, Business Owners, and the Product Owner. Stories consist of the following elements:
A description, usually in business terms
A size, for rough estimation purposes, generally expressed in story points (such as 1, 2, 3, 5)
An acceptance test, giving a short description of how the story will be validated”.
As always, the purpose of this weekly roundup is to offer some fresh perspective on our topic and keep you current. We hope you find something valuable from these articles, and maybe even share it with your colleagues. This week we tried to present how a typical agile team is structured and the basic terms that are used. Stay tuned for more posts on this topic.
Let us know what you thought by sending as a message on LinkedIn.
At RattleBerry, we recruit user experience, digital transformation and marketing professionals for both senior leadership positions and contracts. Programmes and project manager panel members are currently in demand for projects in Ireland, in the technology, retail, media, travel, financial and utility sectors. For information on joining our panel, click here, and for information about working with us on a digital transformation role or project, click here.