Planning For and Delivering Quality in Large Scale Enterprise Agile Development
Success in large enterprise software development depends on delivering capability and Qualities as much as functionality. In larger programs, given that Agile makes it easy to develop functionality quickly, building Qualities like performance and resilience in enterprise Agile needs deliberate and focused effort and planning.
Traditionally, Agile development tended to be smaller, contained (geographically as well as in size), allowing for Quality to be in built and monitored every iteration in the delivery of Agile projects. As Agile goes mainstream and more enterprise programs and IT development is Agile, more attention needs to be paid to the –ilities that will determine success or failure in the Enterprise.
Based on experiences from a geographically distributed, multi-year, multi-vendor 30+ million USD Agile product development that the author program manages, this session highlights the vulnerable areas that impact Agile Quality in large enterprise programs:
- 'We'll figure it out as we go along' Architecture;
- Evolution in corporate security and IT governance guidelines;
- The Agency problem between the needs of the business and the representatives of the business;
- The temptation to build functionality quickly to demonstrate progress.
For each area of vulnerability, the session will provide guidance and ways and means to manage the risk of lowered Quality.
Outline/structure of the Session
This session presents lessons from a large outsourced product development program, with 200 people at its peak in over a dozen scrum teams working in a multi location multi vendor structure. The product size was > 10000 MkII Function Points, and was delivered over 2 years.
The session is divided into 3 parts, each covered in around a third of the 45 minutes availble for the session.
The first part covers the impact of the various factors that are described in the abstract that impact Quality, along with real life examples.
The second part covers mitigation strategies that can be used, along with examples where they were used successfully. These include:
- Using a highly skilled Planning team to oversee Scrum development and ensure that each Scrum team develops to the required standard of Quality.
- Scrum teams (while they continue to be autonomous) need to adhere to development and technical guidelines in every iteration, else they do not release.
- Planning team permits or withholds components from development depending discussions and approvals from enterprise standards and security groups.
- Using Tiger teams outside the regular scrum teams to develop Proof Of Concepts (POCs) to demonstrate the scalability of key components and technologies.
The third part covers the management oversight and intervention needed in order to ensure success.
- Once a component is developed incorrectly, it is impossible to avoid expensive rework, scrappage and accusations of waste; we will share the challenges faced in this area.
- Managing Agents for the Business: A laser like focus needs to maintained on the priorities for the business; while business is primarily interested in the Qualities like performance that will sell the product, it is very easy to have the business representatives distract development with polishing what has been development rather than move the product forward. Managing this needs an alignment with business priorities, and change control even with the nominal product owners.
- Managing integration and taking an overall product view to take the program to completion.
Enterprise Agile looks different from traditional or pure Agile in several ways, and planning and building in Quality is one of these. Session attendees will be able to understand our experience of planning and architecture needs as well as the management discipline needed to ensure a Quality deliverable. The session will be useful to understand the pressures that can compromise Quality in enterprise Agile as well as potential solutions to ensure the Qualities needed by the business are delivered.
We expect the session to be relevant and useful to anyone involved in scaling Agile for enterprise IT development.
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Methodology Patterns: a Different Approach to Create a Methodology for Your ProjectGiovanni Asproni
schedule 3 years agoSold Out!
In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).
In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success.
The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.
How do I know if Agile is working for me or not? – An Executive’s Dilemma
As Agile coaches, several times when we talk to the Sr. Management in a company to taking agile to a bigger level and adopt it across their business units a common response we get is "I have seen agile working for our project teams. I am also in midst of an agile transformation where we are applying it in large programs. But how do I know the transformation is helping me achieve my goals at an organizational level. Our organization typically tracks executives on finance, people & delivery parameters. In an agile context, how do I ensure that I am on track with the executive-level dashboard (finance, people and delivery)?" As part of this session, we plan to share our experience of how "Balance Score Card" technique was implemented at one of the financial services company following agile. By using concept of balance score card we were able to map the agile goals with the IT organization goals and ensure that the agile methods were giving the desired results.
Structuring Enterprise Agile in a Traditional Delivery OrganizationJayathirtha Rao
schedule 3 years agoSold Out!
Indian IT services companies have built large organizations that are aligned to delivering projects with waterfall or similar methodologies. While Agile clearly delivers value to clients, it is important to ensure that delivery managers understand the benefits of Agile as well as have a roadmap to change their current structures to Agile.
In large programs, we are increasingly seeing a conversion of waterfall teams to Agile. What does this mean for delivery managers who have successfully run their teams in waterfall mode? This is an important question to address else we will encounter (as we already do in many cases) resistance to Agile adoption from delivery management.
In this session we will provide examples of how we have addressed the problems related to this conversion, including:
- How to recognize anti-patterns in an organization
- Handling matrix based management that leads to more leads and less deliverables (waste)
- Dealing with teams that build it, hand off and don’t support it
- Typical service company culture of rotating the best people out, and leaders who should look at results but look at interim tracking instead.
We will provide real life scenarios covering:
- Typical distributed agile with multiple vendors – BAs with vendor 1, Dev in their own sprints with vendor 2, QA in their own sprints with vendor 3 – how can you do a vertical slice across a project rather than silos?
- Change budgeting and resource cycles from yearly cycles to smaller sprint aligned measures.
- Change metrics to output based on business value for tracking a program and portfolio, lower metrics should be for the team to measure progress and make improvements.