Tuesday, August 31, 2010

What I Learned at the AGILE 2010 Conference

Posted on behalf of Harsh Sabikhi,
Customer Solutions Engineer, MKS Inc.

Day 3 - Thursday, August 12th

Today I concentrated on learning more about Kanban, Scrum, and how it scales to large organizations. I truly believe Kanban is the next "buzz" or "flavor" in the developer community. I have been thinking of how to extend our current Agile solution to support Kanban. From a metrics standpoint, we can easily add support.

I also attended a session on managing your requirements separate from your user stories. I got a few ideas that I will prototype. The authors were suggesting a maturity model for requirements and only those that are fully scoped should turn into backlog items.

Day 2 - Wednesday, August 11th

General Observation
Most of the people here including the purist are very anti-tooling for some things. They look at tools as a nice to have. The interaction of a whiteboard leads to team collaboration hence better Agile teams. This is why Rally's of the world provide interactive storyboards. But some purists still think this is "fluff".

I had a conversation the Marketing Manager at Hansoft. They have a product very similar to ours which is a platform rather than a solution. Hansoft's value proposition is similar to ours as well: they can manage both Agile, Waterfall, lean, and Kanban projects. What they lack is a version control, and full RM capabilities. They integrate with CVS, perforce, and Subversion.

I met with a Corporate Account Manager based in Atlanta. They recently went to a SaaS model for trials and small customers only. I have briefly talked about this internally but we should seriously look at this and come up with a strategy. I think majority of the Agile vendors have a free trial/eval and we should consider this.

AppFolio Inc. - based in Santa Barbara, CA.
Met with the Scrum Master at AppFolio. They have a team of 20 developers. They are primarily using Excel.

Sessions for today:
Lean and Agile - This was a panel discussion about how to use Lean principles within Agile. The experts all agreed and said Agile is a subset of Lean. What was great and something we should look at developing are "Lean" type metrics. For example, Cycle Time - how long does it take to deliver a feature and not just a User Story in a time-boxed iteration? Management can see and track at the feature level and commit to their end customers on a timeline. Along the metrics conversation, testing was mentioned again.

Managing your product backlog
This session was okay. They just talked about visualizing your backlog and using charts such as priority (x-axis) and cost (y-axis) both measured in story points. The key here was that there are different patterns of shifting priorities.

Portfolio Management
In this session they talked about different allocations of products (New, Now, and Platform) and how we should use different techniques for each. New should use Agile, Now should use Lean and Platform should use Kanban. In addition, sustaining projects should use Lean because you want to deliver slight more value but also manage risk and resources.

Agile Program Management
This session was not what I expected. We did a simulation and created a basket and flowers! The goal was to show multiple project teams working from different backlogs towards a single Program initiative.

Day 1 - Tuesday, August 10th

Meetings for today:
I met with the Offshore Principle from Thoughtworks during my last session of the day. We exchanged business cards and I gave him some collateral on our solution. Thoughtworks is an IT consulting organization.

At the end of the day, I also met with an Analyst from VDC Research. I gave him an overview of Integrity and our platform. Also told him the competitive advantages of our Agile solution and gave him a brief demo. VDC would like MKS to sponsor their "Software & System Lifecycle Management Tools" research.

9 AM - Agile 2010 Keynote session with Dave Thomas
  • There was a lot of talk around Test Driven Development and Continuous Integration. In general, he was anti-tooling. I have been thinking about this for a while as well and would like to understand where we stand with this especially CI. It will be beneficial for us in the field to have great examples of an integration with Hudson for example.

  • Dave talked about Sprint 0 which is a learning sprint for a new Agile team. RBC called this out in their process framework document as well.

  • Learned teams should plan at only 80% of their capacity during Sprint Planning

  • Learned Lean is a top down process whereas, Agile is a bottom up.

  • Cumulative Flow Diagrams are being used by a lot of end customers now because this gives them a full end-to-end trend analysis on all system artifacts (Time spent on User Stories, remaining effort on tasks, defects, etc). They typically do this by exporting to Excel. I don't think we can do this in Integrity anytime soon so I have an idea for this. Basically utilize our Export to Excel.

  • Learned an interesting concept that feature backlog is measured in business values whereas, a component backlog is measured in feature values.
11:00 AM - Upstream Kanban session
  • Kanban is quantitative workflow management. It is about mapping the "value stream". It is similar to Agile but encompasses high-level managers in the organization to work in a single team.

  • Kanban uses an interactive story/task board just like scrum with a few changes. Each stage has a "Work In Progress" limit. Kanban limits the amount of work that can be pulled in from upstream marketing organizations to development because it uses a "pull" method.

  • Advantage is this interactive board is visible to marketing which has a downstream view on the activities R&D is working on and vice versa.

  • Advantage of Kanban is also executives get a report that shows how many calendar days a feature will take from SLA t o Production.
1:30 PM - Lean Pyramid
  • Lean principles - deliver a continuous flow of value to the end customer. Create a learning organization and a continuous improving organization.

  • Lean is about communicating the "vision" from the key stakeholders in the form of requirements or Epics down to User Stories in R&D.

  • Learned an interesting concept of categorizing user stories in a "Canoe Analysis".

  • Talked about WIP again and got me thinking how we can do this in Integrity.

  • A "Cleaner" role might be needed for cross-team collaboration. The "Cleaners" role is just to re-factor component code.

  • TDD was mentioned again and so were CFD.
3:30 PM - Agile in distributed environment
  • This was more of a hands-on technical session. Not what I was expecting.

  • We spent an hour talking about "Development practices" such as XP, TDD, FDD and how they scale to distributed teams. What the challenges are and how to overcome them.

  • We also learned the difference between Distributed Teams and Dispersed teams.
Plan for the rest of the week will be for me to concentrate on "Business" tracks. This is the first time I have attended, so I am learning to focus on each track. I think the business track will help me with the industry trends and how other organizations are doing things. This can then help us shape our product for the future.

Visit MKS to see our solution for the Agile environment.

Monday, August 23, 2010

The Cost of Compliance

It seems that every industry today is plagued with a growing mound of compliance related red tape. According to Jorge Lopez of Gartner Research, "Over the last few years...budgets that were dedicated to dealing with regulations were rising at a rate that was twice as fast as the IT budgets." This coupled with economic pressures to do more with less people is quite overwhelming to many organizations. For this article we will focus on the automotive industry and the medical device industry, but similar challenges exist in many other industries. Specifically, we will look at the challenges they face and how automation plays a significant role in enabling organizations to overcome these obstacles.

Compliance in the Automotive Industry
You need not know much about the automotive industry to know that the economy has taken a severe toll on most if not all global automotive manufacturers. In addition, there have been several high profile safety recalls in recent years as well that have impacted all manufacturers. Many in the industry suggest that the complexity of the modern automobile has much to do with the inability of most manufacturers to control quality and safety to the highest levels. In fact, the next generation S-Class Mercedes is reported to have in excess of 100 Million lines of software code embedded in the various systems that control almost every aspect of the vehicle. This is astounding considering most cars were just topping a million lines of code just a few years ago.

The result of these challenges and recognized complexity is the introduction of much more stringent functional safety requirements in the new ISO 26262 regulations that move into full force in 2011. These types of compliance standards are not really new as ISO 26262 is derived from the IEC 61508 which is related to FAA DO-178b and other standards, but nonetheless complying with these standards is no trivial matter and will undoubted cost the automotive industry $100s of millions if not into the billions of dollars.

In preparation, most auto OEMs and suppliers are looking to technology partners such as MKS to supply them with solutions that are more cost and time effective in proving compliance. These systems must include the following capabilities, just to name a few:
  • Manage all engineering assets from requirements and design at the front end to final validation and verification test procedures and results with many other assets in between.

  • Manage end to end traceability of these assets such that they can show that each and every requirement has been validated as well as traceability from requirements down into the code.

  • Manage all identified risks and clearly show mitigation of these risks by the appropriate requirements using some system such as FMEA.

  • Manage all relevant metadata such as Calibration Data as part of the solution.

  • Ensure strict change management procedures are adhered to across all lifecycle assets

  • Automate and enforce compliance requirements for model driven development (MDD) providing trace through model support.

  • The solution should be certified by TUV or some similar compliance certification organization to ensure compliance of the solution.

Current tools in place for most automotive companies are just not adequate to handle these requirements as most have complex networks of disparate tools and repositories with brittle integrations that cannot provide the end to end traceability, visibility, and reporting required to show compliance. If they could make current systems work, the solutions would be both cost and time prohibitive.

Compliance in the Medical Device Industry
Although not as conspicuous, the medical device industry is under very similar constraints and challenges with tough FDA and EU regulations. Recalls and regulatory compliance pressure for medical devices, especially for Class 1 and 2 device manufacturers, can be extremely costly and time consuming. One recent company we worked with cited 6 weeks of effort for a team of resources had to be tacked on to the end of the development process exclusively for preparing documentation, reports, and trace information to ensure compliance for an FDA 510K submission.

According to one source, the FDA has doubled and maybe tripled the number of inspectors just during the Obama administration. These medical device companies are feeling the pain of compliance using the manual and disparate systems most currently have in place. The costs for manually managing compliance is well in to the millions of dollars annually for many, but the threat of non-compliance or safety related recalls using these error prone systems is actually much greater. This is forcing many into searching for a more automated and comprehensive solution.

An automated platform that would ensure cost effective compliance with these rigorous requirements would need to employ an analogous set of capabilities including:
  • Rigorous management of requirements, specs, design, risks, test protocols, etc. across hardware and software.

  • Comprehensive traceability across all related engineering assets

  • Automated production of EU and FDA specific reports including the Design History File (DHF)

  • A solution that has undergone a computer systems validation (CSV) ensuring 21 CFR Part 11 compliance.

The MKS Integrity Platform
Many automotive and medical device companies rely on the MKS Integrity platform for helping them ensure compliance. The Integrity platform was architected to manage the diverse set of related engineering assets that span the lifecycle. Integrity has received numerous accolades as having best in class functionality in various disciplines including requirements management, software change and configuration management.

The key lies in the ability for Integrity to provide full configuration and change management for all assets in a highly scalable and flexible single platform. Automated work-flow provides hyper productivity while ensuring compliance with industry and company specific standards. Out of the box solution templates for many industries ensure rapid deployment and near instant time to value.

The Conclusion
Compliance does not have to be nearly as costly as it currently is for most organizations. With the right solution in place organizations can drastically reduce the time and cost of compliance while improving overall product quality and safety. Please contact MKS for more information about our solutions.