Sciology = Science + Technology

Commonsense in Technology

  • Archives

  • Pictures

Archive for the ‘estimation’ Category

Is SEI-CMM L5 better than Agile Methodologies ?

Posted by sureshkrishna on September 15, 2007

I was working with a company which moved to CMM L5 and spent lot of $ on going for appraisal. I saw how the quality department and some of the (unlucky) project managers had to run around for the CMM L5 appraisal. Till that time I was more used to XP and Scrum for almost 3.5 years. Now as everyone would expect its very very difficult to get into the CMM mindset level from Agile methodologies. Of course in the end both processes are aiding us to achieve a good Software Product. As a project Lead i had the responsibility to implement a SW Development process. My manager was reasonable enough to listen to me and see the differences between CMM L5 and Agile practices.

In this article i want to explain how i convinced my management to adapt Agile Development for my project. I moved from CMM L5 to Agile Development. The comparison shows how i achieved each process area of CMM via Agile practices.

Some how in the industry there is a misconception that the Agile practices will lead to “Code-Test-Fix” cycles. Many fears that this process would lead to non-deliverable product , etc… In any case i had to convince few stakeholders in my organization to try these practices and see if it is better and makes sense. My Manager, QA Lead, QA Manager and customer are the main stakeholders who would be interested to see what the new process would be and what would it bring to them without disturbing any of the current Organization Level Metrics/Statistics. For me i had the advantage that the customer is working with the agile practices for a long time and there is no need to explain him what it was.

Let me explain the project that i was working for, so that you get the environment where i implemented this. This was a project with 10 team members in India and 5 team members in Germany. We had a time difference of 3 hours daily and we had full access to the Phones and Video Conferences. Everyone speaks english and the entire team knew each other. We have been developing a Eclipse based IDE for automobile systems and we were using CVS as configuration management system, JIRA for the Requirements, Work break up as issues, Bugs and Enhancements processing, Release management, estimations, tracking, we also linked JIRA and CVS via fisheye so that the traceability is not missed. Hummm….i definately have used a lot of JIRA, but trust me it worked perfectly (some say that i over used it). Every one is happy that they do not have to use any other Requirements Management tool (like Clear Quest), Bugs tracking tool (like Bugzilla), Project Management tool (MS Project), Team Tracking tools (PS7 and PC Team), etc… The important thing is that the developers and leads have to use only the Eclipse, CVS and JIRA; Thats all is the environment that makes your product development happy. We do have team members with varied experiences ranging from 12 years to 1 year.

In this article i am not going to explain the agile practices that we implemented but i will limit it to the differences that i found and we tackled with Agile Methodology. For Agile Methodology i have taken few practices from XP and practiced SCRUM. Following is a overview of the comparison that i had done. Of course i finally got the approval to go ahead with the Agile process that i proposed. But it was a lot of work to convince the management. I hope some of you who had done the same would agree with me 🙂 .

CMM and Agile.

Now its the time to look into each key process areas of the CMM and see how Agile Processes/Practices can help. Please make a note that i have mentioned Eclipse, CVS and JIRA in some of the process comparisons as tools that supports process implementation.

Project Planning & Integrated Project Management

  • Joint development with the customer
  • Life Cycle
    • No distinct phases, “Daily Development“, “Daily Integration”, “Daily Reviews”, “Daily Testing” and “Weekly Deliveries”
  • Estimation technique
    • Milestone (Sprint) planning is expected to be flexible. And customer has a knowledge of development on daily basis.
  • Tools recommended by customer
    • JIRA for planning, scheduling, tracking and OPL

Monitoring and Control

  • Team meetings, corrective actions, risk analysis is a daily ritual.
  • Agile methodology which is flexible, responsive, builds a self-managed teams
  • SVL, OTDQ have no importance. Sprints are flexible enough to accommodate various situations.

Quantitative Project Management

  • Flexibility is key. SVL (Schedule Variance) , OTDQ (Ontime Delivery Quotient) and RSI (Reqirement Stability Index) have no importance, sprints are flexible
  • JIRA will be used for scheduling, tracking and defect logging
  • DD/EPY (Delivered Defects per Person Year of effort), PYe(Productivity) , DFDQ (Defects per Delivery) will be calculated from the JIRA data

Requirements Development & Management

  • Frequent/Continuous meetings with stakeholder to get requirements – no concept of frozen Requirements. RSI has no significance.
  • JIRA is the RCMS for the project stakeholders (management, users and development team)
  • Due to the connection between the JIRA and the configuration management, code traceability is automatically maintained

Technical Solution

  • No distinct phases, “Daily Development” – Daily Integration, and weekly Deliveries
  • Not practical to check DIR (Defect Injection Rate) before each delivery
  • Impact analysis and Design is part of JIRA and is shared with Stakeholders

Product Integration

  • Due to Daily Integration and tool support, Integration is not a separate phase

Verification and Validation

  • No Distinct phase for reviews, testing. TDD – Test Driven Development.
  • Daily Reviews and Daily Tests; More efficient than a milestone based or task based reviews and testing.
  • Daily Development concept requires daily reviews and testing. Therefore no Test specification reviews.
  • No formal acceptance Test Specification, weekly Deliveries. As the customer is part of the deliveries (sprints), Acceptance test specification has no significance.

Configuration management

  • Latest code base from the development is taken and labeled.
  • Base lining is not done, as distinct phases does not exist.

Process & Product Quality Assurance

  • PDC (Pre Delivery Check) not done for Weekly deliveries. PDE is done for the major deliveries from the Customer to „End User“.

DAR & CAR

  • All major decisions taken could be documented in the JIRA tool.
    • This gives the flexibility that the entire team can view the decision basis.
  • All review & test defects are entered into the JIRA tool.
    • Informal CAR is done along with customer in the weekly reviews.

Risk Management

  • Daily meetings with the customer
  • Frequent meetings/demos to Stakeholders (also includes management, end users)

Organizational Innovation and Deployment

  • Promotes flexibility so more conducive for innovation

Hope this analysis helps you somehow. But in the end it takes a lot of time and effort to convince management who believes in the world of CMM fanatics.

Posted in Agile Methodology, CMM, CVS, Eclipse, estimation, incremental development, Process, scheduling, SEI, Uncategorized | 16 Comments »

When NOT to offshore ?

Posted by sureshkrishna on June 29, 2007

Recently i have started realizing the side effects of offshoring. I have already worked with  off shoring projects for many years and and i was pretty convinced with this model. Its been almost from past 10 months that i am seeing some (more) challenging topics in this model.

Probably let me explain with the current model that we have. Its a product development company, we have engineering, product management, sales and QA teams wide spread across continents. Engineering team it self is spread out. Now… this product has a LOT of innovation, few resources, lot of accountability and responsibility on each team member. I am sure many of us do have this kind of scenario….but i want to publish my own observations.

Vision : Off shoring team does not share the same vision as ABC Company. The future technology direction, how to move swiftly in the competitive market, what does the sales team need, what does the end customer/user needs, etc.. are different kind of questions that basically makes our thought process to go in a single direction. When these kind of questions and answers are not visualized in individuals mind, its very difficult to drive everyone for a common goal.

Communication : As the company is very small the decisions are very fast and some time its very very difficult to communicate each and every decision taken. When decisions are taken and communicated, we are very notorious in just mentioning What you need ?. And now for the people sitting across 10,000 distance, it difficult to comprehend the cause-effect scenarios and especially Why you need something ?. Because of the geographical and cultural barriers, we tend to get offended to lot of mail communication. We are too good at arguing and sending some nasty mail chains till some one puts an end to it.  

Innovation : First things first. Innovation needs motivation. People need to understand that even to work within their 8 hours/day contract also needs motivation. The very common aspect of the offshore team to be inert is that they tend to think that other guys (customer/coordinator) is sitting in a beautiful country, Why should i break my head for him. When you do not have motivation, you dont care about anything. You are least bothered about the innovation, you are good at repeating the same job again and agin and thats it.

Incremental development : Oh man….never ever do this. I mean Incremental development spread across the geo graphies on the same module. You would see night mares. It might be OK, for initial few months, but once you get a initial shape to the product/module then you will start realizing many things. The module coherence, coding styles, redundancy in code, fix the bugs, revert again, etc… If you can , have the complete modules distributed across. But dont distribute a single module. Some time with these kind of decisions you can ruin your product delivery dates.

Estimation and Scheduling : Do not ever estimate and schedule for a team in teh offshore. That would be like keep a time bomb in your shoe. Understand that the offshore team is with a different mindset, different culture, diffeent personal problems and priorities. Let them estimate and decide when they want to do and just ask them a delivery date. Of course you can always influence and negotiate the deadlines. On that level i feel, its better to kind of macro manage on the estimates and scheduling on the tasks and do a micro management on the delivery dates.

In the end,  if you are a Director, Program/Project Manager, VP involved in off shoring, you know what i have written, but the only thing i want to highlight is that you need to take the offshoring decisions consciously. You need to keep in mind all the effects and side-effects of it. Its better to be informed about effects of decisions rather repent the decisions.

Posted in communication, estimation, incremental development, off shoring, Offshoring, scheduling, vision | Leave a Comment »

 
Design a site like this with WordPress.com
Get started