Agile India Conference Six Fixes to UnSafe starts

This post is about the learning from the presentation by Francis Kelly from Scaled Agile. The presentation focused on the people centric approach to Lean Agile at Scale.

unSafe Starts. These are some of the key pattern of issues and and how Safe methodology can help in solving the issues. I have noted down the key pointers.

1. Manager not leading from the front

There are teams in which the manager don't lead from the front.
How to solve this:
- Train on Lean Agile leadership
- Team problem solving tools can be taught so that he can teach others

2 Alignment as lip service
Pattern of issues-  Shuttle diplomacy to align, Guides others decisions, face to face planning is too expensive

Safe can help through clear content, design, release authority, prioritized backlog, face to face planning and prioritized objectives.

3 Prioritization as game
Patterns- backroom deals, when the team fails the person shouts the loudest

4 Building portfolio practice without strong program execution experience
Patterns-  Wants metrics and more metrics, push more projects in the queue
SaFE- understand decentralized decision making, move from milestone driven metrics to value driven metrics, trust kaizen events

5. Using agile to build bad code
Patterns- Feature driven, likes watching code blow up when its time to merge, TDD, Writes code which no one else can understands

6.Never looking back
Patterns- Big ideas, no retrospectives,
Safe supports Kaizen, small steady improvements

1-2-3 SaFe Implementation- Refer picture below

Key learning from the presentation  This presentation focused on the key anti patterns in organization and how Scaled agile framework can solve some of these issues.

References- SAFe 4.0- http://www.scaledagileframework.com/safe-4-0-sneak-preview/ 

Agile India conference 2015 - Dancing Along the Agile Fluency

In this post  I would summarize the key points which I noted from the talk of Dian Larsen on the topic "Dancing Along the Agile Fluency™ Path". This was an opening talk in the conference. For the sake of simplicity and to note down only the key points I would only bring out the main summary points.

How Threat Modeling can help in Code Reviews

Threat modeling will identify high-risk areas of the system that receive the majority of threats. These areas are often good candidates for directed code reviews and typically include components such as protocol parsers, access control components and session management mechanisms. High-risk areas typically interface with an external entity or deal with data in flexible formats.

Line-by-line code reviews of these high-risk areas are important because an area with large number of threats typically has complicated security requirements. Therefore, analyzing the code for design inconsistencies or insecure coding practices can yield subtle vulnerabilities that other wise would be missed.

Agile Process Performance Model supporting CMMI- Product Quality Assessment

Image Courtesy- http://www.freedigitalphotos.net

Continuous Integration System can be used for effectively assessing the product quality in a very systematic manner. Each product team can select some of the key product quality parameters that are decisive about the quality. In this post we would propose a simple way of assessment which can be built up further by teams to come up with a kind of performance model based on the data that is captured.

Aspect	Details	Measurement/ Formula	Expected Value	Actual Value
Static Code Errors and Warnings	Comprises of selected set of rules OR All rules	Total no. of errors and warnings open	0	<< From CI System>>
Function Coverage	Can be measured for set of Functions OR for all Functions	No of Functions Covered	> 90%	<< From CI System>>
Feature Stability Measure	List of important features OR All features. Feature Stability	Average of the Daily Feature pass rate	100%	<< From CI System>>

Above aspects are just suggestions. There can be other parameters like Code Complexity, Maintainability Index, Line Coverage, Branch Coverage and others. Each team can customize the product quality parameters and measure it accordingly. Each build can be monitored on a daily basis for the key product quality parameters and the historical data can be stored. Using statistical or analytical techniques process performance model can be built based on the dependent, independent and controlled variables among these parameters. Based on the process performance model the product quality can be predicted / assessed at a sprint or release level.

Reference:
http://ppqc.blogspot.in/2008/08/help-understanding-process-performance.html

Agile Process Performance Model supporting CMMI- Feature Stability Prediction

Image Courtesy- http://www.freedigitalphotos.net

The intention of a process performance model is to identify a quantitative understanding of the performance of  the sub-processes which in turn  helps in providing process performance data, baselines and models to quantitatively manage the organization's projects. Process Performance Models are used to represent past and current process performance and to predict future results of the process. At the first glance this looks like very data intensive and very difficult for the agile projects to maintain. In this post we would give some insight into how continuous integration system can support in building feature stability prediction model.


Feature Stability Assessment is one method / technique based on which the feature stability can be assessed and there can be some prediction done for the quality of the product.

When the test cases are being designed, the following naming convention can be used:
<<FeatureName>>_<<UT_TestSuiteName>>
Each Test Suite can be further mapped to the test cases level.
In each build the suite and the test cases which are failing can be monitored closely. Also there can be a trend which can be brought out about the features which are defective in last few builds.
Example-

Feature Stability Assessment can be done at Build Level and at the release level to check the quality of the features being built over a period. This can help in better prediction of the quality of the features and decisions can be taken to focus on specific improvements at feature level. Based on these factors regression models can be built to predict the quality of a product effectively.

CMMI and Agile- Need a balanced approach for organizational success

In our association with various teams of different sizes and different domains, we have come across many questions related to adoption of CMMI® and Agile. Questions like, "We are CMMI® Level 3 Organization, how can we be agile", " Our company is doing Agile, but our customers are looking for CMMI® Level 5, how do we adopt both" etc. In this post and the subsequent posts in this category, we would provide our perspective about CMMI and Agile and how both the good practices can be merged to bring organizational success.

Image Courtesy- http://www.freedigitalphotos.net

Any model or methodology is a set of good practices that have been proven and can be adopted for better results in similar kind of work. All companies wants to deliver the products and services better, faster and cheaper. Nearly all organizations have found that the products and services have varied levels of complexity. It is unusual today for a single organization to develop all the components that compose a  complex product or service. More commonly, some components are built in-house and some are acquired. The integration of these components needs better planning and strong engineering practices.Organization must be able to manage and deliver such complex development and maintenance.

CMMI®-Dev comprises of 22 process areas. These process areas covers aspects related to Engineering, Planning, Support and Organizational processes.  Agile is a way of thinking about software development. The canonical description of this way of thinking is the Agile Manifesto, a collection of 4 Values and 12 principles. (http://www.thinkinginagile.com/2011/03/agile-manifesto.html). Agile Methods are available in different flavors like SCRUM, XP, Lean Software Development (Kanban), DSDM, Crystal and others. Most of the teams adopt SCRUM and XP together. SCRUM comprises of the management practices and XP consists of the engineering practices.

One important fundamental which needs to be noted is : A method or process is a way of working. Whenever we do something, we are following a process. Some processes are written, as-when we are assembling a machine but others are adhoc and informal, as-when sometimes we clean our house. Most of members we have worked have said that CMMI is about excessive documentation. In fact this is not correct about CMMI. As per Appraisal Requirements for CMMI®Version 1.3 (ARC, V1.3) Section 4.3.4," the finding can be derived from objective evidence seen or heard during data collection sessions." This means that for the rating purpose when the data is being collected Objective evidence is seen or heard or observed during the appraisal time. While following the Agile practices there are many instances where the documentation is less. Some examples are given below :

• Daily Standup Meeting is done where the actions are being tracked on a daily basis unlike Weekly Meeting.
• Simple Design is achieved through XP practices like Test Driven Development, Refactoring unlike detailed low level design documents.
• Continuous Integration is practiced instead of dedicated Integration testing phase.

Above list may go on and on. In fact these practices are less documentation intensive but it can ensure that the management and engineering level practices are followed well. It is really important to understand that CMMI looks for the intent of the process area rather than documentation. So CMMI and Agile compliment to each other. The basic issue is about the right understanding about both the set of good practices.

CMMI® provides set of process areas that covers all the activities of software development. Agile methods like SCRUM and XP provides simplified solutions for management and engineering practices. Collection of agile best practices through these methods makes the delivery process fast and robust. It is important to adopt both CMMI and Agile practices together rather than bringing conflicts with each other. All it requires is to balance and customize the process based on the business and the team working for the development. In the next posts we would provide insight about how the good practices of  agile and the CMMI® process areas can be integrated effectively for project and organization success.

Build Optimization Tip 1 - Release Preparation using zipfileset

Continuing with the focus on the importance of Build Scripts in Continuous Integration System, (Refer to previous post : http://www.thinkinginagile.com/2011/05/build-optimization-for-effective.html) we would be covering some of the Tips of Build Optimization in small snippets in Build Optimization Tips Series:

Image Courtesy of www.freedigitalphotos.net

Release Preparation

In any build scripts one of the important activities is the release/artifact preparation. It may be a simple jar/war/ear or a huge zip file which contains different set of jars/wars, configuration files, etc.

What most team do?

a) Create a release directory.

b) Create all necessary folders as per the release structure.

c) Copy all the jars, files etc to respective folders.

d) Prepare the release zip file.

e) Copy the release zip file to the actual release directory.

 

What can be done?

There is a <zipfileset> nested element for jar/zip/war etc. We can use this type to pack the required files or jars from different location.

Sample Code

<zip destfile="${dist}/manual.zip">
    <zipfileset dir="htdocs/manual" prefix="docs/user-guide"/>
    <zipfileset dir="." includes="ChangeLog27.txt" fullpath="docs/ChangeLog.txt"/>
    <zipfileset src="examples.zip" includes="**/*.html" prefix="docs/examples"/>
  </zip>

By this way we can reduce the time to copy different files to a common location.

Refer: http://ant.apache.org/manual/Types/zipfileset.html

Does Process QA role exist in Agile

The above question is a very controvorsial one. In this context QA means Quality Assurance Professional. In some companies QA and QC terms are being used interchangeably. QA professional are eyes and ears of the management. They check whether the defined processes are being followed. If not, provides visibility about the key issues to the management so that timely actions can be taken. In SCRUM, XP or other Agile methodologies there is no clear role like QA, defined.It is left upto the companies to define the roles and responsibilities. However CMMI has a defined Process Area PPQA (Process and Product Quality Assurance) where there is specific mention about some of the roles of QA.
Any organization or project, irrespective of the methodology or life cycle or standards it follows, any role exists due to the value add it brings to the organization or the project. If there is less or no value add some day the role may phase off. This simple rule is applicable for Process QA role too. Following are some of the operational differences of a Process QA role in Agile as compared to Waterfall approach:

• QA should use a judgemental approach towards auditing where there are less records. For example sometimes there may not be record of minutes of meeting or review records as these things happens almost everyday. In Agile there are alternative practices like Daily Standup, Pair Programming for meeting effectiveness and effective reviews. QA should be in a position and should be competent to judge whether the alternative practices are working well.
• Should be able to propose the the life cyle of the project and the required metrics based on the agile process defined.
• Should have good competency to assess the Continuous Integration Situation and Build Management of the team and provide suggestions for improvement.
• QA should be able to understand the domain and the technical details of the project. This sometimes is not a mandatory skills. But if QA has this skill then it makes them more powerful and able to take decision in a more effective manner.
• Should be able to drive key meetings like Retrospection, Kaizen.
• QA should be Agile by himself or herself and should keep upto the pace of the team's progress and ensure that the processes are monitored closely.

The above list may go on and on. We don't wish this post to be a real comprehensive one. The important point is that QA role is very important. Any organization, big or small, require governance mechanism and Process QA professional can really help the organizations to perform better with effective governance system.

Anti Patterns of Continuous Integration

In this post I would try to bring my perspective of what are the top reasons where Continuous Integration fails or in many cases the benefits are not seen immediately. These are some of the anti patterns of continuous integration. Many cases I have seen that team looses hope and feel that it is an overhead which Agile practices has brought in. One of the reason may be that the Team / Team member or the management is looking for a quick solution without deep thinking about how Continuous Integration practice can be done really well. Please note that patience and strong will to do is the only way to become successful:

Reason 1- Every team situation, competency , technology, domain and dynamics is different. Just copying the CI Design,Architecture or roadmap from some other team is a wrong idea. Every team should have their own vision about how do they want the CI to look like. What all they want to run in the Continuous Integration System. Some teams try to run all the tools of inspection, all test cases together and starting with real continuous integration immediately without the infrastructure in place. That may not be a good idea in my opinion. It is always better to have a step by step approach. We can start with periodic build, incremental build and slowly move into the continuous integration approach. But if the team really have the competency then they can start immediately. It is really required to do this analysis.

Reason 2- Assuming that all the team members are very good in test coding skills is a wrong idea. Many times it is found that the test suite organization skills are poor in team members and there is no systematic training. The test code writing skills are not good in some cases due to which the test cases does not work properly. This is one of the reason where CI does not work effectively and there are frequent build failures.

Reason 3- User stories are not granular enough. During the user stories documentation I have seen that the stories has not been written with an overall perspective of granularity so that the developers can really check-in the code frequently and also if the story card can be realized effectively in short period. This is not quite easy and I am sure many people may have different opinion about this. One of the reason which I have seen for this is that the Business Analyst does not write the story as vertical slices from the user perspective. It does not depict the end to end functionality in the story. The requirements are sometimes written in a modular way. Due to this it is very difficult for a coder to checkin at frequent intervals. One pattern is observed that this issue is actually not known and we expect Continuous Integration to work.

Reason 4- CI should be actually run in the clone of production environment. But in big products which are used by many customers there are many environments and the multi-combinational testing, it is required that the strategy of testing is analyzed deeply.
Following is a good example -
Try to answer this

Each user on a computer system has a password which is generally 6-8 characters long, where each character is an uppercase letter or digit. Each password must contain at least 1 digit.
How many password combination is possible.?
The answer is:
2,68,4,483,063,360 possible variations of password exists
1 Test Case Design Time = 1 minute ,60 Test Cases = 60 minutes
1 day= 480 Test Procedure , 155 years to create and execute a complete Test.

In many cases I have seen the team don't analyze the stategy and the CI is run in some combination which is actually not the right representation of the production environment. Teams can use some of the techniques like parwise testing / OAT(Orthogonal Array Testing) to analyze the right combinations. But it is important to use these techniques with good judgement about the test sufficiency and coverage. The Test Strategy is really important to understand the real customer environment, where the test suites should be run and this work should happen during the Infrastructure readiness time for CI,not during the Test Execution time.

Reason 5- The Test Frameworks does not ensure that the SUT system architecture is taken into consideration while designing the overall automation framework. This creates issues, where the frameworks are not scaleable and there are issues related to overall test execution later.
Test Teams must ensure that the Automation framework considers all the aspects of testing like the system under test architecture, test inputs, test outputs, SUT precondition programe state, SUT postcondition programme state, environmental inputs and outputs, component dependency, APIs , capturing the results, analysis of the results etc, the various monitoing tools. Since the focus of the article is continuous integration, I may not elaborate more about the Test Frameworks. Important point is that for running continuous integration systems effectively it is important to have robust test automation system and the automation framework should be scaleable and reliable.
I have found this article very useful and I would highly recommend this for further reading.
http://www.softwarequalitymethods.com/Papers/autoarch.pdf

Reason 6- I have seen sometimes that the team does not have good build scripting skills due to which there are issues. Sometimes the CI Tool chosen does not support administration console for build dependency management etc where it becomes need that there need to be good knowledge on build scripting.

Reason 7- Overall CI Architecture of the system is not very clear. Here CI Architecture does not mean Tool. It means how the different components in the overall system is organized and how it depend on each other and whether the Continuous Integration system is also organized in similiar manner. For big system it is very important that there should be multiple Component level CI System which further builds the overall System level CI. It is also seen that the build staging (Stages to ensure faster feedback in the respective CI System) is not very clear.
These causes issues where the CI takes longer time to execute and finally the team does not use the CI for actual feedback.

Reason 8- All the test cases and inspections tools are run together in one stage without any staging (/Build Pipeline) in place. It is advisable to have continous integration in stages so that feedback can be provided faster. Sometimes all the test cases including Unit Test Case, Component Level Test Cases, Integration Test Cases, Performance , Reliability Test Cases are run together in one system. You can refer to the previous post to know more detail about Staged Build:
http://thinkinginagile.blogspot.com/2011/06/continuous-integration-what-is-staged.html

Reason 8- Test Suite Organization Structure not followed appropriately- Sometimes it is seen that the Test Suites are not categorized properly as unit, functional, integration, non functional test cases due to which it cannot be staged and also it cannot give analysis or test results at feature level.

Reason 9- Local Build not being used effectively- There may be many reasons for local build not being used effectively. Lack of awareness, process or infrastructure issues may be the reason. You may refer to the following post to know the anti patterns of Local Build:
http://thinkinginagile.blogspot.com/2011/07/anti-patterns-of-local-build-private.html

Reason 10- Lack of readiness for the tools and infrastructure- The team must ensure that before the actual execution of the project, the team should have all the infrastructure ready so that the time can be really productive during the actual work and focus on the functional work rather than infrastructure readiness. Sometimes I have seen team is not ready with the tools that need to be integrated with CI system, CI tool may not have been finalized , CI Server PC may be not of good configuration or slow and other related issues. These kind of issues diverts the attention of the team from the main work to tool related aspects which needs to be corrected.

Reason 11- Infrequent Check-ins- Team Members checks in the code weekly once or sometimes two week once. This defeats the purpose of continuous build and integration. There may be many reasons for this. It may be story card granularity issue, discipline issue or any other.

Reason 12- Broken builds are not given enough attention and the other team members keep checking- in the code without fixing the build.

Anti Patterns of Local Build / Private Build

Local Build is a very important practice in Agile which helps in getting sucessful build more frequently. To get more details about what is Local Build you may refer to the previous post:
http://thinkinginagile.blogspot.com/2011/07/private-build-local-build.html
However due to lack of awareness, process or discipline and due to other infrastucture issues there are some anti patterns to Local Build which is furnished below:

• Running all the test cases in the Local Build- Developer runs the functional / integration test cases (typically that takes long time) as part of the local build.


• Running all kinds of Inspection tools in Local Build- Developer runs all the inspection tools like Static Code Analyzer, Test Static Code Analyzer, Simian for Duplicate Code analysis, Useless code detector, Code Complexity Measurement tool etc. ( Just running the static code for the source code is enough. For the detailed feedback anyway the mainline build is there. However if there is a trend seen where the check-in often breaks due to issues from other tools, then the team should focus on competency improvement and ensure that all members are trained well to write good code and test code. It is not advisable to add so many inspection tools to the Local Build as it consumes more time.)


• Unit Test Cases ,in reality is not Unit level cases- Test cases are categorized as unit test cases though it is not unit test cases. The key aspect of unit tests is having no dependency on outside entities like databases, which increases the time it takes to setup and run tests.


• Test Suite Organization Structure not followed well- Sometimes it is seen that the way the test cases are organized , it is difficult to identify the unit test cases separately. When deeply analyzed, it is found that the team does not have any protocol to follow naming convention to identify the test suite and test cases for the test type.


• Not using the same directory structure as configuration Library- Not using the same directory structure as the configuration library due to which the environment and other aspects are not same. The typical directory structure for source code and test suite can be :

• IDE does not support a one click Local Build - Some teams don't use good IDE that can support automated check-in from the IDE and taking the latest code from the configuration library.(Especially in C projects)



• Local build takes more than 3-5 minutes for providing result- I have seen sometimes Local / Private Build takes around 30 minutes to run and the developer has to wait to get the feedback and he /she sits idle. It creates productivity dip and the motivation level of developer is less to run local build every time.



• Developer PC is not of good configuration- Developer PC configuration is not good due to which Local Build takes more time.



• Members taking short cuts- Sometimes the team members in hurry takes short cuts. If this is not addressed, it becomes a culture and later correcting this becomes an issue. Running Local Build is a healthy practice and it is more of a culture.

Lean Principles and Agile-Aren't they same

The Five key principles of Lean are identified as Value, Value Stream, Flow, Pull, Perfection. Agile principles depicts the key aspects of giving highest priority to customer, better collaboration at all levels, working software as primary measure and other aspects. Details mentioned in previous post:
http://thinkinginagile.blogspot.com/2011/03/agile-manifesto.html.
Aren't Lean and Agile two names for the same thing?
Well, Lean and Agile share the same goals. The practices that make up the various agile methodologies also support the lean principles. In fact Lean takes a wider view of the entire business context in which the software development is done. Lean considers Agile software development as supporting practices for Lean Software development.

Value
Value is defined by the customer. We must understand what is really considered as value from the customer's perspective.
Value Stream
Once the value is identified, we need to create a series of steps or processes to produce the product. This is also called the Value Stream. Each Step is either categorized as value-added , non value added but necessary, or non value added waste (which can be actually removed)
Flow
The development process must be designed in such a way that the step of activities should flow continuously. If the value chain stops at any point then it is evident that some waste is getting produced.
Pull
Let customer pull the value. It means that we don't start developing until it is really required. Decide as late as possible to develop anything.
Perfection
Continuously identify areas were waste can be removed and the step of activities can be made perfect.

References
The Art of Lean Software Development - Curt Hibbs, Steve Jewett & Mike Sullivan