This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
2. - Software developments from Agile 2013 : Read more in this section
Explore other sections in this guide:
Six years of fine-tuning Agile software development has helped HP Software move from one- to two-year application function releases to monthly delivery. Getting all software development product-related activities up to that speed, however, has been a challenge, and meeting it has improved teamwork -- specifically better cross-department collaboration and communication -- and has ushered in new team-centric ways to use business intelligence, according to Raziel Tabib, director of products at HP Software.
At Agile 2013 in Nashville Tuesday, Tabib recounted the lessons learned while HP Software, a division of Hewlett-Packard (HP) Co., adopted and then fine-tuned Agile in his session, Need 4 Speed: Leverage new metrics to boost your velocity without compromising on quality. He described ways his project teams use metrics in Agile development, the impact of mobile applications on development, and common mistakes in Agile in this pre-conferenceinterview.
What was the biggest challenge HP faced in speeding up product delivery?
Raziel Tabib: We had to cope with the challenge of bringing transparency across the organization. Agile is about breaking the silence between QA [quality assurance] and dev[elopement]; but not only QA and dev, it's also breaking the silence between apps and ops, between the development and the business and development and marketing.
One way we've broken the silence is by using Application Lifecycle Intelligence, pulling together the data the team generates while working, writing code and implementing the product. This data is being captured in so many systems. By automating the process of capturing this data, digesting the data and understanding the association between the data, we can use analytics to give us a high level of transparency. For example, surface reports tell QA exactly where the risks are and where they need to focus when they do casting.
How does automating analytics help Agile development teams in daily work?
Tabib: It can help in a daily meeting. We don't have to go through asking what everyone has been doing and where he thinks the risk comes, because we actually have the report showing this. We are all immediately on the same page and can discuss just the things that we suspect are important or urgent.
We see mobility within every customer's business. Don't think your business is different.
director of products, HP Software
All of this information helps our meetings be efficient. These metrics help development teams [communicate more effectively with] marketing. At any point in time, marketing can see what is in the pipeline, what has just been released and what is going to be released. The same goes for operations and testing. The metrics help QA leads see which defect has been fixed. We're all connected to the issue tracking system.
Could you give an example of a report that HP Agile development teams use?
Tabib: Velocity reports tell us not just the velocities of each phase of the project. One iteration gets 25 story points, and then the next new sprint is 22 or 18. It's good to know when it's going up and down. Then, your team can ask why team velocity went down, and other automatic reports can help with data on escalations, user stories, re-factoring and so on. Everyone has all the background data even before the meeting, so we can understand where velocity is and some areas where improvement would get the velocity back in shape.
What common mistakes are made in Agile development?
Tabib: Initially, it's a mistake for organizations to not recognize that Agile is a completely new delivery practice, and moving into Agile should not only take place in the development organization. The buy-in should be driven by the highest-level people in the business.
Business has to break that wall between the apps developers and everyone else. There has to be an understanding that ops people are more in line with the apps today, with understanding what is being put into production. Marketing is part of the delivery chain and has to adjust the way they work with the dev team, [especially on] what is about to be released in the next month and what new messages will be marketed.
Another common mistake is undoing everything when you adopt Agile; dropping all the experience you had so far with respect to measuring the quality, measuring a lot of effectiveness of the teams and so on.
One of the common mistakes again is when you scale out Agile projects, you scale out the development, and you don't scale out on the ecosystem of the development team.
Finally, Agile is not all or nothing. We still do a lot of what we call Water-Scrum-Fall, lending some of the good practices we had within Waterfall with respects to analytics and so on, and blending it into the Agile practices. The mix makes development more robust.
A common mistake I hear about is Agile developers leaping into coding before application requirements are gathered and analyzed. Have you seen that happening?
Tabib: Obviously there is a fundamental shift with the way requirements are being managed in Agile. Part of that is getting developers in the mindset that Agile is not just a development process; it's a team process involving the business product owner, the project manager, users and so on. The team plans what to implement in the course of the next six months or more, and then breaks down things based on the business, the user and other non-development priorities. That's a change in the way we've worked with requirements.
How are mobile applications changing software development?
Tabib: We see mobility within every customer's business. Don't think your business is different. You have to start looking at what is your mobile story for customers, whether they're internal consumers of their IT services or external customers.
Mobile application development adds another layer of complexity to what we've discussed so far. The mobile teams are coming into Agile, working on a new set of technologies. But again, mobile has to be looked at as a comprehensive solution. Mobile is not only about building the apps on the device; it's building all the back end. That brings another level of collaboration between the mobile teams and the people who are building on the server-side and supporting all the systems.
Do you have a question or comment about using metrics in Agile development or Agile mobile development for Raziel Tabib or another SearchSoftwareQuality resident expert? Get a response by writing to site editor James Denman at firstname.lastname@example.org.