Sunday, January 30, 2011
Is the Organizational Process Definition Process Area compatible with Agile?
Introduction
The Organization Process Definition process area, a process area at maturity level 3, aims at establishing and maintaining a usable set of organizational process assets and work environment standards.Below are the specific goals and practices:
SG 1 Establish Organizational Process Assets
SP 1.1 Establish Standard Processes
SP 1.2 Establish Lifecycle Model Descriptions
SP 1.3 Establish Tailoring Criteria and Guidelines
SP 1.4 Establish the Organization’s Measurement Repository
SP 1.5 Establish the Organization’s Process Asset Library
SP 1.6 Establish Work Environment Standards
Would the process asset repository be effective in an Agile environment?
No doubt a process asset repository is vital in a framework like CMMI that gives processes so much importance (see section ‘About Capability Maturity Models’ in the CMMI). But would it be the same in an Agile organization? I guess my question is: Can a process repository contain all the necessary knowledge needed to build software successfully? I believe software development cannot be performed just by following a set of processes. Building software requires other things as well, such as creativity, trade-off balancing and software craftsmanship. But then.... how can a software company build and maintain such a knowledge repository that lives and dies in the employee’s minds? Well, I don’t know. What I do know and saw in Agile companies is a culture of sharing the knowledge and learning together. Pair programming and code review practices allow more senior members to spread the knowledge on how things are done in the company. Are there any other ways? Particularly, ways that allow the organization to stick with the knowledge? (after all, the CMMI is right when it states that “people typically work for many companies throughout their careers”). I don’t know again. After all, we are departing from a point where we think that knowledge workers are irreplaceable, right? Probably there isn’t.
Flexibility versus Consistency
CMMI tackled an issue that I always had in my mind, but never knew how to express correctly. Flexibility goes against consistency. CMMI deals with it by defining a set of tailoring guidelines. But, can we predict all future scenarios to be able to create the tailoring guidelines? I believe that breaking rules comes with maturity. In the ‘Ri’ level of the Shu Ha Ri, very mature teams don’t go by the rules. They understand the rationale of each of them and are able to break them, based on the current needs. But to get there, all the previous paths need to have been traversed. The rationale of the rules need to be understood and the consequences of breaking them too.
Conclusion
I am not entirely sure that a process repository would be as effective in software engineering as it is in other harder engineerings. Also, I believe that tailoring a process can be performed not with tailoring guides, but with the understanding of the particular context and a thorough undestanding of the rationale of the existing processes.Tuesday, January 25, 2011
Is the Organizational Process Focus Process Area compatible with Agile?
Introduction
“The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.”Below are the specific goals and practices:
SG 1 Determine Process Improvement Opportunities
SP 1.1 Establish Organizational Process Needs
SP 1.2 Appraise the Organization’s Processes
SP 1.3 Identify the Organization's Process Improvements
SG 2 Plan and Implement Process ImprovementsSP 2.1 Establish Process Action Plans
SP 2.2 Implement Process Action Plans
SG 3 Deploy Organizational Process Assets and Incorporate Lessons LearnedSP 3.1Deploy Organizational Process Assets
SP 3.2 Deploy Standard Processes
SP 3.3 Monitor Implementation
SP 3.4 Incorporate Process-Related Experiences into the Organizational Process Assets
How would an Agile organization do process improvement?
My experience in the Agile world has always been in particular projects. This means we were doing Agile in those projects, but the organization as a whole was not Agile (Probably this is the case for the majority of the Agile projects …?) Why am I saying this? Well, because I was thinking how should process improvement at the organizational level should be performed in an Agile organization, but I am a complete ignorant in this regard. Anyway, If I think how we do process improvement in a particular project with Agile and I scale it to the organization, probably the result would be something very similar to what the CMMI proposes. First, determining the process improvement opportunities (retrospection), then make a plan, deploy it and monitor how it is going.
What would change at the organizational level?
1. Organizational level goals may not coincide %100 with project level goals: Cockburn says they are 2 different games, the project one and the organization one (and the one that the employees are playing). I believe that having to fulfill a process area like this one may really help an Agile organization align its projects.
2. Implementation is much harder: Depending on the organization, teams are different and have different contexts. The problem is much more difficult to resolve.
3. Need for a specific team to handle this: this may be a consequence of the previous point. The CMMI says and I agree, that a specific team that handle process improvement in the organization is needed.
There’s something I like to add to the previous points. The CMMI does never mention the employees as a source for process improvement initiatives and underestimate the importance of them in the implementation in my opinion. I believe that team empowerment is vital to any process improvement initiative. As the Poppendieck’s stated in their book “The people on the front line combine the knowledge of the minute details with the power of many minds”. I believe this is also related with the mentality needed for Kaizen. If all employees are constantly thinking how to improve the current processes, the results may be amazing.
Conclusion
I believe the CMMI goals and practices are completely compatible in this area. Knowledge from the lean methods of process improvement should be incorporated to make the process area even better.Other Areas
- Is the Validation Process Area compatible with Agile?
- Is the Verification Process Area compatible with Agile?- Is the Product Integration Process Area compatible with Agile?
- Is the Technical Solution Process Area compatible with Agile?
- Is the Requirements Development Process Area compatible with Agile?
- Is the Configuration Management Process Area compatible with Agile?
- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?
Wednesday, January 19, 2011
Is the Validation Process Area compatible with Agile?
Introduction
The Validation process area, a process area at maturity level 3, aims at “demonstrating that a product or product component fulfills its intended use when placed in its intended environment.”Below are the specific goals and practices:
SG 1 Prepare for Validation
SP 1.1 Select Products for Validation
SP 1.2 Establish the Validation Environment
SP 1.3 Establish Validation Procedures and Criteria
SG 2 Validate Product or Product ComponentsSP 2.1 Perform Validation
SP 2.2 Analyze Validation Results
There are a couple of points to address in this area:
What is Validated?
The CMMI lists a number or work products where validation can be performed. However, using an incremental approach for software development, the only work product that I conceive for validation is the final product, the increment that has been delivered. Being able to perform validation early on the final product is one of the distinctive characteristics of Agile methodologies.
What is the difference between Validation and Verification?
The CMMI states that Verification is the “you built it right” and Validation is the “you built the right thing”. In Agile, both process areas appear very intertwined, probably because both are performed at the same time or because requirements/user stories are not carved in stone and communication is so important to build it right. Thinking a bit about it, I concluded that Validation goes a bit further than Verification. A customer can validate an increment in functionality, beyond what the requirement for that functionality specified. In other words, a product owner (a good one) can judge the result of building a user story, learn from this result and make changes to improve it. This means Validation. Verification is the task of the Quality Assurance members that try to refine a user story, finding errors or discrepancies, but their only point of reference is what the customer expressed in the user stories or conversations (he’s not in the customer’s mind). In any case, I am not sure that both process areas are necessary in Agile.
Self-Verification or Self-Validation?
See, it’s hard for me to see the difference. Probably, Verification is related with the technology facing testing quadrants in Marick’s testing quadrants while Validation is related with the business facing quadrants. If this is the case, probably self-verification is more important than self-validation. With Validation, as I pointed previously, there’s a component of human intervention that won’t be automatable (exploratory and usability testing always have a big human component). Anyway, there is a big chunk of Validation work that can and should be automatable . In BDD, the customer specifies what he needs, the validation criteria as executable specifications. Doing this specification probably diminishes a lot of the subjectivity in the customer’s mind.
Conclusion
It is hard for me to see the difference between Validation and Verification. If a Waterfall development process is followed, it would be much easier because there is a big period of time where only Verification is performed (the team members trying to detect if what is being built matches the requirements). Validation is performed only in the end by the customers. In Agile, both tasks are performed concurrently and immediately. This diminishes the value of the Verification and increases the value of the Validation. This is what I say that I would probably merge both areas in Agile, performing only Validation. What do you think?Sunday, January 16, 2011
Is the Verification Process Area compatible with Agile?
Introduction
The Verification Process Area, a process area at maturity level 3, aims at “ensuring that the select work products meet their specified requirements”. The specific practices on this process area build on each other in the following way:1. Select Work Products for Verification
2. Establish the Verification Environment
3. Establish Verification Procedures and Criteria
4. Perform Verification
Below are the specific goals and practices:
SG 1 Prepare for Verification
SP 1.1 Select Work Products for Verification
SP 1.2 Establish the Verification Environment
SP 1.3 Establish Verification Procedures and Criteria
SG 2 Perform Peer ReviewsSP 2.1 Prepare for Peer Reviews
SP 2.2 Conduct Peer Reviews
SP 2.3 Analyze Peer Review Data
SG 3 Verify Selected Work ProductsSP 3.1 Perform Verification
SP 3.2 Analyze Verification Results
There are 4 points I would like to discuss on this process area:
How is Verification performed in Agile?
Verification is performed in small chunks, continually and needs constant readjustment due to the iterative nature of the development process. The CMMI states that Verification is an “incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.”. However, it doesn’t mention the need of constant readjustment, which is perhaps due to the fact that Validation is performed concurrently with Verification, turning Verification into a very dynamic task.
What’s the meaning of building the “thing right” in Agile?
CMMI states that the Verification is the “you built it right”, whereas the Validation ensures that “you built the right thing.”. I must say that having spent the majority of my professional life in Agile environments, I never heard the “you built it right” applied to how well it “fulfills the requirements”. I heard that concept applied to the internal quality of the system. How well designed, tested, maintainable and robust is the system. I guess it makes sense to say “you built it right” when the implementation of a user story correctly addressed the written user story. The thing is that this whole cycle of starting with the user story , building it and immediately verifying it is so fast, and there may be so many changes in between, that the whole concept of you build it right looses semantic.
What is an Agile Peer Review Process?
The second goal of this process area talks about peer review, as one of the verification mechanisms available. How should a peer review process be implemented in Agile. I believe that every commit should be reviewed. Reviewing %100 of the code assures that every programmer codes with attention, and that always at least 4 eyes look at the code before being committed to the mainline. Code should be committed at least once a day, to perform continual small integrations. This requires that the review process is very light, fast and effective. How can this be achieved? I believe in informality, mixed with discipline and trust to perform the peer review. First, the criteria should be very clear to anyone. Then, there should be trust and people should be able to discuss and change the code based on the review, without getting mad or getting hard feelings. In an ideal situation, I believe it should be performed face to face, at the moment the developer finish and wants to commit (of course, after having verified that all tests are running, the are no style errors and whatever else is on the review criteria).
Self-Verifying Code
The iterative and incremental nature of Agile turns self-verifiable code or self-tested code into a necessity. If only manual testing is performed, the project is not sustainable in the long run as it becomes too expensive to re-verify all features every iteration.
Conclusion
I see the verification part of a user story as another step towards refining a requirement and delivering what the customer is expecting. This whole process needs to be very light and dynamic. It needs to be very Agile, adapting continually to increase the probabilities of delivering a product that satisfies the user. Automation is vital to sustainably verify all the code every iteration.Other Areas
- Is the Product Integration Process Area compatible with Agile?
- Is the Technical Solution Process Area compatible with Agile?
- Is the Requirements Development Process Area compatible with Agile?
- Is the Configuration Management Process Area compatible with Agile?
- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?
Friday, January 14, 2011
Is the Product Integration Process Area compatible with Agile?
Introduction
The Product Integration Process Area, a process area at maturity level 3, aims at “assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.”Below are the specific goals and practices:
SG 1 Prepare for Product Integration
SP 1.1 Determine Integration Sequence
SP 1.2 Establish the Product Integration Environment
SP 1.3 Establish Product Integration Procedures and Criteria
SG 2 Ensure Interface CompatibilitySP 2.1 Review Interface Descriptions for Completeness
SP 2.2 Manage Interfaces
SG 3 Assemble Product Components and Deliver the ProductSP 3.1 Assemble Product Components
SP 3.3 Evaluate Assembled Product Components
SP 3.4 Package and Deliver the Product or Product Component
What should be the integration procedure suggested by Agile?
If the project is small and the contractual possibilities allow it, the recommended approach should be without any doubt to do Continuous Integration with all the practices suggested by Fowler in his great article (everyone committing to the same mainline, every day). What if the project is too big or a 3rd party team develops certain components of the system? Probably the different components are developed separately and then integrated. The question is how and how often.
One option is to study carefully the integration points before starting developing, then develop the different components (based on the documents created during the BUFD) and then integrating everything in the end. This approach has been proved too risky. No matter how well agreed and documented the integration points are, if there is a problem, it happens when the project has consumed most of its budget and changes are too expensive to be applied. The opposite option would be that all teams (belonging to all components) try to use the same mainline. Sometimes, this can be troublesome as it can happen that the different teams create problems between each other. So some separation, in these types of projects, could be valuable. However, I believe that the separation needs to be made following the Continuous Integration values. So if in a small project, the rule is that every developer integrates and commit every day to the mainline, the development of a big system could be done slicing the products in a way that many integration points are planned. Perhaps once a week or once a month, depending on the project. Of course this creates overhead, specially I can imagine if a lot of mocks and doubles needs to be constructed. However, the risk is also sliced and minimized throughout the project.
Does CMMI recommends one approach?
It is not clear to me, to be honest. In the description of the process area, it states that “Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components.”. However, again the sequence of goals would seem to suggest that a big analysis should be conducted at the beginning, then the interfaces should be managed and at the end the final product should be assembled, using the sub-components. This looks to me as goals that are more related with building a car than building software.
Conclusion
The Agile approach towards integration should be to it continually. How continually? As continually as it possibly can be performed. Remember that what needs to guide the decisions are the values and the principles. What is the rationale for doing Continuous Integration? How can it be applied to this particular project? These are the types of questions that should guide decisions.Wednesday, January 12, 2011
Is the Technical Solution Process Area compatible with Agile?
Introduction
The Technical Solution, a process area at maturity level 3, aims at designing, developing and implementing solutions to requirements.Below are the specific goals and practices:
SG 1 Select Product Component Solutions
SP 1.1 Develop Alternative Solutions and Selection Criteria
SP 1.2 Select Product Component Solutions
SG 2 Develop the DesignSP 2.1 Design the Product or Product Component
SP 2.2 Establish a Technical Data Package
SP 2.3 Design Interfaces Using Criteria
SP 2.4 Perform Make, Buy, or Reuse Analyses
SG 3 Implement the Product DesignSP 3.1 Implement the Design
SP 3.2 Develop Product Support Documentation
There are a couple of points I’d like to discuss about this area:
1. The 3 specific goals distills a Waterfall process life cycle. After reading carefully the whole process area, I would say that the process suggested would look like this:
- It selects the solution (SG1)
- It creates lower lever requirements (SG1 - SP1.2)
- It creates a broad design (SG2 - SP2.1)
- And a detail design (SG2 - SP2.1)
- It implements the design (SG3)
The ways it is written enforces this approach by, for example, specifying the role of the architect who “postulate and develop a model of the product, making judgements about allocation of requirements to product components”
A more Agile friendly maturity model should suggest the following steps in the process development life cycle:
- It selects a solution
- It creates a broad design: The architecture. As I said before, there’s a discussion on how much architecture is enough. For sure, in any Agile approach the architecture remains very broad, just with the most important structural components.
- Design and implement top priority requirements: Detailed design is performed at the same time than implementation of the features.
- Retrofit project: Designing and implementing a set of requirements increases the knowledge of the product. Requirements and existing design should be refined. This represents the iterative nature of Agile development.
2. The proposed method to the technical solution treats software development as another hard engineering. Let’s not forget that CMMI is used not only in software development process improvement efforts, but also in other harder engineerings. It was the belief a while ago (at the moment of the CMMI writting) that software development could be treated as other engineering fields. There is a very interesting discussion in Alistair Cockburn’s book about treating software development as other engineerings. Anyway, for now let’s just say that software uses a different material than what other engineerings use. Software can be changed more easily. Therefore, it isn’t necessary (or profitable) to have the whole design of the product made up front. The design can be evolved inexpensively (and cheaper if the team uses the practices suggested by Beck). This is completely different than, for example, the case where a bridge needs to be built. In the later, the whole design needs to be specified upfront and changes during the life of the project are very expensive, if not impossible.
Conclusion
Although not said explicitly, the nature of the technical solution process area goes against the nature of the technical aspects in Agile. I believe that trying to fullfill the objectives would lead to too big upfront designs, which in Agile are not recommended. The separation of roles between Architects (the people who take the big decisions up front) and the developers who just need to follow the detailed design provided to them goes in a complete different path than what Agile recommends. Treating Software Engineering as another hard engineer is also not appropriate.Another thing that caught my attention is that the technical process area doesn’t say anything about good engineering practices. Of course, CMMI is too general to go into these details. However, I wonder if a useful software improvement model shouldn’t provide goals related to this (e.g. one that I would add is having a automated testing strategy, which defines what kind of automated tests are going to be developed during the project and how the product is going to be tested). As a final sentence, I feel this area too far from the Agile technical area.
Other Areas
- Is the Requirements Development Process Area compatible with Agile?
- Is the Configuration Management Process Area compatible with Agile?
- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?
Friday, January 7, 2011
Is the Requirements Development Process Area compatible with Agile?
Introduction
The requirements development process area, a process area at maturity level 2, aims at producing and analyzing customer, product and product components requirements. CMMI states that requirements start as customer requirements (stakeholders expectations are expressed here) and are later refined into product and product components requirements (expressed in a more technical fashion) with the input of the technical members after analysis and design is performed.
Below are the specific goals and practices:
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Develop the Customer Requirements
SG 2 Develop Product RequirementsSP 2.1 Establish Product and Product Component Requirements
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
SG 3 Analyze and Validate RequirementsSP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality
SP 3.3 Analyze Requirements
SP 3.4 Analyze Requirements to Achieve Balance
SP 3.5 Validate Requirements
Is it Compatible?
CMMI states that stakeholders needs, expectations, constraints and limitations may be difficult to obtain and therefore it suggests an iterative process (very much like Agile). It also states the importance of having a customer surrogate, role that very much resembles that of the Product Owner. However, it also talks about refinement and allocation. I have 2 concerns about those.Is there really the need to express requirements in a technical fashion? Is it advantageous?
Requirements in a software development project represent the common area of understanding between technical and business people. Refinement of Customer Requirements into Product Requirements implies having 2 sets of requirements and therefore the integrity of both have to be assured (i.e. assure that all customer requirements have been address in the product requirements, which if they are written technically will be inaccessible to business folks). This is not to say that requirements should not be refined. I believe they should, but the end result should be one set of requirements that all members of the project can understand. Some people could say that Customer Requirements may be expressed in a business language too difficult to understand for developers. However, is it possible to build a software system without the developers understanding the business logic of what they are building. I don’t think so. There is another issue that worries me about this refinement. All Agile requirements (User Stories) have some business value associated with them. Although sometimes it can get difficult to slice functionality small enough to enter into an iteration, the advantages of building tangible, visible functionality are many. Although CMMI doesn’t state anything about the business value of any type of requirements, I am afraid that this type of requirements may result in technical requirements without visible value. In any case, stating that all requirements introduce some new business value to the system is really important.Is there really the need to allocate requirements to technical components?
Who is this useful for? When is it done? Requirements should express what needs to be done. They shouldn’t express how it is supposed to do it. Otherwise, the requirement is biasing the implementation. Traceability is one of the reasons that CMMI states for performing this allocation. However, as I said before I am not sure about the benefits of having this traceability that assures that requirements have been addressed, but not that they have been full filled. Besides, I reckon that this traceability may be too heavy to keep up to date. Instead, I believe that automated tests expressed in the business language provide the certainty that the requirement have been full filled while being always up to date.Conclusion
Although requirements in Agile should be refined (user stories start as a point of conversation and grow afterwards), the common shared place of understanding is always the product backlog, which is unique set of requirements. Translating customer requirements brings more disadvantages than advantages in my opinion. Same with the allocation of requirements to technical components. Something that really caught my attention is that the CMMI doesn’t say anything about ordering requirements by priority. In Agile, this is a top of the shelf matter, vital to the success of the project.Other Areas
- Is the Configuration Management Process Area compatible with Agile?
- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?
Tuesday, January 4, 2011
Is the Configuration Management Process Area compatible with Agile?
Introduction
The Configuration Management Process Area, a process area at maturity level 2, aims at establishing and maintaining the integrity of work products. The process area deals with selecting the work products that compose the baselines, controlling changes and maintaining the integrity over these items and providing accurate status on this data.
Below are the specific goals and practices:
SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines
SG 2 Track and Control ChangesSP 2.1 Track Change Requests
SP 2.2 Control Configuration Items
SG 3 Establish IntegritySP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits
Is it too Formal?
CMMI states that the first thing is to create a baseline, which is a “a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures.” and then modify this baseline through change requests, which should be approved by all stakeholders. It also states that this process should be audited.Is this really suggesting that ALL changes should go through a change request system? When the developers are working in the project, they should create a change request ticket to commit their code? When the Product Owner is completing a User Story that was missing some information, s/he should do it via a change request ticket? I believe this formality would take too much time to the activities that add value, hurting the agility of the project. Of course, I believe it is important to track everything under a source control system, to keep the history of all configuration items and to analyze the impact of all changes (specially to requirements). Nonetheless, this should be done in the lighter, more non-obtrusive way. For example, the comments written in the commit to the source control system are (or should be) more than enough information that explains this change. Changes (the history) to the product backlog should be kept automatically, without the Product Owner needing to do anything. Formality is replaced with efficiency and trust. The Configuration System method chosen for an Agile project should be light and efficient. It should keep all the necessary information without the users spending too much time maintaining it. Automation (again in this area) is vital. The easiest way to maintain the integrity of a product is to avoid human intervention in the creation of the product. If the product is created automatically (running a command) there is no room for human mistakes.
Conclusion
When I first read the title of the process area, I thought that this process area was going to be totally compatible. However, after I read it, I began having my doubts. Having to create and maintain a baseline could lead to an overhead that reduces agility. Managing the backlog through change requests is practically impossible. Nonetheless, the need to have all items under a configuration management system is unavoidable. Having all or most of the steps of the configuration management process automated is vital.- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?
Subscribe to:
Posts (Atom)