Thinking in Agile

Architecting for Continuous Delivery

2021-06-13T11:33:00.001+05:30

This short article will provide details about the various architecture specific requirements for good implementation of continuous delivery. It emphasizes on the need of the system to be architected/designed for continuous delivery.

Deployability- The system should be well thought from the perspective of ease of deployment.
Security-Security vulnerability should be well thought and should be built into the architecture.
Loggability: The system architecture should consider aspects related to the logging requirements. It should cover what to log, logging mechanism/ log format, log size etc.
Modifiability: The size of the requirements should be considered so that the modifications in the systems can be easily deployed.
Monitorability: The system should be designed in such a way that the interfaces should be able to monitor the state and performance (and related aspects) of the system.
Testability: The system should cover the aspects of testability of the system and cover details of pipeline (where each pipeline serves as quality gate)

Product Quality-Where do you stand

2021-06-13T10:11:00.011+05:30

So..What is your Quality Quotient? :-)

2015-11-18T07:36:00.003+05:30

(Image Courtesy: https://www.linkedin.com/company/quotient-ltd-)

So..What is your Quality Quotient? :-)

8 years back, late in the evening I was packing up to go back home from office, I found one of my teammate, a developer, working alone. I asked him “Why don’t you go home as it is late”. He told me that “tomorrow I have to deliver 2 stories for testing to the test team and I want to ensure no defects from test”. Later I used to observe that the person always used to take pride in the work which he delivers and his aim used to be ensure zero issues or complains from his work. I was really touched and still whenever there is a context of “Building a brand and having credibility for oneself”, I remember that person.

In my experience, I have seen that when the work is done by certain set of members it always comes out with good quality. If there are some products released by some companies we are very sure that, it would be of good quality. If there are products from certain country we are very confident that that Quality is high. For example “Made in Japan” always had a brand for quality and in my opinion it still has. Cars from Germany always have a brand of precision and quality. Similarly watches from Switzerland. Being in Quality Assurance for a large portion of my professional life, I always used to wonder that how is it possible that there is a pattern at individual, organization and country level. I have also met many very high performers in various organizations and I have seen an underlying behavioral pattern. All of these high performers have a strong underlying commitment. Commitment to always consider Quality above all, commitment to go beyond their responsibilities, commitment to update their own skills to ensure that the output, which they deliver always come up with good quality. Based on these observations and my own experience working in Quality, I want to say that at all levels there is Quality Quotient. Like Intelligence Quotient and Emotional Quotient, to deliver work with good quality, we need to have high Quality Quotient. Quality Quotient is not any a big jargon or funda, it is what differentiates between a product which is of low quality to high quality, it differentiates between a country which always deliver with poor quality versus a country which is known for the high quality and individuals who always gives quality output irrespective of the situation in which he or she is.

So what is Quality Quotient? It is the ability to effectively apply the power of Intelligence and emotions for producing anything with high quality. It can be applied at individual, organization, and nation or at any level.

Quality output is not about mere intelligence. It starts with right thinking. In this post I would list done some of those factors derived based on my experience in working in quality assurance. These factors can be applied at all levels for anybody irrespective of the domain we are in. These are purely my personal opinion and I have found a strong correlation between the quality of the output and these factors. Well I don’t have correlation coefficient and regression equation for that J

(Image courtesy: www.thinklink.com)

Intelligence (Know)

Know your Quality Goal and Plan for it: We need to have a quality goal and have a plan to achieve that. Quality Goal for a mobile app may be different than for a network management system. In the former, usability aspect should be the key quality goal. Even if we have zero defects in the app, but not very user-friendly, in my opinion we have not identified the right quality goal. Once we have identified the Quality goal we should plan to achieve it. The plan can be at year/month/week/daily level. For some project or individuals, we may or may not document the plan. But as long as the clarity is there how to achieve that , I feel it is fine.

Know your Done Criteria: For every work, task or activity, we must define the Done criteria. When can we say that the activity is really completed. Many times the defects come when we complete the task without meeting the Done criteria.

Know your Strength and Weakness: We must know our true strengths and Weaknesses and we should be very frank with ourselves on this. If we really understand our strengths and overcome our weaknesses through that in a systematic manner, it would be really great. Sometimes we don’t do real competency assessment and don’t take actions for improvement of our skills and knowledge. If we can't do right assessment about our competency, strength and weaknesses, in my opinion we can never achieve good quality and quality will be a matter of sheer luck.

Know your Stakeholders:

We must pay special attention to our customers, stakeholders or the real audience. We must understand their real requirements and try to validate that as soon as possible in an iterative or quick fashion. Stakeholders are members who have direct or indirect interest in the success of the work or project. We must keep our stakeholders updated about the work and the progress of that. It gives a lot of confidence about us and our work. Sometimes I have seen that we do many things but we don’t keep our customers and stakeholders in loop. This really worries them and creates a kind of vacuum. Timely progress update is not a mundane task. Also this should not be considered as some kind of marketing about ourselves. This is an important activity and we must do that.

Self Review, Self Review, Self Review

Harry (name changed) always finishes his task very quickly and gives to the technical reviewer. Reviewer knows that Harry doesn't finish the task completely ("Done criteria" don’t meet). How do you feel about Harry.. I am very sure all of us would agree that this is not good. We all may have an "Harry" in us who wants to complete the task quickly and move to the next work. Only the members who reviews his/her own work and then give it further in the chain for review or release, delivers with good quality. My personal opinion is that we are our brand and any work that goes out from us should have a signature of quality. Self Review can help in that. We should never be in a hurry to pass the work to next in the flow or the chain without doing adequate check by ourselves.

(Image courtesy: judythewriter.com )

Emotional (Believe)

Believe that Your Output is your brand

We should believe that every output which we deliver is our brand and we must take pride in what we deliver. Every time when work is delivered from our side we should think that our credibility is at stake if the output has any issue. Any good brand or name is built after years of hard work and consistent quality. One mistake can damage the whole name. So our approach should be to consistently deliver with same quality irrespective of whether the work is small or big.

Believe in Quality First, Always..

Sometimes we believe that when many task comes in parallel, mediocre or little less quality is ok as people know that we had been good and we are doing many things in parallel, so there will be a discount in the way people look on to us on quality. My observation is that people forget what situation we were when something was developed or delivered. It is the product or service which we deliver that remains. No customer wants to know what as a service provider, we are going through. Sometimes the customer may empathize with us. Quality of our product, services or anything will outlive us and the situation in which we are in.

Believe in going an Extra Mile for Quality

My experience is that every time we may not get all situations favorable to ensure quality output. Sometimes it may that our competency is not up to the mark for the deliverable or time available is short or any other. In all such situations do we go beyond our limits to ensure that what we deliver goes with good quality. If we feel we can’t deliver with the right quality, do we refrain ourselves from delivering. Remember every time we deliver, our credibility and our brand is at stake. We are our brand. We should do everything possible one time and every time to delivery this.

Retrospect in yourself.. continuously improve..

I have seen many times whenever there is an issue or problem; we first look for external factors for the problem. As humans our first nature is to defend ourselves and find faults in others work due to which the problem came. In my opinion even if the proportion of the problem from our side is 0.01%, we should retrospect and improve on that part. Of course, we should not take accountability for others problem. It is needless to mention that. This can help us in focusing on continuously improving ourselves. It will keep us grounded and ensure that every time we learn something from our mistake. Lets say even if the problem is not from our side we will learn from the mistakes from others. Remember life is too short to make all the mistakes which others have done and then learn from it.

Quality is a result of Intelligent effort

I believe that quality output is not a matter of luck, it is the result of intelligent effort. With luck we can deliver good product or services one time or two times but only through intelligent effort we can deliver quality output in a consistent way.

(Image courtesy: grouphigh.com)

I believe that Intelligence and Emotional aspects are equally important for giving quality product and services. I have seen a pattern in this in many individuals, teams and companies. Quality of anything starts with me, us and the team. Everybody should take equal responsibility in that. Let’s build and give quality products, services and take pride in being ourselves. Remember we are our brand..

The 2015 State of Scrum Report

2015-07-25T12:55:00.004+05:30

This post is a summary of the salient points from the Scrum Alliance State of Scrum Survey 2015.

In February 2015, Scrum Alliance® surveyed almost 5,000 people about their use of Scrum. The survey respondents make up a diverse group, representing 108 countries and more than 14 industries. They reflect a range of functional areas, including IT software development, product development, operations, human resources, executives, and sales and marketing. Most have a technology slant, with 44% working in software development and 33% in IT. And they’re an Agile-savvy group, involved in an average of 4 Agile projects in the last 12 months.

I. WHO IS PRACTICING SCRUM?
• Scrum practices are currently in place among 82% of respondents, and another 11% are piloting Scrum.
• IT and software development professionals continue to be the primary users of Scrum, followed by product development and operations professionals.

II. WHY ARE THEY PRACTICING SCRUM?

•Nearly half the respondents (49%) cite fulfilling customer needs as the highest business priority for Scrum projects.
• Meanwhile, the second-highest priority is all about the business — meeting budget, time, and scope constraints.

III. HOW ARE THEY PRACTICING SCRUM?

• The average team size is 7 people.
• Most Scrum teams (60%) follow 2-week sprints.
• 81% hold a team Scrum each day.
• 83% conduct sprint planning prior to each sprint.
• 90% use at least some Scrum artifacts
• 81% hold retrospective meetings.
• 42% of respondents report using Scrum exclusively.
• Of those using a combination of practices, 63% practice Scrum alongside Waterfall.
• 43% combine Scrum with Kanban.
• 21% combine Scrum with Lean.

IV. IS SCRUM WORKING?
• The overall success rate of projects delivered using Scrum is 62%.
• Teams of the recommended size for Scrum — 4 to 9 members — report the most frequent success

V. ROLE OF CERTIFICATION
• It’s rarely required but commonly recommended.
• 81% of respondents believe certification has helped their Scrum practice.

VII. THE FUTURE OF SCRUM
• 95% of respondents say they plan to continue to use Scrum moving forward.

VIII PRACTICES WIDELY FOLLOWED

• Sprint retrospectives, Done criteria, Continuous Integration/Build, Refactoring are some of the key practices widely followed

You can download the detailed report from the Link of State of Scrum Report - 2015.

Agile Testing practices mapped to Continuous Delivery

2015-07-18T19:17:00.003+05:30

In this post, I will attempt to map the agile test practices to the continuous delivery practices. Some of these practices are related and if done effectively right from test strategy, it can greatly help in delivering valuable software seamlessly. I am sure readers of this post may agree that test code lives as longs as the code lives. So we must invest on test code and the quality of it.

What is Continuous Delivery

Continuous Delivery (CD) is a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. It is used in software development to automate and improve the process of software delivery.

Picture Courtesy: Wikipedia

In Continuous Delivery, there is deployment pipeline that is formed to ensure quick and seamless feedback to the developers and testers about the quality of the check- in. The tests are divided into various types like Unit Test, Functional Test, “ities” like Reliability/Security /Maintainability testing which is run in different pipelines depending on the time taken to execute the test cases. These test cases is run in various stages as the time taken for these test cases execution is less to high. It is important that the test cases and scripts are designed in such a way that these aspects can be done in a seamless way when the code and test code is checked in. These points requires a much deeper and strong test engineering practice understanding and adherence to the core agile principles of collaboration, self organization, technical excellence, attention to working software .

The key test practices important for the effective continuous delivery practices are divided at Task, Story, Sprint and Release Level. There is definitely some overlap between each of the practice across the various levels. I will try to explain the details of each of the practices more from a test requirement for continuous delivery perspective.

Level	Test Practice	Details
Release	Test Strategy	Test Strategy is like an umbrella practice in which the team can think about how the test will be designed, organized, executed, reported, analyzed etc. Test strategy should cover the details about: - Different type of test cases that will be written like Unit Test, Integration Test, Functional Test, “ities” Test . This is an important aspect as some thinking in the beginning will help in later test organization in an effective way. - Automation Architecture - Test Suite organization - Development and Test Collaboration - Etc.
	Automation Architecture	Automation architecture is the architecture of the overall Test automation – How the various components will be tested. All the principles of a System architecture is equally applicable for a test automation system. Sometimes Automation architecture is seen as some list of tools or framework only.
	Test Suite Organization	Test Suite organization is the practice in which it is decided how the test cases will be grouped and organized. Example All UT test cases can be grouped under UT Test Suite at each feature level, similarly the FT and the ‘ities’ test cases.
	Operation /Infrastructure Test	Operation /Infrastructure test are all the tests related to the environment, infrastructure etc. Many times we see that everything works fine till we have deployed the system in the production and once it is deployed to the production some functionality don’t work . This happens due to test not being thought from an operation or infrastructure angle. Practices like Test Driven Development for Infrastructure code can be considered.
	Testing for ‘ilities’	Testing for ‘ilities’ are test from performance, reliability, stress, volume, security , maintainability and related aspects.
	Hardening and ZFR	Hardening and Zero Feature Release is the release or time period for any system development where there is 1-2 release being planned and done with no new feature added. The test is intended to test the stability of the system with no new features added. This is also termed as hardening.
	Test Pyramid	Test Pyramid is a practice in which there is a pyramid formed with the unit test, functional test, ‘ities’ test in decreasing order. What it means is that overall test should comprise of 50-60% unit test , 20-30% Functional test and 10-20% ‘ities’ test.
	Deployment Pipeline Design	Deployment pipeline design is about thinking ahead about what kind of testing will be done in which pipeline and ensuring that all the infrastructure readiness like build scripting, servers etc is made available from this perspective.
Sprint	Development and Test Collaboration	Development and test team should brainstorm about the scenarios, implementation approach, test design, test organization and related aspects. Many times team work in silos and lots of anti patterns gets generated due to this. One such anti pattern is ‘Dual Test Pyramid’. I will have a separate post for all the anti patterns.
	Test Pyramid implementation	Test Pyramid Implementation is about ensuring that at constant interval we check that the tests are being written based on our initial strategy and also fine tune the test strategy based on the implementation.
	Deployment Pipeline implementation	Deployment pipeline implementation is about orchestrating the right test suite at the right pipeline as per the test strategy and ensure that feedback is provided to the right stakeholder at right time
	Exploratory Testing	Irrespective of how much automation we do or how much test design we do, exploratory testing should always be done. It can help in bringing out many such scenarios which we may not have been thought about. Further these test cases can be automated and integrated to the system
Story	Story Level Test	Story level testing is testing done at each story level where each type test cases are written at story level
Story	No false alarms	Many times it is seen that if test fails we are not sure if the issue is with test code or the code. Such false alarms should be avoided and clean test code practices should be followed. It is a good idea to do test code refactoring if such symptoms are seen.
Task	Clean Test Code	Clean test code practices are similar to following coding guidelines and ensure that there are no bad smells in the test code. Test Code should be given equal importance as it lives as long as the code lives.
	Dev Testing	Development test should focus on the unit test and key functional test as per the test strategy. Here the Development and Test team should closely collaborate and ensure that whatever is written is organized appropriately and fits into the right deployment pipeline.
	Local /Private Build	Private Build is a practice in which developer runs the unit test and static check is done before the code is checked in to the configuration library. This is an important discipline to ensure that there is always test available as a safety net. It also ensures that each check-in does not break any build.
General	TIER	Testing is Everybody’s Responsibility. Both Developer and Testers should take equal responsibility of testing. In many organizations, the ratio of tester to developer ratio is 1:3. But the ratio of test code to code is almost 1:1. By basic common sense we can make out it is not possible to write all test case by test team only. All should take equal responsibility of testing and ensure the quality of the testing.

Let me add some some examples which are taken from the best practices of open source

Example 1: Developer Test Suite organization for hadoop-hdfs module

First level structure:

Second level structure inside the hdfs folder:

Next level structure inside the server / datanode folder:

Note:

This structure is by design and not by accident
It is a commonly used good practice to mimic your product code organization in your test code organization

Example 2: Why do we need developer testing if we already have system testing?

Have you heard about the “Zune bug”?

Zune was a portable digital music player from Microsoft. On December 31, 2008, when Zune users across world were trying to use it for their New Year eve’s party, it froze. The music players just hung and did not respond.

The issue was a simple code level defect which anyone with basic programming knowledge could have detected. The defect was in the following piece of code:

year = ORIGINYEAR; /* = 1980 */

while (days > 365)
{
   if (IsLeapYear(year))
   {
       if (days > 366)
       {
           days -= 366;
           year += 1;
       }
   }
   else
   {
       days -= 365;
       year += 1;
   }
}

As you could notice, the defect is in the missing else block of the “if(days > 366)” condition which will result in an infinite loop when “days = 366” (on Dec 31st, 2008).

This a defect which system tests may miss. However, a unit test with the input “days = 366” can catch it easily. Developer testing can ensure that the code we wrote is indeed the code we wanted to write.

Example 3: Clean Test code

We will use the example of a test case from hadoop-hdfs to observe some clean test code practices.

The first candidate for refactoring in test code is often the duplicated setup/configuration code. The snippet above shows two good practices to make this cleaner.

A test case which is longer than a few lines is difficult to understand and maintain. The code snippet above extracts out the lengthier logical code segment to an inner function.

Mocking can accelerate your test automation by handling dependencies more predictably and can help you create more maintainable tests as shown in the snippet above.

Good test practice implementation is an important factor for effective continuous delivery system. In the next posts I will cover some of the anti patterns which I have observed in this.

Good test practice implementation is an important factor for effective continuous delivery system. Let us given consider test code equally important as source code. As long as we don't do this, effective continuous delivery or deployment system may only remain a WISH.

Use the best of Lean Startup, Scrum and XP

2015-07-16T07:25:00.001+05:30

This is short blog on using the best practices from Lean Startup, Scrum and XP.

During product development there are situations where sometimes it is not clear what the customer really wants. In such situations, assuming that the problem is clear and developing the features in the iterations may not be a good idea. This is because even if we run an iteration which is as short as 2-3 weeks and then get feedback, it will be a futile exercise as we may develop some features assuming that what we are developing may solve some customer’s problem and later we come to know that customer don’t want the features, which we developed. So we need to have some methodology which helps in developing what the customer really wants. Here is where we can use the best of Lean Startup, Scrum and XP.

Lean Startup

Lean startup is a method for developing businesses and products. Startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases and validated learning. Here the practice of Problem Validation, Solution Validation and Scaling can be used.

Scrum

Scrum is an iterative and incremental agile software development methodology for managing product development.

Extreme programming (XP)

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

Problem and Solution Validation

Problem validation is when we are really ascertaining the real problem which customer if facing. Here we may use simple practices like interview, Talk in depth with customer, quick wire framing or prototyping to really be sure that the product development team understood the problem correctly. Sometimes requirement is realized or developed as a product in an iterative manner and that is considered as problem validation. In fact this is not true. Moment we start developing the requirement, we are doing solution validation. After the problem validation the next step is when we propose to the customer about the feature or requirement which if the product has, can resolve the problem or not. Here practices like wireframing, scrum and XP practices can help in quick feedback and development. The underlying point is that every time we have a hypothesis which we prove right or wrong though various experiments in the problem and solution validation stages.

Below is a proposed approach which can be followed for the product development where the product can be developed in an iterative fashion using the Scrum, XP and Lean Startup practices.

During the Product Validation and Solution Validation, Practices from Scrum, XP, and practices from Lean Startup – Lean Canvas, Wireframing, Hypothesis driven approach etc. can be used. We can use Hypothesis to arrive at the Minimum Viable product and use various experiments to prove the hypothesis. This way we can step by step develop and iteratively show the product to the customer and take necessary feedback.

Remember that we should not jump into features or solution development without validating the problem. Lean Startup and the best of Scrum and XP helps us in doing this.

Some references :

User Story Mapping- Jeff Patton with Peter Economy
The Lean Startup- Eric Ries
The Startup Owners Manual- Steve Blank
Running Lean- Ash Maurya
http://theleanstartup.com/
www.leanstack.com
http://steveblank.com/

What is Done Criteria in Agile

2015-05-09T06:17:00.000+05:30

Image Courtesy of www.freedigitalphotos.net

One of the primary reason why we have delayed iterations or troubled projects due to poor quality is either unclear definitions of "Done" Criteria or ineffective adherence to the "Done" criteria defined for an iteration or for stories. It would be so nice if we don't have to come back to a finished story to complete pending tasks like code coverage completion or refactoring tasks or any other. A completed story is not a bunch of unintegrated, untested code. It's ready to deploy..
There are various kind of stories. The challenge is how to define the
done criteria for each story. Just to give an example of the different kind of stories that is applicable in a typical project :

Functional Stories (most common)
Spike Stories
Refactoring Stories
Code Quality Improvement Related Stories
Test Design Improvement Stories
Test Execution Stories

and so on..
Defining the right done criteria is half the battle won. For Example- Identifying the right set of acceptance test cases for the functional stories and ensuring that after the story completion, all the acceptance test cases passes is the right application of the done criteria for the functional stories. Partially finished stories result in hidden costs to the project. When it is time to release , the project may have to complete an unpredictable amount of work. This completely destabilizes the release planning and prevents from meeting the project commitments.

The million dollar questions is What does it take for a product to be "done done". Well, this depends on the organization and the kind of project you are operating. However the main point is that a story can be considered done only if the customer can use it as intended. In this post , we would provide list of key aspects that can be covered for a typical functional story:

All code written and code review completed. All the code review comments are tracked to closure.
Code refactored to the team's satisfaction.
All the required testing (Unit Testing, Functional Testing, Integration and Acceptance Testing) is completed and all defects (if any) are closed.
The story is integrated with the continuous integration system and the CI is green. The story works from end to end- typically, UI to database- and fits into the rest of the software.
Line Coverage , Function Coverage, Branch Coverage (if the team uses this metric) meets the set expectation (the expectation may change depending on the project. Ideally we try to meet 100%)
All the static code rules (eg, Checkstyle for Java) is run and there is no coding rule non compliance. If at all there is any non compliance, it is reviewed and actions taken accordingly.
If the story is developed in main flow of system operation, then the relevant non functional testing is completed. (This can also be taken when a cluster of stories is completed in present iteration or future iterations).
All the known defects are fixed.
Customer agree that the story is finished.
Documentation (Technical Writing) completed.

The above list can be used for any functional story with application of this in the specific context of the project. Similarly for other kind of stories, there may be different done criteria which need to be applied. If a team wants to give successful project delivery, then the done criteria need to be rightly defined and need to be followed - of course, with no conditions. Playing Stories for incomplete tasks for a story in present or future iterations are signs of an impending danger. So beware of it and take timely actions.

What is DevOps

2015-04-12T15:25:00.000+05:30

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

DevOps is a software development method that encourages strong communication between the software developers and operations/ IT professionals.The adoption of DevOps is driven by factors such as

Use of Agile and related development methods and growing demand of faster and frequent releases from customers.
Growing differences between development and operations community where both see the roles differently. Each role strongly believes that they are doing the right thing for the business and both of them are correct in isolation.
The organization structure and the reporting of both the roles are different in most of the cases due to which there are differences in focus.
Difference in mindset of the development and operations teams.
Greater availability of virtualized and cloud infrastructure.
Greater focus on automation.

Some Organizations divide the development and operations into different department. Development team is driven by satisfying the end user needs and operations is focused towards availability, scalability and ensure cost effectiveness. While both of them are equally important from an organization standpoint, both the communities are not able to understand the big picture of this. Developers sometimes does not involve the operations in the architecture and design related decisions. Developers often do the configuration management and the environmental changes locally in their system and do not document each of the steps. These steps are evolved after lot of permutations and combinations. It is often very difficult to replicate the same steps in the target environment as there are differences between the environment of developer machine and target run time environment. Another anti pattern seen is that development focuses on delivering functional requirement faster, whereas, operations focuses ensuring stability. This in turn slows down the release of the new feature.

The need of moment is to have greater collaboration between the two teams , giving the development team more infrastructure related understanding and the operations team more application centric knowledge. Also build a team with a shared vision and appreciation for both the roles keeping the big picture of success in mind.

From Six Sigma to Lean Startup- GE is the largest implementation of Lean Startup in the planet

2015-04-02T23:13:00.000+05:30

Article adapted and interpreted from http://www.gereports.com/post/82723688100/the-biggest-startup-eric-ries-and-ge-team-up-to

Yes you heard it right. GE is the example of largest implementation of Lean Startup in the Planet. 100 projects in the pipeline. Eric Ries trained 80 Lean Startup coaches exclusively dedicated to GE’s FastWorks. Together they exposed almost 1,000 GE executives to Lean Startup principles.

The Lean Startup approach does not mean that you have to think small. GE, a global industrial leader with 300,000 employees and $147 billion in revenues, has been in business for more than 130 years. Started by Thomas Edison, the company has historically embraced innovation and new business ideas to remain competitive in the rapidly shifting global market. To advance that goal, GE is now transforming its culture to be leaner, faster and closer to customers.

Over the past year, GE has been working with Ries to develop FastWorks, a program built on his Lean Startup principles. As the name implies, FastWorks combines a set of tools and behaviors designed to deliver better outcomes for customers faster. “It will harness our entrepreneurial spirit and improve the way we work,” says Steve Liguori, GE’s executive director for global innovation and new models.

The program has the backing of top GE management, including Chairman and CEO Jeffrey Immelt and Chief Marketing Officer Beth Comstock. They saw an opportunity to take many of the aspects of the Lean Startup movement and apply them inside the company. “I tell all of our managers to read The Lean Startup,” Immelt says.

GE executive development leader Janice Semper says that through FastWorks, GE was “creating a culture where we operate faster while delivering better outcomes. At the heart of it is the discipline of testing and learning that permeates the entire the organization,” she says.

In the first year, Ries trained 80 coaches exclusively dedicated to FastWorks. Together they exposed almost 1,000 GE executives to Lean Startup principles. GE also launched 100 FastWorks projects in US, Europe, China, Russia and Latin America. They range from building disruptive healthcare solutions to designing new gas turbines. GE plans to expand the program to 5,000 executives and launch hundreds of new projects next year. “GE is an ideal laboratory for applying lean practices because of its scale,” Ries says. “This is undoubtedly the largest deployment of Lean Startup ideas in the world.”

GE Energy Management executive Jeff Schnitzer, for example, is already building a startup inside GE focused on entering large energy markets dominated by established players with a small team and limited funding. “We’ve learned from Eric and started building ‘minimally viable products’ to solve quickly customer needs,” Schnitzer says. “We needed a disruptive, transformational and meaningful solution that included some very substantial ‘pivots.’”

Pivot is a Ries’ term that he borrowed from basketball, and one of the most crucial aspects of lean management. It describes a special kind of change designed to test a new fundamental hypothesis about a product or strategy.

Agile India Conference 2015 - Don't test your code

2015-03-28T15:02:00.001+05:30

These are notes taken during the Agile Conference 2015. Some of these may be one liner just for pointer. For more details refer to the Agile India 2015 conference details.

- Browser stack for cross browser testing

- Cucumber, Jasmine and Aspect tool is used for testing

This talk is about ensuring all members do development and test. The presenter talked about how he transformed the organization Josh to a successful organization using right method, approach and tools. One day in a week is considered open source day.

Agile India Conference 2015- Tales of (NOT) so successful DEV-OPS

2015-03-28T14:28:00.001+05:30

These are notes taken during the Agile Conference 2015. Some of these may be one liner just for pointer. For more details refer to the Agile India 2015 conference details.

This talk talked about some of the above challenges. Some solution worked out -

- Cross functional collaboration - Build empathy and trust.

- Foster win win relationship- Think Dev+ OPS

- Teams using shared practices

- Create a climate of learning.

- Automate the things that are painful.

Agile India Conference 2015- Techniques to speed up build pipeline

2015-03-28T13:37:00.001+05:30

Key principles to speed up the build pipeline
- Focus on the bottleneck- pattern : file operations related
- Divide and conquer
- Fail Fast

- Every time not required to build the jar

- Test on smaller but apt data set

- Robocupy/rsync can help in reducing the copy time as it only differncial copy.

- Use SSD instead of HDD.

- Use in memory DB-SoftPerfect Ram disk can carve disk

- Don't initialize the spring application context, it can be shared application context.

- Do CPU profiling.

- java.until.Calendar is horribly slow. Joda date library.

- Ant has fork mode. Keep forkmode=once

- Create parallel jobs

- Distribute task across multiple slaves.

Fail Fast:

- Restructure the build pipeline.

- Prioritize the test- use protest frame work.

- Incremental build vs clean build

Agile India Conference 2015: Test Driven Development of Infrastructure code in Chef

2015-03-28T11:39:00.001+05:30

This presentation talks about test driven development of infrastructure as code.
TDD is all about writing test first and then writing the code.
Infrastructure code is code to build the infrastructure. It facilitates devops culture and help continuous delivery.

Shell scripts are not very maintainable. Chef kind of language is a domain specific language which is better maintainable. It uses the underlying package manager of the OS, wherever required.

We need to test whether the installation etc has happened rightly or not. We need to create an enviroment first and also should have a mechanism to test.

Chef

Chef works in client server mode.

Chef requires the server and uses workstation to edit the code to be hosted in the server. The client uses the http protocol to connect ot the server. Workstations also bootstraps the chef client in nodes.

Recipy is like a file that does the basic task like installing a sql.

cookbook is like collection of recipies. It can be a collection of recipies that can be uploaded. Cookbook applies at an component level. Example- For tomcat there will be a cookbook and there can be task that can be put together as recipies in the cookbook.

Runlist is a list of recipe.

Chef can be used for creating installers of different software for automating the developer workstation environment also.

Test Framework

Writing test:

running from command the test. test fail as there is no code:

write some code in the yml:

Unit test framework- to give quickest feedback

deploying it to the server

Chef Supermarket has list of cookbooks which can be reused.

Chef control panel

Agile India Conference 2015- Agile Infrastructure

2015-03-28T10:31:00.001+05:30

This presentation talks about rolling your own platform as a service (PaaS) with Docker.

Presenter feels that the Agile manifesto should be ' Individuals and interactions supported by processes and tools, ' Work software supported by useful +valuable documentation, ' Customer delight via empathetic negotiations, Adapting to change when reality meets our plan'

Infrastructure is a delivery mechanism between code +customers.

Devops- key perspsective of learning, reproducability, recovery, flexibility need to be there.

Agile India Conference 2015- How BDD can Save Agile

2015-03-28T09:04:00.001+05:30

This is a talk about BDD.

Teams face typical problems of predictability, communication,quality. Scrum help in many of these things like self organizing but it does not solve some of the problems of communication and quality. In many they work in silos, BA hand off to Developers, Developers hand off to testers etc.

We can work in small pieces, better collaboration and focus on more technical discipline.

We need to focus on the technical discipline.

BDD Is a tool that facilitates interactions between individuals.

Explore- Discover-Define-Drive out

BDD operates at the behaviour level whereas TDD Focuses on the low level unit level.

Conversations matter because :

- software is made by people

- Ignorance is the bottlneck

- Everyone has a unique perspective

For each of the story or the set of stories we should ahve discovery workshop where the discussions can be done and business rules can be discussed and questions can be addressed.

Concrete examples:

-make sense to everyone

-it is rooted in the problem domain

- help build ubiquitous language

- provide a shared source of truth

- help you to split stories into small pieces

The bit of TDD that everyone forgets is refactoring. Refactoring is going to keep the product alive. If we dont do refactoring the product will die

Agile India Conference 2015- Agile Architecture - A contradiction in terms?

2015-03-27T16:39:00.001+05:30

This is an experience report on Agile Architecture.

Background-

The best architectures, requirements and design emerge from self- organizing teams.

Epiphamy- It is essential for the architect to be connected to the code.

Team was facing problems related to following-

-Information used to be miscommunicated or getting lost. Architect used to work harder.

-Team friction- Different design values

Epiphany- It was necessary to develop design skills in the developers

Epiphany- Architect should be good leader.

Solution- Team formed scrum team where the architect, developer and all other roles worked together.

Agile India Conference 2015- Kanban A way towards DevOps in the Legacy Ebterprise

2015-03-27T15:28:00.001+05:30

This presentation talks about using kanban a way towards devops in legacy enterprise.

Most processes think from the perspective of efficiency.

Following are some organization using Devops in large parts other than google, facebook, netflix and others:

Kanban focuses first on visualization

Devops based kanban is to take logically the working software till production.

Prefer pull over push

Amplify feedback loop. Bring Ops driven feedback or development.

Dealing with the silos structure effect on people's actions:

Continuously optimize, start looking into the cumulative diagram, measure and optimize the flow.

Agile India Conference 2015- Starting with VSM and Kanban

2015-03-27T13:30:00.001+05:30

This is a practical workshop on value stream mapping and work in progress.
Kanban is a tool to visualize and track the flow.

Value stream mapping defines the 'as-is' steps and the key roles. Value aded activities is time spent for value added activity related to customer. Non value added activities are time spent between steps.

Calculate your process efficiency= (va/va+nva)

To kanbanify the VSM, Merge 0 value added and 0 non value added step as 1, define board policies, calcuate WIP. Multi tasking is one of the worst thing during development.

-Minimum thoughput = team size

- Total WIP= Min throughput/efficiency eg 7/55% = 13 (assuming no paring)

- % Effort per state= state VA/ total VA eg 4/14.5= 28%

-Proportion wip by state WIP= Total wip * % effort eg 13*28%= 4

Agile India Conference 2015- Lean Startup in Practice: Lessons learned from an MVP

2015-03-27T11:30:00.001+05:30

This is a case study presentation of Lean Startup application.

Business Model Canvas

Avoid survey, get out of the building, talk to the customers, dont ask questions which are close ended. Reference - MOM Test (tbd)

Below snapshot talks about unknown unknown solution:

Focus should be learning, failure to learn is the problem, failing is also a learning. Experiments are a series of tests that help answer a question.

Millions play pictionary online. So people may play charades?

Why is lean startup practice is hard:

- Designing experiments are hard.

- Managing control variables across experiment baches requires rigor and persistence

- Sampling sizes need to be large enough to hold significance.

- Our understanding of cognitive psycology is still evolving.

- Miss commercial opportunities that may not emerge from clear problems.

- Easy to get caught in local maxima and pivot away.

-Tricky balance of bias towards action and bias towards reflection

Agile India Conference 2015- Enabling Continuous Delivery in Enterprises through testing

2015-03-27T10:37:00.001+05:30

This case study presentation was from the experience of core banking implementation project. Any organization objective is create business value, create profit. The project was a distributed one. A core banking has external dependency like the green and blue objects, the red one represents the banking area, modules.

Challenges

130 systems, 290 interfaces

Some of the execution challenges were Multi partners (Policies, Constraints, Way of working), different stakeholders involved, agile implementation required and bank wanted iterative delivery, seeing value incrementally, building trust, co-existene with other systems, data migration, huge scope and difficult to slice in iteration, defect management, team distribution and integration, non functional requirements (security, performance, auditability, compliance, accessability.

To get to this Continuous integration was implemented. Then focus on continuous delivery, which is a natural extention of continuous delivery.

Principles and Practices :

- Test Automation is one of the practice which is very important for continuous delivery.

- Test Automation is the one practice which can make the continous delivery deployment unsuccessful.

-Automation should be considered as Safety net.

- Focus on ideal Test Automation Pyramid.

- Cost goes up when we go up the pyramid while running these tests.

- The UI and other related test cases tests the breadth of the product.

- Some oganization have developer and test pyramid, which is a big anti pattern.

We need to have this as one pyramid.

Agile India Conference 2015- Embrace complexity, Scale Agility

2015-03-27T09:03:00.001+05:30

This presentation talked about embracing complexity and scaling agility.

Cynefin - a sense making framework.

One size does not fit all

Some work is going on with Anderson on Kanban with complexity.

. Micro narratives or observations are the basic units of sense making

. Meaning does not reside in text it is provided by human actors in context.

. Abstraction is key to interpretation and reuse.

Agile India Conference 2015- Agile Guide to accelerating Agility

2015-03-25T16:31:00.001+05:30

In this presentation the presenter focuses on having the leadership with emphasis on Purpose, collaboration and providing delivery to take the right decisions.

As an organization and team we nee to be clear about the purpose.

Old school management method is more authorotarian

Trust ownership model

Alignment enables autonomy

Modern day managment is more to do with having the right people and providing the decision taking capability.

The focus shold be on input and the process so that the output can be of good quality

Focus should be on loose coupling and high cohesion.

Agile transformation @ Cisco Video Business

2015-03-25T15:41:00.001+05:30

This presentation talked about CISCO video business agile transformation at the organization, execution and people level

The execution model was more waterfall based in past. Later it was changed to more scaled approach as following-

For the people practice the focus was to give preference to the people choice of roles

Towards the focus on maturity key practice focused were technical debt reduction, obstacle reduction and mechanism to address. Practice of following 1 technical debt reduction day was followed. Refer snapshots below

Agile India Conference 2015- First amongst equals- Can Ux be there

2015-03-25T15:16:00.001+05:30

Unlike traditional way if user design the best way to do is to do paper protyping and then we do development.

User testing is done with end user sometimes and sometimes with client. Another approach followed by team was to give it to other people not part of the project.

Traditionally the focus is to have complete CSS ready.

Ux can be developed in incremental fashion rather than big bang. Some snapshots are below. Similar code cab be reuses. Developers and UI developers can work together.

QA, BAs, Developers and all the related members are updated and mor collaboration is done

Agile India Conference 2015- Edward De Bono Meets Agile

2015-03-25T14:44:00.001+05:30

This presentation was an intermediate experience report from Intuit Product Development.

Happy teams are self sustaining.

The workshop was conducted in a workshop style- the way the presenter conducts the workshop in his teams to assess the team situation for agility.

Pattern # : 1- Relationships- Three words used for survey- Quality, Speed, Work Life Balance

Pattern # : 2- Open up possibilities- Why do Illamas have long necks?

Pattern # :3- Alternatives- Creativity is all abut generating alternatives

Reference- How can you be more interesting- Edward De Bono