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?
Subscribe to:
Posts (Atom)