Is quality a pond or a flowing river across the software development organization.

Many times we notice that quality is not practically followed across the software development organization but is found in some pockets or is decorated on the walls of the company in nice fancy frames.

Quality is to be followed from team formation to delivering value to the customer. Lets look at each stage on how quality can be imbibed in all the stages of development.

Team formation –

Recruitment needs to focus on recruiting members, who would imbibe quality values in practical sense. This can be achieved by giving practical problems during interviews, which will validate their approach to solve problems and would also validate their understanding of the fundamentals, which is critical to quality.

Planning –

Business needs to invest time to infuse quality in delivering value to customers.If the management is pushing hard with deadlines all the times – the team might try cut corners. I liked the statement from spotify’s blog, which states that “We don’t deliver on date but we deliver on quality”

Rather than start developing business features from day one, Initial stories should include some of below mentioned items(as needed)

1. Development teams should be trained on skills, such as domain, engineering practices(refactoring,Test driven development,..), process, tools and any other skills required for development.  or else it will be like sprinting without wearing right shoes, and eating right diet.

2. High level architecture should be laid out.

3. Infrastructure such as continuous integration, tools for unit, functional,.. automation should be made ready during initial sprints.

4. Practices such as Acceptance test driven development(ATDD) needs to be followed during the iteration.

Development –

The team  needs to follow practices that will provide instant feedback about the quality, such as Test driven Development, peer code review, team code review, static code analysis, Continuous Integration(CI) and automated test system.

Reviews needs to be very open and directed towards the objective of delivering quality product.

As there is no end to improvement, team should think in every retrospective on ways to improve the quality. 

Testing

Shift left strategy needs to be applied for testing the sprint output as early as possible.

Look at all the testing and make sure to move to left to identify the issues early on.

For example – Team should look into moving even performance testing to start, and it does not have to be perfect from day one.

Coaching-

If the team does not have the skills for adopting the practices of agile, it is important to to get a hands-on coach, who can coach the team on technical practices such simple design, refactoring, TDD and also general agile practices. As this practices require attitude shift, coaching is important to adopt these practices.

Knowledge Sharing –

Team members with similar skill set(developers of specific technology, testers,…) can meet on some defined frequency to share the good practices that are used in different projects within the company.

Quality needs to be a common denominator across locations.

Metrics

Metrics should be based on the customer value, how efficient are we and are we continuously improving and striving to improve.

Example – how much time it takes to get feedback from customer, product usage

what is the usage of features by customers, ROI from features being built. 

Metrics should be transparent at all levels so that same metrics is available to all members. so that teams can retrospect and strive to continuously improve.

IT , R&D, business should work together as only one section of the team cannot deliver quality.

Customer –

Quality is also providing what exactly customer wants and not to flood customer with unwanted features that we want the product to have. Customer does not care about the technology or methodology used for development, they are are interested in the end product.

Business team needs to have courage, in removing existing features from product, if they are not providing value to customers.

How much closeness is maintained with customers to understand their needs, context to provide them the solutions.

Quality needs to flow from the time members are recruited and should involved all the stakeholders that are contributing directly or indirectly in the software development process.

We have adopted agile to deliver fast but have we also adopted all the practices that needs to be taken care from quality perspective.

Quality cannot be enforced at just one step of the software development process but should be thought considering the entire flow.

Companies need to invest in learning to succeed

New Technologies are emerging and companies are adopting new business models to respond to changes in technologies, market demands, customer behavior.Disruption is becoming a normal word in the industry.

Companies want the professionals working with them to learn the new technologies, skills and should adopt to new way of working and respond faster to the changing needs.

Professionals working or planning to working in these areas will have adopt the mantra – “unlearn , learn and relearn”.

Has way of learning changed, Oh yes and a lot.

Learning is changing from just going to colleges or full time classes to learning by reading news, books, watching videos and presentation, enrolling for online/offline courses, attending events, hackathons and conferences.

 

Its vital that every professional should devote time for learning.

To encourage continuous learning, companies  could

  1. Enable to employees/teams to setup focus groups
  2. Bring experts from outside so teams get new perspective and understand what other companies/teams are doing
  3. Provide access to learning materials(paid material available in market)
  4. provide 5-15% of time to be invest in trying out new ideas (Accountable – not forcing every idea to succeed)
  5. Provide ways for employees to interact with members outside the team(lunch with random people from organization, mentor-ship)
  6. Arrange events, hackathons within organization(aligning to company’s/project/team goals)

 

Happy Learning 🙂

Building distributed agile team

Companies decide to build team in remote location for various reasons

  • In search of talent
  • Buying companies globally
  • To cater to specific market
  • Take cost advantage

Below is the high level model for building a distributed team.

Partner – To check the experience of vendor in running agile projects, its also important to also talk to teams to understand their stand on agility.

Recruiting team – Recruitment is most important aspect. You should be involved in the recruitment of the team to make sure that the team is ready to adopt agility and some of the team members have experience in technical practices such as Refactoring, Test driven development, Automated Testing.

Agile coach – Local agile coach, who can coach the team on management and technical practices.

Knowledge Transition – There are multiple models of knowledge transition to distributed teams. Either onshore or remote team members should travel to other location for the knowledge transition and it also helps to integrate the distributed teams.

Scaling Team – Its a good idea to start with small teams(few teams) and then scale it after the initial set of teams are stabilized.

Working with distributed teams will require patience and effort from both the ends to make it successful.

Impact of Social Media Analytics on Product Development

Will i be outcasted by product development fraternity, if i say that Product development team’s need to listen more closely to device whispers and customer’s roars’s rather than to technology bells for developing products that are more desirable by the consumers of electronic devices.

Lets look the the major changes that are happening with the consumers of electronics devices companies, which would product development

  • Every day, consumers are using connected devices generating 5 petabytes of data. Just to be clear, that’s 5 times 10 to the fifteenth power or 5 quadrillion bytes. Hidden in this data is a set of device usage and failure patterns, a huge source of potential insights for improving the products design and features.
  • These consumers are part of the world’s largest focus group, social media with millions of consumers regularly sharing their honest and candid opinions online. Companies don’t have to seek consumers’ opinions via panel or research study, they’re already available. Yet, at the same time, may consumers are willing and eager to go one step further and participate with companies to develop better products.
  • Customers sometimes are returning devices that are not faulty due to usability, software issues, remotely, and this is resulting in huge cost of “No fault returns” for device manufacturers.

Despite the fact that social media and device channels represent a rich, continuous stream of customer feedback, few organizations are equipped to take advantage of these inputs in product development life cycle due to

  • No formal strategy for utilization of social media inputs –Unable to make transformational changes in Organization structures, process, tool, practices and company culture to gain full value of social technologies
  • Low Budget for social/device analytics – Companies are not able to define metrics and ROI for using analytics for product development due to which management is not funding such initiatives
  • No Actionable analytics – Companies don’t have strategy, process and tools to plan and utilize the social/device information into actions for product development.
  • Unable to build/utilize Collaborative focus groups – Not able to build collaborative product focus groups to engage customers through social media means due to IP ramifications, Quality of knowledge exchange, etc.
  • Minimal IT experience internally to build or integrate complex systems – Companies have products from different vendors, for integrating social media/device analytics with product development and it’s very difficult task to build or integrate these disparate systems

A better path forward

Let’s look at how product development team’s of electronic industry companies can engage with their consumer and also leverage huge amounts of data on the user’s devices to improve the products

1. To generate new ideas for products

Using crowdsourcing and co-development with customers, companies can generate new product Ideas, which can then be routed to product portfolio and product requirements for new Product development. Companies can also collaborate with consumers to decide and prioritize new features for the product.

Lets look at how some of the companies engaging consumer’s for ideation

Samsung – “We get most of our ideas from the market,” said Kim Hyun-suk, an executive vice president at Samsung, in a conversation about the future of mobile devices and television.

Madison Electric’s led the company to launch the Sparks Innovation Center(crowd sourced, collaborative approach), which has been the point of origin for five profitable new Madison Electric products .

2. Product design improvement and geographic specific product customization

Once products are released to market, the best and most reliable feedback on electronics products and software services can be found online from the social media updates of opinion leaders and influential tech blogs, tweets and so forth. These data can be analyzed, filtered and provided to the product development team for building the product improvements.

Device usage patterns and issues in the devices can be tracked, collated and analyzed to provide insights on the product improvement to be done to the product features and usability.

3. Remote Product Support and software/firmware upgrades

Online customer feedback can be assessed not only to decide on service strategy to fix the current generation of products, but also in coming out with software upgrades, new versions and generations of products.

Three simple, but powerful ideas will allow your company to have more engaged customers and improve overall product experience

Below presentation captures the details of the blog.

Retrospective using story mapping and design thinking

Above is a sample story map activity for a tester persona in a agile team. Its is based on life in the sprint for a persona. We have also mapped the emotions to the activities that the persona is involved with.

The activity details with positive emotions can be mapped to the “whats going well” and the activity details with negative emotions can be tagged to “what needs improvement”.

Once all team members do above activity and record their details in the retrospective chart, they can they create affinity diagram of related items and then pick top 2 areas to improve in the upcoming sprint.(As shown in figure below)

Team can discuss ways of improvement for the top 2 picked areas and track them for upcoming sprints.

Hackathon for multi team retrospective

Retrospective is one of the core concepts of agile methodologies and often one of the most neglected one not from the ritual perspective but from the effectiveness perspective and especially for distributed teams.

Retrospectives in agile is intended to help the team to reflect on the previous sprint and bring improvement to the upcoming sprint based on the wisdom generated from experiences.

Collaborative brainstorming or we can call it Hackathon could be one of the ways to generate improvement ideas/solutions for problem faced by large agile teams either collocated or distributed. It would utilize the knowledge and ideas of members across team and across locations.

This can bring innovative solutions to the table as team members from different locations, would bring diverse perspective to the issues based on their experiences and background

This would demand collaborative tools and good infrastructure for the teams to come together on a virtual platform.

Topics that need to be discussed could be released couple of days before with sufficient background about the problem for the teams to start thinking about ideas and it will give sufficient background to non-collocated teams about the problem topics. Hackathon could be limited from dedicated few hours to couple of days depending upon the team size. This process could be repeated in a frequent basis.

This is also help to increase the binding between teams and help to build the trust for members located in distributed locations.

It’s vital to create the culture of innovation so more members participate in such events, where the company is receptive to ideas from the team and implements them.

Integration of distributed teams

As the companies are being acquired across geographies and companies are going global for utilizing the right talent for building products, distributed development centers are very common sight now.

Agile methodology, which started with collocated team concept, is being adapted to distributed teams. Collaboration across teams becomes most vital component to the effective working of the teams and for sharing the knowledge across the teams.

For distributed agile projects, either the distributed team is from the same company or it’s from the outsourced company.

Teams need to plan on the areas mentioned below, before and while starting the distributed projects.

  • Division of work based on technology or functional across distributed teams
  • Collaboration model, process and tools
  • Network connectivity
  • Access to similar/common Infrastructure, tools, resources across locations
  • Knowledge ramp up plan for the new locations

As there is no one size fits all solution for distributed teams, the projects are different by

  • Size
  • Complexity
  • Number of distributed centers
  • Expertise of teams across locations on the tools, technology, domain
  • Cultural diversity
  • Communication Language

I have come across teams that have started distributed development without understanding the challenges around it and then coming to conclusion that distributed models do not work. One of the biggest lacking areas is that teams don’t take steps to integrate them as one team and motivate them to work towards common goal.

Collaboration being very vital, tools and technology should be used to bridge the communication gap across centers and to bring more transparency and visibility. Apart from collaboration there needs to be frequent travel of members across locations.

Creating culture so that all teams share same values, trust each other, work towards creating high quality project and have the common goal will is important for the foundation of great distributed teams.

There needs to be continuous process of improvement in these areas to build a team that works like one team even if it’s distributed.

Reduction of Time to Market during SDLC

Usage of agile methodology tops the chart, when discussing about reducing time to market in development process.

Of course agile methodology gives the framework for reducing time to market.

There are lots of other areas within the R&D domain that can be worked on to reduce “Time to Market” in a short and long term.

1. Reuse of Code/frameworks/tools/test cases/ etc.

  • Reuse will reduce the time to write new code/test case/ etc.
  • Reuse can be achieved in many ways – By using reuse repository for assets, knowledge sharing sessions, discussion groups, competencies, etc.

2. Automation testing (early the better)

  • It will help to reduce the time to verify the effect of the changes done to the code base.

3. Use easy to develop frameworks, language, tools

  • It’s difficult to get developers, testers with expertise in proprietary languages, tools.
  • It’s also faster to develop the code in most cases with non-proprietary frameworks, tools and languages.

4. Regular retrospective

  • Improve on continuous basis the areas that are hampering “Time to Market” and come up with new ideas to improve “Time to Market”

5. Design principles/Good coding practices – define at the start and review them on frequent basis

  • Logging, threading, etc. Its saves time by doing it right the first time. More time will be spent on fixing the code, if done after much development is done.

6. Review by experts

  • (Weekly) Frequent Review of code, design by experts to find the issues early rather than at later end of project.
  • It also helps to share the knowledge across members.

7. Acceptance test driven development

  • Acceptance test scenarios to be defined before start of the development/coding/.. This will help to reduce the defects.

8. Fast impediment solving

  • Management team needs to resolve the impediments faster to improve teams productivity

9. Cut down or eliminate Dependencies

  • Inspect all the dependencies that is causing the wait – Dependency of people, resources,
  • Easy and transparent way to log the issues, dependencies to highlight and get it resolved.

10. Better Collaboration Tools and Practices (video conference, wiki, messenger, travel across centers …)

  • Relevant for distributed R&D teams
  • Clarification with business team , other dependent teams faster – reduce the wait time and increase the clarity of understanding the discussions

Please share what other practices worked for you in reducing time to market.

Agile developer day

Over 8 million developers worldwide are using agile practices for at least 50% of their projects based on Global Developer Population and Demographics Survey.

There is big shift in way of working, when you move from waterfall development to agile development. Lets look at how the agile developers spends his day.

The day of an agile developer unfolds with planning for the day, which involves recalling on whats left in the plate from last work day and planning the task(s) that can be accomplished during the day. This planning also helps to prepare the short udpate( 1. What has been accomplished from yesterday, 2. What is planned for today ,3. Any impediments) that needs to be shared during the scrum meeting with the entire team.

Every developer needs to understand that they are the owner of the task(s) they pick and they are accountable to deliver them. They need to raise any impediment, which prevents them to complete the task. They should not wait for the next scrum meeting to talk about their impediments.

Once the developer picks up the task, he/she would use test driven development approach to write the code, continuously refactor the code to maintain the quality of code. He would have the eyes and brain of his pair to provide ideas and keep tab on quality of the code.

After the code is build successfully in local environment, the code is checked-in into the version control. Continuous Integration server is waiting for this moment and it grabs the entire code to make sure that the checked-in code does not break existing application

Continuous integration server helps to provide instant feedback on checked-in code so that we can rest assure, before leaving home that we have not broken the system and show can go on.

Its satisfying to see the quality product output getting unfolded with every task being completed by the scrum team members.

I have also found the pomodoro technique very useful for work to be done during the development period of the day.