Agile Chapter 5- extra topics
5.1 Roles in Agile Project
There are several roles, which have different names depending on the methodology being followed, common to agile teams. Roles are not positions, any given person takes on one or more roles and can switch roles over time, and any given role may have zero or more people in it at any given point in a project. The common agile roles are:
- Team lead. This role, called “Scrum Master” in Scrum or team coach or project lead in other methods, is responsible for facilitating the team, obtaining resources for it, and protecting it from problems. This role encompasses the soft skills of project management but not the technical ones such as planning and scheduling, activities which are better left to the team as a whole (more on this later).
- Team member. This role, sometimes referred to as developer or programmer, is responsible for the creation and delivery of a system. This includes modeling, programming, testing, and release activities, as well as others.
- Product owner. The product owner, called on-site customer in XP and active stakeholder in AM, represents the stakeholders. This is the one person responsible on a team (or sub-team for large projects) who is responsible for the prioritized work item list (called a product backlog in Scrum), for making decisions in a timely manner, and for providing information in a timely manner.
- Stakeholder. A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
Figure 1 overviews the structure of a small agile team. What you typically read about in the agile literature is how a team of developers, lead by the team lead, works closely with a product owner to build a high-quality working system on an incremental basis. What you don’t hear about as often is what I call the “supporting cast”:
- Technical experts. Sometimes the team needs the help of technical experts, such as build masters to set up their build scripts or an agile DBA to help design and test their database. Technical experts are brought in on an as-needed, temporary basis, to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team.
- Domain experts. As you can see in Figure 2 the product owner represents a wide range of stakeholders, not just end users, and in practice it isn’t reasonable to expect them to be experts at every single nuance in your domain. As a result the product owner will sometimes bring in domain experts to work with the team, perhaps a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project.
- Independent tester. Effective agile teams often have an independent test team working in parallel that validates their work throughout the lifecycle. This is an optional role, typically adopted only on very complex projects (or at scale).
for more info- roles in agile projects
5.2 Market Scenario and adoption of agile
Agile culture adoption is growing fast in organizations around the world. Internal Agile coaches, consistent Agile practices, and implementation of a common tool across Agile teams are the top three factors encouraging businesses to continue their Agile journey. According to ‘12th annual State of Agile report’, the top five Agile benefits reported by the organizations are –
- Better project visibility – through- rapid feedback
- Faster delivery – through – cloud-based solution
- Enhanced productivity – through – activities oriented learning workshops
- Improved ability to manage the changing priorities – through – deep focus on business value of a user story
- Better IT alignment – through – Agile spirit embracement
for more info – current agile trends — cloud topic also here
adoption of agile-
why companies want to adopt agile ?
Most companies tend fall into one of three problem categories: they want to make software development faster, simpler or better.
Faster – many companies are interested in speeding up their development processes.
Simpler – Simplify the process and the product. Make it easy to get what you want
Better – Your software will be better. Better meaning more of what people want (meeting the needs of the customer) and better quality (tested, validated and approved every step of the way).
discipline and agility
What is Discipline?
• Foundation for any successful endeavor
• Provides strength and comfort
• Creates well-organized memories, history, and experience
What is Agility?
• Counterpart of discipline
• Releases and invents as opposed to ingraining and strengthening
• Applies memory and history to adjust to new environments and, take advantage of new opportunities
Successful Projects Need Both in a Changing Software Environment
• Discipline without agility leads to bureaucracy and stagnation • Traditional Plan-driven development – “Feels like we’re spending more time writing documents than producing software!” • Agility without discipline leads to uncontrolled and fruitless enthusiasm
• Agile development – “Can we realistically scale to do big projects without comprehensive documentation?”
Six principles of “disciplined agility”
The key question is how? The blog cites six leadership principles that can help achieve a balance between discipline and agility. Here’s a quick summary:
- Transparency and visibility
- Adopt the customer’s perspective
- Collaborate more
- Demonstrate successes
- Continue to learn
- Embrace change
difference between agile and rapid application development