cPrime offers a vast array of both public and private Agile courses, and has recently focused on developing a new series of modularized, role-based courses to promote optimal function and understanding within Agile teams. Allowing clients to tailor learning objectives and craft their own curriculum ensures that training engagements provide the most possible value to clients. cPrime recognized that organizations are tired of the “one-size-fits-all” approach to Agile adoption that many Agile training companies offer.

Zubin Irani, CEO, explains, “Every team’s needs, goals and environments are different and require a customized approach. With customized training courses teams can quickly overcome the obstacles of adopting Agile.”

cPrime has developed three role-based courses that fit the modular approach; Agile for Teams, Agile for Scrum Masters and Agile for Products.  All three courses give organizations a chance to select appropriate elements and content that matches their Agile adoption initiatives. Organizations will first go through an assessment session with an Agile coach in order for the coach to understand their environment and accurately tailor their course curriculum. They then participate in a planning session to configure their training backlog.

Agile for Teams is intended for all team members involved on the Agile project including Scrum Masters, Product Owners, Project managers, Executives and more.  This course includes modules that cover basic scrum training such as the Scrum Roles, Basics of Requirements, Sprint Planning, Scrum Ceremonies, Sample Scrum Projects, and Kanban. Also included are more advanced topics such as Advanced Requirements, Hybrid Planning, Planning for Long Time Horizons, Distributed Teams and Scaling up to Large Projects.

Agile for Products focuses on the role of the Product Owner, Product Manager or product and marketing team members. The course modules include product vision, customer focus, user stories, product backlog, story mapping, lean execution, scaling Agile planning and projects and simulation; each encompassing numerous sub-topics and learning areas.

Scrum Masters can choose from a curriculum geared at their role in an Agile project. The curriculum is made up of topics such as servant leadership, facilitating meetings, retrospectives, reducing impediments, and managing the backlog.

cPrime’s Agile for Teams, Scrum Masters, Products  courses will vary in length from one to three days based on the number of modules selected. cPrime has already received positive feedback on their tailored training courses and believes this offering will bring great value to many more organizations.

cPrime continues to be the leader in bringing custom solutions to organizations adopting Agile. They are known for helping companies adopt “hybrid” approaches Agile.

What role does management have in the agile environment where teams are autonomous? To define the role of the functional manager in an agile environment, you must understand that administrators in the agile world have fewer and definitive functions. Agile managers work to create originative and groundbreaking but adjustable and increasingly reconstructive atmospheres in organizations. This helps teams and product owners to accomplish specific objectives.

Agile managers must pay attention to specific areas in their efforts to be beneficial to self-organizing teams. This means that an agile organization looks to its management to administer areas that make the team productive. Such areas include:

* The management of teams

• The management of resources.

• The management of the environment within the organization.

Important Operations of Agile Management

Agile managers have expertise in human resource management and operations and management of standards, which includes quality standards, technical standards and ethical standards. They also have expertise in the advancing technical skills of employees of their organizations as well as other expedient skills. They champion causes and deal with issues of breakdown of barriers. They must be capable of competently implementing product accumulation alterations, even at the latest possible time while still maintaining the highest possible quality.

Why Agile Managers Give Up Certain Roles

Agile managers must give up the roles of process and project management to the ScrumMaster and features teams for specific reasons. Instead of being responsible for and having ownership of conventional roles, agile managers give up being accountable for the following reasons.

• Agile managers give the teams the opportunity to become obligated on their own, and this requires that teams should also take a collaborative responsibility.

• Agile managers give the team the opportunity to give more attention to repetition objectives and not just particular and distinctive responsibility.

• Management in the agile environment is more concerned with entrusting teams to develop on their own and individual advancement is encouraged.

The dynamics of management in the agile environment places focuses on enriching the cardinal role of managers and does not depreciate their responsibilities. Managers in this domain do not place emphasis on the responsibilities that teams collaboratively have the capability to manage on their own. Instead, they endeavor to work by determining what organizational adjustments are necessary. These changes help them give attention to the following aspects.

• They establish and oversee the administration of teams with various functional capabilities so that they can work towards a common goal.

• They work toward the formulation, development and management of essential infrastructures.

• They work towards the improvement of understanding and communication in the organization that are brought up by ScrumMaster and teams through everyday Scrums and Retrospectives or corresponding occurrences.

• They actualize and administer technical standards throughout the organizations with the assistance and advice of teams and technical leads.

• They oversee the development of training and support of change agents internally.

Management in the agile environment is self-organized and has a totally new approach when compared to the traditional approach. The adoption of Agile must be implemented by people with an Agile mindset. Problems are resolved instead of blame being apportioned. Tasks are accomplished through teamwork and emphasis is placed on development and accomplished by a group of people who subordinate their individual interests.

John Willis has been a freelance writer for 7 years now and has worked through a number of online websites such as Freelancer.com, Peopleperhour.com, and Elance.com. More recently, when he doesn’t contribute to college resource site DegreeJungle.com, John has been working with Highway Research as one of their writers.

http://leanagileguy.com/2007/12/30/the-role-of-the-functional-manager-in-scrum/

http://www.tutorialspoint.com/management_concepts/agile_project_management.htm

http://www.methodsandtools.com/archive/archive.php?id=70

http://www.scrumalliance.org/articles/103-the-managers-role-in-agile

cPrime offers a vast array of both public and private Agile courses, and has recently focused on developing a new series of modularized, role-based courses to promote optimal function and understanding within Agile teams. Allowing clients to tailor learning objectives and craft their own curriculum ensures that training engagements provide the most possible value to clients.

Participants are required to have taken Agile for Teams course (or equivalent) to ensure adequate understanding of core concepts of Agile and Scrum. In order to accurately tailor course curriculum, teams must also participate in a foundation planning session that will equip them to select topics and course configuration based on their needs.

Once prerequisites are met, teams will then configure their training backlog. They will select modules that keenly focus on their unique problem areas and deficiencies. cPrime’s full training backlog consists of eight modules:  Product Vision, Customer Focus, User Stories, Product Backlog, Story Mapping, Lean Execution, Scaling Agile Planning and Projects and Simulation; each encompassing numerous sub-topics and learning areas.

cPrime’s Agile Product Training engagements will vary in length from one to two days based on how many and which modules are selected; this duration does not include the time necessary to conduct planning sessions and initial foundational training.

Don’t leave product planning to luck. Let us help you get out of a pinch this St. Patrick’s day with a ½ day Agile Product Roadmapping strategy session. RSVP by March 31st to receive a 50% credit on Agile Services.

In fast-moving environments, product development teams can get lost in the gap that often exists between strategic roadmaps, technical roadmaps, detailed backlogs and task boards. Product Managers, Product Marketers, Product Development Teams and Managers can all benefit from a cohesive Product Roadmap Strategy.

cPrime’s Agile Product Roadmapping Strategy Session will help you and your group to:

• Define the key components of a strategic development roadmap
• Describe internal and external techniques for capturing, communicating and leveraging this information
• Outline the role of a market-driven product roadmap in linking corporate strategy to execution plans
• Understand the use of scenario planning to assess roadmap choices

Upcoming Agile Webinars:

My Role as an Agile Manager

When software development teams move to Agile methods, managers often wonder what their new roles and responsibilities entail within an Agile environment. Self-organizing Agile teams still need guidance and assistance in achieving goals, however, and managers must support these teams by providing direction, assisting ScrumMasters to remove impediments, and helping program management and business needs fit in to the iterative cycle. 

At a high level, managers will learn how to help teams become Agile and identify the most pressing constraints preventing agility.

The Essential Product Owner: Partnering with the Team

The Product Owner (PO) role is arguably the most crucial role within agile teams. Unfortunately, we often hear horror stories about PO’s who are going it alone—who aren’t available to their teams, who change their minds incessantly on business priorities, and who ignore quality requirements and technical debt. Even the best struggle to meet the many demands of the business while still providing sufficient team guidance. If your are a team or PO struggling to effectively deliver results, you’ll leave with ideas for establishing an ecosystem where the Product Owner and the team drive continuously improving performance.

JIRA and GreenHopper are amazing tools, but there are many features that users don’t know about or aren’t utilizing efficiently. The most common pains our clients have are reporting and configuring workflows. JIRA actually has a company friendly workflow option to build multiple workflows within multiple projects as well as ways to report the right information to the right stakeholders. We want to help you love JIRA and GreenHopper again by configuring your workflows, creating succinct reports for stakeholders, training you and your colleagues, and optimizing your tool.

It’s time for you to fall back in love with JIRA and GreenHopper by taking advantage of our February tool offerings of:

A $100 credit* towards our Tools Optimization and Training services or a FREE 1 hour JIRA/GreenHopper Assessment to discuss challenges, answer questions and provide recommendations.

CONTACT US TO REDEEM OFFER

*An additional $100 credit can be redeemed for every $1,000 of Atlassian licenses bought through cPrime.

** We also accept PO’s for payment of licenses (so you don’t have to keep charging it up on your credit cards)**

NEW To our Agile Training:

Advanced Certified Scrum Product Owner Course

While this course covers the details needed to fulfill or support the Product Owner role, we believe that understanding the role and its responsibilities isn’t enough. We offer a user-centric design approach to make successful products, in a truly collaborative way.

At the end of this course you’ll be able to:

• Perform the Product Owner and Product Discovery Team daily work practices
• Draw from a variety of sources to support your product discovery and design work
• Gain empathy with your users to understand how best your product serves their needs
• Practice effective collaboration that spotlights shared understanding and ownership of your products

LEARN MORE

cPrime has been training and coaching medium to Fortune 500 companies in Agile and Project Management for over 10 years. They offer a full service solution in Agile transformations from Agile training to team augmentation. In December of 2012, cPrime conducted their first customized training workshop for Year Up Bay Area students. Through a high-support high expectations model paired with an intensive curriculum and corporate internship, Year Up provides urban young adults the opportunity to fully realize their professional and educational potential. Since 2000, Year Up has transformed the lives of 6,000 young adults. And, Year Up has proven results -four months after the program, 88% of Year Up Bay Area graduates are employed full-time or in college full-time and on average, after the program, Year Up Bay Area graduates make $16.38 an hour or around $30,000 a year.

cPrime’s Year Up training focused on the basics of Project Management and dove deeper into the Agile methodology, which has expanding adoption across the companies Year Up’s students intern for in the Bay Area. Some of their partners include Wells Fargo, Zynga, Bank of America, Kaiser Permanente and Electronic Arts. To make the class as beneficial and practical for the students, cPrime customized the course for the younger non-project manager students, but took real-world concepts from cPrime’s Agile Essential’s Workshop. The workshop, which is conducted for cPrime’s clients who are in the midst of adopting Agile, focuses on overcoming the roadblocks of adopting a new methodology while learning the fundamentals of a Scrum project. The course focused on Agile methodologies which are based on iterative and incremental development that promotes adaptive planning and flexible response to change. Students benefit from the practical hands-on knowledge of Scrum and skills conducted in the workshop because they can directly apply the concepts at their internship through the Year Up program and even in their full-time positions after the program. Further, participation in cPrime’s training gave these students an edge during Meet and Greets with Year Up Bay Area corporate partners.

Brandon Huff, cPrime’s Agile Coach who conducted Year Up’s training, explains how the skills of a Project Manager are relevant to any career these students may choose to go into, “Learning communication skills, project, time, and team management skills are key to the majority of roles these students will employ”. In addition, the students were taught the fundamentals of managing a Scrum project under the Agile methodology. During the training, the students simulated a real Scrum project with sprints, stories and retrospectives.

Year Up says the training was a huge hit for its students and many students are interested in pursuing a project management career. Jay Banfield, Founding Executive Director of Year Up Bay Area, explains, “This kind of contribution from cPrime offers our students incredible value and makes them even more prepared for the careers they will now have access to. We look forward to continuing trainings with cPrime in the future.”

Year Up Bay Area student, Oscar Munoz, shares his feedback on the training, “I didn’t know anything about the Agile process before this training and now, I walked away with a working definition for scrum, agile and waterfall. Even better, now I can actually talk through the concepts. Brandon is a skilled instructor and I appreciated that the training was very interactive – I was never bored.”

cPrime’s CEO, Zubin Irani, has been involved with Year Up for the past two years and has been participating on their  Silicon Valley board launch committee for the past two years. He is happy cPrime has the opportunity to give back to an organization that values education and innovative concepts, like the Agile methodology. They plan to provide more workshops to additional Year Up students in the future.

To learn more about Year Up and see the many student success stories from the program, please visit http://www.yearup.org. To see how cPrime is helping companies adopt Agile methodologies and learn more about their Project Management training curriculum, please visit http://www.cprime.com.

Meetings are optional. I was introduced to this concept nearly a year ago while working with several clients who have implemented a Results Only Work Environment™ – for more information, you can visit gorowe.com. At first, I was skeptical. Agile requires collaboration. Real-time, face-to-face collaboration! How else can that be achieved other than to have a meeting?

But, the more I learned about the concept, the more I agree. Meetings are optional. The intent of collaboration, in Agile, is to get results. Getting results, if we require face-to-face collaboration does not require a meeting, it requires that we get together with intent to work. Doing work and delivering results is what we are hired to do, after all.
This concept was reinforced today (and many times over the last year internally with my own team and while on-site with clients) with such force that I feel compelled to write a little blog post about it as it relates to the difference between meetings and working together. This is especially important for Agile teams and maintaining adherence to the Agile Principles. In particular, meetings can be destructive with regard to the principles of:

• Conversation (working together, face-to-face, to understand and solve toward delivering valuable solutions to business problems)
•  Sustainable Environment (minimizing waste, focusing effort on value, maintaining a predictable and reliable cadence toward delivery)
•  Simplicity (defining a solution that is good enough with the right people working on the right problem at the right time)
• Self-organizing Teams (where the people who do the work identify who and how the work should be done)
• Motivation (maintaining an environment where team members are valued, trust one another, and are empowered to use their talents and skills to solve problems)

The particular example today was a meeting to collaborate as a team that was originally scheduled for yesterday. Yesterday, we convened at the proscribed meeting time, but the meeting organizer was unable to attend. After about 10 minutes, one of the team members received a notice on their mobile device that the meeting was rescheduled. Today, we reconvened at the proscribed meeting time; again the meeting organizer was running late. After about 10 minutes, we left the room and all received an invite to get back together at the top of the next hour. During this third attempt at getting together for a meeting¸ the meeting organizer was again running late and asked (via email that was received by our mobile devices) that we just hang tight for 15 minutes and she would be there to join us and “hoped we can stay a little longer.” In all, we had already wasted more than the 30 minutes planned for the entire meeting just waiting for one team member to arrive. Of course, it was this single team member that was critical to the discussion and no work could be done without her involvement.
As a motivated, goal-driven individual I wanted to stay and wait. Other team members also wanted to “get it over with.” But, the Agile Coach in me (and my value of Lean and Agile Principles) led me to ask the team what they wanted to do to self-organize around this problem of not being able to meet. The short discussion resulted in a team-crafted email response of “Let’s get together face-to-face next week when you can commit to doing work with the team you have called together and stop wasting our time.” The email was a little more diplomatic than the sentence I am using here in the blog post, but the point was very clear.
It dawned on me that, as much as I believe the need to meet face-to-face is crucial to Collaboration, this single meeting had created waste, complexity, distrust and frustration. We needed to be very clear as a team that all team members, especially those who were asking for the gift of our time and input in a calendar invite, need to do more than “schedule a meeting” or “put time on the calendar.” Every team member must commit to doing work together and honor the time that is being spent to collaborate on important issues. During this coaching moment with the team, we also identified that several of the meeting invitees had little, or nothing, to contribute that others could not handle effectively on their own.
So, the meeting we had scheduled for yesterday (which was Thursday) and rescheduled several times for today (Friday), will now be a work session on Tuesday next week in which several of us get together to work face-to-face and collaborate to find a solution to our problem, then to design and plan a result. This meeting, that was originally proposed as important, needed and required the attendance of several team members has truly proven itself to be optional. So optional, in fact, that we canceled it (as a team). Those of us who are really needed one, now have a calendar invite that requests our time to get together and work face-to-face. Whether we need 10 minutes or 10 hours to truly solve this problem, we don’t yet know. But we have timeboxed our work session on Tuesday for 30 minutes to start. If we solve the problem in 3 minutes, we will have 27 minutes back to do other work. If the problem takes 3 hours to solve, we will make sure to identify the next steps and individuals needed to work together in future timeboxes of work. We may even put those timeboxes on our calendars as convenient reminders. But trust me, they will not be meetings!
As I conclude this short post, the next thing I will be doing is to go through my calendar and identify those meetings that are optional (and likely change my attendance status) and to make sure I am available to collaborate face-to-face in those predefined timeboxes noted in my calendar – and to show up, on-time, ready to work!

Written by Zubin Irani, cPrime CEO

Today’s financial institutions are facing huge changes in technology platforms, payments processing systems, financial systems, asset and risk management systems, while attempting to deliver services in the way customers prefer. From m-payments and the ability to view and trade stock options via mobile phones, to e-payment and trends towards an increase in digital and online banking, to the need to rapidly process and keep track of accounts, balances, interest rates and identify financial trends, while reducing financial risk, the platforms and business applications banks and other financial firms use have evolved enormously in recent years, and are continuing to do so at a rapid rate.

Firms in the financial sector also face other challenges, including the need to comply with regulations such as Sarbanes Oxley, SEC, FDIC and the Federal Reserve, while if international, they may also require compliance with Basel II and SEPA directives, among others.

Combine this with the difficult market conditions in the past few years, and the need to sustain revenue growth and retain market share in an increasingly competitive landscape, and IT departments within financial firms are feeling increasing pressure to improve efficiency and speed, while at the same time maintaining controls on cost and capital outlays.

Agile development methods meet many of these requirements. The trend to Agile adoption by other business sectors has been driven by the need to deliver high value, create software that actually meets end user goals, and to reduce risk when business applications are developed.  Yet when financial institutions think “agile”, traditionally they have reacted with “hesitate.”  This has occurred for several reasons, not the least of which is the desire for absolute predictability of costs in a sector that spends large amounts on its IT.

Challenges Faced by Financial Institutions: Big Spending on New Services and to Maintain Aging Systems

The financial services industry is a large consumer of IT services, with its IT spending in North America expected to reach $71 billion, and to continue to grow at a four year compound annual growth rate (CAGR) of 4.1 percent¹.  Global spending will also continue to be significant, with global spending by financial services on IT predicted to reach $393 billion by 2013, with Europe and North America spending the lion’s share of the total (69.1 percent).²

This is a lot of money going towards IT, but why? One reason is the rising demand for convenience banking, with online and mobile banking two of the fastest areas of growth.  But the large investments in IT are also due to a less forward-looking factor that heavily impacts the banking industry. Many financial institutions and banks today have a large and aging legacy IT infrastructure. They originally heavily invested in during the late 90’s, and now these networks require large amounts of patching, maintenance, upgrades and continuous attempts to integrate it with new technologies.

In addition, larger banks are tending to buy out smaller independents, and are inheriting older systems that they must either choose to work with, or completely revise.  This choice can be complicated if a core business platform is surrounded by layers of maintenance code.

Barriers to Adopting Agile within a Financial Institution

Because of the large amount of regulation within the industry, banks have often continued with waterfall methodologies, or “the tried and true,” due to its perception of having more predictable, defined outcomes. In an industry driven by cost analysis, the ability to define each requirement and its cost before starting development has made it attractive for years to this sector.

The challenges of Agile adoption by financial institutions is often greatest within the largest firms, which must coordinate development between segregated teams that work individually on one component of the software, such as design, analysis, development, or testing.  These teams may be distributed across different time zones or even continents.

Another reason for the hesitation to adopt Agile is the fact that in financial services applications, even the smallest error can cause the loss of thousands or millions, especially when account sweeps and trades must be timed with extreme accuracy. The technology cannot fail, or the risk exposure is unacceptable. The requirements for due diligence have caused many financial services firms to stay with waterfall development, where the documentation is extremely extensive, for compliance with auditory and other regulations.

Because of this regulation, the financial services industry has traditionally utilized very formal enterprise change control procedures, and created extensive documentation for auditing purposes. In an industry where “risk management” is the order of the day, any development methodology that has a perceived lack of outcome predictability is not quickly embraced.

Another challenge is the nature of financial software systems, which may interface with multiple peripheral systems and interfaces, requiring careful definition of these interfaces ahead of time. These complex systems can be difficult to develop using a pure Agile methodology, and some, like embedded software, may be more suited to waterfall or a hybrid development process.

Yet in spite of these challenges, a growing number of financial services firms are choosing to transition to Agile. This is due largely to the problems seen – and the costs associated – with staying with waterfall methodologies.

Problems Financial Firms Encounter with Waterfall Development

Traditional waterfall development practices have caused difficulties for numerous financial firms. One that has experienced issues with it is one of the leaders in the financial industries, whose Capital Finance group is currently exploring making the transition from waterfall to Agile and other methodologies. They are looking for a lighter, more responsive way to develop the numerous smaller projects in-house which the time and resource-intensive practices of waterfall are not really suited for. Currently, cPrime is working with them on training in Scrum and Kanban methodologies, providing coaching and mentoring for some initial pilot projects.

The issues faced by Farm Credit Services of America when they used waterfall is another example of the problems encountered by financial services firms that stay with waterfall. Farm Credit Services is a cooperative association that grants loans to Midwest farmers and ranchers, to the tune of over $11 billion of operating capital and real estate financing.  For years, they followed a traditional waterfall approach, and saw customer satisfaction fall as a result. They would spend a lengthy time gathering requirements, carefully defining each, before even beginning development, which frequently lasted for years.

In the meantime, technologies, business practices, and even the original business partners who requested the application would change. And many times, the customer wasn’t happy with the end result, since by the time development was completed, it needed significant changes to keep up with the changes in service delivery and technologies.

This caused Farm Credit Services to decide to change over to Agile development. During the transition, they formed an Agile Champions Team (ACT), and their six development teams now use Scrum. Since the change, they have seen a significant reduction in software defects, and more rapid development times. Most importantly, they have seen a rise in customer satisfaction and development team morale³.

This quick case study highlights some of the problems seen with waterfall. Financial institutions that choose to use it to develop strategic projects often see these projects come in late, and over budget.  In fact, delays in the anticipated launch dates for financial services projects have become notorious – and even expected – due to the lengthy process that waterfall requires.  This causes an industry that concerns itself with costs and the bottom line watch project costs rise, as teams struggle to rework applications that must attempt to keep up with changes in technologies and platforms – even though the requirements and specifications, which took months to obtain,  were defined two or three years previously.

Customer satisfaction with the final applications may be lower with waterfall, as noted before. Even if the application fulfills all the features requested, the customer must be an extremely patient one to deal with waiting two or three years to see a finished product.

Development team morale may be reduced, since developers must rush to test and re-test at the end of a project, realizing that they are working on an application that is already outdated before it even goes to market. And time and resources are often wasted, since some of the original features specified and built into the software are never used, once the application becomes operational and actual use shows that certain features aren’t needed or wanted.

Because of these waterfall drawbacks, financial services firms are turning – albeit slowly-towards investigating Agile development methodologies. They want to reduce time-to-market, and see the improved ability to incorporate customer feedback that Agile provides.

For instance, European-based BNP Paribas operates in over 85 countries, and in 2006 reported a net income of 7.1 billion Euro. In order to improve development team quality and reduce development time for projects, an initial team of 60 developers in the risk IT department adopted Agile for new projects, beginning in 2004. The teams consisted of six developers each, who were trained and mentored in Agile, and they provide working software features during iterations of two weeks’ duration, to incorporate stakeholder feedback.  They also use test-driven development, and the project velocities have improved greatly⁴.

Capital One, a Fortune 500 firm, offers financial products that include credit cards, savings accounts, and loans for consumer and business purposes. They first adopted Agile in 2004, and after moving to Scrum, by the end of 2006 saw an average of 70% reduction in time-to-market, causing them to implement Agile across their enterprise in 2007. By doing so, they also so improved collaboration and teamwork in the development/Scrum teams. Agile worked so well, that they then began developing internally Scrum coaches who could oversee Agile development within the firm⁵.

cPrime has assisted numerous clients in the financial industry make the transition to Agile. (See the interview with cPrime Agile Coach, Jeff Howey, below)

These firms are leaders in the financial industry, and they have seen the advantages of Agile for their organization in terms of improved ability to incorporate feedback, flexibility, improved velocity and high quality in the code produced.

The Key: Transition at a Workable Pace

When a financial service decides to go Agile, it makes sense for the transition to be implemented in stages. At cPrime, we recommend this approach, making small changes at first, that will realize the most value. This is why the planning stage is so important. Careful planning can make the difference between Agile adoption that lets the firm enjoy all of the benefits, or one that falters.

At cPrime, we meet with key decision-makers and managers during an Agile assessment, to ensure consistency and that all are in agreement before going forward with the transition plan. Prior to the transition, the tools to be used are selected, and/or developed and adapted for in-house use.  This is an important part of the transition, since the documentation the tools provide can be critical for a firm that must comply with regulatory and auditory requirements. These can be combined with templates to help automate many of the processes, and provide a documentation trail for later use.

Once the tools are selected, the developers undergo careful training in Agile and Scrum practices, with on-site coaching and mentoring by cPrime staff who have extensive industry experience in Agile implementation within Fortune 500 firms. This training, coaching and mentoring, with actual hands-on practice in using Agile for “real life” development scenarios is critical to a successful Agile transition. Our firm strongly believes that it’s important that all team members understand, and are shown how to use Agile in a practical way, instead of “guessing” how it’s done.

First, the Scrum teams are trained in their roles. This includes Scrum Masters, who help facilitate development, Product Owners who act as intermediaries between stakeholders and development teams and update product backlogs containing the list of the features desired in the finished product) and the development teams. Team leaders learn to enter features into the Sprint backlogs during the transition time. Then, they begin to take on projects: first, small pilot projects are often completed; then initial success is built upon, with larger ones developed over time. Key elements that are different from waterfall include the extensive collaboration, since teams are often multi-disciplinary, and the increased communication, with daily Scrum meetings to asses where development currently is, where it’s going, and identifying any issues or roadblocks that come up.

The Sprints, or time periods for developing specific features in a product backlog, are often shorter than iterations in waterfall, with a Sprint lasting only two to four weeks. The team leaders are taught to estimate the time required to complete features, and to allocate resources during a Sprint, with mentoring and modelling by cPrime staff for the transition. These estimates become more accurate with each Sprint completed. Burndown charts are created that show the backlog items completed to date, and the team velocities are graphically shown to provide visuals of the progress.

Sometimes a Hybrid Approach Makes Sense

For some financial institutions, a hybrid approach may work best, especially at first. cPrime has worked with numerous clients in the financial services sector. The best results occur when management supports the transition, and both the stakeholders and the teams doing development begin to see the benefits quickly, through a carefully planned and executed transition process. Defining whether a hybrid approach will be used – and when – is also done, by mutual agreement.

See cPrime’s Hybrid Agile Model Workshop

By using these methods, the transition to Agile for a financial services firm can be an excellent experience, and the company can begin to enjoy the advantages of Agile: improved velocity, improved ability to incorporate customer feedback; improved collaboration, teamwork and morale internally, and greater customer satisfaction.  The companies using Agile are better able to stay competitive, and use the evolving technologies within the financial services sector. And in the end, they are able to keep pace with marketplace realities, and provide the services that customers require, on the platforms they prefer, with a shorter time-to-market and a greater return on their IT investment.

Interview with Jeff Howey, cPrime’s Agile Coach, around the barrier to adopting Agile as a financial industry.

1. What are some of the barriers to adopting that you have seen, from financial services firms? How have you addressed these hesitations?

Intentionally detailed and methodical approaches to managing requirements (often driven by internal Audit or SOX rules) tend to attract very detail-oriented and methodical people into project management, leadership and customer-facing positions.  Agile requires the ability to work with “good enough” requirements and agreement.  Forcing a process to approve all requirements and manage every step of the process (often at a micro level) is anathema to Agile.  To varying degrees of success, this depends on the ability of the teams to prove the value of Agile delivery and maintain quality in their releases while also satisfying the requirements of the process.  I have seen many Project Managers or leaders of organizations who would be called “micromanagers” in some circumstances become major proponents of Agile when the teams did not ignore the process (or complain excessively about it) and deliver a few releases of high-quality software in frequent release patterns.

Many financial services systems are large and complex with many integration points.  And they deal with money.  This requires extensive testing.   In most of my experiences, the teams would perform Stabilization Sprints to do extensive testing and validation in advance of a release.  This would be particularly true where multiple teams were working on different components of a system that would require integration and stabilization.

2. What are some specific problems with waterfall that cause financial services companies to finally change over from waterfall to Agile?

Customers who used to think they had no choice but to wait months or years for updates to their systems have gotten savvy.  And so has the competition.  In addition to that, many organizations themselves have seen that big projects with a long shelf-life tie up a large amount of investment.  While the pace required to keep up with customer demands and competitors’ innovations has increased, these organizations understand that focusing that investment on short time intervals and having the ability to pivot quickly and gracefully is supported with Agile and forces the organization to choose the most important projects (and features of each project).

3. What helps the transition most? What makes it hardest?

Helping a transition MOST is to have understanding and of the acceptance of the trade-offs of Agile by all levels of an organization.  For example, starting early and working iteratively to deliver requirements and demonstrate them to the Product Owner is intended to make it possible for the team to work collaboratively and quickly toward releasing a valuable product.  It may, at times, unintentionally put the team into a position that future releases require rework.  For instance, a first release of a system may satisfy most needs of most customers and be releasable in a short amount of time.  The goal of the team is to satisfy the remaining needs of remaining customers in the future (as trying to accomplish all of that work would greatly extend the time to deliver).  Most of the time, the requirements  for future releases would be known and taken into account through the architecture and approach of the Release 1 deliverable.  At times, the team may choose to do “just enough” to get the first release out the door and intentionally plan to do the additional work in the future.  That isn’t a huge issue, though it does create work.  The hardest point is that sometimes, it is the smaller details that are unintentionally overlooked or made apparent only through very close inspection and understanding of complex rules or integration points that cause the most pain.  When this is understood at all levels, the organization can adapt gracefully.  When this is not understood, it causes pain and finger-pointing.

There are many obstacles to a smooth transition.  In many cases, it is the resource-allocation model that does not allow a Scrum team to stick together and be dedicated to 1 project together for long periods of time.  That, as an organizational policy, is the hardest thing to overcome – and one of the things that makes a transition move smoothly.  Even harder to overcome is a transition to using Agile processes to deliver software when the rest of the organization (particularly those who are Customer-facing) do not understand or buy-in to the process.  Or, if those organizations have pushed the delivery organizations to use Agile with unreasonable expectations (e.g. Agile does NOT mean “do more with less, faster” – it is about intelligently making frequent tradeoffs to get the most business value sooner.

4.How long does an average transition to Agile take?

This is a tough question… I don’t know that any transition is “average”… but I’ve seen transitions take anywhere from a few months to “never”…

I worked on a pilot project with a Property & Casualty Insurer that went well.  Within a year, a handful of other projects were following Scrum and it was an option within the PMO approaches to choose Scrum for some projects based on select criteria.

I’ve seen attempts by several organizations, including one large banking institution, to move toward Agile as their preferred method of delivery as many as 5 years ago who are still struggling to manage the transition and implement Scrum successfully.

I’m aware of one client who adopted some basic Scrum practices to give more structure to their process.  For years, they were driven by “fire drills” or demands their largest customers in a very reactive environment where customers were driving the dates.  The team was a shared resource from the point that they developed for new requirements but also had to do all of the ongoing support.  The technology team was unable to get the customer-facing organizations on board (as it would require prioritization, scheduling and, more importantly, saying “no” to low-priority customer requests) to manage the shared Backlog with a small team of developers.  This team abandoned Agile and went back to fire-drill mode, overtime and chaotic prioritization as they were unable to stick to Sprint or Release schedules in that environment.

But, mostly, I’ve seen that teams who work together for long periods of time and can focus on 1 project at a time develop mastery of Scrum or Kanban within 4-6 months and are able to really focus on continuously improving their ability to work together and deliver predictably and reliably.  In many organizations, this sets the stage for Agile adoption as one of the approaches for projects.  Where the organization is able to implement structural and procedural processes in support of Agile (e.g. resource allocation models, portfolio management, backlog prioritization, etc.), a widespread adoption of Agile and true Transformation can begin.  In many cases, it is somewhere between the first and second year of multiple projects running in an Agile process that this occurs.  The size of the organization is certainly a part of the issue, but the biggest driver is culture at the team or department level.

5. Do you use a hybrid approach? What kind? Which departments tend to go Agile, which ones tend to stay waterfall?

In large organizations with intentionally heavy project management methodologies or for complex and large, highly-integrated systems, hybrid is the usual choice.  For some teams, Agile is not ideal due to their resource management approach, so a plan-driven approach works best to plan the work.  For some systems, iterative requirements and development are not ideal or do not have support of the business organization and must be written far in advance for approval.

In terms of trends toward Agile, any organization with web or mobile applications tends to move quickly toward Agile, particularly Scrum.  Business Intelligence, Production Support and digital marketing organizations tend to move quickly toward Kanban.  Infrastructure, Data Warehousing and some of the back-office systems tend to continue development in a waterfall approach.

6. What key points should be addressed in Agile adoption, in your opinion?

Culture of the immediate team and organization, not size of the parent company, is the key determining factor in whether some products can be delivered using Agile.

It’s OK for some projects to use Agile while others do not…

Well-documented and well-managed projects (conforming to PMO and other rules, including SOX regulations) can follow Agile… it’s all about how we collaborate with the customer… and less about the speed with which we deliver.

Sources

1. IDC – Worldwide Vertical Markets IT Spending 2010-2015 Forecast: 1Q11 (March 2012)
2. Jegher, Jacob. “IT Spending in Financial Services: A Global Perspective,” Celent Research report, available at http://www.celent.com/node/26799
3. Wiss, Urs.  “Agile Software Development in the Finance Industry: How popular are agile methods in financial services firms.” Bachelor’s Thesis, 2/17/2008
4. Saran, Cliff. “European banking giant adopts agile development methodology,” ComputerWeekly.com, 11/26/2004. http://www.computerweekly.com/feature/European-banking-giant-adopts-agile-development-methodology
5. Silva, Kara and Doss, Chris. “The Growth of an Agile Coach Community at a Fortune 200 Company.” Capital One Financial Corporation, IEEE publication ©2007.

S*** ScrumMasters Say

cPrime’s Agile Practice Lead, Kevin Thompson offers a comical take on ScrumMaster jargon and their role in the scrum team.

To learn more about the role of the ScrumMaster in the scrum team, check out our ScrumMaster Role Cheat Sheet

Want to become a ScrumMaster? We offer convenient training courses across the country.

To purchase the Task and Story Templates seen in this video, visit: http://www.cprime.com/store/agile_development_with_scrum/agile_task_and_story…

To Purchase the Agile Estimation Decks seen in this video, visit: http://www.cprime.com/store/scrum_and_agile_essentials/agile_estimation_card_…

Many students take a Certified ScrumMaster training course intending to kick-start their team or company’s Agile adoption. However, as we know, Agility is simple in theory, but hard in practice. You may be asking yourself, “Okay, I am a Certified ScrumMaster, but what’s the next step?” You understand the fundamentals, but how are you going to guide or convince an entire team or organization to completely embrace Agile methods and adapt the way they’re currently implementing projects? Although it may seem daunting, small steps in the right direction are doable and can impact your team and organization enormously.

We asked a handful of our Agile Coaches and Instructors about their recommendations to first initiating Scrum on a new team as a ScrumMaster. Below we listed the 10 steps that we found most beneficial. Enjoy!

1. Find a project suited for scrum — Find a project with medium term deliverable, around 3 months or so, and medium importance. You want to find a project that is not detrimental to the organization if it fails, but not so insignificant that no one will care.
2. Find a sponsor who will support your endeavor – Describe to them the problems with your current team’s problems tell them how Agile could help. To get ideas, check out the benefits of Scrum here!
3. Acknowledge that this is a learning opportunity – Let your team, management and executives know that this is a learning process and scrum is iterative; it will take a number of sprints before improvement is seen – Remember failure is the only way to success!
4. Find comparison metrics – Compare the success and failure metrics from your scrum project to metrics of a current plan-driven project. One suggestion is to look at the number of known bugs released to production or escaped defects found after your release. Also look at the severity of these defects. You can also try to measure customer satisfaction, adoption/uptake rates, click through rates, team morale, cycle time (between release cycles), or features per cycle.
5. Form your team – Find a team that has all the necessary skills to complete this project – a ScrumMaster, Product Owner, Developers, Q/A, etc.
6. Be prepared to train your team — If you are the only one on your team who has taken Scrum training, be prepared to train your team and guide them through the process. If your budget allows, look for team training opportunities to get everyone up to speed. Read about our Team Training Workshops. cPrime also has an Online Introduction to Scrum Course available here that your team could take for a low cost.
7. Find a Mentor or Coach – If resources allow, find a mentor or coach to help you and your team. (Ask us for help!)
8. Read “Scrum and XP from the Trenches”– You can download the entire book here. Use this book as your guide while going through all the processes of Scrum. It gives you every practical detail of scrum processes, tips and tricks, pitfalls, descriptions of day-to-day work, scaling and planning in scrum. This was the first book that Kevin Thompson, cPrime’s lead Agile Coach, read and he recommends every person starting to use scrum to read it.
9. Schedule your first Sprint Planning Meeting — Make sure your product backlog is in place and that your product owner has rated the importance of the stories. Refine your product backlog story into small tasks or items that will fit into your first sprint (Your sprint backlog).
10. Keep Learning! Your CSM course gave you the fundamentals, but adopting Scrum is an process and it is important to continue to learn best practices and improve your performance.

Join Agile MeetUp Groups      Read Advanced Agile Articles          Attend Advanced Webinars              Read Our Blog