What is Done Criteria in Agile

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

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

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

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

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

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

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

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

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?

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.