Category Archives: Agile Development with Scrum

Understanding the Dynamics of Management in Agile Development

Posted on by
Reply

By John Willis

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 develops new Agile Product Training curriculum

Posted on by
Reply

cPrime will deliver modularized Agile Product Training to Product Owners, Product Managers, Executives and team members that suit unique team needs and provide hands-on learning with interactive exercises that utilize real projects. 

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.

cPrime develops an Agile Project Management training course for urban young adults at the non-profit, Year Up.

Posted on by
Reply

cPrime, the largest Agile education provider in the United States, customizes a practical Project Management and Agile Workshop for Year Up, a non-profit organization dedicated to training urban young adults in tech careers.

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.

year up agile training

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.

agile training at year up

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.

agile training at year up

 

Agile Adoption by the Financial Services Industry

Posted on by
Reply

Seeing a Greater Return on IT Investment

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 percent1.  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).2

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 morale3.

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 greatly4.

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 firm5.

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.

Banking and Agile

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.

 

Video: S*** ScrumMasters Say

Posted on by
Reply

 

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_…

So you’re a ScrumMaster, Now What?

Posted on by
Reply

10 Steps to Jump-Start Scrum Adoption after your CSM Class

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

Challenges of Adopting Agile in Combined Hardware and Software Environments

Posted on by
Reply

By Zubin Irani, cPrime CEO

While the benefit of Agile has been noted by those within firms that create embedded software, or firmware, the practical application of it to combined hardware and software development has been difficult to envision. But waterfall methodologies create at times extremely lengthy development cycles (years, for complex systems), and this has caused decision makers to search for ways to reduce time-to-market without sacrificing quality.  These same decision makers must first work with the challenges unique to their industry, when determining which methodologies and project frameworks would work best.

Challenges unique to a hardware/software development

One of the challenges for combined software and hardware development is that software can normally be developed fairly rapidly, and the development broken down into smaller chunks, or iterations. Hardware, on the other hand, may require three to six months or more to show a working component or feature. If the software must wait for the hardware to be created for final testing, this can create testing delays.

Kevin Thompson, PhD, PMP, CSP, and the Agile Practice Lead at cPrime states, “Historically, the view was, ‘Let’s make the hardware first, then develop the software, and get it to work well’. The problem with this approach is that it takes a long time, and at the end, the hardware might not work, which creates a whole new set of problems.”

Hardware must also often follow strictly defined process models, meet compliance standards, and it can be difficult to make late changes (which would be prohibitively expensive) to hardware. The priority for embedded software, for example, would be to write the hardware drivers first, to allow evaluation of the new device and to allow testing1.  Testing is more complex when software must work within a small physical space, and time itself perfectly to prevent race and other timing issues, requiring testing at some point on the physical hardware2.

If problems occur, with waterfall methods it can be difficult to determine which is at fault:  the hardware or the software. Because hardware often isn’t available until near the end of a project for actual deployment and testing, virtual versions of the hardware such as mocks, simulations and emulations may be developed, if the budget permits3. But this is not the same as testing on the real hardware, under live conditions where heat, movement and other environmental impacts must be taken into consideration, and reliability under these condition ensured (because you really do want your auto safety brake system to work, even on a bumpy, icy, wet road).

Problems with Waterfall for Embedded/Firmware Software developers

The problems with waterfall can be summed up as “technologies, customer requests and market realities change faster than waterfall can keep up with.” This is certainly true when complex projects that use waterfall have been known to last for years. By the time the embedded software is integrated with the hardware, the original project specifications may have changed enormously –or the technology may be outdated.

Other common waterfall problems include features being built that are never used, late product delivery, and the inability to prioritize development to what the customer really wants, especially as time goes on.  “Customers often don’t know fully what they want, until actual work on a project is started, and they can see and preview features,” says Dr. Thompson.  This is especially true when an entirely new type of device is being developed, with no actual way of knowing exactly how the product will work.  Requirements during projects of this type evolve, as the teams come to understand the technology and the device, and as they develop the device and demonstrate it to the customer4.

In spite of the rigid processes, designs, specifications and tests used by waterfall, the resulting software quality may end up being lower than with Agile, which tests every build from the beginning, and employs continuous, integrated testing throughout. When using Agile practice, the resulting software can be so reliable that it is used to help determine if a hardware defect is present, instead of the other way around.

Special Challenges for Agile Implementation in Combined Software and Hardware

A major problem seen when companies who create hardware and the software that runs it face when trying to “go Agile” is that they often attempt to take methods and practices developed for software (such as Scrum, an Agile project management framework), and try to use it for everything, including hardware development.  Scrum is based upon Sprints of relatively short lengths (two weeks to 30 days), with highly defined tasks that must be completed during the Sprint. The nature of software development makes this an excellent framework for rapid progress; but Scrum isn’t necessarily the best framework for hardware development.

If the products are in a highly regulated industry, then the documentation must follow industry requirements for specification and design, as well as normal testing and functional requirements documentation.  This makes it extremely difficult to use Scrum by itself, since the processes for hardware are frequently much more rigid, defined, and design-oriented than those normally defined by Scrum.

On the software side, because software must interface, communicate with, and control hardware, development issues using Agile are more complex for combined software/hardware projects, and the Stories (definition of the functions for a specific feature) that the software developers define for each Sprint are accordingly more complex.

Large projects with large amounts of dependencies can be even more challenging.  One method of dealing with hardware that isn’t ready to test, is to decouple software and hardware development, via an abstraction layer, to allow software development to continue more rapidly.  The challenge is to find a method that allows the rapid development of software, with concurrent development of the hardware, that can best meet the requirements of each process.

Solution: Use Different Agile Approaches for Software and Hardware

One approach for companies who develop hardware and software to consider is using different methodologies for each. “Scrum works very well for software development,” says Dr. Thompson, “while hardware development can be better managed with an approach developed for non-software Agile projects, such as Commitment-Based Project Management (CBPM).”

With CBPM, instead of working on a Sprint timetable, which may be unrealistic for the delivery of working hardware features, the team members each make a personal commitment to develop one hardware feature by a specific date. The team meets regularly, for accountability that they are on target. Progress reviews, with any corrections needed, take place at regular intervals.

If hardware production falls behind, re-planning occurs to address any roadblocks and implement changes to get things back on track. Both Scrum and CBPM are team-oriented approaches, and can improve communication both internally among team members, and with the Product Owners (team member who represents the stakeholders, ensuring that development create the features they want). While the Scrum master (development facilitator) will assign hours to Sprints for software development, the individual hardware team members will define the work that they must complete to meet their commitment by the time they specify, using Performance Against Commitment (PAC) charts to show progress. Both methods allow Product Owners and end users high visibility into how things are going, and where things are going next5. Problems that arise can be addressed quickly.

With CBPM, the emphasis is on delivery of at least a component or piece of the hardware that works, in order to allow the development or testing of the software that will work on it. This is very different from waterfall, where the entire hardware must all be built first. While Scrum for software is based upon two to four-week Sprints with small portions of the software completed at a time, hardware development requires a different approach.

Dr. Thompson says, “The question must be, “What are the basic, smallest chunks of hardware functionality that I can deliver? Can I split the hardware up, so that it’s somewhat modularized? And for each of these ‘modular’ deliveries, what’s the best, the most Agile way to deliver the work?” This transformation in thinking, and the use of CBPM, is at the heart of using Agile in a non-software environment such as hardware production. Instead of defining a four-week Sprint, CBPM has a continuous execution of the project. The goal isn’t a completed Sprint (and associated tasks), but instead, to show actual progress. The result is faster velocity.

With Agile, both hardware and software features are broken down into smaller chunks – only the methodology is a bit different for each. Once software is working, it can be deployed either on any available hardware “modules”, or in a test or simulation environment. This allows the early identification and fixing of race issues and bugs that arise, and reduces the amount of “fixing” and lengthy hours reworking that must occur during late integration.

For CBPM, the Product Owners, or users, collaborate in defining when the deliverable is completed. This differs from Scrum, where “finished” is defined as completing the backlog for that Sprint. Monitoring of progress can performed in the manner that works best for both the hardware team and the Product Owners, with a performance against commitments chart created to show progress.

By the time the software is tried out on the hardware, with Agile the software quality problems are often resolved, and the only issues are related to integration. This is because with Agile, the code is tested, and these tests then help with the design of further code. These tests in themselves become part of the documentation for the system6. Automated regression testing allows the addition of new features or alterations to existing code with more confidence, since issues are revealed quickly.

A significant benefit of Agile for embedded software development is that because the Sprints are shorter, it is easier to create more accurate project completion estimates. This allows for improved risk management. The nature of Agile prevents or reduces technical debt, and performance goes up. A concrete example is a three-year long Agile embedded project studied in Europe, where the Agile project team out-performed 95th percentile “top” waterfall development teams7.

Working Both Together: What It Looks Like 

The exploration required at the beginning of each Agile project is the perfect time to divide responsibilities between software and hardware development teams and to define the processes (Scrum or CBPM) to be used by each. As the system is architected, with its subsystems, and the interfaces for communication between hardware and software are defined, the decision whether to use an emulator, or other approaches for testing are made.

The goal is concurrent work, with hardware creating components, and software developing and testing, at times independently of the hardware at first, and then on the hardware components as they are developed. This requires a large amount of collaboration between engineering, design, developers and Product Owners (who provide feedback). As Stories are implemented, first in smaller ‘chunks” or subsystems/modules, and then with larger, more integrated parts of the whole, the system design will begin to evolve, and to incorporate Product Owner and user feedback into the design.

Daily Scrum meetings help facilitate communication among software team members. Once the Sprint is completed, a Sprint retrospective helps to identify what went right, what didn’t, and how to improve things during the next Sprint. Meanwhile, the hardware teams are using performance against commitment to communicate progress, as well as regular team meetings and “map days” to create project commitments8.

When working on a hybrid project, such as hardware/software, it is important to realize that the processes will be different for each. Hardware will more naturally fall into a waterfall type process, while software will fit into a Scrum methodology. Constraint-based Planning will identify the critical milestones in one project, on which the other depends, and plans the latter around the former9. If the software is ready well ahead of the hardware (which is common), the development team can continue to develop new features until the hardware is ready, and then deploy and test the software on the hardware as it becomes ready.

hybrid project

Hybrid Project Example

cPrime: Challenges Met, and Benefits Enjoyed

cPrime has worked with numerous clients in a combined software and hardware production environment. “We’ve seen the best results when management supports the transition to Agile,” says Dr.Thompson. “All transitions to a new process involve issues, and you need to plan carefully to execute the transition itself.”

This is why when helping companies go Agile, cPrime consultants first meet with key decision-makers, to clarify exactly how the transition should occur, with agreement among all parties. The basis of the initial transition plan is an Agile assessment. Then, team members are defined, including cPrime Scrum and Agile experts who have helped firms that employ hardware and software technologies make extremely successful transitions.

Our firm has found that a phased approach to transition, with small changes that reflect a focus on implementing Agile methods that bring the greatest return first, works best. Staff are taught by on-site consultants how to create user Stories and define “done” for Scrum; or in using maps to define delivery dates, and user feedback as criteria for done with hardware development.

“cPrime offers the companies we work with the benefit of the fact that we understand how things are supports to work,” says Thompson. “We’ve done coaching in transitions, and have worked with companies that have hardware/software networking devices.” The result is improved velocity, improved morale, and improved customer satisfaction.

To learn more about cPrime’s Enterprise Agile Transformation solutions. Contact us at learn@cprime.com.

Sources

  1. Punkka, Timo. “Agile Methods and Firmware Development,” paper for the Helsinki University of Technology, Software Business and Engineering Institute
  2. ibid
  3. Michael J. Karlesky, William I. Bereza, and Carl B. Erickson, PhD. “Effective Test Driven Development for Embedded Software,” April 2006.
  4. Punkka, Timo. “Agile Methods and Firmware Development,” paper for the Helsinki University of Technology, Software Business and Engineering Institute
  5. Esque, Timm J. “Commitment-based Project Management,” available online at  http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
  6. Michael J. Karlesky, William I. Bereza, and Carl B. Erickson, PhD. “Effective Test Driven Development for Embedded Software,” April 2006.
  7. Abrahamsson. Information Technology for European Advancement (ITEA) Innovation Report, “Speeding up embedded software development.”
  8. Esque, Timm J. “Commitment-based Project Management,” available online at  http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
  9.   Thompson, Kevin, “Scrum in the Enterprise: How to Manage the Common Issues of Scrum Projects,”

http://www.cprime.com/articles/Scrum-in-the-enterprise.html

Agile: a Prescription for Improved Healthcare Technology and Delivery

Posted on by
Reply

Overview: New Healthcare Technologies Bring New IT and Development Challenges

The face of healthcare technology is evolving rapidly, with healthcare organizations moving to virtual platforms and mobile (mHealth) technologies to support healthcare delivery and operations. “Telemetry” is no longer confined to an inpatient unit, with Smartphone apps available that can send patient vital signs, ECGs and other information via wireless signals from home to hospital or clinic. Health records are moving towards digitalization, and the software that supports healthcare delivery has become increasingly complex.

The need for healthcare to be able to respond in a timely manner to development that supports clinical decision-making, care delivery and administration in the midst of new environments, while maintaining compliance with regulatory agencies, has become critical. Agile methodologies offer solutions to many of these industry challenges.

ICD-10 Compliance and Healthcare IT Concerns

In order to make the transition to ICD-10 mandated by October 1, 2013, healthcare organizations and providers must verify all business processes, data stores, applications and reports impacted by the change to ICD-10 diagnostic and procedure codes, and allow drill-down to the new diagnostic categories. This task will require verifying current ICD-9 codes maintained within the application logic for supporting business systems.

IT Departments are struggling to define the technical specifications that will guide in-house development and remediation, which requires a large amount of collaboration with administrative and business managers1. Scrum practices make absolute sense in this scenario, since they are designed to increase communication between ‘business” and “development” and can improve the project management and velocity for achieving this task.

One issue surrounding this transition is the use of conversions to deal with ICD-10. Jim Schiel, a cPrime Agile Instructor and Coach, states, “Numerous organizations are taking a ‘crosswalk’ approach,” They are taking the code and information they already have, and converting it over to ICD-10. The challenge is defining at the beginning of this process exactly what data an organization will need. With agile, as the conversion takes place, they can take the original definitions for data required, and refine them as they talk with the customer, to reflect the specific challenges that their organization faces for data collection – and, implement this quickly. This is much better than waiting the six months or longer that waterfall would require.”

Healthcare Business Data Mining and Agile

Data mining and the resulting health analytics and business intelligence have become an important source of information in an industry driven by evidenced-based practice, where treatment is based upon proven value. In addition, insurance providers must demonstrate improved medical loss ratios. This requires improved data sharing between healthcare researchers, providers and insurers, and the development of systems that support clinical decisions and practices within patient populations.

Agile development can help solve these challenges. It allows the rapid delivery of information, and the ability to quickly redefine what needs to be developed next in response to data received. Agile Data Warehousing and governance have become preferred methods for data development for this purpose2.

The Advantages of Agile for Medical device manufacturers

In the past, companies that develop medical devices were slow to adopt agile. “They will sometimes ask, ‘How can you deliver quality software with agile?’” says Schiel, “or even, ‘the FDA won’t possibly allow that. This has been a barrier to adoption, even though the advantages of agile are being seen.”

Companies that develop medical devices used by healthcare organizations often would like to reduce the lengthy time to market that traditional waterfall methodologies impose, and struggle to see how agile can work in an industry that must comply with FDA, IEC, HIPAA, and other regulations for data security, reliability, specification, quality and design controls.

Agile development offers significant benefits to medical device manufacturers. These include:

  1. The pace of overall development is improved
  2. The ability to incorporate user and stakeholder feedback early in the development cycle helps ensure that a successful product is built with the features that reflect current business needs. Agile allows suggestions to be added in earlier instead of later, when changes are more costly. This is a huge improvement over waterfall methods, where initial requirements analysis and then development can cause a gap of years between initial request for software, and the final delivery, creating “feature creep” in order to bring the product up to date. “In healthcare, things change quickly and the information environment is extremely complex,” says Schiel. “Healthcare providers often don’t know exactly what they need, until you start building; or, until they get hit by a circumstance they hadn’t foreseen, and realize that they need an additional feature to deal with it. Waterfall doesn’twork at all well in this type of situation, while agile allows the flexibility to make these needed changes and updates during development.”
  3. Development with agile is more transparent, with working features that can be demonstrated in a deployment context at the end of each sprint. Stakeholders can see visible proof of project progress, and initial testing done.

Risk management is a large, and understandable, concern, when developing devices that can impact patient outcomes. Scrum practices are designed to allow early identification of risks. To meet quality assurance and management goals, the integrated, continuous testing that is core to the agile process (causing high-quality software development as the standard) is often supplemented with specific controls and more frequent review cycles.

The key during the planning phase for agile implementation is to identify the documents required for regulatory compliance, and evidence which must be submitted. This includes evidence that the design and development of the device follow Quality System Regulations as defined in the FDA’s “The Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices3,” with formal review and approval processes in place as defined by the FDA.

In practice, agile has been implemented by numerous well-known medical device manufacturers, including Abbott Laboratories, which reported schedule and team reductions of 20%-30%, cost savings of 35% – 50%, and fewer software defects after going agile4. Metronic reported that after implementing agile practices, their development teams found that work was more enjoyable, they worked better together, found bugs earlier, and felt they achieved higher quality5.

GE Healthcare implemented agile within GE Healthcare Imaging Solutions. The results were so successful, it led Andrew Deitsch, VP and General manager for GE Healthcare IT’s Imaging Solutions, and Ross Hughes, GE Healthcare IT’s Scrum Master to state, “We feel that the benefits so far of our agile adoption are worth the effort. We’re now beginning the next phase of our transition by rolling out scrum globally to the rest of GE Healthcare6.”

Schiel sees specific advantage of agile adoption by medical device manufacturers: “They often deal with how to combine hardware development and software development, and get the two schedules to come together well,” he says. He notes that the key is to plan out the hardware approach, and then start the software development after the hardware is coming along well. He states, “The great advantage of agile is that it lets you incrementally test working software on the hardware – and know if it’s working, early on. With waterfall, you have to ‘hope’ that both will come together in the right way, but it’s really a matter of luck if you can’t test the software on the actual hardware. The bottom line: If testing isn’t done often enough, software goes out doing unexpected stuff – and agile can prevent this from happening. It can actually make the medical device arena even safer, if done correctly.”

Healthcare IT Departments: Going Agile to Reduce Time & Cost

In recent years, healthcare IT management has looked closely at whether agile can help solve some of its major challenges. These include overcoming the limitations of legacy systems, finding universal development tools, increased lifecycle transparency, and improved collaboration among distributed teams and between developers and product owners. The pressure has been on to reduce development time for business and clinical support systems, without sacrificing quality and reliability, while maintaining secure data exchange between organizations.

Another challenge faced by healthcare organizations is the initiative to adopt electronic health records.  Medicare and Medicaid incentive programs have helped, with hospital adoption rates of basic EHR rising from 11.5% to 18% between 2010 and 20117. Making the transition to electronic records requires significant data entry and implementation tasks (such as developing software patches to allow EHR software with different standards to communicate with each other).

One problem that healthcare organizations face is that currently, no one is really certain yet what EHR will look like in practice. “A lot of healthcare organizations know they will need to move to electronic health records and electronic medical records,” says Schiel, “but they aren’t sure yet of all the benefits they will get from it. That’s where agile works well. Using agile, you can say, ‘Let’s start with what we know, and when we identify something more valuable, we can go there.”

This flexibility of agile is a big advantage, especially since at this time, the government regulations regarding security, privacy and how access to EHR will be maintained has yet to be fully defined. If regulations change, agile will allow development to meet these requirements much more easily than waterfall methods would.

Going Agile for Healthcare: How cPrime Helps the Transition

When a healthcare organization that is highly regulated decides to go agile, they must adapt the process to their environment. At cPrime, we address the challenges of changing organizational structure to reflect Scrum and agile teamwork.

Agile Assessment and Planning: Critical to Success

cPrime first conducts an initial assessment of the organization, its culture, and unique pain points. The goal is to adapt agile methodologies to the organization’s unique needs. We meet with management, developers, and quality and regulatory teams, in order to help them understand how agile can work with quality management systems and regulatory requirements.

Planning phase,

The initial planning phase for the transition to agile is critical. At cPrime, we believe in implementing agile with small changes that deliver the greatest value, first. In practice, this will often mean initiating pilot projects within an organization, with the initial teams undergoing classroom training, which includes hands-on practice in using scrum and agile tools, prior to starting the first sprint.

Scrum teams are defined, as Scrum masters, Product Owners and team members are designated. This can include engineers, RA/QA, design, materials, and other departments, in a cross-functional team dedicated to developing the product together. Each member undergoes the training and mentoring necessary to successfully fulfilling their role.

cPrime team members, which includes trainers, coaches and Scrum experts are on site to ensure that the transition goes smoothly.

During planning, an agile lifecycle management (ALM) tool is selected, such as Rally, GreenHopper (JIRA) or VersionOne. cPrime provides classroom training that includes hands-on exercises with real-life scenarios to equip team members. Additional tracking tools designed to follow and validate development throughout the lifecycle, with review and signatures obtained in order to comply with regulatory requirements, may also be selected.

Implementation of Agile: The Pilot Projects

Once a pilot project is begun, the transition to agile is modeled, including how to conduct Scrum meetings. These 15-minute daily meetings look at:

  • What problems are being encountered (that can cause “drag” and reduce team velocity)
  • What is currently being done
  • What needs to be done (priorities for the day)

Scrum meetings improve collaboration and allow more cohesive working together. The goal is to identify ways to improve workflow, and to address any problems.

cPrime provides healthcare clients with Scrum and sprint templates, which are customized to show process compliance for regulatory agencies. Documentation and organizational quality standards, which were defined during planning, are now maintained during pilot projects.

Initial training for Product Owners and Scum Masters in their roles is done, with practical practice in

  • Defining user stories to capture requirements: Product owners meet with clients/stakeholders to learn the features they want, what the finished development must be able to do, and to define FDA or other regulatory requirements, if applicable.
  • Any additional quality process/regulatory steps that must be completed before story acceptance
  • How to refine stories, assign points and priorities and create the Product backlog. Training is provided in how to update the backlog as new features are requested.
  • How to enter tasks into the sprint backlog.

The shorter iterations (sprints) in agile require specific training in estimating hours instead of days for team members. But over time, these shorter lengths allow much more accurate estimates of time and resources, which in turn reduce project risks and cost overruns.

Sprint Planning meetings between the PO and the Team are first modeled by cPrime during the transition to agile, then mentored, as the teams become increasingly familiar with and finally independent.

Development Teams

During implementation, the cross-functional teams learn how to develop the highest priority items during a sprint (normally, these last two to four 4 weeks). Daily scrum meetings are first modeled by cPrime staff, then mentored. These short (15 minute) meetings allow team members to identify any issues that could create “drag” and reduce velocity, and prioritize their work for that day.  A Burndown chart in the “War Room” (where Scrum meetings are held) shows visibly the progress to date on the sprint backlog.

Sprint reviews and retrospectives are mentored, when the team shows management and stakeholders the result of the sprint. This allows feedback between stakeholders, product owners and team members, to improve communication and support collaboration and engagement. Suggestions for improvement are then taken into the next sprint.

The goal during agile implementation is to improve not only velocity, but improve total software quality, and promote greater stakeholder/user satisfaction with the end product.

Improved Productivity for Healthcare Software Developer Directly Related to Agile Implementation

iSirona offers a software-based solution that moves device data from medical devices into EMRs. The company’s software was developed in accordance with the FDA’s quality system regulation controls.

Before iSirona implemented agile, they had a very formal waterfall development process. However, waterfall methods were causing delays in shipping products out to customers. cPrime came onsite, assessed their environment, and recommended changes that would offer the greatest value and would work within their corporate environment.

We conducted Scrum training, and coached/mentored teams through early Sprints, as discussed above. As the iSirona teams became familiar with using Scrum and agile methodologies, they became independent and began to enjoy the benefits of agile methodologies, while maintaining regulatory compliance. The result: after implementing agile, team members were able to develop and deliver products on a timely basis, and their desired production goals were achieved.

Choosing to adopt agile and Scrum methodologies is helping numerous healthcare organizations and medical device manufacturers enjoy improved productivity, improved quality, and better support for healthcare delivery.

Sources:

  1. Natale, Carl. “Healthcare IT faces unspecified challenges in ICD-10 implementation.” Government HealthIT, 6/1/2012; article online at http://www.govhealthit.com/blog/healthcare-it-faces-unspecified-challenges-icd-10-implementation
  2. Roney, Kathleen. “5 Differences Between Static Data Warehouse Design & Agile Data Governance;” Becker Hospital Review. 1/31/12. http://www.beckershospitalreview.com/healthcare-information-technology/5-differences-between-static-data-warehouse-design-a-agile-data-governance.html
  3. “U.S. Food and Drug Administration publication, “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices,” 5/11/2005. Available online at http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm089543.htm
  4. Abbott Laboratories. “Moving to Agile in an FDA Environment; An Experience Report.” Presentation given at Agile Alliance 2009 conference on August 27, 2009.  Available online at http://c-spin.net/2009/cspin200909Agile_In_Regulated_Experience_Report.ppt
  5. Spence, Jon. “There Has to Be a Better Way.” Publication from Proceedings of the Agile Development Conference (ADC) 2005. Available online at http://www.researchgate.net/publication/4231042_There_has_to_be_a_better_way!_software_development
  6. Deitsch, Andrew; Hughes, Ross. “GE Healthcare Goes Agile: Imaging Unit Takes Control of Its Development Environment and Likes the Results.” Dr. Dobbs online, 12/06/2010. Article online at http://www.drdobbs.com/architecture-and-design/228300298.
  7. Leonard, Devin; Tozzi, John. “Why Don’t More Hospitals Use Electronic Health Records?” Bloomberg Businessweek article, 6/21/2012.
  8. Robert Wood Johnson Foundation; Mathematica Policy Research; Harvard School of Public Health report. “Health Information Technology in the United States: Driving Toward Delivery System Change 2012.” http://www.rwjf.org/files/research/74262.5822.hit.full.rpt.final.041612.pdf

Agile + Your Game Development Team = A Reduced Sales Cycle

Posted on by
Reply

How cPrime Helps Gaming Companies Go Agile

Learn how cPrime can help your game development team adopt Agile – Contact Us Now!

Today, firms that develop games face ever-changing technologies and complex engineering requirements that can require development by teams composed of hundreds of members. Game players are highly sophisticated consumers whose demands for realism and “fun” have risen yearly. Marketing campaigns announce launch dates that must be met, with competition to push these dates earlier. The combination of these factors has caused game development costs to rise exponentially over the past decade.  For instance, in 2009 the average cost of production for a multi-platform game was $18 -$28 million from initial concept to gold master1 – and with this kind of investment, games must be able to generate significant revenues.

With increased game complexity, and the need to reach deadlines, crunch time is now measured in months instead of weeks at some firms. This and other issues have caused game development company managers to look for ways to improve the development and production processes to get high-quality code and game assets created more quickly. And this is where Agile for game development has been found to achieve these goals.

Why Go Agile? The Advantages During Game Development

During Design and Pre-production

Today, even a good game proposal alone is not enough for risk-wary publishers, who want to see a working prototype that will prove the game concept. Agile methodologies allow the rapid development of prototypes that help stakeholders determine whether a game concept will sell – or fail – in today’s competitive marketplace before committing to production.

Agile allows rapid prototype build throughout game production, making it easier to identify the highest value features and refine the game concept based on actual play.

During pre-production, Scrum (the project management framework for Agile methodologies our firm prefers) is an excellent method for the pre-production task of creating a reliable game production plan. It lets stakeholders (product owners) identify and communicate the game features they want developed, and to prioritize the ones they want developed first.

With Agile, project managers (scrum masters) then break the game development down into working features that can be built within a pre-set time frame (called a sprint, which is normally 2 weeks). Agile/Scrum lets PMs more accurately perform the pre-production planning of schedules, budgets and task estimation. The requirements for each sprint are entered as tasks into the backlog, and assigned priority. Because production plans are based upon 2 week sprints, and team resources are measured in hours instead of days, the final pre-production plan is a more realistic estimate of the team resources and hours required to meet game development goals. This provides management with a more accurate idea of exactly how much it will cost to design and develop each game feature.

Because Agile de-emphasizes extensive documentation in favor of actual development of working components, it allows the game to more quickly enter actual production, and for the production phase to move more rapidly.

During Game Production

Scrum promotes better collaboration among team members. This is important during the development of a multi-feature, multi-player game, where art, 3D graphics modelers, engineers, AI programmers, level designers and others must all work together to create the time-consuming first level, and then throughout the game development process. In-house and game-specific tools (such as asset conversion tools) must be developed to supplement CodeWarrier, Visual Studio or other development environments – and doing so requires team collaboration and input.

If a game development company uses distributed teams, agile allows greater flexibility and coordination of work between the teams. Coray Seifert at Slingo has even credited agile with saving game production after a fire at their New Jersey office caused their co-located teams to go remote. By using agile practices, the teams still maintained landmark output while working offsite3.

During game production, Agile methodologies let production teams get player and stakeholder feedback faster. Instead of waiting until a major milestone, such as first play, alpha, or beta release to see if everything works, Agile breaks down development into the most important features being developed first, with an actually playable version that is continuously refined.  The working components produced allow the lead game programmers to provide stakeholders with a more transparent view of the milestones achieved, than simply reading documentation.

The playable components completed at the end of each sprint also make it easier to detect design defects and bugs, and fix them from the earliest stages of game development. Earlier fixes translate into a better game design, improved production, and lowered costs.

During Game Testing

Agile enforces integrated testing, or continuous integration, of the source code produced for the game. If a character in a game explodes or dies when a certain action is taken, that isn’t part of the game design, developers will know early in the development cycle, when it is easier (and less costly) to make changes.  Instead of extensive documentation, agile places a greater emphasis on implementation and testing of code during game development.  Because the code is tested early on, it is more reliable, which helps greatly if it is reused, or used to extend a game engine.

This code reliability also helps reduce the time that must be spent on QA testing for the first-playable alpha or later game releases.

Agile can reduce the time to market for game features significantly. Because pre-marketing and consumer expectations makes meeting launch dates so critical, this feature alone makes going Agile attractive to game companies.  For instance, former Valve designer Kim Swift noted that going Agile significantly reduced the time before release for Left 4 Dead 2 when compared to the first version (when traditional methodologies were used). She said, “Since we knew that our shipping date was a lot sooner, we were able to sort out which ideas were actually doable in that amount of time, and that we knew were actually going to be successful, rather than trying a whole bunch of different stuff that wasn’t necessarily going to be what we shipped.”4

During Game Maintenance

Finally, Agile allows for rapid patch development during the maintenance phase. Instead of months, patch development can be reduced to days or weeks.

The Process of Transitioning to Agile: Making It Easier

Once a game development company becomes convinced of the value of moving to an Agile methodology, the next step is planning how the move can occur as smoothly as possible. The goal is to avoid transition problems which can be due to:

  • Inadequate planning
  • Inadequate practical training
  • Trying to change too rapidly

At cPrime, we believe that big changes are slow, risky and expensive, so we focus on quick changes that bring quick results from the start.

Assessment and Planning

When helping a company go Agile, we first meet with key decision-makers and stakeholders, to clarify exactly how the transition should occur, with agreement among all parties. We then complete an initial Agile assessment.

The assessment helps us understand the company’s pain, business goals, and to create a plan to ensure that the transition planned works with its production culture, and aligns with these goals.  Team members are also defined during this time.

Scaling Agile Adoption

As part of the plan, we also organize into measurable tasks how Agile will be adopted by the game development studio, to scale transition efforts with a company’s desired schedule. For instance, a studio may have numerous levels within its infrastructure, and require collaboration among disciplines (including distributed teams) if the transition to Agile is to be successful.

Selecting Tools

The game development company is assisted with selecting Agile Lifecycle Management (ALM) tools, such as GreenHopper (JIRA), VersionOne, or Rally. Once a tool is selected, we provide classroom training that incorporates hands-on exercises with real-life scenarios to train students in how to use the ALM tool to define requirements, plan their work, and track progress, using it to best effectiveness.  Project managers/Scrum masters will learn to use the tool to estimate the team’s net resource in points.

We then recommend phases for implementing Agile that will reduce the risk.  Our solution architect presents to stakeholders the results of the assessment, and recommends the best way to start adopting Agile (and discusses any challenges the company will face during this process).

Transition Phase: Actually Going Agile

Once the game company starts transitioning, cPrime is on-site to offer expert advice and mentoring. The Agile consultants and coaches model Scrum, by acting as Product Owners for the transition process to team members. They maintain the transition backlog, and provide guidance to the transition team members.

At cPrime, we believe that a hybrid methodology is an important part of a successful transition. The way this will look will vary with the game development firm’s environment. For instance, art and design may move to a Kanban framework, while development and engineering move immediately to Scrum.

The goal is to provide a phased approach to transition, without leaving the major players (the studio teams and management) wondering what to do next, or how to actually do it.  This is why our consultants define the Scrum process to be followed by both managers and Scrum Teams, train the teams, and mentor them in order to help reduce the fear and resistance that can often accompany change.

Execution: Here’s a look at how it works, practically. 

Production Teams

After the initial training in Agile and Scrum concepts, principles and roles,  staff are taught how to plan and track for each sprint and  each milestone (such as first play, alpha, and beta releases).

Training is provided in User Stories, and how to define “done” through acceptance criteria and project standards. Using and managing the sprint backlog, and prioritizing tasks are also taught in hands-on exercises, until the team members and scrum masters become comfortable with doing each.

Management

Management is taught how to use Agile for maximum effectiveness and productivity from their internal teams. This includes training in how to interpret reports and various metrics, risk analysis, and market timing and release strategies.  Product owners are shown how to record product requirements as user stories that scrum masters/team leaders can then translate into points and sprint backlog items.  They learn how to customize story templates that we provide to their game and development requirements, and how to prioritize stories and defects to maximize the value returned from their internal teams during production.

Scrum Master

Scrum Masters have one over-riding goal: to facilitate their team’s ability to deliver a quality product that has the features that the Product Owner has asked for.  We offer practical training in reaching this goal, including training in managing backlogs, metrics, and updating estimates.  Scrum masters learn how to gather data to determine velocity, and how to hold Scrum meetings (such as “inspect and adapt”).

Quality assurance tasks are defined, and practical, hands-on training is provided in Agile quality assurance practices, including working with Defects, and creating and managing tests.

System Administrators are taught how to set up projects, add users and teams, assign permissions, and other tasks.

The use of Agile methodologies is first modeled, then mentored. Over time, the mentor’s help is required less and less, as the teams become fully independent.  Often, team members start trusting each other more, and departmental divisions become less pronounced, as cross-disciplinary teams begin working together. It isn’t unusual for companies that start transitioning to see progress (and increased velocity) in a very short time. By the time three to six sprints have occurred, the company is usually fully transitioned, and enjoying the flexibility and reduced sales cycle that an Agile methodology brings.

Maintenance

During the maintenance phase of transition, we offer any ongoing needed support for the new Scrum Teams. These Teams should be able to function on their own in general, but will often encounter new situations for which expert advice will be helpful. During the maintenance phase, cPrime provides support by phone conference or email as needed, to address such issues when they arise.

The Result

By implementing these processes, our clients have enjoyed faster velocity.  The feedback has been tremendously positive, since the firms that go Agile are able to respond much more quickly to customer requests.

Firms we have worked with have noted that we are “less theoretical” and much more “hands on” and practical than other consultancies they have worked with.  This has enabled a successful transition, since team members knew from the start what their new roles would be, and had the support to fulfill them.

The greatest result? The companies we work with have enjoyed greater velocity, with less drag. This translates into reaching launch date goals more predictably, with less crunch time required. The flexibility of Agile has allowed them to develop prototypes more rapidly, and respond to publisher and player feedback much more quickly, for a higher quality product, and a reduced time-to-market.

Learn how cPrime can help your game development team adopt Agile – Contact Us Now!

Sources:

  1. Meloni, Wanda. “The Brief: 2009 Ups and Downs,” M2 Research Industry Analysis online at  http://www.m2research.com/the-brief-2009-ups-and-downs.htm
  2. eMarketer: “Mobile, Social Boost Online Gaming Populations,” June 7, 2012
  3. GDC 2012 conference, “Out of the Fire and Into the Surprisingly Agile Remote Development Environment.” Speaker Seifert, Coray.
  4. Nutt, Christian. “Q&A: Valve’s Swift On Left 4 Dead 2′s Production, AI Boost,” interview for Gamasutra, 11/12/2009 http://www.gamasutra.com/view/news/25701/QA_Valves_Swift_On_Left_4_Dead_2s_Production_AI_Boost.php

Agility Cocktail Hour – LA MeetUp

Posted on by
Reply

Last Night’s Agility Cocktail Hour —

Jeff Howey, cPrime’s Agile Coach, presented at the first LA Agile MeetUp at Ozumo Restaurant in Santa Monica. We had about 30 guests in an intimate room with saki, beer and Japanese appetizers. Attendees listened to Jeff’s presentation on why Agile is gaining momentum in software development communities. He spoke about how to uncover the about the Scrum and Kanban frameworks, where they fit, how they work and how they differ. He explained how to define metrics and goals that measure successful project delivery and team performance.

We asked people at the beginning of the session to write responses to two questions we have: Why they attended the meet up and what are their challenges in their companies?

A few attendees answers below:

Why You Came?

  • “learn about Kanban”
  • “finding a scrum master role”
  • “meet other people who work in Agile software development environments”
  • “we’re here to meet other agile practitioners and build a network to turn to with questions
  • “meet other scrum masters and share challenges and find a coach!”
  • “to learn more!”
  • “meet other people and hear good ideas”
  • “professional networking”
  • “learn more about agile and scrum!”

What Are Your Challenges?

  • “managing infrastructure projects and story estimation”
  • “scrum meetings not turning into status meetings”
  • “incorporating agile practices into matrixed support/infrastructure departments”
  • “how agile is being used at different companies and the challenges and you over come them”
  • “how to know if Im doing agile right”
  • “implementing a PMO for CRM”
  • “convincing clients to use agile / scrum”
  • how quickly ramp up new team members with in scrum context”
  • “incorporating UX people into scrum teams and work flows”
  • “scrum is too popular! and they want me to implement for every department”
  • “finding the right people to train as scrum masters”

To get your questions answered, come to our next LA Agile Meet Up! http://www.meetup.com/LA-Agile-MeetUp/

I would like to thank everyone who joined us!! A special thank you to Jeff who gave a spectacular presentation on understanding Agile and it’s momentum in the software communities. Ozumo’s food and drinks were delicious and the accommodations were remarkable. We are excited for more La Agile Meet Ups to come! We had more guests than expected and the excitement in the room was definitely felt.

Set Up:

The Beginning!

 

Agile, Saki, Beer and yummy food!